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

[Konstantin Kharlamov]

On Sat, 2020-10-03 at 00:26 +0200, David Hurka 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.

Everyone has such commits on more or less non-trivial changes. As a matter of
fact, ATM at dayjob I'm working on a branch, where either because of some
complexities, or because I wanted to make stuff work, and clean up it later, I
have 3 "dirty" commits on top of my branch. Two of them will eventually be
removed, and another one will be cleaned up, and squashed into the previous
commit.

That doesn't prevent me from having a clean history when I finally git-push to an
opened MR, so my colleagues could easily review my code. I know that if I'd push
some "dirty" commits to my "merge request", my colleagues would unnecessarily
spend time navigating these commits, and reviewing code-lines that were fixed in
the further commit. And why? Just because I didn't care to squash last commit?

I should note though that while I do a lot of stuff with git as I work
(e.g. swapping commits, amending a commit, going back to a commit in history then
changing it, etc.), I spend minuscule amount of time on it. To work with git
quickly you simply need to establish some workflow. From my experience the
following things help:

1. Shell autocompletion. E.g. for zsh I'm using `zsh-autosuggestions`. This
   allows you to rarely type longer commands, such as `git rebase
   upstream/master`. Since I rarely rebase on something else, once I typed `git
   r`, I have the completion I can use.
2. Having aliases to commands you use most often. For examples ones I have
   regarding git in my zshrc:
   
       alias rc="git add -u && git rebase --continue"
       alias ca="git add -u && git commit --amend -v"
       alias cax="git add -u && git commit --amend -v --no-edit"
       alias c="git add -u && git commit -v"
       alias po="git push origin HEAD"
       alias pu="git push upstream HEAD"
       alias or="git pull origin   HEAD --rebase"
       alias ur="git pull upstream HEAD --rebase"
       alias co="git checkout"

   The most often used alias here is `cax`. It often happens that you already
   have a commit on top, and you also did some newer changes that should part of
   the commit. So instead of typing out `git commit --amend`, etc, you execute
   `cax`, which is instantaneous.