Re: Strange behavior of git rev-list

2017-09-07 Thread Jeff King
On Fri, Sep 08, 2017 at 12:37:28PM +0900, Junio C Hamano wrote: > > I'm still moderately against storing generation numbers inside the > > objects. They're redundant with the existing parent pointers, which > > means it's an opportunity for the two sets of data to disagree. And as > > we've seen,

Re: Strange behavior of git rev-list

2017-09-07 Thread Junio C Hamano
Jeff King writes: > On Thu, Sep 07, 2017 at 12:24:02PM -0700, Stefan Beller wrote: > >> > We've discussed storing true generation numbers in the past, which would >> > make this optimization more robust, as well as allow us to speed up many >> > other traversals (e.g., the "tag

Re: Strange behavior of git rev-list

2017-09-07 Thread Jeff King
On Thu, Sep 07, 2017 at 12:24:02PM -0700, Stefan Beller wrote: > > We've discussed storing true generation numbers in the past, which would > > make this optimization more robust, as well as allow us to speed up many > > other traversals (e.g., the "tag --contains"). It's something I'd like > >

Re: Strange behavior of git rev-list

2017-09-07 Thread Stefan Beller
On Thu, Sep 7, 2017 at 3:11 AM, Jeff King wrote: > On Thu, Sep 07, 2017 at 11:50:25AM +0200, Paweł Marczewski wrote: > >> Thanks. Any plans to fix that? Or is there a way to turn off this heuristic? > > I don't think there's a way to turn it off for `rev-list`. Merge-base >

Re: Strange behavior of git rev-list

2017-09-07 Thread Jeff King
On Thu, Sep 07, 2017 at 11:50:25AM +0200, Paweł Marczewski wrote: > Thanks. Any plans to fix that? Or is there a way to turn off this heuristic? I don't think there's a way to turn it off for `rev-list`. Merge-base computations are more careful, so you could determine the correct endpoints that

Re: Strange behavior of git rev-list

2017-09-07 Thread Paweł Marczewski
Thanks. Any plans to fix that? Or is there a way to turn off this heuristic? On 7 September 2017 at 11:47, Jeff King wrote: > On Thu, Sep 07, 2017 at 11:20:15AM +0200, Paweł Marczewski wrote: > >> I have an interesting case. In my repository, there are two commits, >> 'one' and

Re: Strange behavior of git rev-list

2017-09-07 Thread Jeff King
On Thu, Sep 07, 2017 at 11:20:15AM +0200, Paweł Marczewski wrote: > I have an interesting case. In my repository, there are two commits, > 'one' and 'two'. 'one' is reachable from 'two' (as evidenced by 'git > rev-list two | grep $(giv rev-parse one)'). However, the output of > 'git rev-list

Strange behavior of git rev-list

2017-09-07 Thread Paweł Marczewski
Hi, I have an interesting case. In my repository, there are two commits, 'one' and 'two'. 'one' is reachable from 'two' (as evidenced by 'git rev-list two | grep $(giv rev-parse one)'). However, the output of 'git rev-list two..one' is not empty, as is 'git rev-list ^two one'. Here is the

Strange behavior of git rev-list --first-parent --ancesty-path

2014-09-29 Thread Василий Макаров
Hello! Imagine following tree: A--B--C \ / D--E B is parent #1 of C. git rev-list --first-parent --ancestry-path D..C returns zero commits. This is correct, since one cannot find any commits between D and C traversing tree by first parent. git rev-list --first-parent --ancestry-path E..C