Re: [PATCH 1/2] do not mangle short options which take arguments

From: Jeff King <peff@peff.net>
Date: Oct 2, 2009, 07:57 UTC
Message-ID: <20091002075724.GC27664@coredump.intra.peff.net>
In-Reply-To: <20091002073628.GA9444@localhost>

On Fri, Oct 02, 2009 at 09:36:28AM +0200, Clemens Buchacher wrote:

> Yes, that syntax looks reasonable. I expect this to be more involved, so I
> will rework the patch once we agree on whether or not we want it at all.

Thanks.

> Yes, that can happen. On the other hand, the "-ammend" typo actually did
> happen.

It did, but we are only guessing at how many people will be disrupted by the new rule. That being said...

Show 9 quoted lines

> And what I'm even more worried about are ambiguities like
> 
>   $ git commit -uno <path>
>   $ git commit -nou <path>
> 
> which are interpreted as one of
> 
>   $ git commit --untracked-files=no <path>
>   $ git commit --untracked-files --no-verify --only <path>

Making this clearer is a much more compelling argument to me. Though I thought it was customary (not just for git, but for other programs) that a short option that takes a parameter (even an optional one) would consume the rest of a short options string. Still, it is a potential source of confusion.

Show 5 quoted lines

> > On the other hand, the cuddled value already has some DWYM magic (it
> > recognizes -amend), so it is already a little bit unsafe to use
> 
> Well, an error message is a lot safer than executing something you did not
> intend.

It's also an error exit code, which can affect how a script performs (e.g., "git diff --exit-code"). But I don't have any real examples off the top of my head of how this could be particularly disastrous, so feel free to dismiss that as pushing too far into the hypothetical.

-Peff