On Wed, Oct 03, 2018 at 02:59:34PM -0400, Derrick Stolee wrote: > > They don't help yet, and there's no good reason to enable bitmaps for > > clients. I have a few patches that use bitmaps for things like > > ahead/behind and --contains checks, but the utility of those may be > > lessened quite a bit by Stolee's commit-graph work. And if it isn't, > > I'm mildly in favor of replacing the existing .bitmap format with > > something better integrated with commit-graphs (which would give us an > > opportunity to clean up some of the rough edges). > > If the commit-graph doesn't improve enough on those applications, then we > could consider adding a commit-to-commit reachability bitmap inside the > commit-graph. ;) That unfortunately wouldn't be enough for us to ditch the existing .bitmap files, since we need full object reachability for some cases (including packing). And commit-to-commit reachability is a trivial subset of that. I'm not sure if it would be better to just leave .bitmaps in place as a server-side thing, and grow a new thing for commit-to-commit reachability (since it would presumably be easier). I'm still excited about the prospect of a bloom filter for paths which each commit touches. I think that's the next big frontier in getting things like "git log -- path" to a reasonable run-time. -Peff
