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 -- 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
