prevent push of irrelevant tags

Hello,

I just ran into the situation that "git push --tags" pushed tags to the remote repo that point to commits that do not exist there. How can this happen? Well, in my case it was because I have more than one remote repo with non-overlapping tags and they cross-polluted each other. Another possibility that comes to mind is local tags for work-in-progress commits, for example.

Git has the information to know that tag X will be useless in repo Y because the commit Z it points to does not exist in Y. It would be nice if "git push --tags" did the right thing and excluded irrelevant tags when pushing. Thank you for your attention and thank you for git!

Regards

Rolf

Rolf Leggewie <foss@rolf.leggewie.biz> writes:

The "--tags" option is to request to push every ref under refs/tags/ hierarchy, so the answer is "because the user asked to".

No, it doesn't.  

Think of a case where:

 1. You have cloned from your origin.

 2. You built history on top of your 'master' branch, and pushed the
    result. The 'master' at your origin now points at this commit.

 3. Somebody working on the project cloned from the same origin, built
    some history, and pushed the result.  The 'master' at your origin is
    again updated to point at this commit (which is a descendant of the
    commit you made in #2).

 4. You tagged the tip of your 'master' as v1.0.

 5. You give the magic "--relevant-tags-only" option to your "git push".

Now what happens?

The only two things your "git push" knows are that your origin does not have v1.0 tag, and that its 'master' branch points at the commit created by somebody else at #3. Most importantly, it does not have the history leading to this commit ("push" never fetches); it does not have a way to tell if it is a descendant of commit you created in #2. In other words, the magic "--relevant-tags-only" is fundamentally flawed as a concept.

Hamano-San,

thank you very much for the ultra-quick reply and your explanation.

On 13.04.2012 04:07, Junio C Hamano wrote:

I am only a simple user so I hope you will not be angry with me if I
misunderstand you.  I believe you are saying that "git push" does not
have the necessary information which I take your word for.  But git
itself surely should know if commit Z is available from repo Y or am I
mistaken?  For example I can do "git log repoY:master|grep $ZcommitID".
 That would return empty if the master branch at repoY didn't have
information about Z*.

Thank you for bearing with me.

Regards

Rolf

* Of course, it's possible that Z is not part of master but another
  branch at Y.

Rolf Leggewie <foss@rolf.leggewie.biz> writes:

A tag is just a ref like any other.

It is not useless. After you pushed the tag the commit Z it points to exists now in Y as well.

Andreas.