[gmx-developers] Transition to Gitlab

[Eric Irrgang]

To clarify: It looks like on GitLab, squashing happens _before_ merging
(i.e. on the source branch rather than the target branch), and then a merge
commit is created, unless the fast-forward policy is also in effect, in
which case the target branch is fast-forwarded with the squashed merge.
https://gitlab.com/help/user/project/merge_requests/squash_and_merge.md#squash-and-fast-forward-merge


> This means that we will require much more manual rebasing in the future
> prior to merging because it is required even if there is no merge conflict.
>

It doesn't necessarily mean rebasing. It is sufficient to merge the target
branch to the source branch for a fast-forward merge to be possible. But it
is not clear this would always be desirable or that there is a
one-size-fits-all merge strategy.

Practically, though, it isn't clear to me that requiring fast-forward
commits helps us, since we generally accept conflict-free automated-rebases
in Gerrit and we still end up with merge-related logic errors.

For brevity and clean bisection, squashed merges make sense. The actual
commit message can be edited with relevant information from the review
process, and the issue tracking system will retain a reference to the
source branch with more information for historical use.

If both squash merging and fast-forward merging are in effect, the person
concluding the merge request would either need to rebase the source branch
or merge master to the source branch. This is not a technical problem if
the developer offering the merge request performs the final submission, but
I don't know if that is allowed or would invalidate the reviews. At the
very least, it is a potential policy issue and warrants additional
documentation. If a merge request can't be applied by a single person once
it passes review, we have a problem.

I think the differences between requiring a clean merge and requiring a
clean rebase are small to null when talking about squashed commits, so it
seems consistent with the current Gerrit workflow to use a squash merge
strategy with merge commits (ff not required).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20190805/527e475a/attachment.html>