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

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

From
Jeff King <peff@peff.net>
Date
Mar 5, 2013, 17:22 UTC
Message-ID
<20130305172233.GA9379@sigill.intra.peff.net>
In-Reply-To
<7vlia1vnwq.fsf@alter.siamese.dyndns.org>
On Tue, Mar 05, 2013 at 07:58:45AM -0800, Junio C Hamano wrote:
Show 9 quoted lines
> > This will find anything under refs/tags, including annotated and
> > non-annotated tags. I wonder if it is worth making a distinction. In
> > many workflows, unannotated tags should not be leaked out to public
> > repos. But because this feature finds any reachable tags, it will push a
> > tag you made a long time ago as a bookmarker on some part of the history
> > unrelated to the release you are making now.
> 
> What does the auto-follow feature of "git fetch" do currently?
> Whatever we do here on the "git push" side should match it.

It fetches anything in refs/tags, unannotated or not. And that is certainly a point in favor of "git push" doing the same.

But I wonder if fetching and pushing are different in that respect. You are (usually) fetching from a public publishing point, and it is assumed that whatever is there is useful for sharing. The only reason to limit it is to save time transferring objects the user does not want.

But for "push", you are on the publishing side, which usually means you need to be a little more careful. It is not just an optimization; it is about deciding what should be shared. You do not want to accidentally push cruft or work in progress in your private repository. I think it's the same logic that leads us to fetch "refs/heads/*" by default, but only push "matching" (or more recently "HEAD").

Show 6 quoted lines
> If somebody wants to add some form of filtering mechanism based on
> the tagname (e.g. '--auto-follow-tags=v[0-9]*'), I would not have a
> strong objection to it, but I think that is something we should do
> on top and consistently between fetch and push.  I am not thrilled
> by the idea of conflating annotated-ness and the public-ness of
> tags.

I don't like it either. But I also don't want to introduce a feature that causes people to accidentally publish cruft. It may not be a problem in practice; I'm just thinking out loud at this point.

-Peff
Previous: Junio C HamanoNext: Junio C Hamano
Message 9 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.