Mike Hommey [off-list ref] 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)
On Tue, Jan 06, 2015 at 02:24:58AM -0800, Junio C Hamano wrote:
Mike Hommey [off-list ref] writes:
quoted
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