| 1 |
On 1 June 2012 08:26, Duncan <1i5t5.duncan@×××.net> wrote: |
| 2 |
> William Hubbs posted on Thu, 31 May 2012 14:54:50 -0500 as excerpted: |
| 3 |
> Of course, if all the official overlays are converted to git branches of |
| 4 |
> the main tree... but won't they still require rebasing as they've already |
| 5 |
> been pushed? (This assumes your workaround idea doesn't work. If it |
| 6 |
> does, great!) |
| 7 |
> |
| 8 |
|
| 9 |
End users will still want to work with overlays that are not merged |
| 10 |
with the main tree, not merely git branches. |
| 11 |
|
| 12 |
Its foreseeable that there will be git branches that /track/ overlays |
| 13 |
and exist as an integration pipeline for content from the overlays |
| 14 |
joining core gentoo, but end users will not want to use that. |
| 15 |
|
| 16 |
For the simple reason of course, that as soon as you want >1 overlay, |
| 17 |
portage's way of doing it with separate repositories is far more |
| 18 |
effective. |
| 19 |
|
| 20 |
You don't want each user to have to maintain an octopus merge between |
| 21 |
all the branches they want to have commits from ;) |
| 22 |
|
| 23 |
-- |
| 24 |
Kent |
| 25 |
|
| 26 |
perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, |
| 27 |
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" |
| 28 |
|
| 29 |
http://kent-fredric.fox.geek.nz |
Archives