On Fri, 2020-10-02 at 11:39 -0600, Nate Graham wrote: > Hello folks, > I've been told that our Sysadmins have developed some tooling capable of > checking the "Squash when merging" checkbox by default for new Merge > Requests. This would be a downstream solution to > https://gitlab.com/gitlab-org/gitlab/-/issues/222175. > > I'd like to propose that this be done as a sane default for new Merge > Requests. Now, personally I have gotten used to the alternative "curate > your MR's git history" approach and have written documentation for it at > https://community.kde.org/Infrastructure/GitLab#Curating_your_merge_request_commit_history . > > However, it remains a fairly advanced workflow which is challenging for > newcomers, drive-by-developers, and people not as familiar with git. For > these people, squash-merging makes much more sense, and when they forget > to check that checkbox and someone merges their work, the result is tons > of garbage commits in the git history.
Well, what you say makes sense. But I don't think squashing commits would help too much with having clean git history in these cases. You see, when there's an MR with tons garbage commits, this likely also means the contributor is doing something complicated enough that should be separated to more than one commit. In which case it's easy to see a problem with this squash-checkbox: a maintainer asks the author to broke their MR to three commits per functional changed, contributors does that, and then everyone happily forget to remove that pesky "squash-checkbox", so upon merging all the work in separating commits gets wasted. It may be a question of whether that newcomer needs to learn to work with git just to contribute. Well, I think that the fact they try to contribute means they're a developer, whether a beginner or not. And as a developer, they have to learn to work with the git-history. I think it's a nice moment to mention this great blog-post on the matter by Peter Hutterer, a libinput maintainer: http://who-t.blogspot.com/2009/12/on-commit-messages.html It may be old, but still relevant. > Accordingly, I think squash-merging makes sense as the default value to > avoid this. People who are comfortable with the "curated MR commit > history" workflow will of course still be able to turn it off. IMO it > makes more sense to ask experts to turn it off than to ask newcomers and > novices to turn it on. Please don't. This will result in having many MRs with a valid history to get squashed just because people would keep forgetting to uncheck it. Given there are much more people who aware of how to work with git history, I think this would hurt more than occasionally merging a non-squashed MR from a newcomer.
