Junio C Hamano <junkio@cox.net> writes: > linux@horizon.com writes: > >> I'm wondering if this isn't a philosophical issue. > > I do not think so.... > ... > This is the message from Linus that announced the current > behaviour: > > http://marc.theaimsgroup.com/?l=git&m=111826424425624 Replying to myself. In the message, Linus talks about being able to do (diff-cache is an old name for diff-index): git-diff-files -p xyzzy ;# to compare with our version git-diff-cache -p MERGE_HEAD xyzzy ;# to compare with his But because of the "index before merge has to match HEAD" rule, the first one could have been written as: git-diff-index -p HEAD xyzzy ;# to compare with ours So in that sense, I suspect it may not be too bad if we just changed merge-one-file with the patch at the end. However, git-diff-index HEAD without paths restriction would show everything the merge brought in, not just the conflicting path, so in that sense it may make things slightly harder for the end user to use. --- diff --git a/git-merge-one-file.sh b/git-merge-one-file.sh index c3eca8b..df6dd67 100755 --- a/git-merge-one-file.sh +++ b/git-merge-one-file.sh @@ -79,11 +79,12 @@ case "${1:-.}${2:-.}${3:-.}" in ;; esac - # We reset the index to the first branch, making - # git-diff-file useful - git-update-index --add --cacheinfo "$6" "$2" "$4" - git-checkout-index -u -f -- "$4" && - merge "$4" "$orig" "$src2" + # Leave the conflicts in stages; failed merge result can be + # seen by "git-diff-index HEAD" or "git-diff-index MERGE_HEAD" + rm -fr "$4" && + git-cat-file blob "$2" >"$4" && + case "$6" in *?7??) chmod +x "$4" ;; esac && + merge "$4" "$orig" "$src2" ret=$? rm -f -- "$orig" "$src2" - 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.htmlReceived on Wed Nov 30 12:27:53 2005
This archive was generated by hypermail 2.1.8 : 2005-11-30 12:28:01 EST