{"thread":{"id":"11383","subject":"[PATCH] git-pull: don't complain about branch merge config if only fetching tags","startedAt":"2007-12-21T12:44:00Z","lastAt":"2007-12-28T21:58:43Z","messageCount":9,"participants":["Gerrit Pape","Junio C Hamano","Daniel Barkalow"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"63923","messageId":"20071221124400.20725.qmail@db93e79e204cd8.315fe32.mid.smarden.org","threadId":"11383","inReplyTo":null,"subject":"[PATCH] git-pull: don't complain about branch merge config if only fetching tags","fromName":"Gerrit Pape","fromEmail":"pape@smarden.org","sentAt":"2007-12-21T12:44:00Z","receivedAt":"2007-12-21T12:44:00Z","isPatch":true,"sender":{"key":"pape@smarden.org","avatar":"https://avatars.githubusercontent.com/u/143170252?v=4"},"body":"When running git pull with the -t switch, it properly fetches tags, but\ncomplains about missing information on how to merge. Since there's\nnothing to merge, make git-pull simply exit after fetching the tags.\n\nThe problem has been reported by Joey Hess through\n http://bugs.debian.org/456035\n\nSigned-off-by: Gerrit Pape \n---\n git-pull.sh | 5 +++++\n 1 files changed, 5 insertions(+), 0 deletions(-)\n\ndiff --git a/git-pull.sh b/git-pull.sh\nindex 698e82b..43be0bd 100755\n--- a/git-pull.sh\n+++ b/git-pull.sh\n@@ -112,6 +112,11 @@ case \"$merge_head\" in\n \t exit 1;;\n \t *) exit $?;;\n \tesac\n+\t# exit if only tags have been fetched\n+\tnot_for_merge=$(sed -e '/\tnot-for-merge\ttag/d' \\\n+\t\t\t\"$GIT_DIR\"/FETCH_HEAD)\n+\ttest \"$not_for_merge\" != '' || exit 0\n+\n \tcurr_branch=${curr_branch#refs/heads/}\n \n \techo >&2 \"You asked me to pull without telling me which branch you\"\n-- \n1.5.3.7\n"},{"id":"63932","messageId":"7v8x3oatvi.fsf@gitster.siamese.dyndns.org","threadId":"11383","inReplyTo":"20071221124400.20725.qmail@db93e79e204cd8.315fe32.mid.smarden.org","subject":"Re: [PATCH] git-pull: don't complain about branch merge config if only fetching tags","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-21T16:35:13Z","receivedAt":"2007-12-21T16:35:13Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Gerrit Pape writes:\n\n> When running git pull with the -t switch, it properly fetches tags, but\n> complains about missing information on how to merge. Since there's\n> nothing to merge, make git-pull simply exit after fetching the tags.\n>\n> The problem has been reported by Joey Hess through\n> http://bugs.debian.org/456035\n>\n> Signed-off-by: Gerrit Pape \n> ---\n> git-pull.sh | 5 +++++\n> 1 files changed, 5 insertions(+), 0 deletions(-)\n>\n> diff --git a/git-pull.sh b/git-pull.sh\n> index 698e82b..43be0bd 100755\n> --- a/git-pull.sh\n> +++ b/git-pull.sh\n> @@ -112,6 +112,11 @@ case \"$merge_head\" in\n> \t exit 1;;\n> \t *) exit $?;;\n> \tesac\n> +\t# exit if only tags have been fetched\n> +\tnot_for_merge=$(sed -e '/\tnot-for-merge\ttag/d' \\\n> +\t\t\t\"$GIT_DIR\"/FETCH_HEAD)\n> +\ttest \"$not_for_merge\" != '' || exit 0\n> +\n> \tcurr_branch=${curr_branch#refs/heads/}\n> \n> \techo >&2 \"You asked me to pull without telling me which branch you\"\n\nI've seen this patch on this list in the past, but isn't \"git\npull -t\" a user-error?\n"},{"id":"64120","messageId":"20071227093016.18337.qmail@e6d9fb481b7087.315fe32.mid.smarden.org","threadId":"11383","inReplyTo":"7v8x3oatvi.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] git-pull: don't complain about branch merge config if only fetching tags","fromName":"Gerrit Pape","fromEmail":"pape@smarden.org","sentAt":"2007-12-27T09:30:16Z","receivedAt":"2007-12-27T09:30:16Z","isPatch":true,"sender":{"key":"pape@smarden.org","avatar":"https://avatars.githubusercontent.com/u/143170252?v=4"},"body":"On Fri, Dec 21, 2007 at 08:35:13AM -0800, Junio C Hamano wrote:\n> Gerrit Pape writes:\n> > When running git pull with the -t switch, it properly fetches tags, but\n> > complains about missing information on how to merge. Since there's\n> > nothing to merge, make git-pull simply exit after fetching the tags.\n\n> I've seen this patch on this list in the past, but isn't \"git\n> pull -t\" a user-error?\n\nIf so, we shouldn't advertise the -t switch in the git-pull(1) manpage.\nAs it stands, I'd understand 'git pull -t' as 'fetch _all_ tags and\nbranch heads and merge according to the configuration'.\n\nRegards, Gerrit.\n"},{"id":"64121","messageId":"7vwsr0ifqi.fsf@gitster.siamese.dyndns.org","threadId":"11383","inReplyTo":"20071227093016.18337.qmail@e6d9fb481b7087.315fe32.mid.smarden.org","subject":"Re: [PATCH] git-pull: don't complain about branch merge config if only fetching tags","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-27T10:39:17Z","receivedAt":"2007-12-27T10:39:17Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Gerrit Pape writes:\n\n>> I've seen this patch on this list in the past, but isn't \"git\n>> pull -t\" a user-error?\n>\n> If so, we shouldn't advertise the -t switch in the git-pull(1) manpage.\n\nPerhaps. Patches are welcomed as always.\n\n> As it stands, I'd understand 'git pull -t' as 'fetch _all_ tags and\n> branch heads and merge according to the configuration'.\n\nYeah, but that would mean that the current error message needs\nto be kept, as that is the logical conclusion of \"merge\naccording to the configuration\". Which is not so nice.\n\nPerhaps using the same logic as your patch to detect the case of\n\"pull --tags and nothing else\" case, and exit with non-zero\nsaying \"you probably meant fetch --tags\" would be a sane\ncompromise? I dunno.\n"},{"id":"64122","messageId":"20071227144618.32373.qmail@5b51609f839e87.315fe32.mid.smarden.org","threadId":"11383","inReplyTo":"7vwsr0ifqi.fsf@gitster.siamese.dyndns.org","subject":"[PATCH] git-pull: warn if only fetching tags with the -t switch","fromName":"Gerrit Pape","fromEmail":"pape@smarden.org","sentAt":"2007-12-27T14:46:18Z","receivedAt":"2007-12-27T14:46:18Z","isPatch":true,"sender":{"key":"pape@smarden.org","avatar":"https://avatars.githubusercontent.com/u/143170252?v=4"},"body":"Subject: [PATCH] git-pull: warn if only fetching tags with the -t switch\n\ngit-pull -t|--tags isn't supposed to be run, remove that option from\nfetch-options.txt, and explicitely add it to git-fetch.txt. Have git pull\nstill fetch tags with the -t switch, but warn afterwards to better use\ngit fetch --tags, and error out.\n---\n\nHow about this?\n\n Documentation/fetch-options.txt | 8 --------\n Documentation/git-fetch.txt | 8 ++++++++\n git-pull.sh | 9 +++++++++\n 3 files changed, 17 insertions(+), 8 deletions(-)\n\ndiff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt\nindex da03422..debdc87 100644\n--- a/Documentation/fetch-options.txt\n+++ b/Documentation/fetch-options.txt\n@@ -29,14 +29,6 @@\n \tand stores them locally. This option disables this\n \tautomatic tag following.\n \n--t, \\--tags::\n-\tMost of the tags are fetched automatically as branch\n-\theads are downloaded, but tags that do not point at\n-\tobjects reachable from the branch heads that are being\n-\ttracked will not be fetched by this mechanism. This\n-\tflag lets all tags and their associated objects be\n-\tdownloaded.\n-\n -k, \\--keep::\n \tKeep downloaded pack.\n \ndiff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt\nindex 9003473..3cdac7f 100644\n--- a/Documentation/git-fetch.txt\n+++ b/Documentation/git-fetch.txt\n@@ -33,6 +33,14 @@ OPTIONS\n -------\n include::fetch-options.txt[]\n \n+-t, \\--tags::\n+ Most of the tags are fetched automatically as branch\n+ heads are downloaded, but tags that do not point at\n+ objects reachable from the branch heads that are being\n+ tracked will not be fetched by this mechanism. This\n+ flag lets all tags and their associated objects be\n+ downloaded.\n+\n include::pull-fetch-param.txt[]\n \n include::urls-remotes.txt[]\ndiff --git a/git-pull.sh b/git-pull.sh\nindex 698e82b..ab15eda 100755\n--- a/git-pull.sh\n+++ b/git-pull.sh\n@@ -112,6 +112,15 @@ case \"$merge_head\" in\n \t exit 1;;\n \t *) exit $?;;\n \tesac\n+\t# warn if only tags have been fetched\n+\tnot_for_merge=$(sed -e '/\tnot-for-merge\ttag/d' \\\n+\t\t\t\"$GIT_DIR\"/FETCH_HEAD)\n+\tif test \"$not_for_merge\" = ''; then\n+\t\techo >&2 \"Fetching tags only, you probably meant:\"\n+\t\techo >&2 \" git fetch --tags\"\n+\t\texit 1;\n+\tfi\n+\n \tcurr_branch=${curr_branch#refs/heads/}\n \n \techo >&2 \"You asked me to pull without telling me which branch you\"\n-- \n1.5.3.7\n"},{"id":"64136","messageId":"7vve6je349.fsf@gitster.siamese.dyndns.org","threadId":"11383","inReplyTo":"20071227144618.32373.qmail@5b51609f839e87.315fe32.mid.smarden.org","subject":"Re: [PATCH] git-pull: warn if only fetching tags with the -t switch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-28T06:37:42Z","receivedAt":"2007-12-28T06:37:42Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Gerrit Pape writes:\n\n> Subject: [PATCH] git-pull: warn if only fetching tags with the -t switch\n>\n> git-pull -t|--tags isn't supposed to be run, remove that option from\n> fetch-options.txt, and explicitely add it to git-fetch.txt. Have git pull\n> still fetch tags with the -t switch, but warn afterwards to better use\n> git fetch --tags, and error out.\n> ---\n>\n> How about this?\n\nThanks.\n\nWe coulc go with this for the time being for 1.5.4, but I am not\nabsolutely confident that ...\n\n> +\t# warn if only tags have been fetched\n> +\tnot_for_merge=$(sed -e '/\tnot-for-merge\ttag/d' \\\n> +\t\t\t\"$GIT_DIR\"/FETCH_HEAD)\n> +\tif test \"$not_for_merge\" = ''; then\n\n... FETCH_HEAD having nothing but not-for-merge tags would\nhappen _only_ when \"pull --tags\" is done. If there are (bogus)\ncommand line other than \"pull --tags\" that results in this\nsituation, we would be issuing a wrong error message.\n\nA trivial example. If you misconfigure your .git/config like\nthis:\n\n [remote \"origin\"]\n url = ...\n fetch = refs/head/*:refs/remotes/origin/*\n\nand say:\n\n\tgit pull\n\nwithout even \"--tags\", then the resulting .git/FETCH_HEAD would\nbe empty, and the above test will trigger, even though the\ncorrect diagnosis is the error message we currently give the\nuser.\n\nSo in that sense, the patch is a regression as it is.\n\nCome to think of it, \"git pull \" is \"git fetch\n\" followed by \"git merge \", and what is\nfetched by the first step \"git fetch\" and what is used by the\nsecond step \"git merge\" are determined by what that \nis. The rules for the case where is empty are\nclearly defined in the documentation for \"git pull\" (partly\nbecause it was clear what should happen if was not\nempty back when the documentation was written).\n\nIt appears that the explicit case also needs documentation.\n\nThe refs fetched are:\n\n + Having --tags on the command line is the same as replacing\n remote.$remote.fetch with refs/tags/*:refs/tags/* in the\n configuration.\n\n + If refspecs are explicitly given from the command line, they\n will be the ones that are fetched, and remotes.$remote.fetch\n is consulted unless they come from the above --tags.\n\n * Otherwise, remotes.$remote.fetch (and its equivalent in\n .git/remotes/$remote) are the ones that are fetched.\n\n * In addition, if branch.$current_branch.merge is specified but\n is not covered by the above, it also is fetched.\n\nThe refs merged are:\n\n + If refspecs are explicitly given from the command line, they\n will be the ones that are merged (nothing else is merged).\n\n * Otherwise branch.$current_branch.merge, if exists, is what is\n merged;\n\n * Otherwise,\n\n * globbing refspecs are ignored;\n\n * the first refspec from the configuration (or the equivalent\n from .git/remotes/$remote) is what is merged.\n\n\"git pull --tags\" tells \"git fetch\" to fetch tags (and nothing\nelse -- because there is no explicit refspecs from the command\nline, remotes.$remote.fetch which was replaced with the globbing\n\"grab all tags\" is used), and as a result, there will not be\nanything that is explicitly specified to be merged. Because the\nuser initiated such a \"pull\", he deserves to be told about the\n\"mistake\".\n\nSo (technically) there is no bug but PEBCAK here. \n\nHOWEVER.\n\nIt probably makes sense to change \"git fetch [$remote] --tags\"\nto fetch tags _in addition to_ what are configured to be fetched\nby default, instead of replacing as we currently do. We could\ncall the current behaviour of --tags a misfeature that invites\nthe user \"mistake\".\n\nSuch a change will make \"--tags\" more transparent to the second\n\"git merge\" phase of \"git pull\". \"git pull --tags [$remote]\"\nwould become equivalent to \"git pull [$remote]\", except that as\nan unrelated side effect it also fetches all tags. I suspect\nthat would match the user expectation better. Daniel, Shawn,\nwhat do you think?\n\nThis is a bit more involved change than I would want to have\nduring -rc freeze.\n"},{"id":"64137","messageId":"7vodcbe17f.fsf@gitster.siamese.dyndns.org","threadId":"11383","inReplyTo":"7vve6je349.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] git-pull: warn if only fetching tags with the -t switch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-28T07:19:00Z","receivedAt":"2007-12-28T07:19:00Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> It appears that the explicit case also needs documentation.\n\nBut with two \"oops-correction\"s.\n\n> The refs fetched are:\n>\n> + Having --tags on the command line is the same as replacing\n> remote.$remote.fetch with refs/tags/*:refs/tags/* in the\n> configuration.\n>\n> + If refspecs are explicitly given from the command line, they\n> will be the ones that are fetched, and remotes.$remote.fetch\n> is consulted unless they come from the above --tags.\n\ns/is consulted/is ignored/;\n\n> * Otherwise, remotes.$remote.fetch (and its equivalent in\n> .git/remotes/$remote) are the ones that are fetched.\n>\n> * In addition, if branch.$current_branch.merge is specified but\n> is not covered by the above, it also is fetched.\n\ns/if /if no explicit refspecs are given and /;\n"},{"id":"64151","messageId":"alpine.LNX.1.00.0712281141450.13593@iabervon.org","threadId":"11383","inReplyTo":"7vve6je349.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] git-pull: warn if only fetching tags with the -t switch","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-12-28T17:32:43Z","receivedAt":"2007-12-28T17:32:43Z","isPatch":true,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Thu, 27 Dec 2007, Junio C Hamano wrote:\n\n> Gerrit Pape writes:\n> \n> > Subject: [PATCH] git-pull: warn if only fetching tags with the -t switch\n> >\n> > git-pull -t|--tags isn't supposed to be run, remove that option from\n> > fetch-options.txt, and explicitely add it to git-fetch.txt. Have git pull\n> > still fetch tags with the -t switch, but warn afterwards to better use\n> > git fetch --tags, and error out.\n> > ---\n> >\n> > How about this?\n> \n> Thanks.\n> \n> We coulc go with this for the time being for 1.5.4, but I am not\n> absolutely confident that ...\n> \n> > +\t# warn if only tags have been fetched\n> > +\tnot_for_merge=$(sed -e '/\tnot-for-merge\ttag/d' \\\n> > +\t\t\t\"$GIT_DIR\"/FETCH_HEAD)\n> > +\tif test \"$not_for_merge\" = ''; then\n> \n> ... FETCH_HEAD having nothing but not-for-merge tags would\n> happen _only_ when \"pull --tags\" is done. If there are (bogus)\n> command line other than \"pull --tags\" that results in this\n> situation, we would be issuing a wrong error message.\n> \n> A trivial example. If you misconfigure your .git/config like\n> this:\n> \n> [remote \"origin\"]\n> url = ...\n> fetch = refs/head/*:refs/remotes/origin/*\n> \n> and say:\n> \n> \tgit pull\n> \n> without even \"--tags\", then the resulting .git/FETCH_HEAD would\n> be empty, and the above test will trigger, even though the\n> correct diagnosis is the error message we currently give the\n> user.\n\nDoesn't git-fetch return an error if the only pattern doesn't match \nanything? I think it's a bug in git-fetch if it returns with no helpful \nmessage and no error status, and a bug in git-pull if the fetch's \ncomplaint doesn't override any messages git-pull might give afterward. \nAfter all, the user will still have an unsolved problem if \"git fetch\" \nabove were to succeed silently.\n\nSo the only interesting case for git-pull is when MERGE_HEAD is not empty \nafter the fetch, but doesn't contain anything marked for merging.\n\nThis means that either (1) the default things-to-merge doesn't include \nanything in the default things-to-fetch, and neither was replaced; or (2) \nthe default things-to-merge doesn't include anything in the specified \nthings-to-fetch, and the things-to-merge wasn't replaced; or (3) the \nspecified things-to-merge doesn't include anything in the specified \nthings-to-fetch.\n\n(3) is impossible, since you can only specify things-to-merge as what \nyou're specifying for things-to-fetch, and the latter is non-empty.\n\n(2) is only possible with --tags, which is (currently) the only thing that \ncan remove items from things-to-fetch without replacing things-to-merge as \nwell. This is where we want the special error message.\n\n(1) is what we give the usual error message for.\n\nSo the sole case I can see where this patch gives the wrong message is \nwhen the default things-to-fetch, so far as it matches anything, \nmatches only tags, and these are not for merging. That is, if you are, in \nfact, fetching tags only, but by virtue of a configuration file that \nfetches tags and doesn't (successfully) fetch anything else.\n\nI'd say, just add a check that --tags was given on the git-pull command \nline to this test.\n\n> Come to think of it, \"git pull \" is \"git fetch\n> \" followed by \"git merge \", and what is\n> fetched by the first step \"git fetch\" and what is used by the\n> second step \"git merge\" are determined by what that \n> is. The rules for the case where is empty are\n> clearly defined in the documentation for \"git pull\" (partly\n> because it was clear what should happen if was not\n> empty back when the documentation was written).\n> \n> It appears that the explicit case also needs documentation.\n> \n> The refs fetched are:\n> \n> + Having --tags on the command line is the same as replacing\n> remote.$remote.fetch with refs/tags/*:refs/tags/* in the\n> configuration.\n> \n> + If refspecs are explicitly given from the command line, they\n> will be the ones that are fetched, and remotes.$remote.fetch\n> is consulted unless they come from the above --tags.\n> \n> * Otherwise, remotes.$remote.fetch (and its equivalent in\n> .git/remotes/$remote) are the ones that are fetched.\n> \n> * In addition, if branch.$current_branch.merge is specified but\n> is not covered by the above, it also is fetched.\n> \n> The refs merged are:\n> \n> + If refspecs are explicitly given from the command line, they\n> will be the ones that are merged (nothing else is merged).\n> \n> * Otherwise branch.$current_branch.merge, if exists, is what is\n> merged;\n> \n> * Otherwise,\n> \n> * globbing refspecs are ignored;\n> \n> * the first refspec from the configuration (or the equivalent\n> from .git/remotes/$remote) is what is merged.\n> \n> \"git pull --tags\" tells \"git fetch\" to fetch tags (and nothing\n> else -- because there is no explicit refspecs from the command\n> line, remotes.$remote.fetch which was replaced with the globbing\n> \"grab all tags\" is used), and as a result, there will not be\n> anything that is explicitly specified to be merged. Because the\n> user initiated such a \"pull\", he deserves to be told about the\n> \"mistake\".\n> \n> So (technically) there is no bug but PEBCAK here. \n> \n> HOWEVER.\n> \n> It probably makes sense to change \"git fetch [$remote] --tags\"\n> to fetch tags _in addition to_ what are configured to be fetched\n> by default, instead of replacing as we currently do. We could\n> call the current behaviour of --tags a misfeature that invites\n> the user \"mistake\".\n> \n> Such a change will make \"--tags\" more transparent to the second\n> \"git merge\" phase of \"git pull\". \"git pull --tags [$remote]\"\n> would become equivalent to \"git pull [$remote]\", except that as\n> an unrelated side effect it also fetches all tags. I suspect\n> that would match the user expectation better. Daniel, Shawn,\n> what do you think?\n\nI think that would be an improvement. I think it would be good if --tags \nweren't a special case (aside from disabling auto-following, which is an \nimplementation detail because it's sure not to find anything). The choices \nare:\n\n1) --tags adds tags, not-for-merge to what gets fetched without replacing \n the usual stuff\n2) --tags is equivalent to refs/tag/*:refs/tags/*; tags are fetched and \n marked for merging (this is unhelpful, of course)\n3) As for (2), but make patterns on the command line not-for-merge as a \n general rule.\n\nI personally like (3), but I think it would be a pain to implement with a \nuseful message for git-pull user error unless git-pull had access to the \ninfo of which defaults fetch used and which were overridden by the command \nline.\n\nOn the other hand, the command that's difficult with (1) is \"get all of \nthe latest tags, but not even the default other refs\", and I don't think \nthat's something that people actually want to do in general, so it should \nbe fine to go with (1).\n\n> This is a bit more involved change than I would want to have\n> during -rc freeze.\n\nCertainly. I think, though, that the OP's patch, plus a check that --tags \nwas given on the command line in the first place, would be worthwhile.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"64158","messageId":"7v63yieb1o.fsf@gitster.siamese.dyndns.org","threadId":"11383","inReplyTo":"alpine.LNX.1.00.0712281141450.13593@iabervon.org","subject":"Re: [PATCH] git-pull: warn if only fetching tags with the -t switch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-28T21:58:43Z","receivedAt":"2007-12-28T21:58:43Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow writes:\n\n> On the other hand, the command that's difficult with (1) is \"get all of \n> the latest tags, but not even the default other refs\", and I don't think \n> that's something that people actually want to do in general, so it should \n> be fine to go with (1).\n\nI agree. \"Behave as if no --tags was given (so an explicit\nrefspec on the command line overrides configured ones, or no\nexplicit refspecs on the command line takes configured ones),\nbut do not auto-follow tags and fetch all tags as not-for-merge\nentries\" would be the most sensible semantics for the option, as\nyou say.\n\n>> This is a bit more involved change than I would want to have\n>> during -rc freeze.\n>\n> Certainly. I think, though, that the OP's patch, plus a check that --tags \n> was given on the command line in the first place, would be worthwhile.\n\nSounds sensible.\n\n---\n git-pull.sh | 66 +++++++++++++++++++++++++++++++++++-----------------------\n 1 files changed, 40 insertions(+), 26 deletions(-)\n\ndiff --git a/git-pull.sh b/git-pull.sh\nindex 698e82b..fa97b0f 100755\n--- a/git-pull.sh\n+++ b/git-pull.sh\n@@ -72,6 +72,40 @@ do\n \tshift\n done\n \n+error_on_no_merge_candidates () {\n+\texec >&2\n+\tfor opt\n+\tdo\n+\t\tcase \"$opt\" in\n+\t\t-t|--t|--ta|--tag|--tags)\n+\t\t\techo \"Fetching tags only, you probably meant:\"\n+\t\t\techo \" git fetch --tags\"\n+\t\t\texit 1\n+\t\tesac\n+\tdone\n+\n+\tcurr_branch=${curr_branch#refs/heads/}\n+\n+\techo \"You asked me to pull without telling me which branch you\"\n+\techo \"want to merge with, and 'branch.${curr_branch}.merge' in\"\n+\techo \"your configuration file does not tell me either. Please\"\n+\techo \"name which branch you want to merge on the command line and\"\n+\techo \"try again (e.g. 'git pull ').\"\n+\techo \"See git-pull(1) for details on the refspec.\"\n+\techo\n+\techo \"If you often merge with the same branch, you may want to\"\n+\techo \"configure the following variables in your configuration\"\n+\techo \"file:\"\n+\techo\n+\techo \" branch.${curr_branch}.remote = \"\n+\techo \" branch.${curr_branch}.merge = \"\n+\techo \" remote..url = \"\n+\techo \" remote..fetch = \"\n+\techo\n+\techo \"See git-config(1) for details.\"\n+\texit 1\n+}\n+\n orig_head=$(git rev-parse --verify HEAD 2>/dev/null)\n git-fetch --update-head-ok \"$@\" || exit 1\n \n@@ -105,33 +139,13 @@ merge_head=$(sed -e '/\tnot-for-merge\t/d' \\\n case \"$merge_head\" in\n '')\n \tcase $? in\n-\t 0) ;;\n-\t 1) echo >&2 \"You are not currently on a branch; you must explicitly\"\n-\t echo >&2 \"specify which branch you wish to merge:\"\n-\t echo >&2 \" git pull \"\n-\t exit 1;;\n-\t *) exit $?;;\n+\t0) error_on_no_merge_candidates \"$@\";;\n+\t1) echo >&2 \"You are not currently on a branch; you must explicitly\"\n+\t echo >&2 \"specify which branch you wish to merge:\"\n+\t echo >&2 \" git pull \"\n+\t exit 1;;\n+\t*) exit $?;;\n \tesac\n-\tcurr_branch=${curr_branch#refs/heads/}\n-\n-\techo >&2 \"You asked me to pull without telling me which branch you\"\n-\techo >&2 \"want to merge with, and 'branch.${curr_branch}.merge' in\"\n-\techo >&2 \"your configuration file does not tell me either. Please\"\n-\techo >&2 \"name which branch you want to merge on the command line and\"\n-\techo >&2 \"try again (e.g. 'git pull ').\"\n-\techo >&2 \"See git-pull(1) for details on the refspec.\"\n-\techo >&2\n-\techo >&2 \"If you often merge with the same branch, you may want to\"\n-\techo >&2 \"configure the following variables in your configuration\"\n-\techo >&2 \"file:\"\n-\techo >&2\n-\techo >&2 \" branch.${curr_branch}.remote = \"\n-\techo >&2 \" branch.${curr_branch}.merge = \"\n-\techo >&2 \" remote..url = \"\n-\techo >&2 \" remote..fetch = \"\n-\techo >&2\n-\techo >&2 \"See git-config(1) for details.\"\n-\texit 1\n \t;;\n ?*' '?*)\n \tif test -z \"$orig_head\"\n"}]}