threads / discuss / 38288

Question about the revision walking API

Subject: Question about the revision walking API

## tl;dr

5 messages between Jan 6, 2015 and Jan 6, 2015.

replies: 4people: 3as markdown or json

Mike Hommey· Jan 6, 2015, 02:02 UTC · lore

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

Junio C Hamano· Jan 6, 2015, 10:24 UTC · re: Mike Hommey · lore

Re: Question about the revision walking API

Mike Hommey <mh@glandium.org> writes:

Show 8 quoted lines

> 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)

Mike Hommey· Jan 6, 2015, 10:51 UTC · re: Junio C Hamano · lore

Re: Question about the revision walking API

On Tue, Jan 06, 2015 at 02:24:58AM -0800, Junio C Hamano wrote:

Show 14 quoted lines

> 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

Christian Couder· Jan 6, 2015, 13:37 UTC · re: Mike Hommey · lore

Re: Question about the revision walking API

Hi,

On Tue, Jan 6, 2015 at 3:02 AM, Mike Hommey <mh@glandium.org> wrote:

Show 23 quoted lines

> 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.

Junio C Hamano· Jan 6, 2015, 18:30 UTC · re: Christian Couder · lore

Re: Question about the revision walking API

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?