On Wed, Nov 28, 2012 at 4:22 AM, Jeff King <p...@peff.net> wrote:
> On Wed, Nov 28, 2012 at 04:15:12AM +0100, Felipe Contreras wrote:
>> > We could improve the test in t5801, but it is nice to let people on such
>> > systems test it, as well. And the infrastructure might be useful if we
>> > ever acquire more bash scripts.
>> >
>> > There's a fair bit of boilerplate, but I think this squashable patch
>> > would do it:
>> Yeah, but I wonder what's the point of installing this script, it's
>> mostly for testing and reference, and to add a whole category for that
>> seems like overkill.
> There's no point in installing it; I just didn't make the effort to
> avoid doing so (note that testpy and testsvn are also installed, which
> are in the same boat; it might make sense to split them all out like we
> do for $TEST_PROGRAMS).
> I agree it's an annoying amount of boilerplate, but it seems simpler
> cognitively to me for it to behave as the other SCRIPT_* builds than to
> do something simple but inconsistent.
> I do not care enough to argue about it. We need to do something to fix
> the impending test breakage on systems like Solaris. I have posted the
> patch to handle BASH_PATH, so do what you want.

I'm not objecting to the change, I'm simply wondering.

Personally I think switching to '/usr/bin/env bash' should be enough
for now. Doing a grep on my git installation throws this:

% grep '/usr/bin/env' -r /opt/git
/opt/git/libexec/git-core/git-instaweb:#!/usr/bin/env ruby

So it's doubtful a lack of /usr/bin/env would cause any more breakages
than it already does for test-git.

And this just landed on 'pu', I don't think there's anything big
impending. If the /usr/bin/env solution turned out to be not enough
for some reason, we can deal with it then. That's my opinion.


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

Reply via email to