Could margebot squash?

[Joachim Breitner]

Hi,

as Richard rightfully says, this is not an aspect of our workflow that
we should change right now, so consider this thread now a leisurely
coffee machine chat full of hypotheticals, not a concrete call for
action. But I’m happy to elaborate the technical details here.

Am Montag, dem 04.04.2022 um 09:04 +0100 schrieb Simon Peyton Jones:
> One downside of this approach is that it requires destructive changes
> to work-in-progres branches: I might think the MR is ready, squash the
> commit sequence into a single commit, but then more work is ready. Now
> it’s hard to revert individual patches, or collaborate with others,
> because the git history was disrupted.
> 
> Another is that the commit message itself isn’t very easily visible to
> reviewers. 
> 
> I couldn't parse this.  What does "but then more work is ready" mean?
> Why is it hard to collaborate with others?  


I think I meant “more work is needed”. Consider the no-app-invariant-
MR. I asked Sebastian to collaborate with me on the branch. It could
have happened that he was making anther refinement to the DmdAnal while
I was preparing the branch for merging. If I made final adjustments, 
squashed the commits and force-pushed the branch while he was working
on it, then he can’t push his branch anymore and has a hell of a time
of figuring out what went wrong, because by squashing and force-pushing
(the “force” is telling) git lost the history it needs to cleanly merge
my changes into his branch to push it again.

In “my” workflow, you never have to force-push a feature-branch, so
this problem does not occur.

>  Which commit message "itself isn’t very easily visible to reviewers."?

Again, consider the no-app-invariant MR. You approved it, without even
knowing what the final commit message would be, because I didn’t squash
yet. So the commit message that will end up on master was not visible
to you as a reviewer.


In “my” workflow, the final commit message will be taken from the MR
description, very visible to a reviewer and easily editable by all.
Maybe a minor point (commit messages are not as important as, say, good
Notes) but still.

Also, I often see that MR descriptions are not kept up-to-date as the
MR changes; this workflow creates more incentives to keep the MR
description good.


> I regard squashing as a positive bonus.  I take a long series of
> commits with messages like "bugfix" and "fix comments" and put them
> into one or more logical commits, each doing (so far as poss) as
> single thing, each with a comprehensible commit message. 

I do too! There is still squashing happening, but it is done by
margebot, not you manually, and only “in transit” to master – your
feature branch is left alone in the process.

(This means there would only be _one_ logical commit per MR, not
multiple, which may be the biggest downside of this. I thought I
disliked the workflow for that reason as well, until I worked with it
in a few projects, and I no longer missed it. Multiple logical commits
didn’t seem that useful after all, especially since they are no longer
individually CI-checked, etc.)


Anyways, probably these things become easier and prettier (or simply
different) once we can use Gitlab’s native merge train. And
unfortunately every workflow is a compromise in one way or another with
git…

Cheers,
Joachim
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/