identical hashes on two branches, but holes in git log

identical hashes on two branches, but holes in git log

[Philippe De Muyter]

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

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

[Junio C Hamano]

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

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.

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

[Philippe De Muyter]

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 ?

Philippe

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

[Junio C Hamano]

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.

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

[Jeff King]

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?

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

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

[Christian Couder]

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

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

[Philippe De Muyter]

Hi Jeff,

On Tue, May 19, 2015 at 07:39:25PM -0400, Jeff King wrote:
> 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.

> 
> 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

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

[John Keeping]

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`.

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

[Philippe De Muyter]

Hi John,

On Wed, May 20, 2015 at 02:25:34PM +0100, John Keeping wrote:
> 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

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

[Jeff King]

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

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

[Philippe De Muyter]

On Wed, May 20, 2015 at 12:18:15PM -0400, Jeff King wrote:
> 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

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

[Philippe De Muyter]

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' :(

I surmise this happens only when 'git merge' has been used.

Philippe

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

[Junio C Hamano]

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".

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

[Philip Oakley]

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

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

[Philippe De Muyter]

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