3

I ran into a strange issue when trying to use git-bisect to find a particular change in the jquery git repository: the bisect command seems to create modified files that prevent the bisect process from continuing. These are the commands I ran first:

git clone https://github.com/jquery/jquery.git
cd jquery
git bisect start
git bisect bad
git bisect good 2aa67026ebe6bea90fd137fc99b4c9422977e3f0

At which point I get the output:

Bisecting: 1977 revisions left to test after this (roughly 11 steps)
[3e5520fbdc7231b3f38e145020b40524c1e6654d] Tagging the 1.4.3rc2 release.

But now, when I run git status, the output is:

# Not currently on any branch.
# You are currently bisecting.
#    (use "git bisect reset" to get back to the original branch)
#
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   build/google-compiler-20091218.jar
#   modified:   build/js.jar
#   modified:   test/data/text.php
#   modified:   test/delegatetest.html
#

Four files show up as modified. If I then run git bisect bad, I get an error saying that my local changes would be overwritten by checkout.

Am I doing something wrong or misunderstanding how git-bisect works? Any workarounds for this issue? Thanks!

msridhar
  • 2,846
  • 4
  • 22
  • 23

4 Answers4

0

You probably shoud enter the git bisect reset HEAD command to clean up the bisection state and return to the original HEAD

Maxime
  • 1,776
  • 1
  • 16
  • 29
  • 2
    Thanks for the answer! My goal, however, is to get the bisection to actually work, not to return to HEAD. Or am I misunderstanding? – msridhar Oct 02 '12 at 19:37
  • Hey :) I might be wrong but I think git bisect is used to find out which commit caused the regression. Once you find it, the bisection job is done and you have to patch the HEAD accordingly to what you saw. – Maxime Oct 04 '12 at 11:34
  • 1
    Ah, so the issue is that the bisection job is not done. In the above example I've only done the first run (you can see in the git output that there are roughly 11 steps left). The problem is the process gets stuck due to modified files, but I didn't modify anything. – msridhar Oct 05 '12 at 14:14
0

I expect that your gitignore file has changed between the two revisions so that git now thinks those 4 files are different to what it expects.

Try a `git diff' (man page) with the appropriate option such as --cached for your gitignore, exclude files and those modified files.

Philip Oakley
  • 13,333
  • 9
  • 48
  • 71
0

In addition to .gitignore changes, you can also get this if you have some other process running that keeps generating these files.

jackr
  • 1,407
  • 1
  • 14
  • 29
0

It looks to me as if those files are being autogenerated by a watcher of some description when a parent file changes.

So as soon as git checks out a commit that changes one of their parents, the new files are generated. When you try to take the next bisect, they would be overwritten by the new commit. Git won't allow that to happen by default, and so cancels the bisect.

The solution is to remove the generated files. Most of the time I've found the following to work:

git stash
git stash drop

However, in the repo I'm working on at the moment, it seems that's not doing the business. Instead I'm having to add them to the staged changes area of the repo, and then reset the staged changes area to HEAD to get rid of them with the following

git add .
git reset --hard HEAD

After which bisect works normally - at least until a commit changes whatever files are creating them and they get regenerated again.

piersb
  • 609
  • 9
  • 22