Git merge workflow: reverse it?

[Nate Graham]

FWIW I'm a +1 too. Having done both, I solidly prefer the cherry-pick 
workflow. It's so much less error-prone, and you don't need to deal with 
the hassle of switching branch targets and rebasing prior to merging.

Nate



On 8/14/20 2:31 PM, Johan Ouwerkerk wrote:
> On Mon, Aug 3, 2020 at 11:50 PM Albert Astals Cid <aacid at kde.org> wrote:
>>
>> El dimecres, 29 de juliol de 2020, a les 14:01:07 CEST, Bhushan Shah va escriure:
>>> At plasma, we are experimenting with new workflow regarding how bugfixes
>>> are put on the stable branch [1].
>>>
>>> # 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.
>>>
>>
>> The conflicts are still going to be there, if your change has conflicts going up, it'll have conflicts going down.
>>
> 
> I guess it's mostly about who is doing the merging and committing in
> this: the hopefully more seasoned people who know the code well
> because they've been maintaining it for a while or the casual
> contributor who might not be fully aware of what master might have
> moved away from that is still in stable (or the reverse).
> 
> It might also be slightly easier to realise that it turns out you have
> to backport a bit more, than it is to future proof your code coming
> from the deep past to minimise the merge conflicts, as it were.
> 
>>
>> 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.
>>
> 
> I think this one thing alone is the main reason to just do it. People
> who maintain stable branches know what they signed up for and
> generally have a pretty good understanding of what they're doing. Even
> seasoned KDE contributors are going to find a workflow with a single
> target branch (always master) to be slightly easier to remember than
> "whatever the stable branch happens to be".
> 
>>> Proposal is to probably adapt this policy kde-wise if people feel that
>>> advantages are worth it.
> 
> I'd lean towards +1
> 
> Regards,
> 
> - Johan
>