Proposal: Encourage squashing commits when merging

[Volker Krause]

On Donnerstag, 15. Mai 2025 16:55:01 Mitteleuropäische Sommerzeit Felix Ernst 
wrote:
> Gitlab allows squashing commits while merging. I suggest to have the
> checkbox for this ticked by default. Contributors would still be able to
> untick it as they see fit.
> 
> I think "encouraging squashing" is the better default because Gitlab has
> features like the "Apply suggestion" button which produces non-descriptive
> commits by default. Furthermore especially new contributors might not
> manage the commit history in their merge requests. When it finally comes to
> merging, the merging person might forget to tick that checkbox, or they
> might have only recently been upgraded to a KDE developer account and not
> know if they should tick this non-default setting, which will then lead to
> a bunch of misleading/confusing/useless commits making their way to the
> commit history of the master branch. Even project maintainers are unable to
> rectify this then.
> 
> The way to change this default is described in
> https://invent.kde.org/help/user/project/merge_requests/squash_and_merge.md
> #configure-squash-options-for-a-project. However, this setting is controlled
> exclusively by KDE system administrators. In a short discussion with Ben
> Cooksley he quite reasonably suggested: "I'm afraid we need a universal
> consistent approach across our repositories, otherwise it will cause issues
> where people get surprised by different behaviour. I'd suggest starting a
> thread regarding the behaviour change to see what the general consensus
> is."
> (https://invent.kde.org/system/dolphin/-/merge_requests/895#note_1131215)
> So this is what I am now doing here.
> 
> So, does anyone mind if we change "Squash commits when merging" to
> "Encourage"?
> (https://invent.kde.org/help/user/project/merge_requests/squash_and_merge.m
> d#configure-squash-options-for-a-project)

Accidentally not squashing is far less destructive than accidentally squashing 
commits that should not have been squashed, and IME the latter is the more 
common case, ie. most MRs I review have a sensible history that should be 
preserved.

I'd be totally ok with being forced to explicitly make a decision each time 
(not sure Gitlab has that option though), but having such a (potentially) 
destructive option enabled by default is IMHO way too risky.

Regards,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20250515/39033d5e/attachment.sig>