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

[Jeff King <peff@peff.net>]

On Mon, Nov 24, 2014 at 12:21:51PM +0100, Øystein Walle wrote:

>  This hook is invoked by 'git commit', and can be bypassed
> -with `--no-verify` option.  It takes no parameter, and is
> +with `--no-verify` option.  It takes one parameter which is "amend" if
> +`--amend` was used when committing and empty otherwise. It is

This interface change is OK for backwards compatibility, since existing
scripts would not look at the arguments (which are always empty
currently). And I think it is OK for adding new options in the future,
too, because the option is always present (just sometimes as an empty
string).  Can we make the non-amend option something more verbose than
the empty string (like "noamend")? I have two reasons:

  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.

> +# a hook that checks if "amend" is passed as an argument
> +cat > "$HOOK" <<EOF
> +#!/bin/sh
> +test "\$1" = amend
> +EOF

Eric mentioned write_script already (and it would be nice to convert the
existing uses in t7503 to use it). You may also want to use "\EOF" to
inhibit interpolation in the here-document, which means you do not have
to quote variables inside the script.

-Peff