On Wed, 2019-01-02 at 15:15 +0100, Milan Crha via desktop-devel-list wrote:
On Wed, 2018-12-19 at 14:37 +0000, Philip Withnall wrote:3. I’d like to see continued movement towards disallowing direct pushes to git, and requiring all commits to go through MRs (and CI).Hi, I hope this won't go through without a good research and reasoning. Any such requirement would be kind of showstopper for me personally. It would be just double work for me when coding (issue is not merge request), causing awful commit history, resulting in unbelievably harder effort required to produce NEWS file content (yes, I do use commit messages to fill the NEWS files in a semi-automated way saving my time, which I can spend on more productive things). To name a few major obstacles at least.
The history would be the same if you set up the Merge Request for your project as "Fast-forward merge". "No merge commits are created and all merges are fast-forwarded, which means that merging is only allowed if the branch could be fast-forwarded. When fast-forward merge is not possible, the user is given the option to rebase." I do also generate the NEWS file from the git history, and it is not any different after having that change (which I did as soon as it was possible to do). FWIW, I do both, direct commit and MR. The former for quick commits, and the latter if someone can jump in to review them.
I also cannot imagine any such thing enabled for 'work-in-progress' branches. That would be awful for any porting/cleanup/larger efforts.
Try to not break master, and merge once the CI passes. That is the point. I have seen one corner case, which required to update the CI first. Also, you can let the CI fail without blocking the MR (exceptionally or when it is a secondary issue) -- Germán Poo-Caamaño http://calcifer.org/
Attachment:
signature.asc
Description: This is a digitally signed message part