Junio C Hamano wrote:
Marius Storm-Olsen <marius@xxxxxxxxxxxxx> writes:
Uhm, 'git checkout side file.txt' is not the same file content
(ignoring EOLs please) as 'git show :3:file.txt'. Ref:
user-manual.html#conflict-resolution
Bruce, I think the comment in this quoted section is wrong.
True, the combined diff can show only the interesting differences
between the three, but that is not because we munge stage #2 and #3.
They contain verbatim copies from the HEAD and the MERGE_HEAD
respectively, and the combining logic runs three-way diffs between
the three stages to discard the hunks that the result comes solely
from either stage #2 or stage #3.
...
-Since the stage 2 and stage 3 versions have already been updated
with -nonconflicting changes, the only remaining differences between
them are -the important ones; thus linkgit:git-diff[1] can use the
information in -the index to show only those conflicts. +When you ask
linkgit:git-diff[1] to show the conflicts, it runs a +three-way diff
between the conflicted merge results in the work tree with +stages 2
and 3 to show only hunks whose contents come from both sides, +mixed
(in other words, when a hunk's merge results come only from stage 2,
+that part is not conflicting and is not shown. Same for stage 3).
Aah, that certainly clears things up a bit. A good patch I'd say.
However, it doesn't change the fact that IMO "git show" should respect
core.autocrlf, while "git cat-file" shouldn't.
I think many would consider
git show MERGE_HEAD:file.txt > file.txt
before
git checkout MERGE_HEAD file.txt
if only because they'd be scared to do a "checkout" in the middle of a
merge conflict.
Personally I think the latter is nice, short and sweet, but that doesn't
mean that it's less scary for people staring out on git. The fact that
the two commands above are *not* identical in result, are the kind of
things that we need to iron out, to make git more accessible to the
general public.
--
.marius
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
