Add git-unresolve <paths>...
authorJunio C Hamano <junkio@cox.net>
Wed, 19 Apr 2006 19:51:29 +0000 (12:51 -0700)
committerJunio C Hamano <junkio@cox.net>
Wed, 19 Apr 2006 23:12:41 +0000 (16:12 -0700)
commitec167793d84ba7b765e1eb71b0257ce7baca2d26
tree4697a60096028302f244bc723a1044e4147010ea
parenta4d0cced53facb17d777a396aa6b388e97f1d909
Add git-unresolve <paths>...

This is an attempt to address the issue raised on #git channel
recently by Carl Worth.

After a conflicted automerge, "git diff" shows a combined diff
to give you how the tentative automerge result differs from
what came from each branch.  During a complex merge, it is
tempting to be able to resolve a few paths at a time, mark
them "I've dealt with them" with git-update-index to unclutter
the next "git diff" output, and keep going.  However, when the
final result does not compile or otherwise found to be a
mismerge, the workflow to fix the mismerged paths suddenly
changes to "git diff HEAD -- path" (to get a diff from our
HEAD before merging) and "git diff MERGE_HEAD -- path" (to get
a diff from theirs), and it cannot show the combined anymore.

With git-unresolve <paths>..., the versions from our branch and
their branch for specified blobs are placed in stage #2 and
stage #3, without touching the working tree files.  This gives
you the combined diff back for easier review, along with
"diff --ours" and "diff --theirs".

One thing it does not do is to place the base in stage #1; this
means "diff --base" would behave differently between the run
immediately after a conflicted three-way merge, and the run
after an update-index by mistake followed by a git-unresolve.

We could theoretically run merge-base between HEAD and
MERGE_HEAD to find which tree to place in stage #1, but
reviewing "diff --base" is not that useful so....

Signed-off-by: Junio C Hamano <junkio@cox.net>
.gitignore
Makefile
unresolve.c [new file with mode: 0644]