Re: git-pull and tag objects

[Junio C Hamano <junkio@cox.net>]

"Alex Riesen" <raa.lkml@gmail.com> writes:

> You have to use "git pull ../baseline master:somewhere".
> This "master:somewhere" expression makes git fetch and stores
> the tags along with the branch' commits. Better yet, create an
> entry in remotes: .git/remotes or .git/config, depending on the version
> of git you have. The current master on kernel.org has the support
> for latter (branches in .git/config), which will also be in the upcoming
> release 1.5.

While this is technically correct, the automatic tag following
performed by git-fetch (git-pull invokes git-fetch internally
and it is done as the side effect) probably needs a bit more
detailed explanation.

Automatic tag following is done by first fetching from the
remote using the given <refspec>s, and if the repository has
objects that are pointed by remote tags that it does not yet
have, then fetch those missing tags.  If the other end has tags
that point at branches you are not interested in, you will not
get them.

There are currently two ways for you to get tags and one and
half ways to decline.

 * "git fetch --tags URL <refspec>..." will download all tags.
   This has nothing to do with the automatic following.

 * "git fetch URL <refspec>..." (including the case where
   <refspec>s are taken from the configuration files) will
   trigger automatic tag following only when <refspec>s store
   the fetch result in tracking branches (this is what raa
   pointed out)

 * "git fetch --no-tags URL <refspec>..." forbids automatic tag
   following, even when <refspec>s are the tracking kind.

The other half way to decline that is implicit in the above is
to use <refspec>s that do not store the result in tracking
branches.

Now, the --no-tags option means "Do not automatically follow
tags".  But the --tags option does not mean the opposite.  It
means "Do fetch _all_ tags".  We do not have an explicit option
that says "Do follow tags".  It is implicitly decided based on
the kind of <refspec>.

This is not a problem in practice and is a good heuristics that
does the right thing for both people near the toplevel and
people who only follow others trees.

If you are following somebody else's tree, you are most likely
using tracking branches (refs/heads/origin in traditional
layout, or refs/remotes/origin/master in the separate-remote
layout).  You usually want the tags from the other end.

On the other hand, if you are fetching because you would want a
one-shot merge from somebody else, you typically do not want to
get tags from there.  This happens more often for people near
the toplevel but not limited to them.  Mere mortals when pulling
from each other do not necessarily want to automatically get
private 'anchor point' tags from the other person.

You would notice "please pull" messages on the mailing list says
repo URL and branch name alone.  This is designed to be easily
cut&pasted to "git fetch" command line:

	Linus, please pull from

        	git://git..../proj.git master

	to get the following updates...

becomes:

        $ git pull git://git..../proj.git master

In such a case, you do not want to automatically follow other's
tags.

One important aspect of git is it is distributed, and being
distributed largely means there is no inherent "upstream" or
"downstream" in the system.  On the face of it, the above
example might seem to indicate that the tag namespace is owned
by upper echelon of people and tags only flow downwards, but
that is not the case.  It only shows that the usage pattern
determines who are interested in whose tags.

A one-shot pull is a sign that a commit history is now crossing
the boundary between one circle of people (e.g. "people who are
primarily interested in networking part of the kernel") who may
have their own set of tags (e.g. "this is the third release
candidate from the networking group to be proposed for general
consumption with 2.6.21 release") to another circle of people
(e.g. "people who integrate various subsystem improvements").
The latter are usually not interested in the detailed tags used
internally in the former group (that is what "internal" means).
That is why it is desirable not to follow tags automatically in
this case.

It may well be that among networking people, they may want to
exchange the tags internal to their group, but in that workflow
they are most likely tracking with each other's progress by
having tracking branches.  Again, the existing heuristic would
automatically follow such tags and that is a good thing.

Although I do not think it is necessary for the above reasons,
if somebody wanted to do it, it is easy and straightforward to
make the automated tag following more orthogonal by letting you
pass --do-follow-tags to "git fetch" to explicitly tell it to
follow tags even when you are not tracking the other side.

--
diff --git a/git-fetch.sh b/git-fetch.sh
index 357cac2..aef2159 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -17,6 +17,7 @@ IFS="$LF"
 
 no_tags=
 tags=
+follow_tags=
 append=
 force=
 verbose=
@@ -46,6 +47,9 @@ do
 	-t|--t|--ta|--tag|--tags)
 		tags=t
 		;;
+	--fol|--foll|--follo|--follow)
+		follow_tags=t
+		;;
 	-n|--n|--no|--no-|--no-t|--no-ta|--no-tag|--no-tags)
 		no_tags=t
 		;;
@@ -454,12 +458,11 @@ fetch_main () {
 fetch_main "$reflist" || exit
 
 # automated tag following
-case "$no_tags$tags" in
-'')
-	case "$reflist" in
-	*:refs/*)
-		# effective only when we are following remote branch
-		# using local tracking branch.
+if test -z "$no_tags$tags" && {
+	test -n "$follow_tags" ||
+	case "$reflist" in *:refs/*) :;; *) false ;; esac
+   }
+then
 		taglist=$(IFS='	' &&
 		echo "$ls_remote_result" |
 		git-show-ref --exclude-existing=refs/tags/ |
@@ -469,7 +472,6 @@ case "$no_tags$tags" in
 			echo >&2 "Auto-following $name"
 			echo ".${name}:${name}"
 		done)
-	esac
 	case "$taglist" in
 	'') ;;
 	?*)
@@ -477,7 +479,7 @@ case "$no_tags$tags" in
 		shallow_depth=
 		fetch_main "$taglist" || exit ;;
 	esac
-esac
+fi
 
 # If the original head was empty (i.e. no "master" yet), or
 # if we were told not to worry, we do not have to check.