git and bzr

Linus Torvalds torvalds at osdl.org
Tue Nov 28 22:41:31 GMT 2006



On Tue, 28 Nov 2006, Linus Torvalds wrote:
> On Tue, 28 Nov 2006, Nicholas Allen wrote:
> > 
> > All useful conflict status is lost isn't it?
> 
> No, it's actually there, but "git status" doesn't really explain it to 
> you.

Side note, to clarify: in the _simple_ cases it's all actually there.

I can well imagine that in more complex cases, involving multiple 
different files, you may well want to re-do the merge and let the merge 
tell you why it refused to merge something.

So the index, for example, contains just a "final end result" of what the 
merge gave up on, and while for a simple rename conflict like your example 
you could certainly see that directly from the index state (and thus we 
could, for example, have a "git status" that talks about it being a 
filename conflict), if you have a criss-cross rename, the index itself 
doesn't really tell you _why_, and it could look superficially like a data 
conflict. 

In such a case, you'd really have to either go back to the merge itself to 
see what happened, or you'd use the "git log" thing and just work it out 
from there (ie you can ask "git log" to tell you about any renames as they 
happened etc).

I don't think I've actually hit a complex enough merge to need this yet, 
but the graphical tools should help too, ie "gitk --merge" should give you 
everything that "git log --merge" gives you (ie just the commits that 
aren't common, and simplified to just the ones that matter for the 
unmerged filenames in the end result). I can well imagine that being 
useful too.

So the tools are certainly there. "git status" just isn't necessarily the 
best one (or the best that it could be, for that matter)..

			Linus




More information about the bazaar mailing list