Proposal: make squash-merging the default behavior for gitlab MRs

[Nate Graham]

So to close the loop on this discussion, it seems like folks are not 
generally in favor of my proposal, for various sensible and 
well-considered reasons. I will beef up our GitLab documentation to add 
more information about how to use a curated commit history approach and 
will drop the idea to squash by default.

We will need to commit to vigilance when merging MRs--our own or someone 
else's--to make sure that merge requests which don't have curated commit 
history are squashed to avoid accidentally polluting the git history.

Note that using the "Apply suggestion" feature in the Gitlab web UI 
creates new commits in the merge request. These must be either manually 
squashed into the commits of a commit-curated MR, or squashed at 
merge-time for an un-commit-curated MR.

Nate



On 10/7/20 10:12 AM, Carson Black wrote:
> Am Mi., 7. Okt. 2020 um 11:27 Uhr schrieb Thomas Friedrichsmeier
> <thomas.friedrichsmeier at kdemail.net>:
>>
>> Am Tue, 6 Oct 2020 08:26:02 -0600
>> schrieb Nate Graham <nate at kde.org>:
>>> GitLab already *kind of* offers this, in the form of the "Squash
>>> commits" checkbox next to the merge button. Apparently it's not
>>> obvious enough though, because I can think of a bunch of cases of
>>> multi-commit MRs with mostly garbage commits accidentally not being
>>> squashed when merging.
>>
>> Unfortunately the workflow is rather backwards in that the checkbox
>> needs to be ticked, when creating the merge request, not after review.
>> However right before merging would be the time to judge whether the
>> commit history contains valuable information or useless noise.
>>
>> (IIRC the "squash commits" checkbox can still be changed at that
>> point, but it's not obviously visible, then).
> 
> The checkbox is fairly visible for me, by the merge button like Nate
> said: https://imgur.com/a/gzRDYnZ
> 
> This can be ticked immediately after review and before merging easily
> like you said would be the ideal time to do so.
> 
> -- Jan
>