Re: What's cooking in git.git (Jan 2010, #01; Mon, 04)

Jeff King [off-list ref] writes:

On Mon, Jan 04, 2010 at 05:35:07PM -0800, Junio C Hamano wrote:

quoted

quoted

1. My patch "t0021:..." contains an unrelated change to t4030 (it
changes a /bin/sh to $SHELL_PATH) that is not necessary. I included it
in my first version of the patch, but later noticed that we already
have many similar uses of /bin/sh instead of $SHELL_PATH in test
scriptlets and decided to remove the change, but I only changed the
commit message and forgot to unstage t4030.

While you are technically correct that the change you made in t4030 is not
justified by the commit log message in the sense that the "hexdump" script
will go through run_command() interface and is not subject to the special
rules filter writers need to keep in mind, the patch text itself is a good
change, isn't it?  Do you want me to split the commit into two (one with
the current message with a patch only to t0021, and another to t4030 with
a justification like "SHELL_PATH is what the user told us to use")?

If we are going to do the t4030 change, there are a ton of other spots
that use /bin/sh directly (I counted 38 with

  grep -n /bin/sh * | grep -v :1:

). Should we be changing all of them?

It is slightly just code churn, because the scripts are so simple that
even broken shells like Solaris /bin/sh run them just fine. The only
real advantage is that it slightly future-proofs them against somebody
making them more complex.

Ok, it is a single liner that invokes Perl, so hardcoded /bin/sh is a much
lessor offence.