Thread (3 messages) flat view 3 messages, 2 authors, 2016-06-15

Re: [PATCH] git pull: Remove option handling done by fetch

From: Jens Lehmann <hidden>
Date: 2016-06-15 22:50:30

Am 04.02.2011 23:26, schrieb Johannes Sixt:
On Freitag, 4. Februar 2011, Jens Lehmann wrote:
quoted
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 <redacted>
---

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
quoted
+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!
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help