> Merge commits provide no value for projects that are based on Github Well, the value sits not in the merge commit, they are merely an artifact of the fact that things evolved separately and rejoined at some point. Which also allows to track changes that simply reconciled the separate evolution. Saying that there's no information there, is in part denying history.
> It makes the usability of cherry picking/merging branches a lot less trivial I'm surely not arguing to keep all temp commits, but instead, have well defined commits that sometimes are allowed to have existed on a branch. But very case dependent. E.g. the scala 3 work for pekko-http, seems to be something were seeing the two things evolve apart from each other makes sense. > If we want signatures we cannot allow squashing, so 2. seems a bit inconsistent... It seems but it isn't. It means that the merger assessed that there's no need/value to maintain the separate commits, so they're allowed to be squashed into 1 commit. At that point, GH does the following: 1. GH is listed as Git committer and the GH signature is applied 2. The GH Actor (so merger) is listed a author, which is fair, as the one deciding to make one commit. The GH signature testifies to the identity of the author, who was authenticated in GH (yes that make GH a central authority on this front) 3. Other authors will be listed with the Co-authored-by comment tag. Which is fair, given that it's about attribution. Just like the Git author tag is. These elements establish the same or similar committer identity trust as locally signed commits (or rebases) do. To sum up: 1. I don't think there's a one size fits all approach, any of squash, rebase and merge can make sense. 2. I do think commit signatures are important, because the signer is the one that declared things to be trustworthy. 3. Because of 2, GH UI rebase is problematic Because of point 2, using squash and rebase should of course be done with care and you can certainly argue that contributors are required to make a set of clean commits before they can be merged. That being said, it's very possible that this is an enterprise mindset which doesn't fit an open source project.
