Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: William Hubbs <williamh@g.o>
Subject: Re: Re: Portage Git migration - clean cut or git-cvsserver
Date: Fri, 1 Jun 2012 10:45:48 -0500
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

Attachment:
pgpyDFA2f7lFQ.pgp (PGP signature)
Replies:
Re: Re: Portage Git migration - clean cut or git-cvsserver
-- Robin H. Johnson
References:
Re: Portage Git migration - clean cut or git-cvsserver
-- Duncan
Re: Re: Portage Git migration - clean cut or git-cvsserver
-- Robin H. Johnson
Re: Re: Portage Git migration - clean cut or git-cvsserver
-- Dirkjan Ochtman
Re: Re: Portage Git migration - clean cut or git-cvsserver
-- Robin H. Johnson
Re: Re: Portage Git migration - clean cut or git-cvsserver
-- Rich Freeman
Re: Re: Portage Git migration - clean cut or git-cvsserver
-- Robin H. Johnson
Re: Re: Portage Git migration - clean cut or git-cvsserver
-- William Hubbs
Re: Portage Git migration - clean cut or git-cvsserver
-- Duncan
Re: Re: Portage Git migration - clean cut or git-cvsserver
-- William Hubbs
Re: Portage Git migration - clean cut or git-cvsserver
-- Duncan
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Re: Portage Git migration - clean cut or git-cvsserver
Next by thread:
Re: Re: Portage Git migration - clean cut or git-cvsserver
Previous by date:
Re: Re: Portage Git migration - clean cut or git-cvsserver
Next by date:
Re: Re: Re: Re: Portage Git migration - clean cut or git-cvsserver


Updated Jun 24, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.