Re: [PATCH] git pull: Remove option handling done by fetch
- From
Jens Lehmann <jens.lehmann@web.de>
- Date
- Feb 5, 2011, 11:26 UTC
- Message-ID
- <4D4D33E7.4000303@web.de>
- In-Reply-To
- <201102042326.08607.j6t@kdbg.org>
Am 04.02.2011 23:26, schrieb Johannes Sixt:
Show 57 quoted lines
> On Freitag, 4. Februar 2011, Jens Lehmann wrote:
>> In commits be254a0ea9 and 7dce19d374 the handling of the new fetch options
>> "--[no-]recurse-submodules" had been added to git-pull.sh. This was not
>> necessary because all options to "git fetch" are passed to it and handled
>> there, so lets remove them.
>>
>> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
>> ---
>>
>> I noticed this while implementing the on-demand recursive fetch.
>>
>> git-pull.sh | 10 ++--------
>> 1 files changed, 2 insertions(+), 8 deletions(-)
>>
>> diff --git a/git-pull.sh b/git-pull.sh
>> index eb87f49..20a3bbe 100755
>> --- a/git-pull.sh
>> +++ b/git-pull.sh
>> @@ -38,7 +38,7 @@ test -z "$(git ls-files -u)" || die_conflict
>> test -f "$GIT_DIR/MERGE_HEAD" && die_merge
>>
>> strategy_args= diffstat= no_commit= squash= no_ff= ff_only=
>> -log_arg= verbosity= progress= recurse_submodules=
>> +log_arg= verbosity= progress=
>> merge_args=
>> curr_branch=$(git symbolic-ref -q HEAD)
>> curr_branch_short="${curr_branch#refs/heads/}"
>> @@ -105,12 +105,6 @@ do
>> --no-r|--no-re|--no-reb|--no-reba|--no-rebas|--no-rebase)
>> rebase=false
>> ;;
>> - --recurse-submodules)
>> - recurse_submodules=--recurse-submodules
>> - ;;
>> - --no-recurse-submodules)
>> - recurse_submodules=--no-recurse-submodules
>> - ;;
>> --d|--dr|--dry|--dry-|--dry-r|--dry-ru|--dry-run)
>> dry_run=--dry-run
>> ;;
>> @@ -223,7 +217,7 @@ test true = "$rebase" && {
>> done
>> }
>> orig_head=$(git rev-parse -q --verify HEAD)
>> -git fetch $verbosity $progress $dry_run $recurse_submodules
>> --update-head-ok "$@" || exit 1
>>> +git fetch $verbosity $progress $dry_run
>> --update-head-ok "$@" || exit 1 test -z "$dry_run" || exit 0
>>
>> curr_head=$(git rev-parse -q --verify HEAD)
>
> Huh? What will, for example,
>
> git pull --recurse-submodules --no-ff origin
>
> do before and after your patch? Doesn't your patch force users to
> write --[no-]recurse-submodules last?Yes, but isn't that exactly what the pull man-page says? Quote: "Options meant for git pull itself and the underlying git merge must be given before the options meant for git fetch." (The reason I added this option handling in the first place was that I hadn't been aware of this at that time either ... ;-)
Thanks for your review!