Many GNOME projects still use clean and linear commit history without merge commits even after porting to GitLab. That means that each commit represents one comprehensive feature or bug fix and there are not any side branches. I am not about to discuss the pros and cons of this approach here, you can find many and many posts on this topic on the internet. I would like to explain some common issues for newcomers when using GitLab forks.
To make some contribution, one has to create a fork of some repository, push desired changes in a new branch and create a merge request to the original project. Please be sure that the “Allows commits from members who can merge to the target branch” checkbox is checked when creating the merge request (or later using the “Edit” button on the top of the page). This is needed to simplify the consequent workflow for the contributor (and maintainers as well). One of the reasons, why this is needed is the fact, that the changes need to be often rebased before they can be merged (to ensure the linear history). Maintainers can’t do this when this feature is not enabled and have to ask contributors to do so. Another reason is that the maintainers can do some changes when the contributor needs help or doesn’t have time to do the changes itself.
When the merge request is created, maintainers usually make a review of the proposed changes and ask the contributor to change something. The existing commits need to be updated using e.g. git commit --amend, or git rebase --interactive (to ensure clean history). Then git push --force has to be used to update the remote branch. This is the right way and it is expected that the --force option is used, there is no other way to update the existing commits.
See GNOME Wiki, GitLab Docs and Git Documentation to get more info about these topics.
Thanks for the public utility post, Ondrej!
I’ve been copy-pasting a text for requesting the “Allow commits from members” checking on MRs. May I link to this post from now on?
For the other point, I would recommend the
--force-with-leaseoption instead of raw--force, especially given we are asking for allowing multiple people to commit to the branch.Surely you can link to this post, I wrote it for this purpose. I’ve not known about
--force-with-lease, thank you that you mentioned that.Best to use
git push --force-with-leaserather thangit push --force,as it aborts if someone else has pushed to the branch since you last pulled from it. It’s basically how--forceshould have been implemented in the first place.I’ve aliased
git ptogit push --atomic --force-with-leaseand it’s stopped me overwriting someone else’s work a few times now.Also
--atomicseems like a good improvement, I will create git alias for this as well!