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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Andreas Schwab wrote:
> Jonathan Nieder <jrnieder@xxxxxxxxx> writes:

>> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]