[Dario Lombardo <lomato@xxxxxxxxx>]

I don't like merge commits and polluted history as well, then that's how I configured my projects on gitlab.

Merge commits are disabled, only fast forward merges are allowed. This requires every merge request to be rebased before merging. Moreover I configured successful CI as a requirement for merging. This last item should be carefully decided: it works well for me since I fix CI as soon as it breaks. But on a larger community and code base as Wireshark the CI could fail for something not related to the MR, hence it would block the merge.

The master branch still remains a protected branch, meaning that its history can't be rewritten. This is a must-have for public projects, though.

Users with higher roles (maintainer/owner) can commit to master, others (developers) can't, and are required to create a branch, then a merge request that can be merged by higher users. Reporter and guest users can't create a branch. If we have forks active, the model is the very same as github. We should carefully consider whether have CI runners available for all forks. Considered the high number of branches and forks, we could break the runners. Unfortunately the gitlab-runner is a piece of code that stucks often in my lab.

On Tue, Oct 8, 2019, 00:34 Guy Harris <guy@xxxxxxxxxxxx> wrote:

1) Can you push (or whatever) a proposed commit to GitLab and then do a git commit --amend, changing either code or commit message, and then push and have that amend the commit-on-GitLab, without polluting the history?

Yes. Provided you're working on a branch. As in github, the master branch is protected. You can't amend a commit and then push it to master. This would require a force push, that is not allowed on master branch, but it's allowed on other branches. A good practice is to push always to a branch, create a MR, let the CI run and mark the MR to be merged as soon as the CI passes. However for higher users, direct commit/push is allowed (for instance for trivial patches as typos this is the preferred way, to avoid using resources for useless CI runs).

 

2) Will this cause merge commits, such as the crap that GitHub dumps in there by default:

        https://github.com/the-tcpdump-group/libpcap/commit/b43fdf882a3bd71391535362b3bf560ec54e77ef

to pollute the history?

Yes, as stated above. What I especially don't like of merge commits is that if I create a branch named "fix-the-stupid-error-I-made-yesterday", I don't want that crap to go into the history. This is true on gerrit and on gitlab/hub with ff-only merges. This is not true in the default configuration on gitlab/hub.

 

3) Will I be forced to use branches in my local repository or can I do all my work in the default branch?

This is git stuff. On master branch you can do whatever work you want. Instead of pushing on master, you can push on another branch:

git push origin HEAD:feature-number-1

If you have 3 new commits in your master branch, 

HEAD^^ ==> ready to roll

HEAD^ ==> not ready

HEAD ==> not ready

you can still push your partial work

git push origin HEAD^^:ready-to-roll

As said before: if we work with ff-only merges, we won't care about branch names. Otherwise we (at least me) will be forced to review the branch name as well. Otherwise weird names will appear in the commit history.

What I like in gerrit that I feel missing in gitlab is a clear opinion about a MR from the cores. Basically in gerrit a core devel that doesn't like a change gives -1. When I see that I get that the other core has noted something wrong in the patch and I will very unlikely (if not impossible) that I will merge that change. If a core sees a breaking change they give -2. This prevents accidental merge from another. In gitlab that's not so clear. There is a discussion on the MR, but when long and discording discussions are in place (and I've seen a lot of them on gerrit), the last opinion can be hard to get.

Thumbs can be used to give a vote, but there is no way to block a MR.