List of all commands that cause git gc --auto

Question

Is there a definitive list of commands anywhere that cause git gc --auto to run? The git-gc(1) man page simply states:

--auto

With this option, git gc checks whether any housekeeping is required; if not, it exits without performing any work. Some git commands run git gc --auto after performing operations that could create many loose objects.

(emphasis added)

I'm in the process of organising a large migration from SVN to Git. The overwhelming majority of users will be on Windows PCs, and a not-insignificant portion of them are non-technical. They will be using TortoiseGit (as it closely matches TortoiseSVN, which they are already familiar with) - I've noticed that TortoiseGit does not include any functionality to run git gc manually at all.

The non-technical staff cannot be expected to have to launch a "git bash" command line to run git gc --auto from the appropriate working dir; and as we are using the "portable" distribution of MsysGit they will not have the "Git GUI Here.." windows shell context menu shortcut.

Is it reasonable to expect that over time Git will mostly self-maintain, or do I need to try and work out a non-technical user friendly method of invoking git gc --auto?

Duramen

Note: git rebase will soon handle git gc --auto in a more sensible way: see https://mcmap.net/q/672265/-git-rebase-gets-stuck-after-resolving-merge-conflict – Chilblain

Don't forget git commit, starting with Git 2.17 (Q2 2018). See my answer below – Chilblain

Answer 1

builtin/merge.c:            const char *argv_gc_auto[] = { "gc", "--auto", NULL };
builtin/receive-pack.c:     "gc", "--auto", "--quiet", NULL,
git-am.sh:                  git gc --auto
git-rebase--interactive.sh: git gc --auto &&
git-svn.perl:               command_noisy('gc', '--auto');

From git grep -- --auto on git.git, those results looked interesting. The notable one is builtin/merge.c meaning that the ever so common git pull should trigger a git gc --auto.

Additionally, unless your 'non-technical' staff is doing rather 'advanced' stuff (at which point they wouldn't be 'non-technical' anymore), I don't see why they would ever need to run git gc manually instead of just letting git gc --auto handle everything.

Micah

Agreed: auto is for "automatic", i.e. the average user doesn't need to do anything. – Inspire

I understand that --auto is supposed to be behind-the-scenes stuff, but was also curious if it gets invoked often enough that one can rely on --auto to perform gc. I've seen other questions asking things like "how often should I run git gc?", but couldn't work out if --auto got called often enough that users could essentially never need to think about manually running git gc. I'll mark this as accepted since it has the list of commands, thanks Arrowmaster. I'm still curious if people think --auto is good enough, or if users should still do manual git gc on occasion. – Duramen

I sometimes use git to backup my files. In those repos a cronjob only performs git add, git commit and git push commands. None of those will trigger a git gc --auto. In that situation therefore I cannot rely upon the automatic cleaning and should do a git gc or git repack manually. – Casals

Answer 2

With Git 2.17 (Q2 2018), you will have to add git commit to the list of commands triggering a git gc --auto.
Actually, that should have been the case since the beginning of Git.

See commit 095c741 (28 Feb 2018) by Ævar Arnfjörð Bjarmason (avar).
^{(Merged by Junio C Hamano -- gitster -- in commit 9bb8eb0, 08 Mar 2018)}

commit: run git gc --auto just before the post-commit hook

Change the behavior of git-commit back to what it was back in d4bb43e ("Invoke "git gc --auto" from commit, merge, am and rebase.", 2007-09-05, Git v1.5.4-rc0) when it was git-commit.sh.

Shortly afterwards in f5bbc32 ("Port git commit to C.", 2007-11-08, Git v1.5.4-rc0) when it was ported to C, the "git gc --auto" invocation went away.

Since that unintended regression, git gc --auto only ran for git-am, git-merge, git-fetch, and git-receive-pack.
It was possible to write a script that would "git commit" a lot of data locally, and gc would never run.

One such repository that was locally committing generated zone file changes had grown to a size of ~60GB before a daily cronjob was added to "git gc", bringing it down to less than 1GB. This will make such cases work without intervention.

I think fixing such pathological cases where the repository will grow forever is a worthwhile trade-off for spending a couple of milliseconds calling "git gc --auto" (in the common cases where it doesn't do anything).

---

You can find another illustration of this list with Git 2.27 (Q2 2020), which teach "am", "commit", "merge" and "rebase", when they are run with the "--quiet" option, to pass "--quiet" down to "gc --auto".

See commit 7c3e9e8, commit 850b6ed (06 May 2020) by Junio C Hamano (gitster).
^{(Merged by Junio C Hamano -- gitster -- in commit 3af459e, 13 May 2020)}

auto-gc: extract a reusable helper from "git fetch"

^{Reviewed-by: Taylor Blau}

Back in 1991006c (fetch: convert argv_gc_auto to struct argv_array, 2014-08-16, Git v2.1.1), we taught "git fetch --quiet" to pass the "--quiet" option down to "gc --auto".

This issue, however, is not limited to "fetch":

$ git grep -e 'gc.*--auto' \*.c

finds hits in "am", "commit", "merge", and "rebase" and these commands do not pass "--quiet" down to "gc --auto" when they themselves are told to be quiet.

As a preparatory step, let's introduce a helper function run_auto_gc(), that the caller can pass a boolean "quiet", and redo the fix to "git fetch" using the helper.

Chilblain