Re: fsck --full is Ok, but clones are not, "missing commits"?!
- From
Johannes Sixt <j.sixt@viscovery.net>
- Date
- Apr 16, 2008, 15:22 UTC
- Message-ID
- <480619AE.8010506@viscovery.net>
- In-Reply-To
- <a537dd660804160804t252d2900j33e30a01dc58979c@mail.gmail.com>
Brian Foster schrieb:
Show 15 quoted lines
> 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).
Show 10 quoted lines
> 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