Thread (7 messages) flat view 7 messages, 4 authors, 2016-06-15

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

From: Johannes Sixt <hidden>
Date: 2016-06-15 22:55:38

Am 03.01.2013 00:19, schrieb Junio C Hamano:
Grégory Pakosz [off-list ref] writes:
quoted
So we have an annotated tag that points to a commit that is rewritten
to nothing as the result of the filtering. What should happen?
If the user asked to filter that tag itself, it may make sense to
remove it, rather than keeping it pointing at the original commit,
because the commit it used to point at no longer exists in the
alternate history being created by filter-branch.
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.

Therefore, IMO, a change that implements the former behavior should also
implement the latter behavior.

-- Hannes
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help