> I was wondering if it should be > > sha1=$(git rev-parse --verify "$ref") > > or something that does not dereference a tag at all. > > The way I read what that loop seems to want to do is: > > Read each refname that was given originally from the file > $tempdir/heads, find out the object it used to refer to and > have it in $sha1, find out what new object the object was > rewritten to and have it in $rewritten, and: > > (1) if the rewrite left the object unchanged, do nothing but > warn users just in case this was a mistake; > (2) if the rewrite told us to remove it, then delete the > ref; or > (3) if the rewrite gave us a new object, replace the ref to > point to that new one. > > And in the latter two cases, save the original one in > $orig_namespace so that the user can choose to recover if > this filter-branch was done by mistake. > > So I do not think unwraping the ref at that point makes any sense, > unless it is not prepared to handle annotated tags at all by > unwrapping tags too early. > > What am I missing? > 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?
My initial questions and patching suggestions are based on git 184.108.40.206 behavior. However, playing with git HEAD exhibits a slightly different behavior: it breaks when invoking git mktag line 459 (introduced by 1bf6551e42c79a594689a356a9b14759d55f3cf5): error: char7: could not get SHA1 hash fatal: invalid tag signature file Could not create new tag object for tag-a It's basically the same problem. In my opinion, lines 447-466 should take into account $new_sha1 is empty. Please forgive me again for not having configured my mailer yet :( When I'm ready to provide a patch that implements a solution we all agree with I'll use git send-email. In the mean time, I would like to pursue the discussion in this mail thread so please find attached a patch that deletes a tag instead of invoking the tag-name-filter when it detects $new_sha1 is empty. I tested the patch doesn't break t7003. What do you think? Gregory
Description: Binary data