Re: [bug] git checkout lies about number of ahead commits when switching from detached HEAD
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Mar 21, 2011, 15:17 UTC
- Message-ID
- <7v4o6wtsdz.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <20110321103549.GA16334@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 9 quoted lines
> 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).
Show 5 quoted lines
> 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.
Show 5 quoted lines
> 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.