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,
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
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
> >
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
>
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
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
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
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
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
9 matches
Mail list logo