Junio C Hamano wrote: > "Troy Telford" <ttelford@xxxxxxxxxxxxxxxx> writes: > >> I'm thinking of it as an option for git-repack-- that the user can set >> the maximum size of any individual pack, and after that limit is >> reached, a new pack file is started. (ie. --max-size 2GB) and will >> end up with two packs, each 2GB in size. > > The way I would suggest you do it is not by size but by distance > from the latest. If you want to split the kernel history for > example, you repack up to 2.6.14 for example, and then repack > the remainder. That way, you can optimize for size for older > (presumably less frequently used) data while optimizing for > speed for more reent stuff. If there would be some enhancement to pack files allowing either limiting the size of pack (e.g. filesystem limits, mmap limits) and/or mmaping only fragment or fragments of pack file, the maximal size of the pack, or maximal size of the mmapped fragment should be configurable per repository, not olny as an option to some command (git-repack for example). Probably would need some enhancement to git-fetch/git-clone too... -- Jakub Narebski Warsaw, Poland ShadeHawk on #git - 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