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