git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 2/2] push: --follow-tag

From
Junio C Hamano <gitster@pobox.com>
Date
Mar 5, 2013, 19:17 UTC
Message-ID
<7v6215u05k.fsf@alter.siamese.dyndns.org>
In-Reply-To
<20130305182255.GB10928@sigill.intra.peff.net>
Jeff King <peff@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 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.

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.

Previous: Jeff KingNext: Jeff King
Message 6 of 11 in “commit: add in_merge_bases_many()”
  1. 1/2 commit: add in_merge_bases_many()Junio C Hamano, Mar 5, 2013
  2. 2/2 push: --follow-tagJunio C Hamano, Mar 5, 2013
  3. Jeff KingMar 5, 2013
  4. Michael HaggertyMar 5, 2013
  5. Jeff KingMar 5, 2013
  6. Junio C HamanoMar 5, 2013
  7. Jeff KingMar 5, 2013
  8. Junio C HamanoMar 5, 2013
  9. Jeff KingMar 5, 2013
  10. Junio C HamanoMar 5, 2013
  11. Jeff KingMar 5, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.