Q:

Migrating a large, divergent TFS Team Project to Git

I have a large-ish TFS team project.
After battling with Git-TFS (we have some funky stuff in our TFS Team Project) I have a full local git repo.
It is too big to fit into the BitBucket 1GB soft limit.
The Team project contains branches that are divergent products.    
-- Base Product (trunk)
--- Client A Product (from trunk)
--- Client B Product (from trunk)
---- Client B Feature Branch (from B)
--- Client C Project (from trunk)
---- Client D Project (from C)
----- Client E Project (from D)
As you can see, we haven't been kind to ourselves when branching in TFS.
Doing a shallow clone show a single commit for any branch is about 150-200MB. Full history for any given branch is just under 1GB
I am proposing doing a git repo per branch, and just pushing the branch history since the branch commit. This would mean that no branch has a common ancestor, forcing baseless merges when wanting to do cross-TFS branch merging. I am also proposing to store a read only full historical repo by doing an aggressive GC and removal of some big objects which allows me to squeeze the whole lot into a single repo. This at least opens up the posibility of doing a graft or a replace+rebase to join the 'current' repo's with the historical one at some point in the future.
I cannot cleanly cut history (and rebase) at any point to provide sensible common ancestry and repo headroom under the 1GB limit.
Can anyone help with a better migration strategy?
UPDATE 1: the sub-text to this question is... When products diverge, how important is the branch structure. A significant issue we have is the merge commit relationships between branches. If I trim history it also forces me to dispose of the merge commit history in some cases (because we have done bonkers merges from early portions of one branch to late portions of another) 
UPDATE 2: 
I have another strategy that dispenses with all of the merge history but retains the original parent branch ancestry. 
Git TFS quick clone with the -c option to create a start point at the desired point in time. 
Git TFS pull --rebase --all
Then init a descending branch
Git TFS branch --init [branch name] 
Then pull again etc 
This gives the common ancestry and dispenses of merge commit history which allows for a smaller repo, but at the expense of the merge history. 

A:

It's difficult to answer without knowing what you have in your repository and what you want to keep. 
But if you have a working directory of about 100-200MB, you must have a lot of binaries.
I'm sure that the first step is to remove all the binaries you can using the very good and easy to use tool, bfg report cleaner
Then, you will see if the size of your repository is still a problem. 
Ps: keep a backup of your repository before rewriting history. At least, it will be your read only reference repository in the end if you need so... 
edit: in fact, I googled about this limit on bitbucket and find this page with 2 very interesting links: How to handle big repositories with git  and Reduce repository size

