Gitlab merge workflow: reverse it?

[Aleix Pol]

On Thu, Jun 25, 2020 at 7:49 PM David Edmundson
<david at davidedmundson.co.uk> wrote:
>> You have this button from commit page, not merge request page.
>>
>> https://i.imgur.com/9kgdpVy.png
>
>
> Found it, that's perfect thanks.
>
> That's also a useful feature in the current workflow.
> Seems you can cherry-pick a commit in a work/branch to a new merge request.
>
>>
>> If you use git cherry-pick with -x option, git automatically adds this
>> message in commit.
>
>
> That's handy. Clearly it's a common workflow then.
>
>>
>> >   - without making people commit locally into stable, could it encourage
>> > people to not test as much?
>>
>> I did not actually suggest using Web UI but using the git operation
>> locally. And in fairness either way we do end up with one bit where
>> thing is untested,
>
>
> It was the use of the web UI that I thought might encourage it, as then you're not even changing branches locally to test things.
> You're right that changing the workflow doesn't necessarily mean changing that.
>
> And yes, it's a problem already, which is why I don't want it getting worse!
>
> There's another advantage in this pattern we've not discussed yet. We can commit something to master, test for a few days and only then decide to cherry-pick to stable, that could potentially improve some things.

That last point is very important. Provided that it will compile for sure...

When Qt suggested doing this, it felt a bit weird but I guess it was
more fear of the unknown than anything else.

I'd say let's do this and see what happens.

The biggest con I find is that it will be harder to track where fixes
are. I do "git tag --contains commitid" quite often, but this will
replicate the commits to the different places so it will be less
useful. A small price to pay I guess.

Aleix