Git merge workflow: reverse it?

Kai Uwe Broulik kde at privat.broulik.de
Tue May 10 08:36:17 BST 2022


Hi,

can we get an update on this?

Plasma is full on cherry-pick now but in KDE Gear it's inconsistent and 
frustrating when some projects use cherry-pick (e.g. Kate) and some 
don't (e.g. Dolphin).

I don't really mind what the outcome is but I need it to be consistent 
and predictable where to target my MRs, at least for every domain 
(Plasma, Gear, ..).

Cheers
Kai Uwe

PS: Since I can never remember: it's git rebase --onto newbase oldbase 
branch

Am 29.07.20 um 14:01 schrieb Bhushan Shah:
> Hello everyone!
> 
> At plasma, we are experimenting with new workflow regarding how bugfixes
> are put on the stable branch [1].
> 
> # Previous workflow
> 
> - Current workflow is that we commit to stable branch and then merge it
>    upwords until master branch
> - i.e commit to Plasma/5.18 branch, merge 5.18 into 5.19 and then
>    master
> 
> # Current workflow
> 
> - Proposed workflow is to instead commit all changes in master, and
>    cherry-pick related changes in the stable branch as needed
> - We had been using this workflow for about 1 month now and I'd say it
>    is working nicely for us.
> 
> # Why?
> 
> We occasionally hit several issues with previous workflow,
> 
> - Merge conflicts when merging changes upwords
> - Changes which are valid only for stable branch needs to be reverted in
>    master branches. So you end-up with, stable-fix, revert of stable fix
>    and then different fix and overall weird history.
> - Accidential merges from the master branch to stable branch which
>    needs to be force-resetted.
> - It's worth noting that Qt also recently changed to merge to dev,
>    cherry-pick backwards.
> - This also allows for workflows where we want to commit some bugfix in
>    the master branch for few days/weeks and if it works fine in general
>    testing then, cherry-pick it in stable branches.
> 
> Proposal is to probably adapt this policy kde-wise if people feel that
> advantages are worth it.
> 
> Thanks
> 
> [1] https://mail.kde.org/pipermail/plasma-devel/2020-June/117887.html
> 


More information about the kde-core-devel mailing list