On Wed, Oct 03 2018, SZEDER Gábor wrote: > On Wed, Oct 03, 2018 at 04:01:40PM +0200, Ævar Arnfjörð Bjarmason wrote: >> >> On Wed, Oct 03 2018, SZEDER Gábor wrote: >> >> > On Wed, Oct 03, 2018 at 03:23:57PM +0200, Ævar Arnfjörð Bjarmason wrote: >> >> Don't have time to patch this now, but thought I'd send a note / RFC >> >> about this. >> >> >> >> Now that we have the commit graph it's nice to be able to set >> >> e.g. core.commitGraph=true & gc.writeCommitGraph=true in ~/.gitconfig or >> >> /etc/gitconfig to apply them to all repos. >> >> >> >> But when I clone e.g. linux.git stuff like 'tag --contains' will be slow >> >> until whenever my first "gc" kicks in, which may be quite some time if >> >> I'm just using it passively. >> >> >> >> So we should make "git gc --auto" be run on clone, >> > >> > There is no garbage after 'git clone'... >> >> "git gc" is really "git gc-or-create-indexes" these days. > > Because it happens to be convenient to create those indexes at > gc-time. But that should not be an excuse to run gc when by > definition no gc is needed. Ah, I thought you just had an objection to the "gc" name being used for non-gc stuff, but if you mean we shouldn't do a giant repack right after clone I agree. I meant that "gc --auto" would learn to do a subset of its work, instead of the current "I have work to do, let's do all of pack-refs/repack/commit-graph etc.". So we wouldn't be spending 5 minutes repacking linux.git right after cloning it, just ~10s generating the commit graph, and the same would happen if you rm'd .git/objects/info/commit-graph and ran "git commit", which would kick of "gc --auto" in the background and do the same thing.
