Your message dated Thu, 14 Mar 2013 15:36:07 -0400 (EDT)
with message-id <[email protected]>
and subject line Re: fixed (git clone: refs/original from filter-branch
prevents clone of tags)
has caused the Debian Bug report #595911,
regarding git clone: refs/original from filter-branch prevents clone of tags
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
595911: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595911
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: git
Version: 1:1.6.5-1
Severity: important
Tags: upstream
Forwarded: http://thread.gmane.org/gmane.comp.version-control.git/153967
Stephen Bash wrote:
> and finally one last filter-branch to permanently commit the grafts.
>
> Unfortunately I'm running into a problem with cloning the resulting
> repository.
[...]
> error: refs/tags/tagFoo does not point to a valid object!
The problem seems to have something to do with the refs/original
namespace, since deleting those refs fixes it. Reproduction script:
-- 8< --
#!/bin/sh
mkdir foo &&
(
cd foo &&
git init &&
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
) &&
git clone file:///`pwd`/foo newFoo
-- >8 --
> 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.
Bisects to
commit 5bdc32d3e50d8335c65e136e6b5234c5dd92a7a9
Author: Nicolas Pitre <[email protected]>
Date: Fri Sep 25 23:54:42 2009 -0400
make 'git clone' ask the remote only for objects it cares about
Current behavior of 'git clone' when not using --mirror is to fetch
everything from the peer, and then filter out unwanted refs just before
writing them out to the cloned repository. This may become highly
inefficient if the peer has an unusual ref namespace, or if it simply
has "remotes" refs of its own, and those locally unwanted refs are
connecting to a large set of objects which becomes unreferenced as soon
as they are fetched.
Let's filter out those unwanted refs from the peer _before_ asking it
what refs we want to fetch instead, which is the most logical thing to
do anyway.
Signed-off-by: Nicolas Pitre <[email protected]>
Signed-off-by: Shawn O. Pearce <[email protected]>
> (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).
and:
> - 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')
This report is to ensure the bug is not forgotten.
Thanks, Stephen.
--- End Message ---
--- Begin Message ---
Version: 1:1.7.8.2-1
‘git bisect’ on your test script finds that the bug was fixed in
v1.7.8.2~16^2~1:
https://git.kernel.org/cgit/git/git.git/commit/?id=1e7ba0f9caf1993491aa4c5cbd796cd31cb0f4af
I’m therefore marking this fixed in 1:1.7.8.2-1.
> (The bug may also be already fixed in squeeze's 1.7.2.5 or wheezy's
> 1.7.10.4; I don't know. That would probably simplify recording the
> resolution here, but I'm also interested in the general case.)
In the general case, we have the fixed-upstream tag.
http://www.debian.org/Bugs/Developer#tags
Anders
--- End Message ---
