Hi Stephen,
Stephen Bash wrote:
> 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.
Thanks for a clear report. I backported your test case:
-- 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 show-ref
) &&
git clone file:///`pwd`/foo newFoo &&
(
cd newFoo &&
git show-ref
)
-- >8 --
which produces the result:
...
07fa3d4c3aba83b293e24a12a87faca363ad34e6 refs/heads/master
90a32c29df06b4f6e4218c1b82b35a3e49aed9f2 refs/original/refs/heads/master
90a32c29df06b4f6e4218c1b82b35a3e49aed9f2 refs/original/refs/tags/tagfoo
ef92777a31663135426a9648d0abb0c06b448fbe refs/tags/tagfoo
...
Resolving deltas: 100% (1/1), done.
error: refs/tags/tagfoo does not point to a valid object!
07fa3d4c3aba83b293e24a12a87faca363ad34e6 refs/heads/master
07fa3d4c3aba83b293e24a12a87faca363ad34e6 refs/remotes/origin/HEAD
07fa3d4c3aba83b293e24a12a87faca363ad34e6 refs/remotes/origin/master
$
The error message bisects to:
commit 5bdc32d3e50d8335c65e136e6b5234c5dd92a7a9 (tags/v1.6.5-rc3~20)
Author: Nicolas Pitre <nico@xxxxxxxxxxx>
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 <nico@xxxxxxxxxxx>
Signed-off-by: Shawn O. Pearce <spearce@xxxxxxxxxxx>
That is not too surprising. Before then, "git clone" fetched
all objects.
The error message is from refs.c::do_one_ref(), which notices the
missing object ef92777a31663135426a9648d0abb0c06b448fbe (i.e., ye
old tag object).
Call chain:
cmd_clone() ->
write_remote_refs() ->
pack_refs() ->
do_for_each_ref() ->
do_one_ref()
The transport is done afaict by then.
Nico, Shawn: ideas?
--
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