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

[Brandon Casey <casey@nrlssc.navy.mil>]

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