Re: git filter-branch --subdirectory-filter, still a mistery

[Thomas Rast <trast@student.ethz.ch>]

[-- Attachment #1: Type: text/plain, Size: 1734 bytes --]

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@student.ethz.ch


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]