On Nov 2, 2010, at 10:28 PM, Jonathan Nieder wrote:
> Kevin Ballard wrote:
>
>> When performing a recursive status or update, any argments with whitespace
>> would be split along that whitespace when passed to the recursive invocation
>> of the update or status command.
>>
>> This is caused by the special handling that sh provides to the $@ variable.
>> Status and update stored "$@" into a separate variable, and passed that
>> variable to the recursive invocation. Unfortunately, the special handling
>> afforded to $@ isn't given to this new variable, and word-breaking occurs
>> along whitespace boundaries.
>>
>> We can use $(git rev-parse --sq-quote "$@") to produce a string containing
>> a quoted version of all given args, suitable for passing to eval. We then
>> recurse using something like `eval cmd_status "$orig_args"` instead of the
>> former `cmd_status $orig_args`. This preserves all arguments exactly as
>> given to the initial invocation of the command.
>
> Probably it is because it is late hear, but I find myself intimidated
> by the block of explanatory text. Maybe an example like
>
> Environment variables only hold strings, not lists of parameters,
> so $orig_args after
>
> orig_args="$@"
>
> fails to remember where each parameter starts and ends, if
> some include whitespace. So
>
> git submodule update \
> --reference='/var/lib/common objects.git' \
> --recursive
>
> becomes
>
> git submodule update --reference=/var/lib/common \
> objects.git --recursive
>
> in the inner repositories. Use "git rev-parse --sq-quote" to
> save parameters in quoted form ready for evaluation by the
> shell, avoiding this problem.
>
> would be simpler?
I agree, yours is simpler. I'll send one final patch with the updated description.
>> --- a/git-submodule.sh
>> +++ b/git-submodule.sh
>> @@ -374,7 +374,7 @@ cmd_init()
>> cmd_update()
>> {
>> # parse $args after "submodule ... update".
>> - orig_args="$@"
>> + orig_args="$(git rev-parse --sq-quote "$@")"
>
> No quotes are needed around the RHS to an assignment like this.
Hrm, looks like you're right. I was under the impression it was necessary in some
cases when the output of the command included newlines, but a quick test shows
that belief to be wrong.
> Anyway,
> Reviewed-by: Jonathan Nieder <jrnieder@xxxxxxxxx>
Thanks.
-Kevin Ballard
--
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