On Fri, Aug 17, 2018 at 8:47 AM Jonathan Nieder <jrnieder@xxxxxxxxx> wrote:
>
> 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.
> 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
