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