Re: identical hashes on two branches, but holes in git log

[Philippe De Muyter <phdm@macq.eu>]

On Thu, May 21, 2015 at 08:58:35PM +0100, Philip Oakley wrote:
> From: "Philippe De Muyter" <phdm@macq.eu>
> To: "Junio C Hamano" <gitster@pobox.com>
> Cc: <git@vger.kernel.org>; "Jeff King" <peff@peff.net>; "John Keeping" 
> <john@keeping.me.uk>
> Sent: Thursday, May 21, 2015 8:15 AM
> Subject: Re: identical hashes on two branches, but holes in git log
>
>
>> On Tue, May 19, 2015 at 03:12:31PM -0700, Junio C Hamano wrote:
>>> Philippe De Muyter <phdm@macq.eu> writes:
>>>
>>> > On Tue, May 19, 2015 at 09:01:10AM -0700, Junio C Hamano wrote:
>>> >> Philippe De Muyter <phdm@macq.eu> writes:
>>> >>
>>> >> > Trying to understand, I have eventually done "git log" on my >> > 
>>> branch and
>>> >> > on v3.15 with the following commands :
>>> >> >
>>> >> > git log v3.15 --full-history --decorate=short | grep '^commit' > >> 
>>> > /tmp/3.15.commits
>>> >> > git log --full-history --decorate=short | grep '^commit' > >> > 
>>> /tmp/mybranch.commits
>>> >>
>>> >> Either
>>> >>
>>> >>     git log --oneline v3.15..HEAD ;# show what I have not in >> theirs
>>> >>
>>> >> or
>>> >>
>>> >>     gitk v3.15...HEAD ;# show our differences graphically
>>> >
>>> > This shows the commits in my branch starting from the most recent > 
>>> common point,
>>> > thus my commits, but I see differences in the files not explained > by 
>>> my commits,
>>> > but by the fact that many older commits (between v3.13 and v3.14) > are 
>>> missing on
>>> > my branch, but still in both branches I have a commit called v3.14 > 
>>> with the
>>> > same hash.  Is that normal ?
>>>
>>> Sorry, cannot parse.  Neither of the above would show files, so just
>>> about the place where you start talking about "I see differences in
>>> the files", you lost me.
>>
>> Look at the other part of the thread, with the discussion with Jeff and 
>> John
>>
>> The light has come, and what I understand is:
>>
>> don't trust the default (ordering) mode of 'git log' :(
>
>
> Surely the question now should be "What should the man page say that would 
> have explained the default ordering mode in an understandable way, rather 
> than the current misunderstanding?".
>
> What 'ordering' were you 'trusting' (presuming) anyway? The current default 
> mode doesn't actually say anything about the order anyway (as you've 
> discovered).

I have used 'git log' on the current 'master' branch of the linux kernel
to find at which point in the history a commit - that I know is disruptive
for my work and that I know by name because I have seen it passing on a
mailing list - had been applied.

'git log -decorate=short' showed it happening between v3.14-rc1 and v3.14-rc2,
but after

	git checkout v3.14

I did not find the effects of the commit in the files that should have been
affected by the commit.

I expected at least that a commit listed between two tags on the same branch
was really applied to that branch between those two tags.

Philippe
>
>>
>> I surmise this happens only when 'git merge' has been used.
>>
> --
> Philip