Thread (9 messages) flat view 9 messages, 5 authors, 2016-06-15

Re: bug in name-rev on linux-2.6 repo?

From: Jonathan Nieder <hidden>
Date: 2016-06-15 22:48:41

Possibly related (same subject, not in this thread)

Andreas Schwab wrote:
Jonathan Nieder [off-list ref] writes:
quoted
The commit doesn’t seem to be part of any tagged release, nor linus’s
master:
$ git branch --contains a1de02dccf906faba2ee2d99cac56799bda3b96a
* master
$ git merge-base v2.6.34-rc1 a1de02dccf906faba2ee2d99cac56799bda3b96a
a1de02dccf906faba2ee2d99cac56799bda3b96a
git merge-base v2.6.33 a1de02dccf906faba2ee2d99cac56799bda3b96a
724e6d3fe8003c3f60bf404bf22e4e331327c596

So it has been merged beween v2.6.33 and v2.6.34-rc1
To first commit after rc8, to be exact.  But for some reason, the
revision walker doesn’t notice that:

 $ git rev-list origin/master..a1de02dcc | wc -l
 1

The tip of the relevant branch before merging was 64e290e (thanks to
Johan’s --ancestor-path suggestion and Junio’s nice implementation).
So we can walk up through the revisions:

 $ git rev-parse 64e290e~35
 a1de02dccf906faba2ee2d99cac56799bda3b96a
 $ git rev-list origin/master..64e290e~35 | wc -l
 0
 $ git rev-list origin/master..$(git rev-parse 64e290e~35) | wc -l
 1
 $ for i in 36 35 34 33 32 31 30
 > do
 >	printf "%d " "$i"
 >	git rev-list origin/master..$(git rev-parse 64e290e~$i) | wc -l
 > done
 36 0
 35 1
 34 2
 33 3
 32 4
 31 0
 30 0

Using v2.6.34-rc1~199 (the ext4 merge commit) instead of origin/master
reveals the same problem.  v2.6.34-rc1~199^2 (the tip of the ext4
branch) does not.

Hope that helps.
Jonathan
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help