Re: [PATCH/RFC] commit: add short option for --amend

From: Duy Nguyen <pclouds@gmail.com>
Date: Aug 17, 2018, 14:33 UTC
Message-ID: <CACsJy8Di4GQLqkBmcnrfmU9aS=wizxU36Ly0BRgDEDmFG=+2Fg@mail.gmail.com>
In-Reply-To: <20180817064734.GB131749@aiede.svl.corp.google.com>

On Fri, Aug 17, 2018 at 8:47 AM Jonathan Nieder <jrnieder@gmail.com> wrote:

Show 18 quoted lines

>
> Nguyễn Thái Ngọc Duy wrote:
>
> > --- a/builtin/commit.c
> > +++ b/builtin/commit.c
> > @@ -1489,7 +1489,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
> >                           STATUS_FORMAT_LONG),
> >               OPT_BOOL('z', "null", &s.null_termination,
> >                        N_("terminate entries with NUL")),
> > -             OPT_BOOL(0, "amend", &amend, N_("amend previous commit")),
> > +             OPT_BOOL('j', "amend", &amend, N_("amend previous commit")),
> [...]
> > Thoughts?
>
> I'm not a fan.  I would have trouble remembering what the short option
> name means, and it matches the common --jobs option for parallelism
> that many commands use.  "git commit --am" works today already and
> doesn't run into those problems.

The alternative is -A or -M which may be easier associated with --amend. That "--am" also would break the moment somebody adds --amsomething.

Show 9 quoted lines

> I'm sympathetic to the goal of saving typing, but I'm more sympathetic
> to the goal of making user support easier, which is what makes me end
> up there.
>
> That said, I've been looking recently at Mercurial's "hg evolve"
> extension[1] and I wouldn't be against a well thought out new command
> (e.g. "git amend") that does the equivalent of "git commit --amend"
> with some related features.  So I think there are some paths forward
> that involve abbreviating.

I'm not opposed to a new command like this, but I don't think it should stop us from adding short options.

-- 
Duy