# RE: Fatal error from git bisect

2 messages from 2006-02-09 to 2006-02-09. Participants: Mark E Mason, Linus Torvalds.
Thread: https://gitlist.dev/t/3276

## Mark E Mason, 2006-02-09 19:59

Subject: RE: Fatal error from git bisect
Message-ID: <7E000E7F06B05C49BDBB769ADAF44D0773A4A8@NT-SJCA-0750.brcm.ad.broadcom.com>
URL: https://gitlist.dev/e/7E000E7F06B05C49BDBB769ADAF44D0773A4A8%40NT-SJCA-0750.brcm.ad.broadcom.com

```
Hello!
 
> From: Linus Torvalds [mailto:torvalds@osdl.org] 
[snip]
> On Thu, 9 Feb 2006, Mark E Mason wrote:
> >  
> > I'm trying to use 'git bisect' and am running into the 
> following error:
> >
> > fatal: Entry 'block/elevator.c' would be overwritten by 
> merge. Cannot merge.
> 
> This seems to mean that you have a dirty block/elevator.c 
> file. Have you perhaps edited it?

I thought of that, but even removing the workspace file doesn't get
around this:

[mason@hawaii linux.git]$ git bisect reset
[mason@hawaii linux.git]$ git bisect start
[mason@hawaii linux.git]$ git bisect good
d166b5a220813a08a79312fc384d11e1c57e9072
[mason@hawaii linux.git]$ git bisect bad
a7900c9bdb64c11688719bef9f6373fbc4c276ab
Bisecting: 116 revisions left to test after this
fatal: Entry 'block/elevator.c' would be overwritten by merge. Cannot
merge.
[mason@hawaii linux.git]$ rm block/elevator.c
[mason@hawaii linux.git]$ git bisect bad
a7900c9bdb64c11688719bef9f6373fbc4c276ab
Bisecting: 116 revisions left to test after this
fatal: Entry 'block/elevator.c' would be overwritten by merge. Cannot
merge.

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.

Thanks!
Mark



 

```

## Linus Torvalds, 2006-02-09 20:16

Subject: RE: Fatal error from git bisect
Message-ID: <Pine.LNX.4.64.0602091210230.2458@g5.osdl.org>
URL: https://gitlist.dev/e/Pine.LNX.4.64.0602091210230.2458%40g5.osdl.org
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

```