git-pull and tag objects

git-pull and tag objects

[Alex Bennee]

Hi,

I have a master repositary which I keep in sync with a CVS server. Each
time it imports a new baseline it tags it with the baseline tag we use.
This allows for easy branching of "baseline" levels.

I have slave repositaries which are cloned of the baseline which I do my
development in. However when I bring the master branch of these work
repositaries upto date (via git-pull ../baseline master) I find the tag
objects are lost. Should they not be part of the tree? After all when I
sync to Linus's kernel repo I get all his version tags as part of that.

-- 
Alex, homepage: http://www.bennee.com/~alex/
"Spare no expense to save money on this one." -- Samuel Goldwyn

Re: git-pull and tag objects

[Alex Riesen]

On 2/8/07, Alex Bennee <kernel-hacker@bennee.com> wrote:
> I have slave repositaries which are cloned of the baseline which I do my
> development in. However when I bring the master branch of these work
> repositaries upto date (via git-pull ../baseline master) I find the tag
> objects are lost. Should they not be part of the tree? After all when I
> sync to Linus's kernel repo I get all his version tags as part of that.

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.

Re: git-pull and tag objects

[Junio C Hamano]

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

[PATCH] git-fetch: document automatic tag following.

[Junio C Hamano]

I've added this to the documentation.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---
 Documentation/git-fetch.txt |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
index 7ecf240..5fbeab7 100644
--- a/Documentation/git-fetch.txt
+++ b/Documentation/git-fetch.txt
@@ -20,6 +20,14 @@ The ref names and their object names of fetched refs are stored
 in `.git/FETCH_HEAD`.  This information is left for a later merge
 operation done by "git merge".
 
+When <refspec> stores the fetched result in tracking branches,
+the tags that point at these branches are automatically
+followed.  This 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.
+
 
 OPTIONS
 -------
-- 
1.5.0.rc4.16.g9e258

Re: git-pull and tag objects

[Theodore Tso]

Thanks for this great explanation of how tags work.  Hopefully some or
all of this can get incorporated into the git's user's manual.
Adding the paragraph to the git-tag as you did in your patch is a
good start, but having the entire explanation of how things work in
the user's manual would be a really good thing, IMHO.

This brings up another question which I've been looking for, but for
which I haven't found a good answer in the git documentation.  A
google search shows a suggestion by hpa (and a brief discussion from
sct) about how to handle conflicting tags back in 2005, but as far as
I can tell it didn't go anywhere.

Anyway, the questions that don't appear to be addressed in the git
documentations are:

1) Suppose I do a "git tag" of a release, and then realize that I
messed up, and I need to do some additional release work (i.e.,
editing a debian changelog file, etc.) before really doing another
release, what do I do to tag a later revision as the "real" version
v1.2?

2) Suppose I have v2.6.20 pointing to a particular revision, which was
obtained from pulling from Linus's tree, and I pull from some other
tree, say the wireless tree, and the maintainer there either
accidentally or maliciously has the tag v2.6.20 pointing to some other
revision.  What happens in that case?  Does the answer change if the
tag is a signed vs. unsigned tag?

3) The git-tag man page talks about GPG signing tags, but it doesn't
talk about how a GPG-signed tag is validated.  Does this happen
manually or automatically?  If it happens manually, how should a tag
be verified?  If the answer is using git-verify-tag, then there should
probably be better references in the documentation to git-verify-tag.
It might also be a very good idea to have a config option which
automatically verifies signed tags.

4) Is there a good/easy way to show whether a tag is a signed
vs. unsigned tag?  Short of using "git cat-file -t <tag>", there
doesn't seem to be, and being forced to use a low-level git command to
get that kind of information seems.... unsatisfactory.

Thanks,

						- Ted

Re: git-pull and tag objects

[Linus Torvalds]

On Sat, 10 Feb 2007, Theodore Tso wrote:
> 
> This brings up another question which I've been looking for, but for
> which I haven't found a good answer in the git documentation.  A
> google search shows a suggestion by hpa (and a brief discussion from
> sct) about how to handle conflicting tags back in 2005, but as far as
> I can tell it didn't go anywhere.

I don't think we've ever had a conflicting tag.

> 1) Suppose I do a "git tag" of a release, and then realize that I
> messed up, and I need to do some additional release work (i.e.,
> editing a debian changelog file, etc.) before really doing another
> release, what do I do to tag a later revision as the "real" version
> v1.2?

Well, if you never pushed anything out, just re-tag it. Use "-f" to 
replace the old one. And you're done.

But if you have pushed things out (or others could just read your 
repository directly), then others will have already seen the old tag. In 
that case you can do one of two things:

 - The sane thing.

   Just admit you screwed up, and use a different name. Others have 
   already seen one tag-name, and if you keep the same name, you may be in 
   the situation that two people both have "version X", but they actually 
   have _different_ "X"'s.

   So just call it "X.1" and be done with it. 

 - The insane thing.

   You really want to call the new version "X" too, _even_though_ others 
   have already seen the old one. So just use "git tag -f" again, as if 
   you hadn't already published the old one.

   HOWEVER!

   Git does *not* (and in my very very strong opinion, MUST NOT!) change 
   tags behind users back. So if somebody already got the old tag, doing a 
   "git pull" on your tree shouldn't just make them overwrite the old one. 

And I really think that git does the right thing. If somebody got a 
release tag from you, you cannot just change the tag for them by updating 
your own one. I think this is a BIG security issue, in that people MUST be 
able to trust their tag-names. If I got a particular tag, NO WAY IN HELL 
must git just replace it for me because you happened to have a newer one!

So if you really want to do the insane thing, you need to just fess up to 
it, and tell people that you messed up. You can do that by making a very 
public announcement saying

  "Ok, I messed up, and I pushed out an earlier version tagged as X. I 
   then fixed somethign, and retagged the *fixed* tree as X again.

   If you got the wrong tag, and want the new one, you'll have to delete 
   the old one and fetch the new one:

	git tag -d X
	git fetch origin X

   to get my updated tag.

   You can test which tag you have by doing

	git rev-parse X

   which should return 0123456789abcdef.. if you have the new version".

Does this seem a bit complicated? HELL YES. But it *should* be. There is 
no way in hell that it would be correct to just "fix" it behind peoples 
backs. People need to know that their tags might have been changed.

> 3) The git-tag man page talks about GPG signing tags, but it doesn't
> talk about how a GPG-signed tag is validated.  Does this happen
> manually or automatically?

Use "git verify-tag X" to see something like this:

	[torvalds@woody linux]$ git-verify-tag v2.6.17
	gpg: Signature made Sat 17 Jun 2006 06:49:59 PM PDT using DSA key ID 76E21CBB
	gpg: Good signature from "Linus Torvalds (tag signing key) <torvalds@osdl.org>"

but you obviously need to have the public key in question available to 
you.

We could verify tags automatically, of course, but the question is, what 
would the policy be? 

(Side note: the 'monotone' people do the trust thing very deep in 
monotone, AND IT IS A COMPLETE DISASTER! I'm surprised they are not only 
continuing with it, they are adding more and more infrastructure exactly 
because once you do it automatically, you need to be able to handle any 
possible policy. It's insane. It's also really sad, because monotone gets 
so many things right. Their security model is just *totally* broken, and 
makes the whole thing be just a steaming pile of shit. Sad. Not that the 
whole C++/boost/STL crap exactly "helps" either, but the security thing 
is probably the more fundamental problem.)

			Linus

Re: git-pull and tag objects

[Jakub Narebski]

Linus Torvalds wrote:
 
> On Sat, 10 Feb 2007, Theodore Tso wrote:

>> 3) The git-tag man page talks about GPG signing tags, but it doesn't
>> talk about how a GPG-signed tag is validated.  Does this happen
>> manually or automatically?
> 
> Use "git verify-tag X" to see something like this:
> 
>       [torvalds@woody linux]$ git-verify-tag v2.6.17
>       gpg: Signature made Sat 17 Jun 2006 06:49:59 PM PDT using DSA key ID 76E21CBB
>       gpg: Good signature from "Linus Torvalds (tag signing key) <torvalds@osdl.org>"
> 
> but you obviously need to have the public key in question available to 
> you.

One of the solutions, used in git.git repository, is to put public key
as a out-of-tree blob using git-hash-object, then tag it using singed tag
with instruction about how to extract key in the tag message (tag comment).

 $ git cat-file -p junio-gpg-pub
 object 0246401b5d117e01717149c413aa2f8702a83d4f
 type blob
 tag junio-gpg-pub
 tagger Junio C Hamano <junkio@cox.net> Tue Dec 13 16:33:29 2005 -0800

 GPG key to sign git.git archive.

 This blob object contains the GPG public key I use to sign git.git
 archive.

 To use it to verify tags I signed, do:

   $ git-cat-file blob junio-gpg-pub | gpg --import

 to import it into your keyring, and then

   $ git-verify-tag $tag_to_be_verified

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: git-pull and tag objects

[Linus Torvalds]

On Sat, 10 Feb 2007, Jakub Narebski wrote:
> 
> One of the solutions, used in git.git repository, is to put public key
> as a out-of-tree blob using git-hash-object, then tag it using singed tag
> with instruction about how to extract key in the tag message (tag comment).

No. That's horrible. Yes, it's what Junio did, but if you don't trust the 
archive, the _last_ thing you should do is to depend on a blob in the 
archive itself to contain the thing to make you trust it more.

So you want to get the gpg public key from somewhere else to be able to 
_independently_ verify that it's ok.

Otherwise, somebody could just totally replace the object with one of 
their own, and then _claim_ that the public key they made is 
"junio-gpg-pub", and fool people into thinkign it's signed by Junio.

So to get a valid chain of trust, you really have to have some sideband 
channel to get you started. There's a lot of infrastructure for that 
elsewhere (ie the whole "sign other peoples keys" thing that is so central 
to pgp), but even if you don't have a key to start with, you're actually 
better off getting a key (even with no other validation) from an 
independent source than have it be in the repository itself. Because at 
least then any attacker has to fake _two_ things, rather than just a 
single repo.

Of course, in *practice* this is not a problem. And, in fact, thanks to 
git's SHA1 setup, you obviously don't have to really verify the key itself 
in git, you really only want to verify that yes, the object name is 
correct (ie if you get some sideband information from Junio that the 
"object 0246401b5d117e01717149c413aa2f8702a83d4f" really is Junio's key, 
that's sufficient in itself).

(The "sideband channel" can be something as simple as google. For example, 
if you just google for the SHA1 of the tag itself, you'll actually get a 
lot of hits for it - a0e7d36193b96f552073558acf5fcc1f10528917 (which is 
not the key itself, but it is the tag that points to it, which in turn is 
signed with the key) shows up in manyplaces, and that very fact in itself 
is "interesting" as a sideband information. It's not "proof", but it's 
certainly one piece of information that may make you more comfortable with 
that tag not being something recent and fake - it's been around and been 
quoted by me in email archives, so if it's faked, it's fooled a number of 
people).

		Linus

Re: git-pull and tag objects

[Theodore Tso]

On Sat, Feb 10, 2007 at 09:56:25AM -0800, Linus Torvalds wrote:
> We could verify tags automatically, of course, but the question is, what 
> would the policy be? 

What I would propose (post-1.5.0!) is that the policy file be local to
the repository, and consist of an ordered list of regular expressions
and and lists of PGP keys associated with each regexp.  So for
example, I might have in my repository a config file which states that
any tag that matches v2.6.[0-9]+ and v2.6.[0-9]+-rc[0-9]+ must be
signed by PGP key 0x76E21CBB (Linus's key).

What I would very much like is for the tags to be automatically
verified whenever I do a git-fetch operation, and for me to get a big,
fat, warning if some tag isn't signed by an authoried key.

So this would help make sure that when I'm pulling from kernel.org,
I'm getting something that originally came from Linus, and someone
hasn't managed to insert trojan into the git tree, but it doesn't help
in between releases.  In order to solve that problem we would have to
have some kind of scheme where branch heads could be optionally
signed, and then transfered over to the public repository.  Then, in
the git config file, we could list an expected set of keys that should
sign any branch head for a particular tracking branch.  

Since all of this is local policy, someone who wanted to have a
different set of trusted peers, they could do so.  And, of course,
someone who wanted to run completely open with no gpg signature
checking at all could do so.  (aka "rms/rms mode" :-)

Does this make sense?

						- Ted

Re: git-pull and tag objects

[Linus Torvalds]

On Sat, 10 Feb 2007, Theodore Tso wrote:
> 
> What I would propose (post-1.5.0!) is that the policy file be local to
> the repository, and consist of an ordered list of regular expressions
> and and lists of PGP keys associated with each regexp.  So for
> example, I might have in my repository a config file which states that
> any tag that matches v2.6.[0-9]+ and v2.6.[0-9]+-rc[0-9]+ must be
> signed by PGP key 0x76E21CBB (Linus's key).

Actually, I think you can do it already.

I think the "update" hook runs whenever we're pulling a ref, once for each 
ref. It might happen just for pushing to a remote, though.

Anyway, with a hook, it's easy enough to just add exactly the kind of 
thing you are outlining, and yes, it would be repository-local.

		Linus

Re: git-pull and tag objects

[Junio C Hamano]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> But if you have pushed things out (or others could just read your 
> repository directly), then others will have already seen the old tag. In 
> that case you can do one of two things:
> ...
>  - The insane thing.
>
>    You really want to call the new version "X" too, _even_though_ others 
>    have already seen the old one. So just use "git tag -f" again, as if 
>    you hadn't already published the old one.
>
>    HOWEVER!
>
>    Git does *not* (and in my very very strong opinion, MUST NOT!) change 
>    tags behind users back. So if somebody already got the old tag, doing a 
>    "git pull" on your tree shouldn't just make them overwrite the old one. 
>
> And I really think that git does the right thing. If somebody got a 
> release tag from you, you cannot just change the tag for them by updating 
> your own one. I think this is a BIG security issue, in that people MUST be 
> able to trust their tag-names. If I got a particular tag, NO WAY IN HELL 
> must git just replace it for me because you happened to have a newer one!
>
> So if you really want to do the insane thing, you need to just fess up to 
> it, and tell people that you messed up.

Confession time.

Although it is correct that the people who already saw the
original tag would not lose the tag object from their repository
when you publish a replacement tag, we have _always_ overwritten
the refs/tags/$tag to point at the new one, effectively losing
the original.

* 0a623e7c (Jul 5, 2005)
In this version "git fetch $repo tag v2.6.13" would have done just

	echo "$head" >"$GIT_DIR/$destination"

without checking if it already existed.

* ae2da406 (Aug 22, 2005)

We started checking if the fetched/followed tag already existed
with this version.  However, the result of the check was only
used to say "$tagname: updating with $new_sha1 from $old_sha1"
in the status message.

And after numerous code reorganizations of git-fetch throughout
its life, this logic has never been touched.  This comment
around ll. 170 we currently have:

    case "$1" in
    refs/tags/*)
	# Tags need not be pointing at commits so there
	# is no way to guarantee "fast-forward" anyway.

was introduced with 853a3697 (Aug 20, 2005) and stayed there
ever since.

I think it is worth fixing this by tightening the rule as you
described, even with this late in the game for 1.5.0.  The user
either needs to force it, or remove it beforehand.


diff --git a/git-fetch.sh b/git-fetch.sh
index 357cac2..1078016 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -169,14 +169,18 @@ update_local_ref () {
 
     case "$1" in
     refs/tags/*)
-	# Tags need not be pointing at commits so there
-	# is no way to guarantee "fast-forward" anyway.
+	# Tags should never be blindly overwritten without user's
+	# consent.
 	if test -n "$oldshort_"
 	then
 		if now_=$(git show-ref --hash "$1") && test "$now_" = "$2"
 		then
 			[ "$verbose" ] && echo >&2 "* $1: same as $3"
 			[ "$verbose" ] && echo >&2 "  $label_: $newshort_" ||:
+		elif test -z "$force$single_force"
+		then
+			echo >&2 "* $1: refusing to update with $3"
+			false
 		else
 			echo >&2 "* $1: updating with $3"
 			echo >&2 "  $label_: $newshort_"

Re: git-pull and tag objects

[Linus Torvalds]

On Sat, 10 Feb 2007, Junio C Hamano wrote:
> 
> Although it is correct that the people who already saw the
> original tag would not lose the tag object from their repository
> when you publish a replacement tag, we have _always_ overwritten
> the refs/tags/$tag to point at the new one, effectively losing
> the original.
> 
> * 0a623e7c (Jul 5, 2005)
> In this version "git fetch $repo tag v2.6.13" would have done just
> 
> 	echo "$head" >"$GIT_DIR/$destination"
> 
> without checking if it already existed.

Yes, but only if you actually explicitly asked for it, methinks.

If you just do a "git pull", it won't do it.

So I think it's ok. 

		Linus

Re: git-pull and tag objects

[Junio C Hamano]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Sat, 10 Feb 2007, Junio C Hamano wrote:
>> 
>> Although it is correct that the people who already saw the
>> original tag would not lose the tag object from their repository
>> when you publish a replacement tag, we have _always_ overwritten
>> the refs/tags/$tag to point at the new one, effectively losing
>> the original.
>> 
>> * 0a623e7c (Jul 5, 2005)
>> In this version "git fetch $repo tag v2.6.13" would have done just
>> 
>> 	echo "$head" >"$GIT_DIR/$destination"
>> 
>> without checking if it already existed.
>
> Yes, but only if you actually explicitly asked for it, methinks.
>
> If you just do a "git pull", it won't do it.
>
> So I think it's ok. 

Well, what you are saying is that it used to be Ok in Jul 5 2005
version but with tag following it is not Ok anymore, isn't it?

Re: git-pull and tag objects

[Junio C Hamano]

Junio C Hamano <junkio@cox.net> writes:

> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
>> So I think it's ok. 
>
> Well, what you are saying is that it used to be Ok in Jul 5 2005
> version but with tag following it is not Ok anymore, isn't it?

Oops. I misread my own code.

You are right.  We filter and refetch only the ones we do not
have, so we are Ok.

Sorry for the noise.

Re: git-pull and tag objects

[Linus Torvalds]

On Sun, 11 Feb 2007, Junio C Hamano wrote:
> 
> Well, what you are saying is that it used to be Ok in Jul 5 2005
> version but with tag following it is not Ok anymore, isn't it?

Do we actually do it with automatic tag following? I tested, and it didn't 
do anything bad for me.

		Linus

Re: git-pull and tag objects

[Junio C Hamano]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Sun, 11 Feb 2007, Junio C Hamano wrote:
>> 
>> Well, what you are saying is that it used to be Ok in Jul 5 2005
>> version but with tag following it is not Ok anymore, isn't it?
>
> Do we actually do it with automatic tag following? I tested, and it didn't 
> do anything bad for me.

You are right.

The only iffy case that is remaining is "git fetch --tags $URL".
The user is explicitly saying "I want all tags from there", but
the user may not be expecting tags that are already present in
the local repository to be overwritten.

The filtering on the auto-follow codepath Johannes added with
"git-show-ref --exclude-existing" would fix this case as well.

-- >8 --
[PATCH] "git-fetch --tags $URL" should not overwrite existing tags

Use the same --exclude-existing filter as we use for automatic
tag following to avoid overwriting existing tags with replacement
ones the other side created.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/git-fetch.sh b/git-fetch.sh
index 357cac2..ca984e7 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -253,23 +253,10 @@ if test "$tags"
 then
 	taglist=`IFS='	' &&
 		  echo "$ls_remote_result" |
+		  git-show-ref --exclude-existing=refs/tags/ |
 	          while read sha1 name
 		  do
-			case "$sha1" in
-			fail)
-				exit 1
-			esac
-			case "$name" in
-			*^*) continue ;;
-			refs/tags/*) ;;
-			*) continue ;;
-			esac
-		  	if git-check-ref-format "$name"
-			then
-			    echo ".${name}:${name}"
-			else
-			    echo >&2 "warning: tag ${name} ignored"
-			fi
+			echo ".${name}:${name}"
 		  done` || exit
 	if test "$#" -gt 1
 	then

Re: git-pull and tag objects

[Junio C Hamano]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Sat, 10 Feb 2007, Jakub Narebski wrote:
>> 
>> One of the solutions, used in git.git repository, is to put public key
>> as a out-of-tree blob using git-hash-object, then tag it using singed tag
>> with instruction about how to extract key in the tag message (tag comment).
>
> No. That's horrible. Yes, it's what Junio did, but if you don't trust the 
> archive, the _last_ thing you should do is to depend on a blob in the 
> archive itself to contain the thing to make you trust it more.

True.  I should have made it clear it was purely a convenient
way for people to get the public key and verifying that key
needs to be done on a separate channel.  Otherwise it would have
confused people (exactly like Jakub was confused).

Re: git-pull and tag objects

[Jakub Narebski]

Junio C Hamano wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>> On Sat, 10 Feb 2007, Jakub Narebski wrote:
>>> 
>>> One of the solutions, used in git.git repository, is to put public key
>>> as a out-of-tree blob using git-hash-object, then tag it using singed tag
>>> with instruction about how to extract key in the tag message (tag comment).
>>
>> No. That's horrible. Yes, it's what Junio did, but if you don't trust the 
>> archive, the _last_ thing you should do is to depend on a blob in the 
>> archive itself to contain the thing to make you trust it more.
> 
> True.  I should have made it clear it was purely a convenient
> way for people to get the public key and verifying that key
> needs to be done on a separate channel.  Otherwise it would have
> confused people (exactly like Jakub was confused).

Gaah, perhaps I wasn't clear: I mentioned this as a method to _transfer_
the actual data for public key (I thought the question was about that).
Not that one should place any trust because tags are signed by in-repo
key...

-- 
Jakub Narebski
Poland

Re: git-pull and tag objects

[Theodore Tso]

On Sat, Feb 10, 2007 at 09:52:29PM -0800, Junio C Hamano wrote:
> Although it is correct that the people who already saw the
> original tag would not lose the tag object from their repository
> when you publish a replacement tag, we have _always_ overwritten
> the refs/tags/$tag to point at the new one, effectively losing
> the original.

So I have a suspicion that I have multiple tag objects with the same
tag name (E2FSPROGS-1_26), from doing an hg conversion.  Is there an
easy way to search all of the tag objects in my git repository to see
if this is the case, so I can delete them lest they cause any
confusion/problems?

						- Ted

Re: git-pull and tag objects

[Junio C Hamano]

Theodore Tso <tytso@mit.edu> writes:

> On Sat, Feb 10, 2007 at 09:52:29PM -0800, Junio C Hamano wrote:
>> Although it is correct that the people who already saw the
>> original tag would not lose the tag object from their repository
>> when you publish a replacement tag, we have _always_ overwritten
>> the refs/tags/$tag to point at the new one, effectively losing
>> the original.
>
> So I have a suspicion that I have multiple tag objects with the same
> tag name (E2FSPROGS-1_26), from doing an hg conversion.  Is there an
> easy way to search all of the tag objects in my git repository to see
> if this is the case, so I can delete them lest they cause any
> confusion/problems?

"fsck --full" should report "dangling tag".

Re: git-pull and tag objects

[Linus Torvalds]

On Mon, 12 Feb 2007, Junio C Hamano wrote:
> 
> "fsck --full" should report "dangling tag".

Well, except if
 - you've pruned
 - the importer never imported anything but the most recent one.

One thing that _might_ be a good idea for tags (if people _really_ want to 
actually update tags under the same name) is to have a "parent" pointer 
for tag objects, the same way we have for commits. That way you could - if 
you really wanted to - create a chain of tags, and show the history of 
them.

Now, I personally think you'd be better off just having separate names, 
but for something like a "passed testing" tag, it might be valid to (a) 
have the last one and (b) have a history chain. And it's not like it would 
be technically "hard" to do.

I dunno. Personally I'd rather try to just tell people to not re-use 
tag-names, because it kind of destroys the whole point of a tag ("I 
checked out tag X!" just leadsto "_Which_ X?").

And you could certainly do the "passed testing" thing with commits in a 
separate branch instead: you'd create the "testing" branch, which is 
always a set of commits that have as their primary parent the commit that 
got tested, and as the second parent the previous commit in the "testing" 
series).

So _generally_ I think we're better off keeping things the way they are, 
but on the other hand, if only to work well with idiotic systems that 
mis-use tags in ways that tags shouldn't be used, we *could* just extend 
on what tyou can do with a git tag too..

		Linus

Re: git-pull and tag objects

[Junio C Hamano]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Mon, 12 Feb 2007, Junio C Hamano wrote:
>> 
>> "fsck --full" should report "dangling tag".
>
> Well, except if
>  - you've pruned
>  - the importer never imported anything but the most recent one.

True -- but Ted was talking about look for them in order to
eradicate them, so if you've pruned or never had one, you are
Ok.

> One thing that _might_ be a good idea for tags (if people _really_ want to 
> actually update tags under the same name) is to have a "parent" pointer 
> for tag objects, the same way we have for commits. That way you could - if 
> you really wanted to - create a chain of tags, and show the history of 
> them.
> ...
> I dunno. Personally I'd rather try to just tell people to not re-use 
> tag-names, because it kind of destroys the whole point of a tag ("I 
> checked out tag X!" just leadsto "_Which_ X?").

I agree.

> And you could certainly do the "passed testing" thing with commits in a 
> separate branch instead: you'd create the "testing" branch, which is 
> always a set of commits that have as their primary parent the commit that 
> got tested, and as the second parent the previous commit in the "testing" 
> series).

I personally feel that that kind of commit is misusing the
parent field (for one thing, it would not play well with merges
at all, although people who abuse commits to record non-ancestry
structure may not even be interested in merging such things so
it may not be a problem in practice).  If people want to express
relationship between commits (and other objects in general)
other than ancestry, I think it would be cleaner to allow a tag
to have more than one pointers to other objects.

I know you are against arbitrary pointers inside objects that
does not have semantic meaning, and I agree.  Probably your
"previous version of this tag was that one" is better than "more
than one arbitrary pointers" in that sense.

But I do not know how useful a linear history of tags are; it is
semantically the same as v1.5.0, v1.5.0.1, v1.5.0.2, ... sequence.

Re: git-pull and tag objects

[Johannes Schindelin]

Hi,

On Tue, 13 Feb 2007, Junio C Hamano wrote:

> Linus Torvalds <torvalds@linux-foundation.org> writes:
> 
> > And you could certainly do the "passed testing" thing with commits in 
> > a separate branch instead: you'd create the "testing" branch, which is 
> > always a set of commits that have as their primary parent the commit 
> > that got tested, and as the second parent the previous commit in the 
> > "testing" series).
> 
> I personally feel that that kind of commit is misusing the parent field 
> (for one thing, it would not play well with merges at all, although 
> people who abuse commits to record non-ancestry structure may not even 
> be interested in merging such things so it may not be a problem in 
> practice).

I don't think it is misusing the parent field, but I would make the 
primary parent the ancestor in terms of testing. In a very real sense, 
this maps the history -- not of development, but of testing. It also makes 
sense to bisect on this line of history.

The chance of a mismerge is somewhat real, though. At first I thought that 
you'd need a special script anyway, until I realized that it's just a 
matter of "git merge -s theirs <from-devel>".

Ciao,
Dscho

Re: git-pull and tag objects

[Linus Torvalds]

On Wed, 14 Feb 2007, Johannes Schindelin wrote:
> 
> The chance of a mismerge is somewhat real, though. At first I thought that 
> you'd need a special script anyway, until I realized that it's just a 
> matter of "git merge -s theirs <from-devel>".

In fact, it's even quite doable as

	git commit-tree theirs^{tree} -p HEAD -p theirs < changelog

(choose your parent order at will) so it's not as if it's much of a 
"script". It's a core command to do something like this.

Using "git commit -s theirs" might not work (shouldn't, but I didn't test) 
for the first entry, so you probably *do* want to script this regardless. 
But git makes it really really easy.

		Linus

Re: git-pull and tag objects

[Jakub Narebski]

Linus Torvalds wrote:

> One thing that _might_ be a good idea for tags (if people _really_ want to 
> actually update tags under the same name) is to have a "parent" pointer 
> for tag objects, the same way we have for commits. That way you could - if 
> you really wanted to - create a chain of tags, and show the history of 
> them.

Wouldn't it be better to just use reflog for given tag? That assuming of
course that we could protect tag reflog from pruning...
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: git-pull and tag objects

[Johannes Schindelin]

Hi,

[*SIGH* I am Cc'ing Linus, since you -- again -- forgot that]

On Thu, 15 Feb 2007, Jakub Narebski wrote:

> Linus Torvalds wrote:
> 
> > One thing that _might_ be a good idea for tags (if people _really_ 
> > want to actually update tags under the same name) is to have a 
> > "parent" pointer for tag objects, the same way we have for commits. 
> > That way you could - if you really wanted to - create a chain of tags, 
> > and show the history of them.
> 
> Wouldn't it be better to just use reflog for given tag? That assuming of 
> course that we could protect tag reflog from pruning...

No. Reflogs are a local thing, tags not necessarily. And much fun 
"pushing" a reflog to another repo.

Ciao,
Dscho