Re: GitLab postmortem

On Wed, 2019-01-02 at 15:15 +0100, Milan Crha via desktop-devel-list
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

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
   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

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

Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]