Jeff King <peff@xxxxxxxx> writes: > For the case of 2 traversals, I suspect that clearing everything between > is not so different from clearing from the tips, since most everything > parsed was probably from the first traversal. But as we lib-ify more, we > may end up with more and more traversals in a single program, so it's > probably better to go the more efficient route from the beginning. "Let the one that has more information to do the clearing" is not about performance but about correctness and reusability potential. When you insert a new traversal B in the existing codeflow before another traversal C, B knows not just which commits it started from (hence knows which commits were marked by it), but more importantly it also knows what mark bits were potentially modified. If the existing codeflow had another traversal A before you added B, and C took the marks A left on the objects into account while doing its work, the only sensible clean-up is to clear marks B touched (and no other marks) immediately after B, and we obviously do not want C (and any later traversals in other codepaths that we may later want to insert B) to have too much knowledge of which marks may have been clobbered by B. Of course, C could be coded defensively to clear marks other than what it cares about (namely, the ones other than what A would have left and the ones that would affect itself e.g. UNINTERESTING), and whoever inserts B into existing codeflow needs to make sure that B does not stomp on marks deliberately left by earlier traversals like A for later users like C regardless of how the latter is coded. > So how about this? > > [1/3]: checkout: add basic tests for detached-orphan warning > [2/3]: checkout: clear commit marks after detached-orphan check > [3/3]: checkout: tweak detached-orphan warning format Looks very sensible, except for the clear_marks(-1) that clears everything I have a slight doubt about. I think 3/3 was way overdue and it was my fault. Thanks for cleaning up my mess. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html