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

Re: git filter-branch doesn't dereference annotated tags

From
Grégory Pakosz <gpakosz@visionobjects.com>
Date
Jan 3, 2013, 09:50 UTC
Message-ID
<CAC_01E2HXSnXBgDm=Cbwgi5PbiuHp_qPpoaqT_=pdDWDMnC5jA@mail.gmail.com>
In-Reply-To
<50E55198.5080202@kdbg.org>
Show 11 quoted lines
>
> IOW, if the command was something like
>
>   git filter-branch ...filter options... -- v1.0 master ...
>
> and v1.0 is an annotated tag, then it is reasonable to expect v1.0 to be
> deleted if the commit it points to goes away. But if the commit did not
> go away, but was rewritten, then it is equally reasonable to expect that
> the tag is also rewritten. But I don't think that we currently do the
> latter.
>
When the commit doesn't go away, the tag is currently being rewritten properly.
> Therefore, IMO, a change that implements the former behavior should also
> implement the latter behavior.
>
The patch in my latest email does both. (yet lacks unit tests for now)
Gregory
Previous: Johannes SixtNext: Johannes Sixt
Message 10 of 13 in “git filter-branch doesn't dereference annotated tags”
  1. Grégory PakoszDec 31, 2012
  2. Junio C HamanoDec 31, 2012
  3. Grégory PakoszJan 1, 2013
  4. Junio C HamanoJan 1, 2013
  5. Grégory PakoszJan 1, 2013
  6. Junio C HamanoJan 1, 2013
  7. Grégory PakoszJan 2, 2013
  8. Junio C HamanoJan 2, 2013
  9. Johannes SixtJan 3, 2013
  10. Grégory PakoszJan 3, 2013
  11. Johannes SixtJan 3, 2013
  12. Brandon CaseyJan 3, 2013
  13. Johannes SixtJan 1, 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.