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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
