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, 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. 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
