From: Linus Torvalds Date: Thu, 09 Feb 2006 20:16:10 GMT Subject: RE: Fatal error from git bisect Message-ID: In-Reply-To: <7E000E7F06B05C49BDBB769ADAF44D0773A4A8@NT-SJCA-0750.brcm.ad.broadcom.com> On Thu, 9 Feb 2006, Mark E Mason wrote: > > I thought of that, but even removing the workspace file doesn't get > around this: That doesn't necessarily help. Removing the workspace file potentially just makes the workspace even _more_ dirty, rather than less. It makes git think you've edited the file that it wants to check out another verion of. (Of course, an extra file can _also_ be a sign of being dirty, so sometimes removing such a file _does_ generate a "more clean" tree). Basically, "dirty" means that it doesn't match the head commit. > I've made no commits to this tree - it's just an up-to-date pull of the > linux-mips.org tree. I also have no local edits at this point. > > [mason@hawaii linux.git]$ git diff > [mason@hawaii linux.git]$ > > What's puzzling me is that (as I understand it) git bisect simply > manipulates the workspace, not the repository. Well, it doesn't _change_ the repository, but it does move around in it, using "git-read-tree -u -m". That can error out if the old tree and the new tree differs in a particular file, and the workspace doesn't match the old tree in that file. Now, it could be a git bug, but before you go there, try to make sure tat your tree is really clean. Do a git checkout -f master followed by "git status" to make sure that the workspace is clean (no unexpected untracked files, no diffs against HEAD, no nothing). The "git checkout -f master" should have cleaned everything up, but it won't actually touch extra files that it doesn't know about, so.. Linus