Gentoo Archives: gentoo-dev

From: Nicolas Sebrecht <nsebrecht@×××××.fr>
To: gentoo-dev@l.g.o
Cc: Nicolas Sebrecht <nsebrecht@×××××.fr>
Subject: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver
Date: Fri, 01 Jun 2012 13:26:42
Message-Id: 20120601132545.GA2416@nicolas-desktop
In Reply to: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver by Duncan <1i5t5.duncan@cox.net>
1 The 01/06/12, Duncan wrote:
2
3 > But it seems to me that overlays are the primary use case for commits to
4 > public trees other than gentoo first. Otherwise, the whole rebase-vs-
5 > merge problem goes away, because the first public commit is to the gentoo
6 > tree. But especially with overlays (like kde) that have an overlay-
7 > first, test, then gentoo-tree, policy, that public overlay tree (which is
8 > already in git) is part of the process. Commits MUST go thru the overlay
9 > to get to the tree, and that overlay is public, so constant rebasing is a
10 > definite no-no.
11
12 The purpose of overlays is to have ebuilds maintained outside of the
13 official Gentoo portage. Importing a ebuild from an overlay whether it
14 uses Git or not means importing the ebuild(s). In the Git context, it
15 means the Gentoo maintainer has to make an import commit the same way
16 it would be done to start a project with somthing like:
17
18 cp 'files to be commited' .
19 git add .
20 git commit -m 'initial import'
21
22 So, like explained before your concern is clearly out of the current
23 discussion. Importing commit history from Overlays is not supported and
24 will probably never be. Gentoo doesn't forces (and doesn't want to)
25 overlays maintainers to use Git.
26
27 --
28 Nicolas Sebrecht

Replies