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

From: Jan Wielemaker <j.wielemaker@uva.nl>
Date: Aug 8, 2008, 07:44 UTC
Message-ID: <200808080944.23048.J.Wielemaker@uva.nl>
In-Reply-To: <200808080148.27384.trast@student.ethz.ch>

Hi Thomas,

Thanks for looking into this!

On Friday 08 August 2008 01:48:05 Thomas Rast wrote:

Show 20 quoted lines

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

Great. I knew a more fundamental approach was asked for, but I bet my simple-minded work-around gives the same result, no?

Show 13 quoted lines

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

Thanks. As I'm using the GIT version anyway, I'll apply these patches and see what happens. The trouble is related to tags and possibly to branches. I get completely correct result if I delete all branches and tags before filtering. That at least helps for this particular subproject (though some of the tags are useful).

I didn't further investigate branches (I think the packages/chr directory is not involved in any branch; if you are interested, the boot directory should show traces of the V57X branch).

I did see that (all/some?) tags that involve changes to the packages/chr directory nicely end up in its history, but others do not appear on the filtered master branch and give access to the complete project. See for example V5.6.59 (the latest release tag). Try (in the filtered branch)

	git diff V5.6.59..

That should only show some small changes, but it diffs the entire project against the subdir ...

Show 7 quoted lines

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

Thanks for the tip.

	Cheers --- Jan