On 02/10/20 19:39, Nate Graham wrote: > Hello folks, Hi
> 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. People should not blindly merge a MR without checking the commit history first: - if the submitter pushed one or more well-written atomic commits, those can be merged without squashing - otherwise, whoever merges the MR should squash the history and write a proper commit message. Or they should ask the submitter to fix its history. > > 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. +0, I don't have a preference for this default value. As explained, it's orthogonal to the problem of a bad commit history. > > Thoughts? > > Nate Cheers, Elvis