<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><div>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. <a href="https://gitlab.com/help/user/project/merge_requests/squash_and_merge.md#squash-and-fast-forward-merge">https://gitlab.com/help/user/project/merge_requests/squash_and_merge.md#squash-and-fast-forward-merge</a></div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">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.<br></blockquote><div><br></div><div>It doesn&#39;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.</div><div><br></div><div>Practically, though, it isn&#39;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.</div><div><div><br></div><div>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.</div></div><div><br></div><div>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&#39;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&#39;t be applied by a single person once it passes review, we have a problem.</div><div><br></div><div>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).</div><div><br></div></div></div></div></div></div>