Junio C Hamano wrote: > Taylor Blau <me@xxxxxxxxxxxx> writes: > > Relaxing the bitmap traversal to allow it to produce over-counted > > results gives us the opportunity to make some significant improvements. > > Instead of the above, the new algorithm only has to walk from the > > *boundary* down to the nearest bitmap, instead of from each of the > > UNINTERESTING tips. > > Is it only me, or are all readers equally confused by the use of > the term "boundary" that hasn't been given any definition? > > > And is more-or-less equivalent to using the *old* algorithm with this > > invocation: > > > > $ git rev-list --objects --boundary $WANTS --not $HAVES | > > It is especially confusing because the "--boundary" (at least as I > originally had invented it), i.e. a commit that is smudged with > UNINTERESTING bit, whose parent we did not bother to dig further to > paint with the same UNINTERESTING bit, is not something we start our > computation with; it is something we learn _after_ completing the > history traversing. So I am utterly confused X-<. I don't know if it's the case, but in my mind all the `--not $HAVES` are boundaries. Some of these might be overshadowed by another boundary higher up in the topology and thus not shown, so in a sense are "uninteresting boundaries". Perhaps because you invented `--boundary` you think a "boundary" is only an interesting boundary which must be computed, and all the other are not true boundaries. Cheers. -- Felipe Contreras
