threads / discuss / 39367

identical hashes on two branches, but holes in git log

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

## tl;dr

15 messages between May 19, 2015 and May 21, 2015.

replies: 14people: 6as markdown or json

Philippe De Muyter· May 19, 2015, 13:29 UTC · lore
Hello,

I work on the linux kernel sources (with origin = linux-stable) and I have my local branch (the one with my local patches) supposedly based on v3.14. But actually if I invoke "git diff v3.14", I get much more diffs than my own patches.

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

I compare then the two histories with
diff -u /tmp/3.15.commits /tmp/mybranch.commits
and I get (excerpt) :

--- /tmp/3.15.commits 2015-05-19 13:19:59.665205514 +0200 +++ /tmp/mybranch.commits 2015-05-19 13:19:52.452081328 +0200

@@ -1,3780 +1,84 @@
-commit 1860e379875dfe7271c649058aeddffe5afd9d0d (tag: v3.15)
-commit ...
...
-commit fad01e866afdbe01a1f3ec06a39c3a8b9e197014 (tag: v3.15-rc8)
...
...
-commit c9eaa447e77efe77b7fa4c953bd62de8297fd6c5 (tag: v3.15-rc1)
...
-commit 57673c2b0baa900dddae3b9eb3d7748ebf550eb3
+commit a1fb433346cb5733945b5fc243f7334744bae4fd (HEAD, macq_boards-3.14.0)
+commit ...
...
+commit 2be7b20bbb337e0031e0f0d39c9a4845b6bbf3b8
 commit 455c6fdbd219161bd09b1165f11699d6d73de11c (tag: v3.14)	==== identical commit
-commit c32fc9c803f8ed90a7548810de48ca33a3020168		==== commit missing in my branch
 commit fedc1ed0f11be666de066b0c78443254736a942e		==== more identical commits
 commit 01358e562a8b97f50ec04025c009c71508e6d373
 commit 915ac4e26ef9c39a0f831e935509243732abedc0
@@ -3784,4289 +88,252 @@
 commit 0b1b901b5a98bb36943d10820efc796f7cd45ff3
 commit 1d6a32acd70ab18499829c0a9a5dbe2bace72a13
 commit 0818bf27c05b2de56c5b2bd08cfae2a939bd5f52
-commit 877e1f1529a5c4fcc8460c1317c753ff8a6874c5		==== more missing commits
-commit 57918dfadf717acf7d0488d5970c56a282d0aad1
-commit 86ea5e6b793d45fa7d2aa504ac3aefc813f0fd55
-commit a5dde0c72ccbb0f66b3491ee83f4c579aea0651d
-commit c7f6ee264b511d8a35063e9821cf36ad18e4e4fd
...
-commit c99abc8b39d8281dad04d771bb7a2de36fec4d9f
 commit b098d6726bbfb94c06d6e1097466187afddae61f (tag: v3.14-rc8) ==== more identical commits
 commit 822316461b15e0207e50ff661f9cf830af116e9f
 commit 56f1f4b24e8787d7ba794dbe2e949d504c054892
...

How is that possible (to have the same commit, with the same hash but
different ancestors), and how can I recover from that situation ?

I really would like to rebase my branch on v3.14, but it says it is already !

I have also done a 'git fsck'.  It has shown only 

Checking object directories: 100% (256/256), done.                                                                                         
Checking objects: 100% (4566799/4566799), done.                                                                                            
Checking connectivity: 4494119, done
dangling tree ...
dangling commit ...
dangling blob ...

This is with git version 1.7.10.4

TIA

Philippe

-- 
Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles
Junio C Hamano· May 19, 2015, 16:01 UTC · re: Philippe De Muyter · lore

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

Philippe De Muyter <phdm@macq.eu> writes:
Show 5 quoted lines
> 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

may give you a better picture than what you did, which was to artificially flatten the topology and lose the crucial information as to which commit is the parents of which other commit.

Philippe De Muyter· May 19, 2015, 21:47 UTC · re: Junio C Hamano · lore

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

On Tue, May 19, 2015 at 09:01:10AM -0700, Junio C Hamano wrote:
Show 15 quoted lines
> 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 ?

Philippe
Junio C Hamano· May 19, 2015, 22:12 UTC · re: Philippe De Muyter · lore

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

Philippe De Muyter <phdm@macq.eu> writes:
Show 22 quoted lines
> 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.

Philippe De Muyter· May 21, 2015, 07:15 UTC · re: Junio C Hamano · lore

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:
Show 28 quoted lines
> 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' :(
I surmise this happens only when 'git merge' has been used.
Philippe
Philip Oakley· May 21, 2015, 19:58 UTC · re: Philippe De Muyter · lore

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

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
Show 44 quoted lines
> 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 surmise this happens only when 'git merge' has been used.
>

-- Philip

Philippe De Muyter· May 21, 2015, 20:37 UTC · re: Philip Oakley · lore

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

On Thu, May 21, 2015 at 08:58:35PM +0100, Philip Oakley wrote:
Show 60 quoted lines
> 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
Show 6 quoted lines
>
>>
>> I surmise this happens only when 'git merge' has been used.
>>
> --
> Philip
Christian Couder· May 20, 2015, 07:39 UTC · re: Philippe De Muyter · lore

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

On Tue, May 19, 2015 at 11:47 PM, Philippe De Muyter <phdm@macq.eu> wrote:
Show 22 quoted lines
> 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 ?

As this is the linux kernel, maybe everything you are working on is open source and you can push it to a public git hosting service (like GitHub, BitBucket, ...), so people can have a look there or clone it from there?

(And if you do that it would help when talking about differences in some files, if you could tell which files and which commits, and maybe also which git commands you used.)

Jeff King· May 19, 2015, 23:39 UTC · re: Philippe De Muyter · lore

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

On Tue, May 19, 2015 at 03:29:58PM +0200, Philippe De Muyter wrote:
Show 28 quoted lines
> 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
> 
> I compare then the two histories with
> 
> diff -u /tmp/3.15.commits /tmp/mybranch.commits
> 
> and I get (excerpt) :
> 
> --- /tmp/3.15.commits      2015-05-19 13:19:59.665205514 +0200
> +++ /tmp/mybranch.commits     2015-05-19 13:19:52.452081328 +0200
> @@ -1,3780 +1,84 @@
> -commit 1860e379875dfe7271c649058aeddffe5afd9d0d (tag: v3.15)
> -commit ...
> ...
> -commit fad01e866afdbe01a1f3ec06a39c3a8b9e197014 (tag: v3.15-rc8)
> ...
> ...
> -commit c9eaa447e77efe77b7fa4c953bd62de8297fd6c5 (tag: v3.15-rc1)
> ...
> -commit 57673c2b0baa900dddae3b9eb3d7748ebf550eb3
> +commit a1fb433346cb5733945b5fc243f7334744bae4fd (HEAD, macq_boards-3.14.0)
> +commit ...
> ...
> +commit 2be7b20bbb337e0031e0f0d39c9a4845b6bbf3b8

It looks like v3.15 is ahead of your branch. And I _think_ your question is: since they both contain v3.14, shouldn't they also contain all of the ancestors of v3.14?

The answer is yes. But from your output here:
>  commit 455c6fdbd219161bd09b1165f11699d6d73de11c (tag: v3.14)	==== identical commit
> -commit c32fc9c803f8ed90a7548810de48ca33a3020168		==== commit missing in my branch
>  commit fedc1ed0f11be666de066b0c78443254736a942e		==== more identical commits

I think what you are saying is: c32fc9c803 comes after v3.14, so it should be an ancestor, right?

And the answer is no. Git's traversal order does not necessarily reflect the true topology if you have multiple lines of development. And in this case, they do not have a direct ancestry relationship (i.e., they are on separate branches, and neither is an ancestor of the other).

-Peff
Philippe De Muyter· May 20, 2015, 13:13 UTC · re: Jeff King · lore

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

Hi Jeff,
On Tue, May 19, 2015 at 07:39:25PM -0400, Jeff King wrote:
Show 34 quoted lines
> On Tue, May 19, 2015 at 03:29:58PM +0200, Philippe De Muyter wrote:
> 
> > 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
> > 
> > I compare then the two histories with
> > 
> > diff -u /tmp/3.15.commits /tmp/mybranch.commits
> > 
> > and I get (excerpt) :
> > 
> > --- /tmp/3.15.commits      2015-05-19 13:19:59.665205514 +0200
> > +++ /tmp/mybranch.commits     2015-05-19 13:19:52.452081328 +0200
> > @@ -1,3780 +1,84 @@
> > -commit 1860e379875dfe7271c649058aeddffe5afd9d0d (tag: v3.15)
> > -commit ...
> > ...
> > -commit fad01e866afdbe01a1f3ec06a39c3a8b9e197014 (tag: v3.15-rc8)
> > ...
> > ...
> > -commit c9eaa447e77efe77b7fa4c953bd62de8297fd6c5 (tag: v3.15-rc1)
> > ...
> > -commit 57673c2b0baa900dddae3b9eb3d7748ebf550eb3
> > +commit a1fb433346cb5733945b5fc243f7334744bae4fd (HEAD, macq_boards-3.14.0)
> > +commit ...
> > ...
> > +commit 2be7b20bbb337e0031e0f0d39c9a4845b6bbf3b8
> 
> It looks like v3.15 is ahead of your branch. And I _think_ your question
> is: since they both contain v3.14, shouldn't they also contain all of
> the ancestors of v3.14?
Thanks for understanding and clarifying my question.
Show 14 quoted lines
> 
> The answer is yes. But from your output here:
> 
> >  commit 455c6fdbd219161bd09b1165f11699d6d73de11c (tag: v3.14)	==== identical commit
> > -commit c32fc9c803f8ed90a7548810de48ca33a3020168		==== commit missing in my branch
> >  commit fedc1ed0f11be666de066b0c78443254736a942e		==== more identical commits
> 
> I think what you are saying is: c32fc9c803 comes after v3.14, so it
> should be an ancestor, right?
> 
> And the answer is no. Git's traversal order does not necessarily reflect
> the true topology if you have multiple lines of development. And in this
> case, they do not have a direct ancestry relationship (i.e., they are on
> separate branches, and neither is an ancestor of the other).

Thanks for the explanation. Would that also be true (that unrelated commits could come in the output) with a simple 'git log' ?

My initial problem (still unresolved/unanswered) is that some commits that appeared between v3.14-rc1 and v3.14-rc2 (specifically 817c27a128e18aed840adc295f988e1656fed7d1) are present in v3.15, but not in my branch.

I have just checked online the v3.14 version on 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/arch/arm/boot/dts/imx6qdl.dtsi

and I see also the same "problem": the commit removing 738 lines is in the log 817c27a128e18aed840adc295f988e1656fed7d1 "ARM: dts: imx6qdl: make pinctrl nodes board specific", but the v3.14 version of the file still contains the 738 removed line, and I see no commit restoring those lines.

I do not understand why those 738 lines are still present in v3.14 although they were removed between v3.14-rc1 and v3.14-rc2 :(

Philippe
John Keeping· May 20, 2015, 13:25 UTC · re: Philippe De Muyter · lore

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

On Wed, May 20, 2015 at 03:13:59PM +0200, Philippe De Muyter wrote:
Show 17 quoted lines
> My initial problem (still unresolved/unanswered) is that some commits
> that appeared between v3.14-rc1 and v3.14-rc2 (specifically
> 817c27a128e18aed840adc295f988e1656fed7d1) are present in v3.15, but not
> in my branch.
> 
> I have just checked online the v3.14 version on 
> 
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/arch/arm/boot/dts/imx6qdl.dtsi 
> 
> and I see also the same "problem": the commit removing 738 lines is in the log
> 817c27a128e18aed840adc295f988e1656fed7d1
> "ARM: dts: imx6qdl: make pinctrl nodes board specific",
> but the v3.14 version of the file still contains the 738 removed line,
> and I see no commit restoring those lines.
> 
> I do not understand why those 738 lines are still present in v3.14 although
> they were removed between v3.14-rc1 and v3.14-rc2 :(
Commit 817c27a128e18aed840adc295f988e1656fed7d1 isn't in v3.14:

$ git describe --contains 817c27a128e18aed840adc295f988e1656fed7d1 v3.15-rc1~77^2~40^2~57

$ git tag --contains 817c27a128e18aed840adc295f988e1656fed7d1 v3.15 v3.15-rc1 v3.15-rc2 v3.15-rc3 v3.15-rc4 v3.15-rc5 v3.15-rc6 v3.15-rc7 v3.15-rc8 v3.15.1 v3.15.10 v3.15.2 [snip later tags]

However, the commit date of 817c27a128e18aed840adc295f988e1656fed7d1 is between the dates of v3.14-rc1 and v3.14-rc2 so the default commit ordering of `git log` will show it between those two tags. `--topo-order` may help but I suspect the history is too complex to infer the relationship between commits without `--graph`.

Philippe De Muyter· May 20, 2015, 14:12 UTC · re: John Keeping · lore

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

Hi John,
On Wed, May 20, 2015 at 02:25:34PM +0100, John Keeping wrote:
Show 44 quoted lines
> On Wed, May 20, 2015 at 03:13:59PM +0200, Philippe De Muyter wrote:
> > My initial problem (still unresolved/unanswered) is that some commits
> > that appeared between v3.14-rc1 and v3.14-rc2 (specifically
> > 817c27a128e18aed840adc295f988e1656fed7d1) are present in v3.15, but not
> > in my branch.
> > 
> > I have just checked online the v3.14 version on 
> > 
> > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/arch/arm/boot/dts/imx6qdl.dtsi 
> > 
> > and I see also the same "problem": the commit removing 738 lines is in the log
> > 817c27a128e18aed840adc295f988e1656fed7d1
> > "ARM: dts: imx6qdl: make pinctrl nodes board specific",
> > but the v3.14 version of the file still contains the 738 removed line,
> > and I see no commit restoring those lines.
> > 
> > I do not understand why those 738 lines are still present in v3.14 although
> > they were removed between v3.14-rc1 and v3.14-rc2 :(
> 
> Commit 817c27a128e18aed840adc295f988e1656fed7d1 isn't in v3.14:
> 
> $ git describe --contains 817c27a128e18aed840adc295f988e1656fed7d1
> v3.15-rc1~77^2~40^2~57
> 
> $ git tag --contains 817c27a128e18aed840adc295f988e1656fed7d1
> v3.15
> v3.15-rc1
> v3.15-rc2
> v3.15-rc3
> v3.15-rc4
> v3.15-rc5
> v3.15-rc6
> v3.15-rc7
> v3.15-rc8
> v3.15.1
> v3.15.10
> v3.15.2
> [snip later tags]
> 
> However, the commit date of 817c27a128e18aed840adc295f988e1656fed7d1 is
> between the dates of v3.14-rc1 and v3.14-rc2 so the default commit
> ordering of `git log` will show it between those two tags.
> `--topo-order` may help but I suspect the history is too complex to
> infer the relationship between commits without `--graph`.

OK and Thanks. You saved me. I began to think I was going mad or there was a bug in git.

After reading the man page of 'git log', should --topo-order not be the default log order ?

Philippe
Jeff King· May 20, 2015, 16:18 UTC · re: Philippe De Muyter · lore

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

On Wed, May 20, 2015 at 04:12:38PM +0200, Philippe De Muyter wrote:
> After reading the man page of 'git log', should --topo-order not be the
> default log order ?

The problem with --topo-order is that it has to traverse all of the commits before starting output. So:

  $ time git log | head -1
  commit 64fb1d0e975e92e012802d371e417266d6531676
  real    0m0.038s
  user    0m0.032s
  sys     0m0.008s
  $ time git log --topo-order | head -1
  commit 64fb1d0e975e92e012802d371e417266d6531676
  real    0m4.247s
  user    0m4.140s
  sys     0m0.108s
-Peff
Philippe De Muyter· May 21, 2015, 07:05 UTC · re: Jeff King · lore

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

On Wed, May 20, 2015 at 12:18:15PM -0400, Jeff King wrote:
Show 23 quoted lines
> On Wed, May 20, 2015 at 04:12:38PM +0200, Philippe De Muyter wrote:
> 
> > After reading the man page of 'git log', should --topo-order not be the
> > default log order ?
> 
> The problem with --topo-order is that it has to traverse all of the
> commits before starting output. So:
> 
>   $ time git log | head -1
>   commit 64fb1d0e975e92e012802d371e417266d6531676
> 
>   real    0m0.038s
>   user    0m0.032s
>   sys     0m0.008s
> 
>   $ time git log --topo-order | head -1
>   commit 64fb1d0e975e92e012802d371e417266d6531676
> 
>   real    0m4.247s
>   user    0m4.140s
>   sys     0m0.108s
> 
> -Peff
So we trade correctness for speed :(
Is there a way to set topo-order as the default log order via git config ?

Is topo-order already implemented as starting with the default order followed by an ancestor check or does it switch immediately to topological sort ?

Philippe
Junio C Hamano· May 21, 2015, 16:45 UTC · re: Philippe De Muyter · lore

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

Philippe De Muyter <phdm@macq.eu> writes:
> So we trade correctness for speed :(
No corretness is traded with anything else here.

There are applications where topology matters and where it doesn't. When topology really matters (e.g. drawing the graph), the caller can choose to use --topo-order to have git do the work. Of course the caller could accept output without --topo-order in streaming fashion and stitch the parent-child relationship itself.

And of course, in applications where topology does not matter, you do not have to wait.

That is called "choice", not "trading".

← back to recent threads