Jens Lehmann wrote:
> Am 15.10.2013 21:16, schrieb Jonathan Nieder:
>> So I suspect this will fix more scripts than it breaks, though it may
>> still break some. :/
> Hmm, I'm really not sure if we should do this or not.
What convinced me was Anders's observation that the current behavior
can have very bad consequences if a script is passing untrusted input
in multiple arguments to git submodule foreach.
I still haven't found any examples that pass input intended for the
shell to git submodule foreach in multiple arguments. I suspect no
one will notice, except that some scripts (like libreoffice's "g")
start to work better when passed arguments containing shell
> And maybe only change that on a major version bump where people should
> not be terribly surprised about such a change in behavior and are more
> likely to read release notes?
Ok with me, but please don't make it 2.0. :)
> E.g. at
> $dayjob we have foreach commands running in the shell execution for
> quite some jobs on our Jenkins server; nobody would see any warnings
> there until we'd have the reason to dig deeper int the logs because
> something breaks.
Yes, I think that's typical. Warning to stderr probably wouldn't
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