On Thu, May 21, 2015 at 08:58:35PM +0100, Philip Oakley wrote:
> From: "Philippe De Muyter" <[email protected]>
> To: "Junio C Hamano" <[email protected]>
> Cc: <[email protected]>; "Jeff King" <[email protected]>; "John Keeping"
> <[email protected]>
> 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 <[email protected]> writes:
>>>
>>> > On Tue, May 19, 2015 at 09:01:10AM -0700, Junio C Hamano wrote:
>>> >> Philippe De Muyter <[email protected]> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
