From: David Kastrup <dak@gnu.org>
Date: Wed, 16 Apr 2008 09:14:43 GMT
Subject: Re: fsck --full is Ok, but clones are not, "missing commits"?!
Message-ID: <86lk3ecgak.fsf@lola.quinscape.zz>
In-Reply-To: <20080416063739.4B72647879@blf.utvinternet.co.uk>

Brian Foster <brian.foster@innova-card.com> writes:

>    (many many apologies if this turns into a double post,
>   there seems to have been problems with the 1st attempt?)
>
>  I've recently inherited a bare git repository,
>  which, as far as I can tell (I'm something of
>  a newbie with git), seems Ok: `git fsck --full'
>  does not report any problems.    however, any
>  clones I make from it are not Ok:
>
> 	$ git-fsck --full   # clone (same command for bare repo is Ok)
> 	broken link from  commit dd3f3c0636cfd50719c706b030db5473b0270add
> 		      to  commit 0fed9c2eb14eee47097e1d870fe8e55a6430edeb
> 	missing commit fb57c018d15005b60f104e57f198ff34a6035b99
> 	missing commit f8947cb0b5fe605e6cb5f73c89f262424b64ef3c
> 	missing commit 0fed9c2eb14eee47097e1d870fe8e55a6430edeb
> 	missing commit dff364d8da15be0b856a174062fb785acb1c363e

>From the git-clone manpage


	--shared, -s
	    When the repository to clone is on the local machine,
	    instead of using hard links, automatically setup
	    .git/objects/info/alternates to share the objects with
	    the source repository. The resulting repository starts
	    out without any object of its own. NOTE: this is a
	    possibly dangerous operation; do not use it unless you
	    understand what it does. If you clone your repository
	    using this option, then delete branches in the source
	    repository and then run git-gc(1) using the --prune
	    option in the source repository, it may remove objects
	    which are referenced by the cloned repository.

Did you use something like that?

-- 
David Kastrup