On Fri, Jun 02, 2017 at 04:25:08PM -0700, Jonathan Nieder wrote: > > We have a name-hash cache extension in the bitmap file, but it doesn't > > carry enough information to deduce the .git-ness of a file. I don't > > think it would be too hard to add a "flags" extension, and give a single > > bit to "this is a .git file". > > A nicer approach IMHO is to include an extra bitmap, like the existing > object-type bitmaps (see the dump_bitmap calls in > bitmap_writer_finish). This would would represent the set of all > .git* blobs in the pack.
Yeah, it could be stored as a bitmap, which would be slightly smaller (since it would be mostly 0's). I think either way it would need an extension flag in the header to signal its presence. Older versions of Git are OK with having flags they don't understand. I know JGit used to complain about seeing a bitmap with unknown flags, but I'm not sure if that is still the case. > > If you're not just avoiding large blobs but trying > > to get a narrow clone, you don't want the .git files from the > > uninteresting parts of the tree. > > This is something I've wondered about, too. Part of the story is that > we haven't started omitting trees, so there is already O(number of > trees) objects being sent and some additional small blobs for .git* > specials doesn't make it much worse. Sending all .git* blobs keeps > things simple since the server doesn't have to infer which .git* blobs > are relevant to this client. > > Longer term, we will likely want to allow clients to request omission > of some trees, too. Omitting the corresponding .git* files becomes > more straightforward at that point. > > Does that make sense? Yeah, I agree we'd want to avoid the trees, too, in that case. -Peff
