git filter-branches - no progress at end

I just converted a 10G CVS r开发者_开发百科epo (about 120 modules) in one single git repo using cvs2git without any errors on a RHEL5 machine. I'd like to split one subdirectory+history off the repository and create a new one. (Like: How can I move a single directory from a git repository to a new repository whilst maintaining the history?)

I tried:

git filter-branch --subdirectory-filter xxx.model -- --all

which works fine, until the last item is processed - then it hangs using CPU without any progress. Using strace, it looks something like this: [broken link]. strace-ing all forks ends up in a >2.5G output - I don't know if it grows bigger; I stopped it.

What is causing that strange behaviour? Is there any other method of creating a new repository with a subdirectory+history of an existing repository?

The operation finished successfully after hours of running. The only problem was, that it seemed for us that there is no progress, but that's not true. There's just no output.

Set GIT_TRACE=1 and redo the command and there is output and progress visible.

It's possible that the high amount of tags caused the operation to slow down.

Whatever you do will require the existing git repository to be rewritten. So you might as well just run the conversion again, splitting the projects first then converting the projects separately.

If the two projects are already in separate subdirectories of the CVS repository, you can simply point cvs2git at one subdirectory and then at the other.

If the projects are more intermingled with each other, then make a copy of the CVS repository, use filesystem commands to separate the projects into separate subdirectories, and again convert them separately.

Spoken to the people in freenode/#git I found another way to do the same by removing (git rm) everything except the directory I want to keep.

git filter-branch --prune-empty --index-filter "git ls-files --exclude-standard |grep -v '^foobar'|xargs git rm -r -f --cached --ignore-unmatch" HEAD

This operation is slow, but works (guess so). I didn't have a look at the result due to an abortion.

BTW: Someone in #git told me that these operation could often occupy days to finish, so it is likely that if I had wait (although it looks like there is no progress/"it hangs") it had finished.