From: Philippe De Muyter <hidden> Date: 2016-06-15 23:04:49
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) :
...
-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
From: Jeff King <hidden> Date: 2016-06-15 23:04:50
On Tue, May 19, 2015 at 03:29:58PM +0200, Philippe De Muyter wrote:
quoted hunk
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) :
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
From: Philippe De Muyter <hidden> Date: 2016-06-15 23:04:50
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:
quoted
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) :
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:
quoted
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
From: John Keeping <hidden> Date: 2016-06-15 23:04:50
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`.
From: Philippe De Muyter <hidden> Date: 2016-06-15 23:04:50
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:
quoted
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
From: Jeff King <hidden> Date: 2016-06-15 23:04:50
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
From: Philippe De Muyter <hidden> Date: 2016-06-15 23:04:51
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:
quoted
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