The fast-forward merge option is per-repo and is on the settings page (see screenshot at: http://tyler.zone/merge-method.png).
While the UI is different in Gerrit vs GitLab, the underlying mechanisms here are the same—that is, in Gerrit you are merging a ref (e.g., refs/changes/yy/xxxyy/1
) into a branch (e.g., main
) and in GitLab you merge a ref (refs/heads/fix/T1
) — which is itself is a "branch" — into a branch (e.g., main
).
The creation of those refs in Gerrit is automatic and we rarely think about it. Pushing via e.g., git push origin HEAD:refs/for/main
causes Gerrit to make changesets for every commit from origin/main..HEAD
. In GitLab making each ref has to happen locally rather than automatically. This can be accomplished via something like:
while read changeset; do
git push origin "$changeset":refs/heads/thcipriani/changes/"$changeset"
done < <(git log --format=%h @{u}..HEAD)
to create a branch for each change. It is noteworthy that this is fighting the "feature branch" strategy the drives merge-requests. That is, if all your changes are related (i.e., a feature branch) then, in a GitLab world, these become a single merge-request.
Merging from the bottom up isn't necessary for chains of merge-requests as far as I can tell. For example, let's say:
- you have 3 changes:
A
, B
, C
- you create 3 merge requests (one for each change):
mA
, mB
, and mC
mA
's merge target branch is main
- To get a small review diff
mB
's merge target is mA
mC
's merge target is mB
From here, the logical thing might be to merge from the bottom up: merge mC
-> mB
; mB
to mA
; mA
to main
—this works; however, it's not the only thing you could do.
You could merge mA
to main
(which deletes the mA
branch by default), and then change your merge-target for mB
from mA
to main
. This is, in essence, a "rebase".
This has been a long-winded way of saying: all git workflows are possible in git.
In many ways Gerrit aligns more closely with how git works (branches weren't always things) and the abstraction it provides makes some workflows easier. The merge-request workflow is a different abstraction than Gerrit's patchset-based workflow and it requires users to make explicit what was once an implementation detail of the tooling: namely that there are refs that represent a set of changes that we're trying to merge to a branch. This will have an effect on how we write changes.
If GitLab's abstractions makes a certain workflows more onerous then we should document those workflows to see if we can work with GitLab/the GitLab community to make them easier.