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@joachim-breitner.de http://www.joachim-breitner.de/