Re: Possible bug in Git
- From
Avery Pennarun <apenwarr@gmail.com>
- Date
- Apr 16, 2010, 00:13 UTC
- Message-ID
- <k2n32541b131004151713s51498b01s34c5a95c0f360901@mail.gmail.com>
- In-Reply-To
- <o2m32541b131004151706hb48a0d04yf7fa4238d423a4e3@mail.gmail.com>
On Thu, Apr 15, 2010 at 8:06 PM, Avery Pennarun <apenwarr@gmail.com> wrote:
Show 26 quoted lines
> 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