Re: [PATCH] commit: inform pre-commit if --amend is used

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Nov 24, 2014 at 08:58:37PM -0800, Junio C Hamano wrote:

> Jeff King <peff@xxxxxxxx> writes:
> 
> >   1. It is a bit more obvious when debugging or dumping arguments (e.g.,
> >      via GIT_TRACE), especially if new options are added after the
> >      first.
> >
> >   2. It makes it easier for a script to work on old and new versions of
> >      git. It sees either "amend" or "noamend" for the two obvious cases,
> >      and if it sees no argument, then it knows that it does not know
> >      either way (it is running on an old version of git).
> >
> >      Technically one can tell the difference in shell between an empty
> >      string and a missing argument, but it is sufficiently subtle that I
> >      think "noamend" is a better route.
> 
> If we ever add more info, would we want to keep piling on new
> arguments, though?  Wouldn't it a viable option to use "amend" vs
> not giving anything (not even an empty string), so that normal case
> there won't be no parameter?

Then when you add new arguments, the hook has to search through the
parameters looking for one that matches, rather than just checking "$1"
for "amend" (and "$2" for the new option, and so on). As long as the set
of options remains relatively small, I think that is preferable.

We could also just pass them through the environment, which gives nice
named parameters.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]