On Sat, Oct 3, 2020 at 12:26 AM David Hurka <david.hu...@mailbox.org> wrote: > > > > 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, [...] > > This workflow is too advanced for me. My commits are usually garbage like “fix > pipeline”, and often contain notes on what I was doing and what I still need > to do. If I was maintaining a clean history, that wouldn’t be possible. >
Arguing from theory on maintaining a good commit history, this actually means you should not be squashing your commits -- you should be using the `fixup` operation in an interactive rebase.... But I understand where you are coming from. At work we used to have a policy on squash commits for much the same reason, even professional developers don't always bother to learn their scm tools. (I've also worked with someone who did not appreciate the idea of commit history and commit messages at all, as in a "why would I ever look at that?" level of don't care). Still others have raised a valid point that for long term maintenance it is better to have a curated history if you can get it. That is why we abandoned it eventually, especially for non-functional refactoring commits or for a bunch of accumulated bug fixes squashing did more harm than good. Essentially you get punished for doing things 'correctly' (for opinionated values of correct). > > Is it possible to make the default configurable for each user? Then I could > simply check “Squash by default” and all my MRs are how I want them. > > I'm not sure about that, but at least it *is* possible to do this per repo, there's no need why projects should stick to a global default. So if you're the maintainer you could nudge the default towards what makes sense for your project and its dominant workflow. Go to Settings (side bar) > General > Squashing and merging. Apparently that has been a feature of Gitlab core since version 11. Regards, - Johan Ouwerkerk
