1 |
On 24 August 2011 18:48, Donnie Berkholz <dberkholz@g.o> wrote: |
2 |
> On 12:07 Wed 24 Aug , wiktor w brodlo wrote: |
3 |
>> On 24 August 2011 04:16, Donnie Berkholz <dberkholz@g.o> wrote: |
4 |
>> > On 23:00 Mon 22 Aug , wiktor w brodlo wrote: |
5 |
>> >> I will also continue my never-ending quest of slimming Anaconda down |
6 |
>> >> as there's still a lot of dead/useless code in the tree (but figuring |
7 |
>> >> out what can go and what should stay is a task on its own). |
8 |
>> > |
9 |
>> > Wiktor, |
10 |
>> > |
11 |
>> > lxnay was kind enough to point out that removing "dead" code will make |
12 |
>> > it extremely hard to rebase your work upon upstream changes. How do you |
13 |
>> > propose to deal with that? |
14 |
>> |
15 |
>> Maybe not *extremely* hard. These days Anaconda development, both in |
16 |
>> Fedora and in Sabayon, isn't exactly lightening-fast, so I think |
17 |
>> following their development and merging back any nice changes |
18 |
>> systematically won't take up too much time. I always thought that I'd |
19 |
>> just keep their respective git repos locally and if there are any |
20 |
>> changes, look at what they do and determine if they're of any use to |
21 |
>> Gentoo. This way, only the changes done to the files that we also have |
22 |
>> will be merged back in, and then only if they affect our installer - |
23 |
>> for example, yum, Fedora repos, Entropy (Sabayon's package manager) |
24 |
>> etc support is totally unneeded in Gentoo so there's no point even |
25 |
>> bothering ourselves with changes to those parts, so I don't see any |
26 |
>> point in keeping this code. |
27 |
> |
28 |
> You think manually inspecting all commits is worth it? Seems like `git |
29 |
> pull --rebase` would be a lot easier. |
30 |
|
31 |
That would work too ;-) |
32 |
Though having a look at the commits before the pull is a good idea by itself. |