Thread (4 messages) flat view 4 messages, 4 authors, 2016-06-15

Re: [PATCH 0/2] Respecting core.autocrlf when showing objects

From: Marius Storm-Olsen <hidden>
Date: 2016-06-15 22:44:44

Possibly related (same subject, not in this thread)

Junio C Hamano wrote:
Marius Storm-Olsen [off-list ref] writes:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help