On Wed, 19 Apr 2006 16:57:49 -0700, Junio C Hamano wrote: > > I suspect this is just a misunderstanding caused by insufficient > explanation, so let's try this a bit differently. Junio, Thanks for the careful explanation. > With the patch applied (or use "next" branch I'll be pushing out > shortly), let's try the core-tutorial example up to the point > where we need to make a merge commit and get conflict. Heh. We dropped back to the identical example with our crossed-in-flight messages. > But later (much later) we find out that there was something > wrong with this hand-resolve and now we would want to fix it. > The new command, "git unresolve" is designed to help us exactly > in this situation: Yes. And this was in fact the question I had asked in IRC. How to get the diff again when I realize the file I updated is wrong. And as you point out, git-unresolve does just the trick here. The question I asked in my latest message is basically just "Shouldn't there be a way to get the diff from the several parents to the index?". That's slightly different, but it is the functionality I was looking for when I was trying to recover from my update-of-botched-merge. And its useful separately as part of the pre-commit-review I've said I always want to be able to do, (and as you designed "git status -v" to provide). So there's the final piece I'd like here. I think "git status -a -v" should provide a multi-parent diff when merging, as should "git status -v" after manually doing an update-index while merging. -Carl
Attachment:
pgpfkiLbFwEuE.pgp
Description: PGP signature