Why does git-bisect need to be run from the top level directory of the working tree?

Question

If someone is trying to run any of the git-bisect commands from anywhere other than the repository root directory, it says:

You need to run this command from the top level of the working tree.

Why? I don't know of any other git command that has this requirement, and I see no obvious reason why bisect should be special. The manual page does not mention this restriction.

It really doesn't matter. I'm basically just curious.

Answer 1

Looking at some of the commits in the project, I see it by Marcel M. Carey ([e-mail])

It talks in commit (this is about git-pull, but I think it matters)

"git pull" does not work because POSIX shells have an idea of ​​the current directory operation, other than getcwd (). The shell stores this path in PWD. As a result, "cd ../" can be interpreted differently in a shell script than chdir ("../") in a C program. The shell interprets "../", essentially cutting off the last component of the text path from PWD, then like C chdir () follows the link ".." in the current directory in the file system. When PWD is a symbolic link, these are different directions. As a result, Git C teams find the right top-level working tree and no shell scripts.

https://github.com/git/git/commit/08fc0608657ee91bc85276667804c36a93138c7d

SO I would say that part of the reason is due to the fact that git-bisect is a shell script that cannot be trusted to independently find the full level (when using symbolic links).

Answer 2

The bisection process should check for different versions of your project. If a specific revision does not contain the current folder, then the current folder will be deleted.

In this case, your shell may appear in a folder that is no longer in the file system! Git will not be able to find the top level .git folder, and therefore the bisect process cannot continue without intervention.

Demonstration:

 $ git rev-parse --show-toplevel /path/to/project $ mkdir tmp $ cd tmp $ rmdir ../tmp $ git rev-parse --show-toplevel fatal: Unable to read current working directory: No such file or directory 

Of course, the same problem can occur when doing git checkout , and it can be easily fixed after the fact, for example. with cd .. (willoller explains why this works in the shell but not in git).

But since deactivation is a process, it makes sense to avoid this situation before we start, especially if we want to use automation like git bisect run .

Answer 3

As a result, Git C commands find the correct top-level working tree, but shell scripts do not.

So, with Git 2.21 (February 2019), git bisect continues the transition from a shell script to C.

See commit 06f5608 , commit 450ebb7 , commit 129a6cf , commit 4fbdbd5 , commit e3b1e3b , commit 0f30233 , commit 5e82c3d (January 2, 2019) from Pranit Bauva ( pranitbauva1997 ) .
jeffhostetler : Ramsey Jones ( jeffhostetler ) and Stefan Beyer ( sbeyer ) .
^{(Combined Junio ​​C Hamano - gitster - in commit 09a9c1f , February 7, 2019)}

bisect - helper: bisect_start shell bisect_start partially in C

bisect_start shell function is partially in C and add the bisect-start subcommand to git bisect--helper to call it from git-bisect.sh.

The last part is not converted, because it calls another shell function. bisect_start shell bisect_start will be completed after bisect_next shell function bisect_next in C.

This is not complete yet, but a side effect of this migration will be the ability to execute git bisect from a subfolder.

---

Git 2.23 further improves this conversion to C.
See Commit 7877ac3 (May 21, 2019) by Johannes dscho ( dscho ) .
^{(Combined Junio ​​C Hamano - gitster - in commit 5b476dc , June 17, 2019)}