Brian Foster <brian.foster@xxxxxxxxxxxxxxx> 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 -- 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
