Re: [PATCH v2] gc: recommend `git gc --prune=now` instead of `git prune`

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Jun 9, 2020, 11:06 UTC
Message-ID: <87bllsa47u.fsf@evledraar.gmail.com>
In-Reply-To: <pull.652.v2.git.1591662224566.gitgitgadget@gmail.com>

On Tue, Jun 09 2020, John Lin via GitGitGadget wrote:

Show 5 quoted lines

> From: John Lin <johnlinp@gmail.com>
>
> `git prune` is a plumbing command and should not be run directly by
> users. The corresponding porcelain command is `git gc`, which is
> mentioned in the man page of `git prune`.

This change feels incomplete without a change to git-prune's documentation, see 8d308b3540 ("Documentation: point git-prune users to git-gc", 2008-04-29).

I.e. it still talks about "in most cases you shouldn't run this", but here we are removing a case where it would otherwise make sense because the user shouldn't use it directly.

I think instead the small change that makes the most sense here is to just add "prune" to completions, i.e. I disagree with Denton Liu in https://github.com/gitgitgadget/git/issues/642#issuecomment-640202110

The "right" change is much harder, there's numerous odd edge cases that "gc" can get into with these loose objects (for the curious [1] and [2] are a nice entry to that rabbit hole).

Fixing that is non-trivial, but in the meantime I don't think it's good to:

 a) Recommend an option to "gc" which implies "repack -a", which as
    noted in gc's docs can produce corruption in a live repository.

    I.e. I don't think "let's not recommend this plumbing" should lead
    us to "let's recommend this thing that could corrupt the repository
    instead".

 b) Even if you don't get the corruption with "a" above "gc --prune=now"
    will produce a very differently packed repository. This might have
    unexpected performance etc. trade-offs the user wasn't expecting
    from a "run this for a quick fix" command.

 c) In the cases where "prune" here would help, e.g. on some large repo
    where something else added a lot of loose unreachable objects during
    the "gc" for some reason recommending a full "gc" might take a lot
    more time than just the "prune".

1. https://public-inbox.org/git/87eflvmovg.fsf@evledraar.gmail.com/
2. https://public-inbox.org/git/8736lnxlig.fsf@evledraar.gmail.com/

Show 48 quoted lines

> Signed-off-by: John Lin <johnlinp@gmail.com>
> ---
>     Recommend "git gc --prune=now" instead of "git prune"
>
>     Signed-off-by: John Lin johnlinp@gmail.com [johnlinp@gmail.com]
>
>     Fix according to #642.
>
> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-652%2Fjohnlinp%2Ffix-git-gc-warning-message-v2
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-652/johnlinp/fix-git-gc-warning-message-v2
> Pull-Request: https://github.com/gitgitgadget/git/pull/652
>
> Range-diff vs v1:
>
>  1:  83b7137abfd ! 1:  42aa6380067 Recommend "git gc --prune=now" instead of "git prune"
>      @@ Metadata
>       Author: John Lin <johnlinp@gmail.com>
>
>        ## Commit message ##
>      -    Recommend "git gc --prune=now" instead of "git prune"
>      +    gc: recommend `git gc --prune=now` instead of `git prune`
>      +
>      +    `git prune` is a plumbing command and should not be run directly by
>      +    users. The corresponding porcelain command is `git gc`, which is
>      +    mentioned in the man page of `git prune`.
>
>           Signed-off-by: John Lin <johnlinp@gmail.com>
>
>
>
>  builtin/gc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/builtin/gc.c b/builtin/gc.c
> index 8e0b9cf41b3..74185eac917 100644
> --- a/builtin/gc.c
> +++ b/builtin/gc.c
> @@ -692,7 +692,7 @@ int cmd_gc(int argc, const char **argv, const char *prefix)
>
>  	if (auto_gc && too_many_loose_objects())
>  		warning(_("There are too many unreachable loose objects; "
> -			"run 'git prune' to remove them."));
> +			"run 'git gc --prune=now' to remove them."));
>
>  	if (!daemonized)
>  		unlink(git_path("gc.log"));
>
> base-commit: 20514004ddf1a3528de8933bc32f284e175e1012