Grégory Pakosz <gpak...@visionobjects.com> writes: > in my use case, $ref is "refs/tags/4.0" which is an annotated tag > > $ git rev-parse "refs/tags/4.0" > e941b1999906c17b59320f776d58b71fc2fcdb72
Yeah, but in that case it appears to me that you told the command to rewrite the tag itself and the history behind the commit the tag refers to, but the end result did not rewrite the tag itself and left the tag pointing at the original history. The "$rewritten" variable being empty in this codepath tells me that the command decided that it *does* want to delete the tag, but as J6t mentioned in his review, it is unclear to me what is expected by the user. If the command and the filters you gave the command decided the tag should be removed, then not being able to delete it is a problem and the code you patched that compares the object name of the tag and the object name of the commit the tag refers to is certainly doing a wrong comparison. But I have this suspicion that you did not want to remove the tag in the first place. The application of "map" shell function to obtain $rewritten is done on the unwrapped object name by passing "$ref^0" to rev-parse, but perhaps that "^0" is the real source of the problem instead, so that it checks what new object the original annotated tag was rewritten to? If the tag object was rewritten, either to empty to signal its removal or to a new object name, then we do want to update-ref it, but the decision should be made on its object name, not the object name of the commit it points at? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
