On Tue, Jun 10, 2014 at 12:45 PM, Andrew Savchenko <birc...@gmail.com> wrote: > > Why are you saying that git is inefficient with large projects? It > was developed with efficiency in mind in the first place. And > kernel guys will likely disagree with "git is not great with crazy > big projects" statement.
The kernel tree that "everybody" uses has only a single committer - Linus. That is definitely a potential challenge that we may run into migrating gentoo-x86 - we have many committers and a fairly high commit rate. With Linux you have a million separate git repos and everybody cascades their changes up, which get merged into bigger and bigger patch sets. So, Linus might get a set of updates to merge from the video driver maintainer and it might contain 400 bundled commits, but it isn't like the 400 committers have direct access to Linus's tree. They all commit to their own trees and cascade up to the next level via email. We already have a working method of migrating the entire portage history to git. However, the infra tools/etc are all built around git and only a few people have access to update them. The git repository needs to make it out to the mirrors/etc. There are also a bunch of process-related details to work out. Does everybody try to rebase onto master, or do we have lots of merges? What happens if you do rebase onto master and then when you go to push it isn't a fast-forward any longer because somebody else pushed first? But, for the most part we just need to get the back-end re-written to work with a git repo. Actually migrating the tree itself to git is largely a solved problem. Rich
