[SciPy-Dev] On the topic of separate merge commits

[Evgeni Burovski]

> On Tue, Aug 24, 2021 at 4:51 PM Tyler Reddy <tyler.je.reddy at gmail.com> wrote:
> >
> > > Hence I thought you would be the best placed to answer my interrogations.
> >
> > I am certainly not the appropriate person to target for "interrogations" on this matter. It is a long-standing practice in the community, and a feature GitHub has in their GUI to create separate merge commits even when there is only a single commit in the PR.
> >
> > If SciPy or the community strongly prefers not to do it, then I'll switch to squashing, but until then I strongly disagree that I should have to defend PRs where I do that.
>
> I must say - that's what I tend to do (merge, not squash).   I can see
> arguments for squashing, if the history is very messy, but if the
> history is good, and the commits are well organized, squashing seems
> like the wrong thing to do.   Why not leave it to the judgement of the
> person doing the merge?

I'd second what Mattew said.
(I would also create a merge commit without much thinking, btw).
There are clear limiting cases (messy history; a single 5kLOC commit
etc), but otherwise it's really a judgement call of a person who does
the merge.
While Github does offer a bunch of options, deciding to just not think
about the merge mode is a perfectly valid strategy. I personally don't
think we need to standardize it, or even think about it too much.
In the project of our size, there's going to be some variation between
maintainers, and it's likely OK. One person prefers to squash, the
other prefers a merge commit --- and it's fine IMO.

Cheers,

Evgeni