Re: Possible bug in Git

On Thu, Apr 15, 2010 at 8:06 PM, Avery Pennarun [off-list ref] wrote:

On Thu, Apr 15, 2010 at 8:01 PM, Junio C Hamano [off-list ref] wrote:

quoted

Avery Pennarun [off-list ref] writes:

quoted

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:

quoted

quoted

quoted

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