Hi Thomas, On Friday 08 August 2008 01:48:05 Thomas Rast wrote: > 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. That works! > > 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. I retried with your two patches. That looks a *lot* better. After using the above and deleting the reported branches there are still some branches left, but at least switching to them doesn't bring the complete project back. Now there are a few weird tags left, some of these may well be the result of weird things in the repository. The repository was on CVS until about a year ago and was converted (using SVN as intermediate). The big problem is anything that relates to the days before the filtered directory was part of the project. There are lots of tags there and switching to them brings back the old project. I'd guess the correct behaviour is that either all these tags refer to an empty tree or (which I would prefer) all such tags are deleted. Is this a bug? Is there a trick here? git clone --depth doesn't seem appropriate. Cheers --- Jan -- 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
