Can we use "squash" merging instead of "merge commit" for Pull Requests?

[wookayin]

Can we have pull requests from OSS contributors merged by "squashing" or some kind of "rebasing" instead of the default strategy "merging" (i.e., creating a merge commit)?

The reason why I'm suggesting this is to make git graph look much nicer and does not look intimidating?

In my opinion, such octopus-like merge commits ("Merge Pull Request ...") are basically useless and has no practical meaning. It would be really great if the git history could be maintained linearly and clean, so that non-Googlers & OSS contributors can better read the commit history. The non-linear commit graph makes searching and tracking of history really difficult, given the large size of the repository.

I know Google uses their internal VCS (Piper) tool and use Copybara to make synchronization between Github and Piper. According to @mihaimaruseac's comment, every (internal) changelist in Piper associated with a PR must be atomic; each PR must correspond to just one single CL. However, with Github's PR workflow we can do this with the "squash-and-merge" strategy. This should be possible with Copybara and Github's repo configuration, and I strongly suggest jax (and other projects) should use this merging strategy by default so as to be more open-source friendly.

I have asked the same thing for TensorFlow (as well as many other Google's OSS projects), but it hasn't been responded or gained much attention for many years.

[froystig]

We too have said at several points that standard github-style squash-merges would be a nice improvement. Maybe we should move this discussion to the Copybara project's github to track it there?

[wookayin]

Thank you @froystig for the response. I see, so it looks like that at the moment Copybara doesn't have such features implemented yet? I'm fine with moving the discussion there and having the Copybara team more involved together.

[froystig]

My understanding is that Copybara handles the merge by pushing a git commit (i.e. an explicit merge node) rather than via Github API queries. Either way, seems good to raise with them.

[LONGMANKE]

Such "Merge Pull Request..." merge commits that resemble an octopus, in my opinion, are essentially pointless and have no real world application. It would be fantastic if the git history could be kept neat and linear so that OSS contributors and anyone outside of Google could more easily read the commit history. Given the scale of the repository, the non-linear commit graph makes searching and tracking history quite challenging.

I am aware that Google synchronizes Github and Piper via Copybara and their internal VCS tool, Piper. According to @mihaimaruseac's reply, each Piper PR must correspond to a single CL, and every (internal) changelist connected with a PR must be atomic.