On Sat, Oct 26, 2013 at 05:25:14PM +0700, Nguyen Thai Ngoc Duy wrote:
> > For bitmaps to be used, the following must be true:
> > 1. We must be packing to stdout (as a normal `pack-objects` from
> > `upload-pack` would do).
> > 2. There must be a .bitmap index containing at least one of the
> > "have" objects that the client is asking for.
> > 3. Bitmaps must be enabled (they are enabled by default, but can be
> > disabled by setting `pack.usebitmaps` to false, or by using
> > `--no-use-bitmap-index` on the command-line).
> > If any of these is not true, we fall back to doing a normal walk of the
> > object graph.
> I haven't read the bitmap creation code yet. But it probably does not
> matter. If the client requests a shallow fetch, you probably want to
> fall back to normal walk too.
One other criterion I should have mentioned: we must be using the
internal rev-list. That prevented us in v220.127.116.11 and earlier from using
bitmaps for shallow fetches. But as of v18.104.22.168, we always use
pack-objects' rev-walker. We may need to pass --no-use-bitmap-index for
As for repos that are themselves shallow, I do not know how doing a
"repack -b" would fare. Probably not well.
> Bitmaps may be made work with shallow fetches too, I'm not sure. We
> could substract the shallow'd commits out. The problem is if some
> other commits share parts of the shallow'd commits, I'm not sure how
> to detect that.
Yeah, I do not think shallow follows the same have/want reachability
rules that we rely on for taking the set difference via bitmaps. It may
be made to work eventually, but I think the important thing at this
point is making sure we properly fall back to the slow method when
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html