Re: [RFC] git gc "--prune=now" semantics considered harmful

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: May 27, 2018, 01:27 UTC
Message-ID: <CA+55aFycPQ9PTbAGXqL7i9QQPsx-AT8R3S5gTvC0Ue=ot2J9FQ@mail.gmail.com>
In-Reply-To: <xmqqd0xim1tp.fsf@gitster-ct.c.googlers.com>

On Sat, May 26, 2018 at 4:31 PM Junio C Hamano <gitster@pobox.com> wrote:

> *That* is something I don't do.  After all, I am fully aware that I
> have started end-of-day ritual by that time, so I won't even look at
> a new patch (or a pull request for that matter).

Sounds like you're more organized about the end-of-day ritual than I am. For me the gc is not quite so structured.

Show 6 quoted lines

> I however have to wonder if there are opposite "oops" end-user
> operation we also need to worry about, i.e. we are doing a large-ish
> fetch, and get bored and run a gc fron another terminal.  Perhaps
> *that* is a bit too stupid to worry about?  Auto-gc deliberately
> does not use 'now' because it wants to leave a grace period to avoid
> exactly that kind of race.

For me, a "pull" never takes that long. Sure, any manual merging and the writing of the commit message might take a while, but it's "foreground" activity for me, I'd not start a gc in the middle of it.

So at least to me, doing "git fsck --full" and "git gc --prune=now" are somewhat special because they take a while and tend to be background things that I "start and forget" about (the same way I sometimes start and forget a kernel build).

Which is why that current "git gc --prune=now" behavior seems a bit dangerous.

                Linus