On Thu, Apr 15, 2010 at 8:06 PM, Avery Pennarun <apenwarr@xxxxxxxxx> wrote: > On Thu, Apr 15, 2010 at 8:01 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> Avery Pennarun <apenwarr@xxxxxxxxx> 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 -- 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