Re: Possible bug in Git

[Avery Pennarun <apenwarr@gmail.com>]

On Thu, Apr 15, 2010 at 8:06 PM, Avery Pennarun <apenwarr@gmail.com> wrote:
> On Thu, Apr 15, 2010 at 8:01 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Avery Pennarun <apenwarr@gmail.com> writes:
>>
>>> So what git tries to do is reduce the diff output of a merge commit
>>> down to just the "unexpected" parts: the parts that are different from
>>> what you'd get if you just merged in the individual changes in the
>>> obvious way.
>>
>> This (and everything you said after this paragraph) is not quite correct.
>> What is shown is the pieces that do not match either of the parent.
>>
>> So if you have a conflicted merge and resolve it by taking what one side
>> did literally (think: "merge -X ours"), that hunk becomes uninteresting
>> because the end result matches what one of the parents had.
>
> Hmm, but David also said:
>
>>>> git show commit:path shows empty file:
>>>> $ git show dac6a95f5:facturacion/facturacion/scripts/lineasfacturascli.qs | wc
>>>>     0       0       0
>
> The output seems to match neither parent in any way, and yet the
> simplification has resulted in no diff at all.  Strange, no?
>
> Avery
>

 mkdir testy
 cd testy
 git init
 cp /etc/profile .
 git add profile
 git commit -m root
 git checkout -b a master
 cat /etc/profile >>profile
 git commit -a -m test1
 git checkout -b b master
 cat /etc/profile | tr A-Za-z a-zA-Z >profile
 git commit -a -m test1b
 git merge a
   # produces a conflict
 true >profile   # blank the file
 git commit -a -m resolved
 git show HEAD:profile
   # no output

Note that if you instead replace the file with a nonempty (but
different) file, you get something appropriate as the output.

Have fun,

Avery