On Mon, Mar 12 2018, Junio C. Hamano jotted: > On Mon, Mar 12, 2018 at 11:56 AM, Ævar Arnfjörð Bjarmason > <ava...@gmail.com> wrote: >> 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. > > Yeah, but that is exactly what I suggested, no? That is, if you don't do any > specific marking to describe _which_ ones need to be kept, this new thing > would kick in and pick the largest one and repack all others. If you choose > to want more control, on the other hand, you can mark those packs you > would want to keep, and this mechanism will not kick in to countermand > your explicit settings done via those .keep files.
Yes, this configurable mechanism as it stands only needs /etc/gitconfig. What I was pointing out in this mail is that we really should get the advanced use-cases right as well (see my 87a7vdqegi....@evledraar.gmail.com for details) via the config, because it's a pain to cross the chasm between setting config centrally on the one hand, and needing to track down .git's in arbitrary locations on the FS (you may not have cloned them yourself) to set *.keep flags. Doubly so if the machines in questions are just the laptops of some developers. It's relatively easy to tell them "we work with git repos, run this git config commands", not so easy to have them install & keep up-to-date some arbitrary cronjob that needs to hunt down their repos and set *.keep flags.
