On Fri, Jun 01, 2012 at 12:57:10PM +0000, Duncan wrote: > William Hubbs posted on Thu, 31 May 2012 15:57:14 -0500 as excerpted: > > Overlays aren't really part of this discussion; those are independent > > trees which we have no control over, so commiting changes from overlays > > to the main tree is the responsibility of the overlay maintainers. > > But it seems to me that overlays are the primary use case for commits to > public trees other than gentoo first. Otherwise, the whole rebase-vs- > merge problem goes away, because the first public commit is to the gentoo > tree. But especially with overlays (like kde) that have an overlay- > first, test, then gentoo-tree, policy, that public overlay tree (which is > already in git) is part of the process. Commits MUST go thru the overlay > to get to the tree, and that overlay is public, so constant rebasing is a > definite no-no. > > Which unless your workaround idea works, pretty much leaves us with merge- > commits as a necessity. (Which of course, as Ciaran pointed out, are > part of the point of git, such that running git without merge-commits > defeats part of the purpose of the whole exercise.)
Overlays are completely separate repositories. There is nothing stopping an overlay from using git right now even if the main tree isn't using git. They just work in their git repositories until they are ready to commit something to the main tree, then they move the changes to the main tree. What the main tree on git would give them is the ability to create a branch from the main tree for their changes, but that would not be pushed to the main repository. All they would have to do when they are ready for their code to be merged back into the main repository is make sure that they are creating a fast-forward merge so that there is no merge commit on the master branch. William
pgpmzpgQTqKJR.pgp
Description: PGP signature
