On Thu, Apr 15, 2010 at 6:47 AM, David Martínez Martí <desarrollo@xxxxxxxxxxxx> 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@xxxxxxxxxxxx> 1260959309 +0100 > committer David Martinez Marti <desarrollo@xxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html