On Mon, Mar 18, 2019 at 11:48:46PM +0100, Ævar Arnfjörð Bjarmason wrote: > > I know this last sentence came from the existing documentation, but I > > wonder if we should be more vague here. We'd pack with "repack -dl" when > > we have just loose objects, and "repack -Adl" when we have too many > > packs. Or "repack -adl" if we're pruning now, and "--unpack-unreachable" > > otherwise. > > > > I think the point of git-gc is that you don't have to care about that > > stuff. It works magically, and if you are implementing your own custom > > gc scheme, then you are probably better off reading the output of > > GIT_TRACE or looking at the source, rather than this documentation. > > Yeah I can just drop it while I'm at it. Was just losslessly trying to > port the existing docs. Yeah, I'm sympathetic to that (if you did drop it, you might have gotten the opposite review). ;) I think it would be OK to just mention it in the commit message, but I'd also be OK dropping it in a preliminary patch. > >> marked with `*.keep` file in the repository, `git gc > >> --auto` consolidates them into one larger pack. The > >> - default value is 50. Setting this to 0 disables it. > >> + default value is 50. Setting this (or `gc.auto`) to 0 > >> + disables it. Packs will be consolidated using the `-A` option > >> + of `git repack`. > > > > If we do revise the "-d -l" bit for the loose limit, we'd probably want > > to adjust this to match. > > Or not mention it either? Yes. :) > > I'm not sure how to read this "or". What's the difference between "0" or > > the memory heuristic, and when is one used? Or is that what the "if the > > number of kept packs is more than..." below is trying to say? > > That by default we don't use gc.bigPackThreshold, unless we find that > you're under memory pressure. I.e. "it's off by default, unless your > system has too little memory". OK, I see. It might make sense to write that out more explicitly. -Peff
