[IMPORTANT] Change in branch handling in emerge

[Patrick Spendrin]

Am 12.02.2013 17:05, schrieb Thomas Friedrichsmeier:
> Hi,
> 
> On Tuesday 12 February 2013, Andre Heinecke wrote:
>> At Tuesday 12 February 2013 10:02:02 Patrick Spendrin wrote:
>>> default target changes for kde packages aren't needed anymore because I
>>> added a way to set the targets and the branch in one file for all KDE
>>> packages in master and kde-4.10.
> 
> what about default targets on dependencies which are not kde packages?

These won't be changed, I am not sure how we want to handle that, but
likely something like:
instead of applying the defaultTarget change in branch kde-4.(X-3) you
would apply it in kde-4.(X-2) and then merge it into kde-4.(X-1),
kde-4.X and master.

> 
>>>> Can you give an example workflow for a patch that you want to apply in
>>>> the 4.9 4.10 and master branches and apply it to the targets for 4.9
>>>> 4.10 and master?
>>>
>>> You need to apply this in 4.9 and in 4.10, then merge 4.10 to master. In
>>> the case the patch applies to both 4.9 and 4.10, you could first apply
>>> the patch in 4.10, then cherry-pick this to 4.9, otherwise you will have
>>> to apply the patch in both branches.
>>>
>>> Merging from 4.10 to master is possible nowadays.
>>
>> Nice, in that case this workflow should work in the same way it does for
>> other parts of KDE.
> 
> Could you translate that into a prototypical sequence of commands to type (for 
> the mildly git-impaired folks like myself)? Also, in kdelibs, merging to 
> master happens all by itself (the magic "it" being David Faure). Will the same 
> work in emerge.git, in case I forget to merge to master (or in case git scares 
> me off with something I don't understand)?

well, it won't be magically, it would be nice if everybody tries to take
care of that himself. I know that this might need a bit of time, but we
do not need to hurry I hope. If you simply forget to merge your changes
into one branch I will probably also just do that for you if it comes to
my eyes.

Ok, now an example from the near *future*:
win32libs/openssl gets a security update, I need to add the version
1.0.1f and change the default target.
I'll apply that to the oldest supported branch which still is kde-4.10
(git add emerge\portage\win32libs\openssl && git commit -m "<important
message here>" ).
Then I merge that into the other branches kde-4.11, kde-4.12, master:

git checkout kde-4.11 && git pull origin kde-4.11
git merge origin kde-4.10 && git push origin kde-4.11

git checkout kde-4.12 && git pull origin kde-4.12
git merge origin kde-4.11 && git push origin kde-4.12

git checkout master && git pull origin master
git merge origin kde-4.12 && git push origin master

I am not good enough using git, likely git merge origin kde-4.10 might
work for all branches. At the moment, this is not important because
there is only the 4.10 branch and master.

Second thing that might happen:
while merging, you might have to resolve conflicts. This is nothing
hard, the common conflict for the above example is:
In master somebody changed the default target to 1.0.2a already (and
committed that only in master), so the merge from 4.12 to master will
result in a conflict. So you'll edit the file in question, in this case
you keep the default target for master at 1.0.2a and do
git add emerge\portage\win32libs\openssl
git commit
and then you go ahead and do a git push origin master.

I hope this example describes my thoughts a bit, and if you have
problems, just post them here, you might not be the only one having them.

> Regards
> Thomas
> 
> 

regards,
Patrick