tags:

views:

45

answers:

3

Hi, I just converted a 10G CVS repo (about 120 modules) in one single git repo using cvs2git whithout any errors on a RHEL5 machine. I'd like to split one subdirectory+history off the repository and create a new one. (Like: http://stackoverflow.com/questions/811251/how-can-i-move-a-single-directory-from-a-git-repository-to-a-new-repository-whils)

I try

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: http://www.copypastecode.com/42535/ Strace-ing all forks ends up in a >2.5G output - I don't know if it grows bigger, I stopped it, though.

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

Thank you in advance, greetings.

A: 

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.

mhagger
Thank you - that would be one possible solution for the current situation (fresh repository converted/created). But the problem is a more general one if we want to restructure the repository again someday.
usr200910
A: 

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.

usr200910
A: 

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.

usr200910