# git pull --upload-pack reversion in git 2.5.0

8 messages from 2015-07-30 to 2015-07-31. Participants: Joey Hess, Matthieu Moy, Junio C Hamano, Paul Tan.
Thread: https://gitlist.dev/t/39973

## Joey Hess, 2015-07-30 15:45

Subject: git pull --upload-pack reversion in git 2.5.0
Message-ID: <20150730154523.GA17002@kitenet.net>
URL: https://gitlist.dev/e/20150730154523.GA17002%40kitenet.net

```
In git 2.1.4, I can run: git pull --upload-pack 'echo --foo'

This also seems to work in 2.4.6, but in 2.5.0, the option parser
does something weird, apparently looking inside the quoted parameter
and parsing parameters in there:

error: unknown option `foo'
usage: git fetch [<options>] [<repository> [<refspec>...]]

Needless to say, this broke my use of --upload-pack.

-- 
see shy jo

```

## Matthieu Moy, 2015-07-30 17:17

Subject: Re: git pull --upload-pack reversion in git 2.5.0
Message-ID: <vpqvbd1k1ke.fsf@anie.imag.fr>
URL: https://gitlist.dev/e/vpqvbd1k1ke.fsf%40anie.imag.fr
In-Reply-To: <20150730154523.GA17002@kitenet.net>

```
Joey Hess <id@joeyh.name> writes:

> In git 2.1.4, I can run: git pull --upload-pack 'echo --foo'
>
> This also seems to work in 2.4.6, but in 2.5.0, the option parser
> does something weird, apparently looking inside the quoted parameter
> and parsing parameters in there:
>
> error: unknown option `foo'
> usage: git fetch [<options>] [<repository> [<refspec>...]]

This bisects down to:

commit e3b601da2af53cbb9a63e59113d524a8d946ea12 (junio/pt/pull-optparse)
Author: Paul Tan <pyokagan@gmail.com>
Date:   Tue Jun 2 22:22:53 2015 +0800

    pull: use git-rev-parse --parseopt for option parsing
    
    To enable unambiguous parsing of abbreviated options, bundled short
    options, separate form options and to provide consistent usage help, use
    git-rev-parse --parseopt for option parsing. With this, simplify the
    option parsing code.
    
    Signed-off-by: Paul Tan <pyokagan@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>

=> Cc-ing Paul.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

```

## Joey Hess, 2015-07-30 18:31

Subject: Re: git pull --upload-pack reversion in git 2.5.0
Message-ID: <20150730183144.GA6360@kitenet.net>
URL: https://gitlist.dev/e/20150730183144.GA6360%40kitenet.net
In-Reply-To: <vpqvbd1k1ke.fsf@anie.imag.fr>

```
I think this comes down to a lack of quoting where git-pull runs
git-fetch. Before eb2a8d9ed3fca2ba2f617b704992d483605f3bb6,
"$@" was passed through to git-fetch, but now there is a $upload_pack
which is passed without being quoted.

-- 
see shy jo

```

## Junio C Hamano, 2015-07-30 18:41

Subject: Re: git pull --upload-pack reversion in git 2.5.0
Message-ID: <CAPc5daXPY7RQSM6oyFYJ2LjYjaT9dDG-+3=nbHONirGh50pdBA@mail.gmail.com>
URL: https://gitlist.dev/e/CAPc5daXPY7RQSM6oyFYJ2LjYjaT9dDG-%2B3%3DnbHONirGh50pdBA%40mail.gmail.com
In-Reply-To: <20150730183144.GA6360@kitenet.net>

```
On Thu, Jul 30, 2015 at 11:31 AM, Joey Hess <id@joeyh.name> wrote:
> I think this comes down to a lack of quoting where git-pull runs
> git-fetch. Before eb2a8d9ed3fca2ba2f617b704992d483605f3bb6,
> "$@" was passed through to git-fetch, but now there is a $upload_pack
> which is passed without being quoted.

Yes, it is not just the matter of using "$upload_pack", though ;-)

${upload_pack+"$upload_pack"} or something.

```

## Matthieu Moy, 2015-07-30 20:40

Subject: [PATCH] pull.sh: quote $upload_pack when passing it to git-fetch
Message-ID: <1438288803-17953-1-git-send-email-Matthieu.Moy@imag.fr>
URL: https://gitlist.dev/e/1438288803-17953-1-git-send-email-Matthieu.Moy%40imag.fr
In-Reply-To: <CAPc5daXPY7RQSM6oyFYJ2LjYjaT9dDG-+3=nbHONirGh50pdBA@mail.gmail.com>

```
The previous code broke for example

  git pull --upload-pack 'echo --foo'

Reported-by: Joey Hess <id@joeyh.name>
Fix-suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
Junio wrote:
> ${upload_pack+"$upload_pack"} or something.

Indeed, we need to pass nothing, not the empty string if $upload_pack
is not defined.

This should fix it.

 git-pull.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/git-pull.sh b/git-pull.sh
index a814bf6..26c5e9f 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -295,7 +295,7 @@ test true = "$rebase" && {
 }
 orig_head=$(git rev-parse -q --verify HEAD)
 git fetch $verbosity $progress $dry_run $recurse_submodules $all $append \
-$upload_pack $force $tags $prune $keep $depth $unshallow $update_shallow \
+${upload_pack+"$upload_pack"} $force $tags $prune $keep $depth $unshallow $update_shallow \
 $refmap --update-head-ok "$@" || exit 1
 test -z "$dry_run" || exit 0
 
-- 
2.5.0.rc0.7.ge1edd74.dirty

```

## Junio C Hamano, 2015-07-30 21:13

Subject: Re: [PATCH] pull.sh: quote $upload_pack when passing it to git-fetch
Message-ID: <xmqq8u9x73hv.fsf@gitster.dls.corp.google.com>
URL: https://gitlist.dev/e/xmqq8u9x73hv.fsf%40gitster.dls.corp.google.com
In-Reply-To: <1438288803-17953-1-git-send-email-Matthieu.Moy@imag.fr>

```
Matthieu Moy <Matthieu.Moy@imag.fr> writes:

> The previous code broke for example
>
>   git pull --upload-pack 'echo --foo'
>
> Reported-by: Joey Hess <id@joeyh.name>
> Fix-suggested-by: Junio C Hamano <gitster@pobox.com>
> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
> ---
> Junio wrote:
>> ${upload_pack+"$upload_pack"} or something.
>
> Indeed, we need to pass nothing, not the empty string if $upload_pack
> is not defined.
>
> This should fix it.

The problematic commit touches a lot more than upload-pack, but all
others that take user-supplied strings are meant for "git merge" or
"git rebase" that are properly quoted and then eval'ed, so this
should be sufficient.

Thanks.

>
>  git-pull.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/git-pull.sh b/git-pull.sh
> index a814bf6..26c5e9f 100755
> --- a/git-pull.sh
> +++ b/git-pull.sh
> @@ -295,7 +295,7 @@ test true = "$rebase" && {
>  }
>  orig_head=$(git rev-parse -q --verify HEAD)
>  git fetch $verbosity $progress $dry_run $recurse_submodules $all $append \
> -$upload_pack $force $tags $prune $keep $depth $unshallow $update_shallow \
> +${upload_pack+"$upload_pack"} $force $tags $prune $keep $depth
> $unshallow $update_shallow \
>  $refmap --update-head-ok "$@" || exit 1
>  test -z "$dry_run" || exit 0

```

## Paul Tan, 2015-07-31 11:01

Subject: Re: [PATCH] pull.sh: quote $upload_pack when passing it to git-fetch
Message-ID: <CACRoPnR5z95xGNgcPThnGO1KfftcETBprs8HyeskroXGD4ZPgw@mail.gmail.com>
URL: https://gitlist.dev/e/CACRoPnR5z95xGNgcPThnGO1KfftcETBprs8HyeskroXGD4ZPgw%40mail.gmail.com
In-Reply-To: <1438288803-17953-1-git-send-email-Matthieu.Moy@imag.fr>

```
On Fri, Jul 31, 2015 at 4:40 AM, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> The previous code broke for example
>
>   git pull --upload-pack 'echo --foo'
>
> Reported-by: Joey Hess <id@joeyh.name>
> Fix-suggested-by: Junio C Hamano <gitster@pobox.com>
> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>

Thanks for cleaning up my mess! ><

Regards,
Paul

```

## Junio C Hamano, 2015-07-31 17:54

Subject: Re: git pull --upload-pack reversion in git 2.5.0
Message-ID: <xmqqk2tg5i2f.fsf@gitster.dls.corp.google.com>
URL: https://gitlist.dev/e/xmqqk2tg5i2f.fsf%40gitster.dls.corp.google.com
In-Reply-To: <CAPc5daXPY7RQSM6oyFYJ2LjYjaT9dDG-+3=nbHONirGh50pdBA@mail.gmail.com>

```
Junio C Hamano <gitster@pobox.com> writes:

> On Thu, Jul 30, 2015 at 11:31 AM, Joey Hess <id@joeyh.name> wrote:
>> I think this comes down to a lack of quoting where git-pull runs
>> git-fetch. Before eb2a8d9ed3fca2ba2f617b704992d483605f3bb6,
>> "$@" was passed through to git-fetch, but now there is a $upload_pack
>> which is passed without being quoted.
>
> Yes, it is not just the matter of using "$upload_pack", though ;-)
>
> ${upload_pack+"$upload_pack"} or something.

Thanks for a bug report.

The next time, I'd appreciate if these regressions are caught before
it hits the tagged release, during the pre-release -rc period at the
latest, but preferrably earlier.  I'm greedy and expect far more
from those who are known to be competent heavy Git users than from
"I update every few releases" casual folks ;-)

Thanks, anyway.

```