gc: recommend `git gc --prune=now` instead of `git prune` #652

johnlinp · 2020-06-08T00:48:16Z

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

Fix according to #642.

johnlinp · 2020-06-08T02:01:06Z

/submit

gitgitgadget · 2020-06-08T02:02:48Z

Submitted as pull.652.git.1591581739031.gitgitgadget@gmail.com

gitgitgadget · 2020-06-08T10:19:13Z

On the Git mailing list, Denton Liu wrote (reply to this):

Hi John,

Thanks for working on this topic.

On Mon, Jun 08, 2020 at 02:02:18AM +0000, John Lin via GitGitGadget wrote:
> Subject: [PATCH] Recommend "git gc --prune=now" instead of "git prune"

The format for subjects is generally "<area>: <description>" so perhaps
something like "git gc: recommend use of `git gc --prune=now`"?

> From: John Lin <johnlinp@gmail.com>
> 
> Signed-off-by: John Lin <johnlinp@gmail.com>

This commit is missing some justification. In the commit message, we
should mention that `git prune` is a plumbing command and in the
documentation for it, it mentions that the porcelain `git gc` command
should be used instead.

`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>

johnlinp · 2020-06-09T00:22:39Z

Hi Denton, gitgitgadget[bot] <notifications@github.com> 於 2020年6月8日週一下午6:19寫道：

On the Git mailing list, Denton Liu wrote (reply to this): Hi John, Thanks for working on this topic. On Mon, Jun 08, 2020 at 02:02:18AM +0000, John Lin via GitGitGadget wrote: > Subject: [PATCH] Recommend "git gc --prune=now" instead of "git prune" The format for subjects is generally "<area>: <description>" so perhaps something like "git gc: recommend use of `git gc --prune=now`"? > From: John Lin ***@***.***> > > Signed-off-by: John Lin ***@***.***> This commit is missing some justification. In the commit message, we should mention that `git prune` is a plumbing command and in the documentation for it, it mentions that the porcelain `git gc` command should be used instead.

Thank you for the suggestions. I've updated the commit message. Please take a look again. Thanks. Best, John Lin

…

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

johnlinp · 2020-06-09T00:22:51Z

/submit

gitgitgadget · 2020-06-09T00:23:57Z

Submitted as pull.652.v2.git.1591662224566.gitgitgadget@gmail.com

Denton-L · 2020-06-09T01:21:38Z

Thanks for the update, John. By the way, when responding to the emails from the mailing list, you should respond to the actual emails that you get CC'd on. If you respond to the GGG emails from GitHub, the response is only posted here and not everyone checks GitHub regularly.

johnlinp · 2020-06-09T02:38:54Z

Ouch. I didn't notice this. Thanks for telling me. I'll reply to the actual email next time.

gitgitgadget · 2020-06-09T05:11:05Z

On the Git mailing list, Junio C Hamano wrote (reply to this):

"John Lin via GitGitGadget" <gitgitgadget@gmail.com> writes:

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

Much better than v1 that came without any justification ;-)

I however wouldn't say "should not"---that feels a bit too strong (I
personally use "prune" from the command line once or twice every
week and do not see why I should be forbidden from doing so [*1*]),
but the users who see this message would not need such a precise
control afforded by use of "git prune", so "gc --prune=now" is a
better recommendation.

Thanks.

[Footnote]

*1* The command does not even produce a machine readable output.
    The reason it is not recommended (but that is different from
    "should not") to casual users over "git gc" is because it is a
    very focused tool (it is only about removing loose objects and
    does not touch other things) and applicable to a very specific
    condition.  Those who can recognize that they are in that
    situation should not be forbidden from using it with a dogmatic
    "should not".

gitgitgadget · 2020-06-09T11:08:18Z

On the Git mailing list, Ævar Arnfjörð Bjarmason wrote (reply to this):


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

> 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/

> 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

gitgitgadget · 2020-06-09T16:05:28Z

On the Git mailing list, Junio C Hamano wrote (reply to this):

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> On Tue, Jun 09 2020, John Lin via GitGitGadget wrote:
>
>> 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,...

That's perfectly reasonable stance to take.

gitgitgadget · 2020-06-10T03:45:19Z

On the Git mailing list, 林自均 wrote (reply to this):

Hi all,

Thank you Bjarmason & Junio. If Denton doesn't have other concerns,
I'll start working on adding bash completion for "git prune".

Best,
John Lin

Junio C Hamano <gitster@pobox.com> 於 2020年6月10日 週三 上午12:03寫道：
>
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
> > On Tue, Jun 09 2020, John Lin via GitGitGadget wrote:
> >
> >> 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,...
>
> That's perfectly reasonable stance to take.

gitgitgadget · 2020-06-10T03:51:18Z

On the Git mailing list, Denton Liu wrote (reply to this):

On Wed, Jun 10, 2020 at 11:43:09AM +0800, 林自均 wrote:
> Hi all,
> 
> Thank you Bjarmason & Junio. If Denton doesn't have other concerns,
> I'll start working on adding bash completion for "git prune".

No concerns. Thanks for contributing!

gitgitgadget · 2020-06-10T07:39:33Z

On the Git mailing list, 林自均 wrote (reply to this):

Thanks Denton!

Best,
John Lin

Denton Liu <liu.denton@gmail.com> 於 2020年6月10日 週三 上午11:48寫道：
>
> On Wed, Jun 10, 2020 at 11:43:09AM +0800, 林自均 wrote:
> > Hi all,
> >
> > Thank you Bjarmason & Junio. If Denton doesn't have other concerns,
> > I'll start working on adding bash completion for "git prune".
>
> No concerns. Thanks for contributing!

dscho · 2020-06-10T16:46:19Z

Please note that closing PRs and opening new ones loses all history, and also does not add the range-diff that is so helpful for reviewers.

Next time, just force-push to the same PR and /submit again.

johnlinp · 2020-06-13T03:21:42Z

@dscho Thank you for the advice. I would like to ask more about this issue.

I understand that I shouldn't close #651 and create #652 since the 2 PRs are closed related and the history of #651 is important for the reviewers in #652.

However, I think it's clearer to create a new PR for the bash completion of git prune since it's so different from #652. What do you think?

dscho · 2020-06-13T20:15:23Z

Of course, you can do what you want, but if I had submitted these patches, I would have made them v1 and v2.

johnlinp · 2020-06-15T00:17:03Z

I see. Thank you for the suggestions.

gc: recommend git gc --prune=now instead of git prune

42aa638

`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>

johnlinp force-pushed the fix-git-gc-warning-message branch from 83b7137 to 42aa638 Compare June 9, 2020 00:16

johnlinp changed the title ~~Recommend "git gc --prune=now" instead of "git prune"~~ gc: recommend git gc --prune=now instead of git prune Jun 9, 2020

johnlinp mentioned this pull request Jun 10, 2020

Recommend "git gc --auto" instead of "git prune" #651

Closed

johnlinp mentioned this pull request Jun 10, 2020

Add bash completions for git prune #642

Closed

johnlinp closed this Jun 10, 2020

johnlinp deleted the fix-git-gc-warning-message branch June 13, 2020 03:21

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

gc: recommend `git gc --prune=now` instead of `git prune` #652

gc: recommend `git gc --prune=now` instead of `git prune` #652

johnlinp commented Jun 8, 2020 •

edited

johnlinp commented Jun 8, 2020

gitgitgadget bot commented Jun 8, 2020

gitgitgadget bot commented Jun 8, 2020

johnlinp commented Jun 9, 2020 via email

johnlinp commented Jun 9, 2020

gitgitgadget bot commented Jun 9, 2020

Denton-L commented Jun 9, 2020

johnlinp commented Jun 9, 2020

gitgitgadget bot commented Jun 9, 2020

gitgitgadget bot commented Jun 9, 2020

gitgitgadget bot commented Jun 9, 2020

gitgitgadget bot commented Jun 10, 2020

gitgitgadget bot commented Jun 10, 2020

gitgitgadget bot commented Jun 10, 2020

dscho commented Jun 10, 2020

johnlinp commented Jun 13, 2020

dscho commented Jun 13, 2020

johnlinp commented Jun 15, 2020

gc: recommend git gc --prune=now instead of git prune #652

gc: recommend git gc --prune=now instead of git prune #652

Conversation

johnlinp commented Jun 8, 2020 • edited

johnlinp commented Jun 8, 2020

gitgitgadget bot commented Jun 8, 2020

gitgitgadget bot commented Jun 8, 2020

johnlinp commented Jun 9, 2020 via email

johnlinp commented Jun 9, 2020

gitgitgadget bot commented Jun 9, 2020

Denton-L commented Jun 9, 2020

johnlinp commented Jun 9, 2020

gitgitgadget bot commented Jun 9, 2020

gitgitgadget bot commented Jun 9, 2020

gitgitgadget bot commented Jun 9, 2020

gitgitgadget bot commented Jun 10, 2020

gitgitgadget bot commented Jun 10, 2020

gitgitgadget bot commented Jun 10, 2020

dscho commented Jun 10, 2020

johnlinp commented Jun 13, 2020

dscho commented Jun 13, 2020

johnlinp commented Jun 15, 2020

gc: recommend `git gc --prune=now` instead of `git prune` #652

gc: recommend `git gc --prune=now` instead of `git prune` #652

johnlinp commented Jun 8, 2020 •

edited