On Tue, Mar 05, 2013 at 11:17:11AM -0800, Junio C Hamano wrote: > 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. That depends on the specifics of the rule. If the rule is "any commit that the server already has", then yes, it runs afoul of that problem. But what if it is "any commit in the ref update being sent"? That is, we would look at the range "origin/master..master" and send any tags that point to commits in that range. > 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 v1.8.1.6, continue working > without being able to push perhaps due to network disruption, and > have already started building towards v1.8.1.7 when the network > comes back. 'maint' may be past v1.8.1.6 and its tip won't be > pointing at that tag, but it still is missing from the public > repository. Right, I think "tags at the tip" is too likely to miss things you did want to send. > 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. I know, and I'm willing to accept that the right resolution is "we should not have this feature" (or possibly "the documentation must warn about caveats of the feature). I'm just worried about it accidentally being misused and causing problems. -Peff -- 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