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
More majordomo info at

Reply via email to