Re: Possible bug in Git

[Avery Pennarun <apenwarr@gmail.com>]

On Thu, Apr 15, 2010 at 6:47 AM, David Martínez Martí
<desarrollo@gestiweb.com> wrote:
> $ git show dac6a95f5 -p --pretty=raw --
> facturacion/facturacion/scripts/lineasfacturascli.qs
> commit dac6a95f559604978ff9e1fac24ad752c54382ae
> tree f1472f1d289f9813df5fd691c9cea6ccb04313a7
> parent 5dfdd78f24f4578cdfeed876b8bacb45790af9ef
> parent 6ed54c8c6508b6d5551290b45785eaf44dd05d75
> author David Martinez Marti <desarrollo@gestiweb.com> 1260959309 +0100
> committer David Martinez Marti <desarrollo@gestiweb.com> 1260959309 +0100
>
>    Merge remote branch 'origin/infosial'
>
>    Conflicts:
>       [...]
>    [empty diff]
>
> There was a conflict on that file but it doesn't show anything changed about
> it. Gitk does the same.

You're trying to show the log of a merge commit.  git tries to be
clever about showing diffs on such commits, but it screws up rather
too often to be reliable, and this bites a lot of people (including
myself).

The core of the problem is this: if you're looking at 'git log -p',
you'll see all the individual commits.  But a merge commit is
essentially a combination of all the commits on branch #2 as you add
them to branch #1.  (Or alternatively: all the commits on branch #1 as
you add them to branch #2.)  So if git did the obvious thing and just
showed the *entire* diff that the merge applies to branch #1, it would
be a big long patch, but worse, it would be *equivalent* to the
patches you've already seen from other individual commits.

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.  Unfortunately, actually calculating that would be really
complicated; it would require redoing the whole merge just to find out
what happened, and that turns out to be too slow.  So git uses
heuristics to try to guess what happened, and those heuristics don't
always work out.  In your case, it seems to have decided that "nothing
special happened" during the merge even though apparently the file was
entirely blanked out, which seems obviously wrong to me, but I don't
actually know how the heuristics work.

The "git log" options -c and --cc are documented (in 'man git-log') as
supposedly affecting this behaviour.  However, it seems that "--cc"
became the default somehow, and there's no obvious way to turn it back
to the "supposedly default" plain or -c behaviour.  Maybe someone else
on the list can comment more.

Have fun,

Avery