Johannes Sixt wrote: > 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). I don't think the tag-name-filter section has been reached yet. I think the problem is the --all option to rev-parse. This adds everything under .git/refs to the list of heads to rewrite. Just a guess, but possibly the linux-2.6.15 is an annotated tag, which is dereferenced to a commit (the oldsha1), and then when update-ref is called with the newsha1 and the oldsha1, the oldsha1 doesn't match what is in refs/tags/linux-2.6.15 since that points to the sha1 of the tag object. Try --branches instead of --all. Or leave it blank if you just want to filter the current branch. Also, if you're interested in retaining the annotations from the tags, search the list for '[PATCH v4] filter-branch.sh: support nearly proper tag name filtering' or grab the patch from git's pu branch. -brandon -- 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
