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 <n...@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 <n...@fluxnic.net>
Signed-off-by: Shawn O. Pearce <spea...@spearce.org>
> (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.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
