On Tue, Jun 09 2020, John Lin via GitGitGadget wrote:
> From: John Lin <johnlinp@xxxxxxxxx>
>
> `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@xxxxxxxxxxxxxxxxxxx/
2. https://public-inbox.org/git/8736lnxlig.fsf@xxxxxxxxxxxxxxxxxxx/
> Signed-off-by: John Lin <johnlinp@xxxxxxxxx>
> ---
> Recommend "git gc --prune=now" instead of "git prune"
>
> Signed-off-by: John Lin johnlinp@xxxxxxxxx [johnlinp@xxxxxxxxx]
>
> 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@xxxxxxxxx>
>
> ## 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@xxxxxxxxx>
>
>
>
> 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
