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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> > 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]