threads / discuss / 50625

is it "git gc --prune=now" or "git gc --prune=all"?

Subject: is it "git gc --prune=now" or "git gc --prune=all"?

## tl;dr

5 messages between Mar 2, 2019 and Mar 11, 2019.

replies: 4people: 3as markdown or json

Robert P. J. Day· Mar 2, 2019, 08:26 UTC · lore
  more pedantry, but digging through "git gc", the man page reads:
       --prune=<date>
           Prune loose objects older than date (default is 2 weeks
           ago, overridable by the config variable gc.pruneExpire).
           --prune=all prunes loose objects regardless of their age
           ^^^^^^^^^^^

but the code for gc.c contains a check for "now" (which actually makes more sense semantically):

  static void add_repack_all_option(struct string_list *keep_pack)
  {
        if (prune_expire && !strcmp(prune_expire, "now"))
                argv_array_push(&repack, "-a");
        else {
        ... snip ...

while the man page does not seem to mention the possible value of "now".

  am i misreading something? should the man page mention the possible
value of "now" as opposed to "all"?
rday
-- 
========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                  http://crashcourse.ca/dokuwiki

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================
Jeff King· Mar 5, 2019, 05:03 UTC · re: Robert P. J. Day · lore

Re: is it "git gc --prune=now" or "git gc --prune=all"?

On Sat, Mar 02, 2019 at 03:26:37AM -0500, Robert P. J. Day wrote:
Show 23 quoted lines
>   more pedantry, but digging through "git gc", the man page reads:
> 
>        --prune=<date>
>            Prune loose objects older than date (default is 2 weeks
>            ago, overridable by the config variable gc.pruneExpire).
>            --prune=all prunes loose objects regardless of their age
>            ^^^^^^^^^^^
> 
> but the code for gc.c contains a check for "now" (which actually makes
> more sense semantically):
> 
>   static void add_repack_all_option(struct string_list *keep_pack)
>   {
>         if (prune_expire && !strcmp(prune_expire, "now"))
>                 argv_array_push(&repack, "-a");
>         else {
>         ... snip ...
> 
> while the man page does not seem to mention the possible value of
> "now".
> 
>   am i misreading something? should the man page mention the possible
> value of "now" as opposed to "all"?

Using "all" would also work. It wouldn't shortcut to using "-a" (which lets pack-objects save a little work), but it is handled in parse_expiry_date() the same as "now". I do think the documentation should recommend "now". Possibly builtin/gc.c should be smarter about recognizing "all" in the conditional you quoted, too, though I don't know that it's all that important (especially if we tweak the documentation).

-Peff
Junio C Hamano· Mar 6, 2019, 00:08 UTC · re: Jeff King · lore

Re: is it "git gc --prune=now" or "git gc --prune=all"?

Jeff King <peff@peff.net> writes:
Show 5 quoted lines
> ... I do think the documentation
> should recommend "now". Possibly builtin/gc.c should be smarter about
> recognizing "all" in the conditional you quoted, too, though I don't
> know that it's all that important (especially if we tweak the
> documentation).

Yup, as the placeholder for the value is labeled as "<date>", "now" would be the one we should be encouraging.

Thanks.
Robert P. J. Day· Mar 9, 2019, 18:13 UTC · re: Junio C Hamano · lore

Re: is it "git gc --prune=now" or "git gc --prune=all"?

On Wed, 6 Mar 2019, Junio C Hamano wrote:
Show 9 quoted lines
> Jeff King <peff@peff.net> writes:
>
> > ... I do think the documentation should recommend "now". Possibly
> > builtin/gc.c should be smarter about recognizing "all" in the
> > conditional you quoted, too, though I don't know that it's all
> > that important (especially if we tweak the documentation).
>
> Yup, as the placeholder for the value is labeled as "<date>", "now"
> would be the one we should be encouraging.
  i can submit an obviously trivial patch for that -- i can see in
date.c the equally valid alternatives:
    int parse_expiry_date(const char *date, timestamp_t *timestamp)
    {
        int errors = 0;
        if (!strcmp(date, "never") || !strcmp(date, "false"))
                *timestamp = 0;
        else if (!strcmp(date, "all") || !strcmp(date, "now"))
        ... snip ...
  is the preference to simply list both alternatives, or to
*encourage* the more intuitive "now" and "never" values while politely
deprecating the others? the impression i get is the latter.
rday
-- 
========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                  http://crashcourse.ca/dokuwiki

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================
Junio C Hamano· Mar 11, 2019, 02:18 UTC · re: Robert P. J. Day · lore

Re: is it "git gc --prune=now" or "git gc --prune=all"?

"Robert P. J. Day" <rpjday@crashcourse.ca> writes:
Show 13 quoted lines
> On Wed, 6 Mar 2019, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> writes:
>>
>> > ... I do think the documentation should recommend "now". Possibly
>> > builtin/gc.c should be smarter about recognizing "all" in the
>> > conditional you quoted, too, though I don't know that it's all
>> > that important (especially if we tweak the documentation).
>>
>> Yup, as the placeholder for the value is labeled as "<date>", "now"
>> would be the one we should be encouraging.
>
>   i can submit an obviously trivial patch for that

You already did to turn --prune=all into --prune=now in the doc, I think.

Do we encourage 'false' where we should encourage 'never'? I see we do not even mention the negative form in git-gc manpage, and I think it is a good thing, especially because --prune=<date> is listed just next to --no-prune, which is even more explicit.

← back to recent threads