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

[Marius Storm-Olsen <marius@trolltech.com>]

Junio C Hamano wrote:
> Marius Storm-Olsen <marius@trolltech.com> 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