Re: [PATCH 3/3] pack-bitmap.c: use commit boundary during bitmap traversal

[Felipe Contreras <felipe.contreras@gmail.com>]

Junio C Hamano wrote:
> Taylor Blau <me@ttaylorr.com> 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