Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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

Tags:

git

git-bisect

If one tries to run any of the git-bisect commands from anywhere other than the root directory of the repository, one is told:

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

Why is that? I know of no other git command that has this requirement, and I see no obvious reason that bisect should be special. The man page makes no mention of this restriction, either.

It's really not a big deal. I'm mostly just curious.

like image 820
Parker Coates Avatar asked Sep 18 '12 15:09

Parker Coates


People also ask

How does git bisect work?

git bisect performs a binary search to find the faulty commit. Git bisect requires the user to input the “good” commit and the “bad” commit, and then performs a binary search on the commits, starting with the commit that is at the midpoint between the “good” and “bad” commit.

What is git bisect how can you use it to determine the source of a regression bug?

The git bisect command is a fantastic tool that can help you determine which commit introduced the bug. A regression bug is a specific type of software bug that prevents a feature or software from working when it was working before the bug was introduced. Just remember, git bisect won't "fix" the broken commit for you.

How do I remove a bad commit in git bisect?

Use git log to check the previous commits. Use Git Bisect to find the commit in which line 2 is changed from 'b = 20' to 'b = 0.00000'. Remove the bad commit by using Git Revert. Leave the commit message as is.


2 Answers

Looking at some commits in the project, I see one by Marcel M. Cary ([email protected])

He says in a commit (it happens to be about git-pull but I think it is relevant)

"git pull" fails because POSIX shells have a notion of current working directory that is different from 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 "../" by essentially stripping the last textual path component from PWD, whereas C chdir() follows the ".." link in the current directory on the filesystem. When PWD is a symlink, these are different destinations. As a result, Git's C commands find the correct top-level working tree, and shell scripts do not.

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

SO I'd say part of the reason is because git-bisect is a shell script which can't be trusted to find the toplevel on its own (when symlinks are involved).

like image 184
willoller Avatar answered Oct 20 '22 20:10

willoller


The bisecting process needs to check out different revisions of your project. If a particular revision does not contain the current folder, then the current folder will be removed.

In that case, your shell could end up sitting in a folder which is no longer on the filesystem! Git will then be unable to find the toplevel's .git folder and so the bisect process cannot continue without intervention.

A 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 this same problem can occur when doing git checkout, and it can be easily fixed after the fact, e.g. with cd .. (willoller explains why that works in the shell but not in git).

But since bisecting is a process it makes sense to avoid this situation before we begin, especially if we want to use automation such as git bisect run.

like image 44
joeytwiddle Avatar answered Oct 20 '22 19:10

joeytwiddle