Re: fsck --full is Ok, but clones are not, "missing commits"?!

[Johannes Sixt <j.sixt@viscovery.net>]

Brian Foster schrieb:
>  at toplevel of a (not-bare) clone, with  info/grafts  in-place,
>  and a happy `fsck -full' (same machine so same git version):
> 
> 	$ git filter-branch --tag-name-filter cat -- --all  # at not-bare toplevel
> 	Rewrite 7df30811617517bc4d5ec7c190a435667228320c (168/168)
> 	Ref 'refs/heads/master' was rewritten
> 	Ref 'refs/remotes/origin/HEAD' was rewritten
> 	WARNING: Ref 'refs/remotes/origin/master' is unchanged
> 	Ref 'refs/tags/linux-2.6.15' was rewritten
> 	error: Ref refs/tags/linux-2.6.15 is at \
> 		26a33413c95dfda6c70ca4a83da49cddb7b236b9 but expected \
> 		2dcaaf2decd31ac9a21d616604c0a7c1fa65d5a4
> 	fatal: refs/tags/linux-2.6.15: cannot lock the ref
> 	Could not rewrite refs/tags/linux-2.6.15
> 	$

Actually, I don't know how to overcome this situation; maybe forget about
the tags and remove the '--tag-name-filter cat' part. They wouldn't have
been rewritten correctly anyway (annotated tags loose the message and
become unannotated).

>  as such, is there some way of adding them back to the bare
>  repository (if that even makes sense?), or whatever?  (i.e.,
>  that have not been lost, is it possible to take advantage
>  of that fact?)
> 
>  also (sorry!), does anyone recognise the development process
>  that apparently was used?  (the one pre-existing clone has
>  few-to-no clews, since it was used for some fairly trivial
>  local development, not for the "merging" (if I can call it
>  that) with linux-mips repository.)

In this case you might be able to salvage missing objects by cloning
linux-mips. Just copy the objects/pack/* from that clone into your
objects/pack, remove info/grafts, and maybe things "just work"?

-- Hannes