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 metacharacters. > 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 help. Thanks, Jonathan -- 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