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 |