On Thu, Jun 25, 2020 at 7:49 PM David Edmundson <da...@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
