Git merge workflow: reverse it?
Albert Astals Cid
aacid at kde.org
Mon Aug 3 22:50:43 BST 2020
El dimecres, 29 de juliol de 2020, a les 14:01:07 CEST, Bhushan Shah va escriure:
> Hello everyone!
> At plasma, we are experimenting with new workflow regarding how bugfixes
> are put on the stable branch .
> # 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
> # 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
The conflicts are still going to be there, if your change has conflicts going up, it'll have conflicts going down.
> - 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.
I don't remember having one of teose, but i guess Plasma moves much faster than the repos I usually work on.
> - Accidential merges from the master branch to stable branch which
> needs to be force-resetted.
I don't see how the proposed workflow help with developer clumsiness
> - It's worth noting that Qt also recently changed to merge to dev,
> cherry-pick backwards.
Which is not nice, at the moment it means you need to do a fix for Qt 6 if you want it in Qt 5.15; i did one or two "uncompiled" commits to Qt6 because of that.
This could potentially be a problem for us too, I don't want to compile Plasma master + KF5 master (that Plasma may depend on) just to fix something "trivial" in the stable branch I'm using (which i can compile without problems because my distro has all the packages needed for it)
> - 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.
One improvement I think you didn't mention is:
- "Non-core" people don't know what's the stable branch. I see that in Okular, most drive-by Merge Requests are against master, because that's the easy thing to do, for a "newbie" it's hard to figure out if something should go to the stable branch or not (is it a bugfix? a feature?), and if so, which is the stable branch if there's one, etc.
> Proposal is to probably adapt this policy kde-wise if people feel that
> advantages are worth it.
+0 from my side
>  https://mail.kde.org/pipermail/plasma-devel/2020-June/117887.html
More information about the kde-core-devel