I'd suggest just re-doing the merge. Something like
git reset --hard
git merge -m "dummy message" MERGE_HEAD
will do it for you (that's the new "nicer syntax" for doing a merge, in
real life I'd personally just have done a re-pull or somehing)
No, it's actually there, but "git status" doesn't really explain it to
you.
The go-to command tends to be "git diff", which after a merge will not
show anything that already merged correctly (because it will have been
updated in the git index _and_ updated in the working tree, so there will
be no diff from stuff that auto-merged). So any output at all after a
failed merge from "git diff" generally tells you exactly what failed.
But since 99%+ of all merge conflicts are data-conflicts, I suspect the
output is mostly geared towards that.
The other useful tools to be used are "git log --merge" (explained in a
separate mail) and for people like me who like the git index and grok it
fully, doing a
git ls-files --unmerged --stage
is probably what I'd do (but I have to admit, that is _not_ a very
user-friendly interface - you need to not only have understood the index
file, you actually need to understand it on a very deep level).
"git status" is really used to be just a stupid around "git ls-files"
(it's now largely a built-in), but it was really _so_ stupid that it
doesn't really try to explain what it does - it's more like a simplified
version of ls-files with some of the information pruned away, and other
parts in a slightly more palatable format ;)
So improving "git status" might mean that some people could avoid having
to learn about the index file details ;)
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
