refs/original breaks git-clone for tags (was Re: Tags, Grafts, and Clones, oh my!)

quoted

Thanks for the testcase! Offhand, it definitely looks like a bug.
I'm
investigating to figure out which part of the chain is at fault.

No problem. I was very happily to isolate it outside the large repo I
was working with...

Data from further testing:
- doing a "normal" local clone doesn't emit the error
- a remote clone over ssh does emit the error (so it's not just
file:///)
- in a brand new repo (init'ed, not cloned) 'git fetch ../foo
refs/tags/tagFoo:refs/tags/tagFoo' fails:
error: unable to find 28fffee... (sha of tag object)
- in a brand new repo 'git fetch ../foo
refs/heads/branchFoo:ref/heads/branchFoo' succeeds, and correctly
fetches tagFoo (where branchFoo is created via 'git checkout -b
branchFoo tagFoo')

After a lot of guess and check, it appears the issue is somehow related to the refs/original directory created by filter-branch.  If that directory is moved out of refs/ or deleted the clone succeeds.  Digging further, a simple rename of refs/original/refs/tags/tagFoo to anything else also fixes the problem.

A simplified test case is:

git init foo
cd foo
echo A >> foo.txt
git add foo.txt
git commit -m "Created foo"
git tag -am "Tagging foo" tagFoo
git filter-branch --env-filter 'export GIT_AUTHOR_NAME=xyz123' --tag-name-filter cat -- --all
cd ..
git clone file:///`pwd`/foo newFoo

git clone will "succeed" (exit 0), but throw the error 

   error: refs/tags/tagFoo does not point to a valid object!

and the tagFoo will not exist in the new repo.

(The env-filter is arbitrary, just need something that will force a commit rewrite)  For this bug to occur, the filter-branch must create refs/original/refs/tags/tagFoo, so if the filter-branch command is 

git filter-branch --env-filter 'export GIT_AUTHOR_NAME=xyz123' --tag-name-filter cat master

filter-branch will happily rewrite the tag, but won't create the offending file, so the clone will succeed without error (and the tag will exist in the new repo).  

Removing refs/original is a pretty trivial work-around, so I'm going to modify my scripts and continue working on my SVN transition.  Let me know if I can be of any assistance tracking down the actual bug.

Thanks,
Stephen