Jan Wielemaker wrote: > Ref 'refs/tags/V5.6.50' was rewritten > error: Ref refs/tags/V5.6.50 is at 8678b32f71178019c06aefa40e2d3fb9a2e8ef25 > but > expected 2e8aef64e2fed088720a19ac2ffa2481e5bc7806 > fatal: Cannot lock the ref 'refs/tags/V5.6.50'. > Could not rewrite refs/tags/V5.6.50 [...] > Now, if I look in .git/packed-refs [...] and I changed all these to > `lightweight' tags This appears to be a bug. I've whipped up a patch that will follow and should fix the bug. It has nothing to do with packed-refs; the current filter-branch chokes on annotated tags during --subdirectory-filter, even though there is support for tag rewriting. However, to enable tag rewriting, you need to say --tag-name-filter cat. > Now it runs to the end. Unfortunagtely the history is completely > screwed up :-(: > > * There are a lot of commits that are not related to the dir > * Commits start long before the directory came into existence, > Looks like it just shows the whole project at this place. For some reason the ancestor detection does not work right. I'm also following up with an RFH patch that significantly improves the success rate (in terms of branches and tags successfully mapped to a rewritten commit) in the case of your repository. I doubt more staring at the code would yield any more ideas at this hour, so ideas would be appreciated. The rest is just the other commits/tags showing a lot of the history. I don't know of any built-in way to prune the branches and tags that aren't part of the new master, but git branch -a --no-merged master can tell you which branches aren't ancestors of master. - Thomas -- Thomas Rast trast@xxxxxxxxxxxxxxx
Attachment:
signature.asc
Description: This is a digitally signed message part.
