Hi all,
Currently, squashing commits when merging on the orekit gitlab is allowed, but not encouraged as someone needs to tick it. I suggest we switch to ticking it by default. Of course, it can still be unselected manually.
For large contributions which deserve several commits to reflect the work and facilitate cherry picking, I would recommend not squashing.
Thoughts?
Cheers,
Romain.
I tend to refrain from squashing commit, exactly for the reason you mention: keeping an history of the work. It may help later on when validating new features, to follow again the flow of thoughts.
I agree with you, most of the times, commits should be squashed as the task is supposed to be “small”. As larger contributions are scarcer, it would make sense to automatically squash commits.
+1 for me !
Cheers,
Vincent
I think for contributors that know how to use git well, having GitLab squash commits just destroys the organization in their commits. When done well, the commits in a MR are each a logical increment of the changes. For example commit 1: refactor to prepare for new feature, commit 2: add new feature, commit 3: use new feature throughout Orekit.
For contributors that don’t know how to use git well, the commit history in their MRs usually becomes a mess. For example, commits that make a change, and then a later commit that undoes the change, adding a large file only to delete it in a later commit, or commits with unhelpful commit messages or that don’t mention the issue number (if there is one). In those cases, squashing commits can be a way to mitigate the mess. I think learning how to use git well would be the better solution, but not all contributors will want to do that.
I think committers have sufficient experience to make the judgement call whether or not to squash commits when merging the MR. When in doubt, I tend to not squash commits because it alters a history that is already public, and I think that requires a good reason.
I agree with @luc and @evan.ward. To be honest, I never ask myself whether I should squash commits. Even if, like everyone else, I can be a bit messy in this regard, I assume that they are thematic. By leaving them as they are, we reduce the number of lines to analyze when we manage to associate a regression with a commit.
As Evan says, I think it makes more sense to teach all contributors how to manage their commits properly and encourage them to exercise self-discipline.
And above all, let’s teach everyone the virtues of the git add -p command, which saves people like me who are a bit messy on a daily basis. 