So to close the loop on this discussion, it seems like folks are not
generally in favor of my proposal, for various sensible and
well-considered reasons. I will beef up our GitLab documentation to add
more information about how to use a curated commit history approach and
will drop the idea to squash by default.
We will need to commit to vigilance when merging MRs--our own or someone
else's--to make sure that merge requests which don't have curated commit
history are squashed to avoid accidentally polluting the git history.
Note that using the "Apply suggestion" feature in the Gitlab web UI
creates new commits in the merge request. These must be either manually
squashed into the commits of a commit-curated MR, or squashed at
merge-time for an un-commit-curated MR.
Nate
On 10/7/20 10:12 AM, Carson Black wrote:
Am Mi., 7. Okt. 2020 um 11:27 Uhr schrieb Thomas Friedrichsmeier
<thomas.friedrichsme...@kdemail.net>:
Am Tue, 6 Oct 2020 08:26:02 -0600
schrieb Nate Graham <n...@kde.org>:
GitLab already *kind of* offers this, in the form of the "Squash
commits" checkbox next to the merge button. Apparently it's not
obvious enough though, because I can think of a bunch of cases of
multi-commit MRs with mostly garbage commits accidentally not being
squashed when merging.
Unfortunately the workflow is rather backwards in that the checkbox
needs to be ticked, when creating the merge request, not after review.
However right before merging would be the time to judge whether the
commit history contains valuable information or useless noise.
(IIRC the "squash commits" checkbox can still be changed at that
point, but it's not obviously visible, then).
The checkbox is fairly visible for me, by the merge button like Nate
said: https://imgur.com/a/gzRDYnZ
This can be ticked immediately after review and before merging easily
like you said would be the ideal time to do so.
-- Jan
