Rolf Leggewie <foss@xxxxxxxxxxxxxxxxx> writes:
> 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?
The "--tags" option is to request to push every ref under refs/tags/
hierarchy, so the answer is "because the user asked to".
> Git has the information to know...
No, it doesn't.
> that tag X will be useless in repo Y
> because the commit Z it points to does not exist in Y.
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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html