Re: [bug] git checkout lies about number of ahead commits when switching from detached HEAD

Jeff King [off-list ref] writes:

  1. B does not use any of the same marks as A. Otherwise, it will end
     up clearing part of A's result during cleanup (not to mention that
     it may get a bogus result because of what was left from A).

  2. B works on a totally disjoint set of history from A and C.

I don't think (1) is that realistic in the general case. Sure, you might
only want to use TMP_MARK. But the revision walker behind the scenes is
using SEEN and UNINTERESTING, which is going to bring you into conflict.

I suspect I didn't write it clearly enough, but I think we are saying the
same thing.

Of course SEEN/UNINTERESTING needs to be reset for any traversal.  That is
a given for anybody who uses get_revision() to traverse the history.  "B
knows more about the bit it uses than other people, so it should be able
to do a better job of cleaning after it than others" is exactly about (1).

For (2), there are cases where it works. In this recent bug, for
example, it would sometimes produce the correct results depending on the
exact traversal done in the orphan-warning (e.g., if you were exploring
way back in history near a tag, the traversal wouldn't come near the
commits needed to get the tracking info for the new branch).

And then "B knows more about where in the history it travesed, so it
should be able to do a better job" is about (2).

But you can only know that it's a reasonable thing to do if you manually
analyze A, B, and C as a set, and even then only if you can know pretty
specifically what the inputs are.

Oh, that is a given that whoever is inserting B between A and C needs to
know about their relationship, and whoever wishes to design B to be
reusable in other different contexts needs to know what masks other people
may care about not to stomp on them.  I had this idea of allocating masks
on-demand instead of the current static assignment in the back of my head
for a few years, but my gut feeling keeps me telling that the added
complexity (and lax use of object bits by coders leading to memory
footprint bloat) may not be worth it.

I can change it to UNINTERESTING. As far as I can tell, that is the only
one set by prepare_revision_walk. It just felt like a leaky abstraction
for this code to have to know which flags might get set by the
underlying code. But obviously callers do need to know and care which
flags might be set and when.

Yes, the code has to know about the bits, and explicitly declaring it
knows what it is doing and using is about being assuring, not being leaky.