Git merge workflow: reverse it?

[Aleix Pol]

On Tue, May 10, 2022 at 9:36 AM Kai Uwe Broulik <kde at privat.broulik.de> wrote:
>
> 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
> >

After having worked with using the Plasma workflow of cherry-picking
into stable (and especially since switching to gitlab) I don't really
see ourselves using something else.

As far as I remember it's worked great, it's super easy to implement
and I don't really remember things going worse but it sure is simpler
to track as a developer (and maintainer).

Aleix