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 <p...@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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
