Re: refs/original breaks git-clone for tags

[Jonathan Nieder <jrnieder@gmail.com>]

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@fluxnic.net>
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@fluxnic.net>
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

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?