Re: Silly "git gc" UI issue.

Christian Couder writes: > On Sat, Apr 21, 2018 at 5:13 AM, Junio C Hamano wrote: > >> @@ -388,6 +389,9 @@ int cmd_gc(int argc, const char **argv, const char >> *prefix) >> if (argc > 0) >>

Re: Silly "git gc" UI issue.

On Sat, Apr 21, 2018 at 5:13 AM, Junio C Hamano wrote: > @@ -388,6 +389,9 @@ int cmd_gc(int argc, const char **argv, const char > *prefix) > if (argc > 0) > usage_with_options(builtin_gc_usage, builtin_gc_options); > > + if (prune_expire &&

Re: Silly "git gc" UI issue.

Simon Ruderich writes: > On Thu, Apr 19, 2018 at 02:10:40PM +0900, Junio C Hamano wrote: >> diff --git a/parse-options-cb.c b/parse-options-cb.c >> index c6679cb2cd..872627eafe 100644 >> --- a/parse-options-cb.c >> +++ b/parse-options-cb.c >> @@ -38,7 +38,11 @@ int

Re: Silly "git gc" UI issue.

On Thu, Apr 19, 2018 at 02:10:40PM +0900, Junio C Hamano wrote: > diff --git a/parse-options-cb.c b/parse-options-cb.c > index c6679cb2cd..872627eafe 100644 > --- a/parse-options-cb.c > +++ b/parse-options-cb.c > @@ -38,7 +38,11 @@ int parse_opt_approxidate_cb(const struct option *opt, > const

Re: Silly "git gc" UI issue.

Simon Ruderich writes: > On Thu, Apr 19, 2018 at 10:52:47AM +0900, Junio C Hamano wrote: >> It turns out that prune silently goes away given a bad expiry >> >> $ git prune --expire=nyah ; echo $? >> 129 > > I noticed that git log --since/--after/--before/--until have

Re: Silly "git gc" UI issue.

On Thu, Apr 19, 2018 at 10:52:47AM +0900, Junio C Hamano wrote: > It turns out that prune silently goes away given a bad expiry > > $ git prune --expire=nyah ; echo $? > 129 I noticed that git log --since/--after/--before/--until have a similar behavior and ignore date parsing errors in

Re: Silly "git gc" UI issue.

Linus Torvalds writes: > Maybe something like the attached patch? Then I get: > ... > [torvalds@i7 linux]$ time git gc --prune=npw > fatal: Failed to parse prune expiry value npw > > real0m0.004s > user0m0.002s > sys

Re: Silly "git gc" UI issue.

Linus Torvalds writes: > Yes, I get that nice "malformed expiration date 'npw'" error, but I > get it after 64 seconds has passed. Ah, that timing aspect of the issue didn't occur to me. The patch indeed is a reasonable workaround. Thanks.

Re: Silly "git gc" UI issue.

On Wed, Apr 18, 2018 at 7:16 PM, Junio C Hamano wrote: > A few commands that parse --expire= command line option > behaves silly when given nonsense input. For example So this patch definitely improves on the error message. But look at what happens for the kernel:

Re: Silly "git gc" UI issue.

On Wed, Apr 18, 2018 at 6:52 PM, Junio C Hamano wrote: > > Regardless of your originai "git gc" issue, we should make "prune" > say something on this error. And when we do so, I would think that > error message will come before the final "error: failed to run > prune". So to

Re: Silly "git gc" UI issue.

A few commands that parse --expire= command line option behaves silly when given nonsense input. For example $ git prune --no-expire Segmentation falut $ git prune --expire=npw; echo $? 129 Both come from parse_opt_expiry_date_cb(). The former is because the function is not

Re: Silly "git gc" UI issue.

Junio C Hamano writes: > It turns out that prune silently goes away given a bad expiry > > $ git prune --expire=nyah ; echo $? > 129 > > Regardless of your originai "git gc" issue, we should make "prune" > say something on this error. And when we do so, I would think

Re: Silly "git gc" UI issue.

Linus Torvalds writes: > You get this: > >git gc --prune=npw > > Yeah, that "npw" should be "now", which is where the klutz thing comes in. > > It turns out that git reacts ridiculously badly to this. $ git gc --prune=npw Counting objects: 10, done.

Silly "git gc" UI issue.

Ok, this is ridiculous, but I've done it several times, so I thought I'd finally mention it to somebody on the git list that may care: "My name is Linus, and I'm a klutz". what does that have to do with anything? Now, imagine you're a klutz. Imagine you want to clean up your .git directory.