diff options
author | Junio C Hamano <junkio@cox.net> | 2006-04-19 12:51:29 -0700 |
---|---|---|
committer | Junio C Hamano <junkio@cox.net> | 2006-04-19 16:12:41 -0700 |
commit | ec167793d84ba7b765e1eb71b0257ce7baca2d26 (patch) | |
tree | 4697a60096028302f244bc723a1044e4147010ea /git-applymbox.sh | |
parent | Merge branch 'lt/xsha1' (diff) | |
download | tgif-ec167793d84ba7b765e1eb71b0257ce7baca2d26.tar.xz |
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>
Diffstat (limited to 'git-applymbox.sh')
0 files changed, 0 insertions, 0 deletions