Junio C Hamano wrote:
> Ramsay Jones <ramsay@xxxxxxxxxxxxxxxxxxx> writes:
>
>> As an alternative, we finesse the problem by renaming the $path
>> variable to $sm_path (submodule path). This fixes the problem on
>> MinGW along with all test failures on cygwin (t7400.{7,32,34},
>> t7406.3 and t7407.{2,6}). We note that the foreach subcommand
>> provides $path to user scripts (ie it is part of the API), so we
>> can't simply rename it to $sm_path.
>
> Which might mean that foreach is unusable on systems whose environment
> variables are case insensitive, as whatever command spawned by foreach
> has its $PATH clobberred.
[sorry for the late reply; I've been away from email for nearly a week.]
No, the foreach command is (mostly) fine; given the fact that the user
script is eval-ed in a context in which $path is not exported. The reason
for the 'mostly' is simply that the user could shoot himself in the
foot by export-ing $path in their script, so that something like:
$ git submodule foreach 'export path; echo $path `git rev-parse HEAD`'
will indeed fail (ie git rev-parse will not execute).
How likely is this to happen? I suspect it would be somewhat rare.
Hmm, does it deserve a note in the docs?
> It is not a regression to them, so it is not
> urgent to address it, but going forward, perhaps we can encourage users
> of _all_ platforms to use $sm_path for portability?
Maybe, but I don't have strong feelings either way. Using $sm_path rather
than $path would, of course, eliminate even the above (very unlikely)
problem ...
ATB,
Ramsay Jones
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html