William Hubbs posted on Thu, 31 May 2012 15:57:14 -0500 as excerpted: > On Thu, May 31, 2012 at 08:26:58PM +0000, Duncan wrote: >> William Hubbs posted on Thu, 31 May 2012 14:54:50 -0500 as excerpted: >> >> I don't know what's going to happen to all the overlays with the main >> tree switch to git, but won't that break various "overlay first" >> policies, say for the kde overlay? >> >> Of course, if all the official overlays are converted to git branches >> of the main tree... but won't they still require rebasing as they've >> already been pushed? (This assumes your workaround idea doesn't work. >> If it does, great!) > > 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.) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
