Here's a quick update on the git-migration experiment. We've pretty much
settled on doing one large repository for the entire tree for a couple
- It's realistic to complete in the short term: It doesn't require a
level of rearchitecture that will delay it forever. The alternative of
one repo per package requires changes to many of our tools, and
enhancements to git of varying scopes.
- Many of the biggest problems with it have been solved. For example,
this week I found a tool that should retain history when merging a
package in an overlay to the main tree, even if there is no common
- The remaining problems are not blockers. For example, there is no way
to check out just part of a tree. Disk space isn't so hard to find now
that this is a requirement.
- Robin has commented that he doesn't know what kind of server-side
resources are required. I've talked to a number of git admins
(kernel.org, fedora, freedesktop.org, gnome), and they have all said the
hardware requirements for git are negligible. They don't have any
resource on their servers that's being used up. It's gitweb that is
The next thing I can think of that needs to happen is putting together a
concrete plan for how a migration would work and making sure all
necessary tools support it, on all sides: developer, user, and
infrastructure. We've got portage support now, but I don't have any idea
what needs to change on the backend infra servers.
Developer, Gentoo Linux