From: Mark Levedahl <mlevedahl@gmail.com>
Date: Thu, 27 Nov 2014 14:40:08 GMT
Subject: Re: [PATCH] commit: inform pre-commit if --amend is used
Message-ID: <547737C8.7070609@gmail.com>
In-Reply-To: <20141125050331.GB20805@peff.net>

On 11/25/2014 12:03 AM, Jeff King wrote:
> On Mon, Nov 24, 2014 at 08:58:37PM -0800, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> 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
>

See http://comments.gmane.org/gmane.comp.version-control.git/148479 for 
an earlier conversation on this exact topic. Also, see 
http://permalink.gmane.org/gmane.comp.version-control.git/148480 for a 
similar change in git-gui.

-Mark