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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html