[PATCH] git-pull: don't complain about branch merge config if only fetching tags

[PATCH] git-pull: don't complain about branch merge config if only fetching tags

[Gerrit Pape]

When running git pull with the -t switch, it properly fetches tags, but
complains about missing information on how to merge.  Since there's
nothing to merge, make git-pull simply exit after fetching the tags.

The problem has been reported by Joey Hess through
 http://bugs.debian.org/456035

Signed-off-by: Gerrit Pape <pape@smarden.org>
---
 git-pull.sh |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/git-pull.sh b/git-pull.sh
index 698e82b..43be0bd 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -112,6 +112,11 @@ case "$merge_head" in
 	     exit 1;;
 	  *) exit $?;;
 	esac
+	# exit if only tags have been fetched
+	not_for_merge=$(sed -e '/	not-for-merge	tag/d' \
+			"$GIT_DIR"/FETCH_HEAD)
+	test "$not_for_merge" != '' || exit 0
+
 	curr_branch=${curr_branch#refs/heads/}
 
 	echo >&2 "You asked me to pull without telling me which branch you"
-- 
1.5.3.7

Re: [PATCH] git-pull: don't complain about branch merge config if only fetching tags

[Junio C Hamano]

Gerrit Pape <pape@smarden.org> writes:

> When running git pull with the -t switch, it properly fetches tags, but
> complains about missing information on how to merge.  Since there's
> nothing to merge, make git-pull simply exit after fetching the tags.
>
> The problem has been reported by Joey Hess through
>  http://bugs.debian.org/456035
>
> Signed-off-by: Gerrit Pape <pape@smarden.org>
> ---
>  git-pull.sh |    5 +++++
>  1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/git-pull.sh b/git-pull.sh
> index 698e82b..43be0bd 100755
> --- a/git-pull.sh
> +++ b/git-pull.sh
> @@ -112,6 +112,11 @@ case "$merge_head" in
>  	     exit 1;;
>  	  *) exit $?;;
>  	esac
> +	# exit if only tags have been fetched
> +	not_for_merge=$(sed -e '/	not-for-merge	tag/d' \
> +			"$GIT_DIR"/FETCH_HEAD)
> +	test "$not_for_merge" != '' || exit 0
> +
>  	curr_branch=${curr_branch#refs/heads/}
>  
>  	echo >&2 "You asked me to pull without telling me which branch you"

I've seen this patch on this list in the past, but isn't "git
pull -t" a user-error?

Re: [PATCH] git-pull: don't complain about branch merge config if only fetching tags

[Gerrit Pape]

On Fri, Dec 21, 2007 at 08:35:13AM -0800, Junio C Hamano wrote:
> Gerrit Pape <pape@smarden.org> writes:
> > When running git pull with the -t switch, it properly fetches tags, but
> > complains about missing information on how to merge.  Since there's
> > nothing to merge, make git-pull simply exit after fetching the tags.

> I've seen this patch on this list in the past, but isn't "git
> pull -t" a user-error?

If so, we shouldn't advertise the -t switch in the git-pull(1) manpage.
As it stands, I'd understand 'git pull -t' as 'fetch _all_ tags and
branch heads and merge according to the configuration'.

Regards, Gerrit.

Re: [PATCH] git-pull: don't complain about branch merge config if only fetching tags

[Junio C Hamano]

Gerrit Pape <pape@smarden.org> writes:

>> I've seen this patch on this list in the past, but isn't "git
>> pull -t" a user-error?
>
> If so, we shouldn't advertise the -t switch in the git-pull(1) manpage.

Perhaps.  Patches are welcomed as always.

> As it stands, I'd understand 'git pull -t' as 'fetch _all_ tags and
> branch heads and merge according to the configuration'.

Yeah, but that would mean that the current error message needs
to be kept, as that is the logical conclusion of "merge
according to the configuration".  Which is not so nice.

Perhaps using the same logic as your patch to detect the case of
"pull --tags and nothing else" case, and exit with non-zero
saying "you probably meant fetch --tags" would be a sane
compromise?  I dunno.

[PATCH] git-pull: warn if only fetching tags with the -t switch

[Gerrit Pape]

Subject: [PATCH] git-pull: warn if only fetching tags with the -t switch

git-pull -t|--tags isn't supposed to be run, remove that option from
fetch-options.txt, and explicitely add it to git-fetch.txt.  Have git pull
still fetch tags with the -t switch, but warn afterwards to better use
git fetch --tags, and error out.
---

How about this?

 Documentation/fetch-options.txt |    8 --------
 Documentation/git-fetch.txt     |    8 ++++++++
 git-pull.sh                     |    9 +++++++++
 3 files changed, 17 insertions(+), 8 deletions(-)

diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index da03422..debdc87 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -29,14 +29,6 @@
 	and stores them locally.  This option disables this
 	automatic tag following.
 
--t, \--tags::
-	Most of the tags are fetched automatically as branch
-	heads are downloaded, but tags that do not point at
-	objects reachable from the branch heads that are being
-	tracked will not be fetched by this mechanism.  This
-	flag lets all tags and their associated objects be
-	downloaded.
-
 -k, \--keep::
 	Keep downloaded pack.
 
diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
index 9003473..3cdac7f 100644
--- a/Documentation/git-fetch.txt
+++ b/Documentation/git-fetch.txt
@@ -33,6 +33,14 @@ OPTIONS
 -------
 include::fetch-options.txt[]
 
+-t, \--tags::
+        Most of the tags are fetched automatically as branch
+        heads are downloaded, but tags that do not point at
+        objects reachable from the branch heads that are being
+        tracked will not be fetched by this mechanism.  This
+        flag lets all tags and their associated objects be
+        downloaded.
+
 include::pull-fetch-param.txt[]
 
 include::urls-remotes.txt[]
diff --git a/git-pull.sh b/git-pull.sh
index 698e82b..ab15eda 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -112,6 +112,15 @@ case "$merge_head" in
 	     exit 1;;
 	  *) exit $?;;
 	esac
+	# warn if only tags have been fetched
+	not_for_merge=$(sed -e '/	not-for-merge	tag/d' \
+			"$GIT_DIR"/FETCH_HEAD)
+	if test "$not_for_merge" = ''; then
+		echo >&2 "Fetching tags only, you probably meant:"
+		echo >&2 "  git fetch --tags"
+		exit 1;
+	fi
+
 	curr_branch=${curr_branch#refs/heads/}
 
 	echo >&2 "You asked me to pull without telling me which branch you"
-- 
1.5.3.7

Re: [PATCH] git-pull: warn if only fetching tags with the -t switch

[Junio C Hamano]

Gerrit Pape <pape@smarden.org> writes:

> Subject: [PATCH] git-pull: warn if only fetching tags with the -t switch
>
> git-pull -t|--tags isn't supposed to be run, remove that option from
> fetch-options.txt, and explicitely add it to git-fetch.txt.  Have git pull
> still fetch tags with the -t switch, but warn afterwards to better use
> git fetch --tags, and error out.
> ---
>
> How about this?

Thanks.

We coulc go with this for the time being for 1.5.4, but I am not
absolutely confident that ...

> +	# warn if only tags have been fetched
> +	not_for_merge=$(sed -e '/	not-for-merge	tag/d' \
> +			"$GIT_DIR"/FETCH_HEAD)
> +	if test "$not_for_merge" = ''; then

... FETCH_HEAD having nothing but not-for-merge tags would
happen _only_ when "pull --tags" is done.  If there are (bogus)
command line other than "pull --tags" that results in this
situation, we would be issuing a wrong error message.

A trivial example.  If you misconfigure your .git/config like
this:

        [remote "origin"]
                url = ...
                fetch = refs/head/*:refs/remotes/origin/*

and say:

	git pull

without even "--tags", then the resulting .git/FETCH_HEAD would
be empty, and the above test will trigger, even though the
correct diagnosis is the error message we currently give the
user.

So in that sense, the patch is a regression as it is.

Come to think of it, "git pull <anything>" is "git fetch
<anything>" followed by "git merge <something>", and what is
fetched by the first step "git fetch" and what is used by the
second step "git merge" are determined by what that <anything>
is.  The rules for the case where <anything> is empty are
clearly defined in the documentation for "git pull" (partly
because it was clear what should happen if <anything> was not
empty back when the documentation was written).

It appears that the explicit case also needs documentation.

The refs fetched are:

 + Having --tags on the command line is the same as replacing
   remote.$remote.fetch with refs/tags/*:refs/tags/* in the
   configuration.

 + If refspecs are explicitly given from the command line, they
   will be the ones that are fetched, and remotes.$remote.fetch
   is consulted unless they come from the above --tags.

 * Otherwise, remotes.$remote.fetch (and its equivalent in
   .git/remotes/$remote) are the ones that are fetched.

 * In addition, if branch.$current_branch.merge is specified but
   is not covered by the above, it also is fetched.

The refs merged are:

 + If refspecs are explicitly given from the command line, they
   will be the ones that are merged (nothing else is merged).

 * Otherwise branch.$current_branch.merge, if exists, is what is
   merged;

 * Otherwise,

   * globbing refspecs are ignored;

   * the first refspec from the configuration (or the equivalent
     from .git/remotes/$remote) is what is merged.

"git pull --tags" tells "git fetch" to fetch tags (and nothing
else -- because there is no explicit refspecs from the command
line, remotes.$remote.fetch which was replaced with the globbing
"grab all tags" is used), and as a result, there will not be
anything that is explicitly specified to be merged.  Because the
user initiated such a "pull", he deserves to be told about the
"mistake".

So (technically) there is no bug but PEBCAK here.  

HOWEVER.

It probably makes sense to change "git fetch [$remote] --tags"
to fetch tags _in addition to_ what are configured to be fetched
by default, instead of replacing as we currently do.  We could
call the current behaviour of --tags a misfeature that invites
the user "mistake".

Such a change will make "--tags" more transparent to the second
"git merge" phase of "git pull".  "git pull --tags [$remote]"
would become equivalent to "git pull [$remote]", except that as
an unrelated side effect it also fetches all tags.  I suspect
that would match the user expectation better.  Daniel, Shawn,
what do you think?

This is a bit more involved change than I would want to have
during -rc freeze.

Re: [PATCH] git-pull: warn if only fetching tags with the -t switch

[Junio C Hamano]

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

> It appears that the explicit case also needs documentation.

But with two "oops-correction"s.

> The refs fetched are:
>
>  + Having --tags on the command line is the same as replacing
>    remote.$remote.fetch with refs/tags/*:refs/tags/* in the
>    configuration.
>
>  + If refspecs are explicitly given from the command line, they
>    will be the ones that are fetched, and remotes.$remote.fetch
>    is consulted unless they come from the above --tags.

s/is consulted/is ignored/;

>  * Otherwise, remotes.$remote.fetch (and its equivalent in
>    .git/remotes/$remote) are the ones that are fetched.
>
>  * In addition, if branch.$current_branch.merge is specified but
>    is not covered by the above, it also is fetched.

s/if /if no explicit refspecs are given and /;

Re: [PATCH] git-pull: warn if only fetching tags with the -t switch

[Daniel Barkalow]

On Thu, 27 Dec 2007, Junio C Hamano wrote:

> Gerrit Pape <pape@smarden.org> writes:
> 
> > Subject: [PATCH] git-pull: warn if only fetching tags with the -t switch
> >
> > git-pull -t|--tags isn't supposed to be run, remove that option from
> > fetch-options.txt, and explicitely add it to git-fetch.txt.  Have git pull
> > still fetch tags with the -t switch, but warn afterwards to better use
> > git fetch --tags, and error out.
> > ---
> >
> > How about this?
> 
> Thanks.
> 
> We coulc go with this for the time being for 1.5.4, but I am not
> absolutely confident that ...
> 
> > +	# warn if only tags have been fetched
> > +	not_for_merge=$(sed -e '/	not-for-merge	tag/d' \
> > +			"$GIT_DIR"/FETCH_HEAD)
> > +	if test "$not_for_merge" = ''; then
> 
> ... FETCH_HEAD having nothing but not-for-merge tags would
> happen _only_ when "pull --tags" is done.  If there are (bogus)
> command line other than "pull --tags" that results in this
> situation, we would be issuing a wrong error message.
> 
> A trivial example.  If you misconfigure your .git/config like
> this:
> 
>         [remote "origin"]
>                 url = ...
>                 fetch = refs/head/*:refs/remotes/origin/*
> 
> and say:
> 
> 	git pull
> 
> without even "--tags", then the resulting .git/FETCH_HEAD would
> be empty, and the above test will trigger, even though the
> correct diagnosis is the error message we currently give the
> user.

Doesn't git-fetch return an error if the only pattern doesn't match 
anything? I think it's a bug in git-fetch if it returns with no helpful 
message and no error status, and a bug in git-pull if the fetch's 
complaint doesn't override any messages git-pull might give afterward. 
After all, the user will still have an unsolved problem if "git fetch" 
above were to succeed silently.

So the only interesting case for git-pull is when MERGE_HEAD is not empty 
after the fetch, but doesn't contain anything marked for merging.

This means that either (1) the default things-to-merge doesn't include 
anything in the default things-to-fetch, and neither was replaced; or (2) 
the default things-to-merge doesn't include anything in the specified 
things-to-fetch, and the things-to-merge wasn't replaced; or (3) the 
specified things-to-merge doesn't include anything in the specified 
things-to-fetch.

(3) is impossible, since you can only specify things-to-merge as what 
you're specifying for things-to-fetch, and the latter is non-empty.

(2) is only possible with --tags, which is (currently) the only thing that 
can remove items from things-to-fetch without replacing things-to-merge as 
well. This is where we want the special error message.

(1) is what we give the usual error message for.

So the sole case I can see where this patch gives the wrong message is 
when the default things-to-fetch, so far as it matches anything, 
matches only tags, and these are not for merging. That is, if you are, in 
fact, fetching tags only, but by virtue of a configuration file that 
fetches tags and doesn't (successfully) fetch anything else.

I'd say, just add a check that --tags was given on the git-pull command 
line to this test.

> Come to think of it, "git pull <anything>" is "git fetch
> <anything>" followed by "git merge <something>", and what is
> fetched by the first step "git fetch" and what is used by the
> second step "git merge" are determined by what that <anything>
> is.  The rules for the case where <anything> is empty are
> clearly defined in the documentation for "git pull" (partly
> because it was clear what should happen if <anything> was not
> empty back when the documentation was written).
> 
> It appears that the explicit case also needs documentation.
> 
> The refs fetched are:
> 
>  + Having --tags on the command line is the same as replacing
>    remote.$remote.fetch with refs/tags/*:refs/tags/* in the
>    configuration.
> 
>  + If refspecs are explicitly given from the command line, they
>    will be the ones that are fetched, and remotes.$remote.fetch
>    is consulted unless they come from the above --tags.
> 
>  * Otherwise, remotes.$remote.fetch (and its equivalent in
>    .git/remotes/$remote) are the ones that are fetched.
> 
>  * In addition, if branch.$current_branch.merge is specified but
>    is not covered by the above, it also is fetched.
> 
> The refs merged are:
> 
>  + If refspecs are explicitly given from the command line, they
>    will be the ones that are merged (nothing else is merged).
> 
>  * Otherwise branch.$current_branch.merge, if exists, is what is
>    merged;
> 
>  * Otherwise,
> 
>    * globbing refspecs are ignored;
> 
>    * the first refspec from the configuration (or the equivalent
>      from .git/remotes/$remote) is what is merged.
> 
> "git pull --tags" tells "git fetch" to fetch tags (and nothing
> else -- because there is no explicit refspecs from the command
> line, remotes.$remote.fetch which was replaced with the globbing
> "grab all tags" is used), and as a result, there will not be
> anything that is explicitly specified to be merged.  Because the
> user initiated such a "pull", he deserves to be told about the
> "mistake".
> 
> So (technically) there is no bug but PEBCAK here.  
> 
> HOWEVER.
> 
> It probably makes sense to change "git fetch [$remote] --tags"
> to fetch tags _in addition to_ what are configured to be fetched
> by default, instead of replacing as we currently do.  We could
> call the current behaviour of --tags a misfeature that invites
> the user "mistake".
> 
> Such a change will make "--tags" more transparent to the second
> "git merge" phase of "git pull".  "git pull --tags [$remote]"
> would become equivalent to "git pull [$remote]", except that as
> an unrelated side effect it also fetches all tags.  I suspect
> that would match the user expectation better.  Daniel, Shawn,
> what do you think?

I think that would be an improvement. I think it would be good if --tags 
weren't a special case (aside from disabling auto-following, which is an 
implementation detail because it's sure not to find anything). The choices 
are:

1) --tags adds tags, not-for-merge to what gets fetched without replacing 
   the usual stuff
2) --tags is equivalent to refs/tag/*:refs/tags/*; tags are fetched and 
   marked for merging (this is unhelpful, of course)
3) As for (2), but make patterns on the command line not-for-merge as a 
   general rule.

I personally like (3), but I think it would be a pain to implement with a 
useful message for git-pull user error unless git-pull had access to the 
info of which defaults fetch used and which were overridden by the command 
line.

On the other hand, the command that's difficult with (1) is "get all of 
the latest tags, but not even the default other refs", and I don't think 
that's something that people actually want to do in general, so it should 
be fine to go with (1).

> This is a bit more involved change than I would want to have
> during -rc freeze.

Certainly. I think, though, that the OP's patch, plus a check that --tags 
was given on the command line in the first place, would be worthwhile.

	-Daniel
*This .sig left intentionally blank*

Re: [PATCH] git-pull: warn if only fetching tags with the -t switch

[Junio C Hamano]

Daniel Barkalow <barkalow@iabervon.org> writes:

> On the other hand, the command that's difficult with (1) is "get all of 
> the latest tags, but not even the default other refs", and I don't think 
> that's something that people actually want to do in general, so it should 
> be fine to go with (1).

I agree.  "Behave as if no --tags was given (so an explicit
refspec on the command line overrides configured ones, or no
explicit refspecs on the command line takes configured ones),
but do not auto-follow tags and fetch all tags as not-for-merge
entries" would be the most sensible semantics for the option, as
you say.

>> This is a bit more involved change than I would want to have
>> during -rc freeze.
>
> Certainly. I think, though, that the OP's patch, plus a check that --tags 
> was given on the command line in the first place, would be worthwhile.

Sounds sensible.

---
 git-pull.sh |   66 +++++++++++++++++++++++++++++++++++-----------------------
 1 files changed, 40 insertions(+), 26 deletions(-)

diff --git a/git-pull.sh b/git-pull.sh
index 698e82b..fa97b0f 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -72,6 +72,40 @@ do
 	shift
 done
 
+error_on_no_merge_candidates () {
+	exec >&2
+	for opt
+	do
+		case "$opt" in
+		-t|--t|--ta|--tag|--tags)
+			echo "Fetching tags only, you probably meant:"
+			echo "  git fetch --tags"
+			exit 1
+		esac
+	done
+
+	curr_branch=${curr_branch#refs/heads/}
+
+	echo "You asked me to pull without telling me which branch you"
+	echo "want to merge with, and 'branch.${curr_branch}.merge' in"
+	echo "your configuration file does not tell me either.  Please"
+	echo "name which branch you want to merge on the command line and"
+	echo "try again (e.g. 'git pull <repository> <refspec>')."
+	echo "See git-pull(1) for details on the refspec."
+	echo
+	echo "If you often merge with the same branch, you may want to"
+	echo "configure the following variables in your configuration"
+	echo "file:"
+	echo
+	echo "    branch.${curr_branch}.remote = <nickname>"
+	echo "    branch.${curr_branch}.merge = <remote-ref>"
+	echo "    remote.<nickname>.url = <url>"
+	echo "    remote.<nickname>.fetch = <refspec>"
+	echo
+	echo "See git-config(1) for details."
+	exit 1
+}
+
 orig_head=$(git rev-parse --verify HEAD 2>/dev/null)
 git-fetch --update-head-ok "$@" || exit 1
 
@@ -105,33 +139,13 @@ merge_head=$(sed -e '/	not-for-merge	/d' \
 case "$merge_head" in
 '')
 	case $? in
-	  0) ;;
-	  1) echo >&2 "You are not currently on a branch; you must explicitly"
-	     echo >&2 "specify which branch you wish to merge:"
-	     echo >&2 "  git pull <remote> <branch>"
-	     exit 1;;
-	  *) exit $?;;
+	0) error_on_no_merge_candidates "$@";;
+	1) echo >&2 "You are not currently on a branch; you must explicitly"
+	   echo >&2 "specify which branch you wish to merge:"
+	   echo >&2 "  git pull <remote> <branch>"
+	   exit 1;;
+	*) exit $?;;
 	esac
-	curr_branch=${curr_branch#refs/heads/}
-
-	echo >&2 "You asked me to pull without telling me which branch you"
-	echo >&2 "want to merge with, and 'branch.${curr_branch}.merge' in"
-	echo >&2 "your configuration file does not tell me either.  Please"
-	echo >&2 "name which branch you want to merge on the command line and"
-	echo >&2 "try again (e.g. 'git pull <repository> <refspec>')."
-	echo >&2 "See git-pull(1) for details on the refspec."
-	echo >&2
-	echo >&2 "If you often merge with the same branch, you may want to"
-	echo >&2 "configure the following variables in your configuration"
-	echo >&2 "file:"
-	echo >&2
-	echo >&2 "    branch.${curr_branch}.remote = <nickname>"
-	echo >&2 "    branch.${curr_branch}.merge = <remote-ref>"
-	echo >&2 "    remote.<nickname>.url = <url>"
-	echo >&2 "    remote.<nickname>.fetch = <refspec>"
-	echo >&2
-	echo >&2 "See git-config(1) for details."
-	exit 1
 	;;
 ?*' '?*)
 	if test -z "$orig_head"