Avoid push --force when updating a gitlab merge request

Question

tl;dr How can I update a gitlab merge request the same way as a gerrit changeset?

In a rather standard gitlab setting, I own a project and want it to keep a linear history. I set the merge settings accordingly and everything works fine from the UI.

If I want to incorporate feedback into an existing merge request, I am currently forced to git push --force my branch which I find both inconvenient and dangerous. As a counterexample, gerrit has a special target refs/for/XXX where I can push my changes. Gerrit then identifies the changeset by an Id in the commit message and happily creates a new version of the changeset.

Is there a similar feature for gitlab? Can I push my (rebased, squashed, ammended) changeset somewhere so that it automatically becomes a new version of an existing MR?

Ditter

I extended my reply, all the versions you push to a merge-request are saved in gitlab and you can compare them, even when using force-push, so it is actually very similar to gerrit. – Larkins

Answer 1

Force push is a valid workflow in this case. It is not that dangerous, because the old version of the branch is still available locally via git reflog and on the server all the versions you pushed are also saved in gitlab (see https://docs.gitlab.com/ee/user/project/merge_requests/versions.html).

You can push modifications happening during the review in new commits and once the branch is ready to be merged use gitlab's squash commits functionality if you really want to avoid force pushing, but this offers less flexibility than using interactive rebase with force push, because it means that the whole branch will be turned into a single commit before being merged.

Tana

Answer 2

You do not need to force push to update a merge request, unless the change rewrites history.

For example, if you have an existing merge request with changes to my_branch and you want to make another change, you can do the following after making the changes to one or more files:

# In case newer changes have been made on the remote/GitLab
git pull origin my_branch

git add .
git commit -m 'Additional changes'
git push origin my_branch

The above does not require a force push because it has not rewritten the history. However, if you rewrite history such as through a rebase, a force push is required:

git add .
git commit -m 'Additional changes'
git rebase -i master
git push origin my_branch --force

The other scenario that could require a force push that doesn't involve a rebase is if there have been more changes to the branch from another user or directly from GitLab that you don't have on your local branch. If you don't pull those newer changes before making other changes, a force push would be required. But a force push would also be destructive so you probably don't want to do that. Instead, you would want to first pull those changes, as I gave in the first example, and then do a regular push after making your changes.

Predicative