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

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

 



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@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


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
--
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]