Jeff King <p...@peff.net> writes:
> Yeah, I think that is another sensible variant. It does not really
> "backfill" in the way that Junio's patch does (e.g., if you forgot to
> push out v1.6 to a remote 2 weeks ago and now you are pushing out v1.7,
> Junio's patch will magically fill it in).
I may have tentatively tagged the tip of 'master' as v1.8.2 in my
private repository, started the integration testing, but may not be
confident enough to push out the branch nor the tag yet. I may have
an experimental topic that I want to share with others before I am
done with the release to unblock them, and the topic may build on
the 'master' I may or may not want to redo before the release.
I can do so with "git push github jc/topic" (no --follow-tags).
After doing such a "you may want to start with this" push, I can
continue working on the release, and the 'master' branch may turn
out to be good to go without redoing.
A later "git push github --follow-tags master" in such a case should
send v1.8.2 out. It is inexcuable to break it, saying "Oh, I've
seen that commit already---it is part of the previous update to
jc/topic". That defeats the whole point of --follow-tags.
The other "tags at the tip" is slightly less problematic than
"ignore the commits the receiving end has already seen", but it will
break if I tag the tip of 'maint' as v188.8.131.52, continue working
without being able to push perhaps due to network disruption, and
have already started building towards v184.108.40.206 when the network
comes back. 'maint' may be past v220.127.116.11 and its tip won't be
pointing at that tag, but it still is missing from the public
While I agree with your goal to make it safer to use "push", both
"ignore commits that the receiving end already saw" and "only look
at the commits at the tip being sent" castrate the option too much
to the point that it is meaningless. The whole point of asking
explicitly with the "--follow-tags" option to "push" to push out
relevant tags is, eh, to push out relevant tags. I do not think it
is magical at all. "backfill" is an integral part of the option.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html