On Wed, Mar 07 2018, Junio C. Hamano jotted: > Duy Nguyen <pclouds@xxxxxxxxx> writes: >>> But to those who say "packs larger than this value is too big" via >>> configuration, keeping only the largest of these above-threshold >>> packs would look counter-intuitive, wouldn't it, I wonder? >> >> I think I'll just clarify this in the document. There may be a use >> case for keeping multiple large packs, but I don't see it (*). We can >> deal with it when it comes. > > When the project's history grows too much, a large pack that holds > its first 10 years of stuff, together with another one that holds > its second 20 years of stuff, may both be larger than the threshold > and want to be kept. If we pick only the largest one, we would > explode the other one and repack together with loose objects. > > But realistically, those who would want to control the way in which > their repository is packed to such a degree are very likely to add > ".keep" files to these two packfiles themselves, so the above would > probably not a concern. Perhaps we shouldn't do the "automatically > pick the largest one and exclude from repacking" when there is a > packfile that is marked with ".keep"? As someone who expects to use this (although hopefully in slightly modified form), it's very useful if we can keep the useful semantics in gc.* config values without needing some external job finding repos and creating *.keep files to get custom behavior. E.g. I have the use-case of wanting to set this on servers that I know are going to be used for cloning some big repos in user's ~ directory manually, so if I can set something sensible in /etc/gitconfig that's great, but it sucks a lot more to need to write some cronjob that goes hunting for repos in those ~ directories and tweaks *.keep files.
