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 v1.8.4.1 and earlier from using bitmaps for shallow fetches. But as of v1.8.4.2, we always use pack-objects' rev-walker. We may need to pass --no-use-bitmap-index for shallow fetches. 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 shallow. -Peff -- 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