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. > >> and change the > >> need_to_gc() / cmd_gc() behavior so that we detect that the > >> gc.writeCommitGraph=true setting is on, but we have no commit graph, and > >> then just generate that without doing a full repack. > > > > Or just teach 'git clone' to run 'git commit-graph write ...' > > Then when adding something like the commit graph we'd need to patch both > git-clone and git-gc, it's much more straightforward to make > need_to_gc() more granular. > > >> As an aside such more granular "gc" would be nice for e.g. pack-refs > >> too. It's possible for us to just have one pack, but to have 100k loose > >> refs. > >> > >> It might also be good to have some gc.autoDetachOnClone option and have > >> it false by default, so we don't have a race condition where "clone > >> linux && git -C linux tag --contains" is slow because the graph hasn't > >> been generated yet, and generating the graph initially doesn't take that > >> long compared to the time to clone a large repo (and on a small one it > >> won't matter either way). > >> > >> I was going to say "also for midx", but of course after clone we have > >> just one pack, so I can't imagine us needing this. But I can see us > >> having other such optional side-indexes in the future generated by gc, > >> and they'd also benefit from this. > >> > >> #leftoverbits
