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

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

Gerrit Pape [off-list ref] writes:

quoted

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 ...

quoted

+	# 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*