Splitting a project into branches afterwards

["Yohann Bénédic" <yohann.benedic@orange.com>]

Hello everyone!

First of all, I believe that what I am about to ask is impossible, but I 
give it a shot because there may be ways to get a close enough result or 
another approach that I have not thinked of.

What I have.
A git repository cloned from svn (entire repo : 30,000 commits in 60 
branches) that contains the source code of several products built around a 
common framework. Branches where made to track the delivered version of each 
product, so that there is a product_A_v1 branch, a product_B_v2 branch, etc. 
The key point is that there is only one trunk that is common to all of the 
products and framework. The source code is organized in a low-level -> high 
level hierarchy which results in not having a clean top level folders for 
product_A, product_B, … and framework.

What I wish I had.
A git repository with a framework branch that only contains common code, a 
product_A branch that derived from the framework branch at some point, 
introducing all the product_A-specific source code. Same with the other 
products.

My attempt.
I started from the master branch and created a framework branch out of it. I 
removed all the product specific code from it (A, B etc.) and commited 
(let's call that the initial_removal commit for further reference). I then 
created a product_A branch from the master branch and removed all the 
product-specific code other than product A's (keeping the framework) and 
commited (that's another initial_removal commit). I then did the same for 
product_B, C, etc.
At this point, I am happy with the situation, even though the history 
reminds me that the products were not cleanly separated from each other in 
the past. The problem is with the "initial_removal" commits I made on each 
branch. If the framework branch moves forward, I want my product_A branch to 
be able follow along : that's a merge of the framework from product_A. In 
product_A, I might fix something from the framework and need to patch the 
latter. That's a merge in the other direction. Both these merges will apply 
the "initial_removal" commits, generating conflics at best, silently 
succeeding at worst. And that's were I am stuck because and can't find a way 
to tell git to ignore them once and for all so that I can have a normal 
workflow afterwards.

Further ideas.
I feel like sub-trees might help me here, but I haven't learned enough about 
them to knwo for sure: anyone telling me "nope they won't help" or "yes 
that's what you are looking for" would help.
Any complete procedure is welcomde too :) as weel as pointers to other git 
concepts.

Thank you all for your time.

Yohann

PS. I am not a native english speaker. Please, forgive any mistake or 
misleading sentence I might have written. Corrections are welcomed too!