1 |
William Hubbs posted on Thu, 31 May 2012 15:57:14 -0500 as excerpted: |
2 |
|
3 |
> On Thu, May 31, 2012 at 08:26:58PM +0000, Duncan wrote: |
4 |
>> William Hubbs posted on Thu, 31 May 2012 14:54:50 -0500 as excerpted: |
5 |
>> |
6 |
>> I don't know what's going to happen to all the overlays with the main |
7 |
>> tree switch to git, but won't that break various "overlay first" |
8 |
>> policies, say for the kde overlay? |
9 |
>> |
10 |
>> Of course, if all the official overlays are converted to git branches |
11 |
>> of the main tree... but won't they still require rebasing as they've |
12 |
>> already been pushed? (This assumes your workaround idea doesn't work. |
13 |
>> If it does, great!) |
14 |
> |
15 |
> Overlays aren't really part of this discussion; those are independent |
16 |
> trees which we have no control over, so commiting changes from overlays |
17 |
> to the main tree is the responsibility of the overlay maintainers. |
18 |
|
19 |
But it seems to me that overlays are the primary use case for commits to |
20 |
public trees other than gentoo first. Otherwise, the whole rebase-vs- |
21 |
merge problem goes away, because the first public commit is to the gentoo |
22 |
tree. But especially with overlays (like kde) that have an overlay- |
23 |
first, test, then gentoo-tree, policy, that public overlay tree (which is |
24 |
already in git) is part of the process. Commits MUST go thru the overlay |
25 |
to get to the tree, and that overlay is public, so constant rebasing is a |
26 |
definite no-no. |
27 |
|
28 |
Which unless your workaround idea works, pretty much leaves us with merge- |
29 |
commits as a necessity. (Which of course, as Ciaran pointed out, are |
30 |
part of the point of git, such that running git without merge-commits |
31 |
defeats part of the purpose of the whole exercise.) |
32 |
|
33 |
-- |
34 |
Duncan - List replies preferred. No HTML msgs. |
35 |
"Every nonfree program has a lord, a master -- |
36 |
and if you use the program, he is your master." Richard Stallman |