Question about the revision walking API

Question about the revision walking API

[Mike Hommey]

Hi,

I would like to know if the revision walking API works as one would
expect with a calling sequence like the following:

- init_revisions
- add_pending_object/setup_revisions
- prepare_revision_walk
- get_revision (repeated)
- reset_revision_walk (I guess)
- add_pending_object
- prepare_revision_walk
- get_revision (repeated)

That is, do a first revision walk based on a given rev_info, then reuse that
rev_info with additional commit objects (in my case, I want to add more
UNINTERESTING commits) and redo a revision walk based on the modified
rev_info (so, avoid reinitializing a rev_info and filling it from
scratch again with the additional UNINTERESTING commits).

I guess I could try and see if that works, but I'd rather have an
informed answer than to derive my own from the fact my testcase would
happen to work by chance.

Cheers,

Mike

Re: Question about the revision walking API

[Junio C Hamano]

Mike Hommey <mh@glandium.org> writes:

> I would like to know if the revision walking API works as one would
> expect with a calling sequence like the following:
>
> - init_revisions
> - add_pending_object/setup_revisions
> - prepare_revision_walk
> - get_revision (repeated)
> - reset_revision_walk (I guess)

Around here you would need to clear flag bits left on the objects by
your previous traversal.  After "git log A..B", commits in that
range would have various combinations of SEEN, ADDED and SHOWN
flags, and also some commits reachable from A would be marked as
UNINTERESTING.  You do not want these to interfere with your next
traversal which may not have anything to do with what you computed
with the previous round.

> - add_pending_object
> - prepare_revision_walk
> - get_revision (repeated)

Re: Question about the revision walking API

[Mike Hommey]

On Tue, Jan 06, 2015 at 02:24:58AM -0800, Junio C Hamano wrote:
> Mike Hommey <mh@glandium.org> writes:
> 
> > I would like to know if the revision walking API works as one would
> > expect with a calling sequence like the following:
> >
> > - init_revisions
> > - add_pending_object/setup_revisions
> > - prepare_revision_walk
> > - get_revision (repeated)
> > - reset_revision_walk (I guess)
> 
> Around here you would need to clear flag bits left on the objects by
> your previous traversal.  After "git log A..B", commits in that
> range would have various combinations of SEEN, ADDED and SHOWN

afaics, that's what reset_revision_walk does.

> flags, and also some commits reachable from A would be marked as
> UNINTERESTING.

Do you mean the ancestry of A? That wouldn't matter in my case.

> You do not want these to interfere with your next
> traversal which may not have anything to do with what you computed
> with the previous round.

Okay, so aiui, doing a revision walk doesn't impact anything other
than the object flags, so I can safely use add_pending_object to add
to what I already had in the rev_info?

Cheers,

Mike

Re: Question about the revision walking API

[Christian Couder]

Hi,


On Tue, Jan 6, 2015 at 3:02 AM, Mike Hommey <mh@glandium.org> wrote:
> Hi,
>
> I would like to know if the revision walking API works as one would
> expect with a calling sequence like the following:
>
> - init_revisions
> - add_pending_object/setup_revisions
> - prepare_revision_walk
> - get_revision (repeated)
> - reset_revision_walk (I guess)
> - add_pending_object
> - prepare_revision_walk
> - get_revision (repeated)
>
> That is, do a first revision walk based on a given rev_info, then reuse that
> rev_info with additional commit objects (in my case, I want to add more
> UNINTERESTING commits) and redo a revision walk based on the modified
> rev_info (so, avoid reinitializing a rev_info and filling it from
> scratch again with the additional UNINTERESTING commits).
>
> I guess I could try and see if that works, but I'd rather have an
> informed answer than to derive my own from the fact my testcase would
> happen to work by chance.

I am not sure what you describe above would work, but something like
what is done in bisect.c should work, see check_ancestors() and
bisect_next_all(). It might not be the most efficient solution though,
so I am interested if you find something more efficient.

Best,
Christian.

Re: Question about the revision walking API

[Junio C Hamano]

Christian Couder <christian.couder@gmail.com> writes:

> I am not sure what you describe above would work, but something like
> what is done in bisect.c should work, see check_ancestors() and
> bisect_next_all(). It might not be the most efficient solution though,
> so I am interested if you find something more efficient.

I do not think what bisect does is a correct solution for general
case; I didn't check too carefully when I applied your patch long
time ago, but I recall that you only clear flag bits from commits
that are still in the pending queue in that codepath.  That may be
sufficient if the subsequent traversal goes only outside the area
previous traversal walked, but the approach is inappropriate for
general cases, no?