Split Up Folders in a git repository into separate branches

Question

I have finally migrated our CVS repository to git. Unfortunately we didn't use branches in CVS but different versions/branches were separated into different subdirectories.

I.E. we have the following directory structure:

/root
    /lib
    /tools
    /src
        /v1.0
        /v2.0
        /v3.5

Is there a way to separate the 3 versions in the src subdirectory into separate branches instead of keeping the directory for each version?

I have found the same question here on Stack Overflow Question 4877053, where the use of git-subtree is proposed, but even after reading the manual for git-subtree, I didn't understand how to use it to solve my problem.

Can someone give me a more detailed explanation or even another solution?

I'm quite new to git, perhaps that's why I didn't understand the subtree manual ;-)

Thanks very much for all your anwers!

Answer 1

It depends what you want left in the repository afterwards.

If you want three branches, v1.0, v2.0, v3.5, all with structure like this:

/root
    /lib
    /tools
    /src

then yes, I'm pretty sure you can do that. You'll end up with something like this in terms of branch structure:

-- A -- B -- Current 
              | 
              |--- v1.0
              |--- v2.0
              |--- v3.5

A, B, Current being commits you've committed since you migrated to git, and where v1.0, v2.0 and v3.5 are essentially "dead-end" branches. You could do some fancy things if you want to get a branch structure more like:

-- v1.0 --- v2.0 --- v3.5 -- A -- B -- Current

That is, separate v1.0, v2.0, and v3.5 into their own branches, then rebase v1.0 onto v2.0, v2.0 onto v3.5, and v3.5 onto the first commit in the current version.

But I'm not sure exactly what you want to do.

---

Is there a way to separate the 3 versions in the src subdirectory into separate branches instead of keeping the directory for each version?

Yes, I'm pretty sure you can do this. My methodology is a little ... convoluted, I'll admit, but here goes. Please, be careful and read the man pages - the following commands probably won't screw everything up, but use at your own risk.

1. git checkout -b v1.0 - get onto a new branch.

2. Remove everything except v1.0. There are a few ways to do this. This question has some methods for removal of everything except ; I couldn't get them working for me, it might work better for you.

   `git filter-branch --index-filter "git rm -r -f --cached --ignore-unmatch src/v2.0" --prune-empty -f`
   

   This will remove src/v2.0 and all associated history from the branch. -f isn't necessary for this filter; but git-filter-branch does some sort of backup (read the man page?) and it might spit errors. It defiantly will the second time you try git filter-branch.

   Repeat this to remove src/v3.5 as well.

   This will leave you with src/v1.0. You possibly want to shift the source from src/v1.0 to src; you could run a git filter-branch --subdirectory-filter (read the man page) to get you a directory structure /v1.0-files (contains nothing but the files from subdirectory v1.0; has moved contents from v1.0 to root), and then look at the examples in the man git-filter-branch page (specifically the bottom example) to shift files into a subdirectory. That might be overkill, and you'd then need to merge that into a branch containing all the other stuff that git filter-branch --subdirectory culled; a simple mv v1.0/* . might work, but you'd then have another commit in your history. I don't know what you'd prefer.

   So now you've got v1.0 in it's own branch. Yay!

3. Repeat for v2.0 and v3.5.

I'm afraid I can't see this doing anything but giving you ... "odd" history, though. Presumably v2.0 has, essentially, v1.0 + improvements; the structure I've listed above (three "dead-end" branches) shows v2.0 and v3.5 don't build on the previous versions. I'm not entirely sure what kind of history you have, if this is an issue, etc etc.

Because you've got v1.0, v2.0 and v3.5 in their own little branches, you can git merge them or git rebase etc etc, if you'd prefer a nicer looking history.

Hopefully this gives you a little bit to think about; like I said, please read the man pages. :)