Panic when starting from subfolder

[savchenko]

Describe the bug
gitui crashes.

To Reproduce
Unreproducible. Roughly: several different origins and branches. Some branches exist only on remotes.

I am now able to reproduce this reliably when HEAD is out of sync with remotes and gitui is launched from a subfolder instead of from the git rev-parse --show-toplevel.

* 0000000 - (2 minutes ago) ______ ____________, ___ ______ ___________ (HEAD)
* 0000000 - (3 minutes ago) ____ ____ ______ ____ `______` __ `____` __
* 0000000 - (2 days ago) ___________ `__________()`
* 0000000 - (2 days ago) ______ ______
* 0000000 - (2 days ago) _______ ________, ____ _________ _______
| *-.   0000000 - (3 days ago) __ ______: ___ ___________ (refs/stash)
| |\ \  
| | | * 0000000 - (3 days ago) untracked files on master: d3713ed [WIP] ___________, ___'_____ _______ ___ _________
| | * 0000000 - (3 days ago) _____ __ ______: d3713ed [WIP] ___________, ___'_____ _______ ___ _________
| |/  
| * d3713ed - (3 days ago) [WIP] ___________, _____ ___ _______ ___ _________ (master)
|/  
* 1234567 - (3 days ago) ______ ____________
* 0000000 - (3 days ago) ______ __ ___________
* 0000000 - (6 days ago) ______ `_________()` _________
* 0000000 - (6 days ago) ____.______._______ -> ____.______
* 0000000 - (7 days ago) _______ _______ ______ (origin/master, origin/HEAD)

Output of git status

git status
HEAD detached from 1234567
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   file1
	modified:   file2

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	file3

no changes added to commit (use "git add" and/or "git commit -a")

Setting branch to track the ref. via git checkout -B master doesn't help.

Expected behaviour
A clear and concise description of what you expected to happen.

Screenshots

GitUI was close due to an unexpected panic.
Please file an issue on https://github.com/extrawurst/gitui/issues with the following info:

PanicInfo { payload: Any { .. }, message: Some(failed to fetch: GixOpen(NotARepository { source: MissingHead, path: "." })), location: Location { file: "asyncgit/src/revlog.rs", line: 186, col: 14 }, can_unwind: true, force_no_backtrace: false }
trace:
   0: <unknown>
   1: <unknown>
   2: <unknown>
   3: <unknown>
   4: <unknown>
   5: <unknown>
   6: <unknown>
   7: <unknown>
   8: <unknown>
   9: <unknown>
  10: <unknown>
  11: <unknown>
  12: <unknown>
  13: start_thread
             at ./nptl/pthread_create.c:442:8
  14: __GI___clone3
             at ./misc/../sysdeps/unix/sysv/linux/x86_64/clone3.S:81


GitUI was close due to an unexpected panic.
Please file an issue on https://github.com/extrawurst/gitui/issues with the following info:

Any { .. }
trace:
   0: <unknown>
   1: <unknown>
   2: <unknown>
   3: <unknown>
   4: <unknown>
   5: <unknown>
   6: start_thread
             at ./nptl/pthread_create.c:442:8
   7: __GI___clone3
             at ./misc/../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Aborted (core dumped)

Context (please complete the following information):

• OS/Distro + Version: Debian 12, x64
• GitUI Version: gitui nightly 2024-07-27 (4ef633a)
• Rust version: rustc 1.76.0 (07dca489a 2024-02-04)

Additional context
N/A

[cruessler]

From what I can see, this is the location the innermost error happens:

https://github.com/GitoxideLabs/gitoxide/blob/dc8bd63f608d6704d76c2fd68d2a3c9d425ce1c8/gix-discover/src/is.rs#L74

The error is caused by the absence of .git/HEAD. Can you check whether this file is present in the repository?

I don’t have context yet on whether the absence of .git/HEAD should be treated as an error in this case.

[savchenko]

@cruessler , without .git/HEAD a repo won't be even recognised as such. That being said, I haven't observed this for a very long time, certainly not since v0.2.6+

[cruessler]

That matches what I know about that location. Initially, it was merged using gix::open and only later changed to gix::discover. The former only tries to find the .git directory in the current directory while the latter also traverses all the ancestors to search for a .git directory. The change was done in #2301.

[extrawurst]

so it probably a dupe of #2358