OK with Squash Merge?

[michalfita]

@tmplt, @tstellanova, @martinmortsell, @jamesmunns It's typical in open source project to squash merge PRs as they're sourced from forks, but that's sometimes not how companies prefer doing.

What are your preferences, if any?

Thanks.

[tstellanova]

My preference is to squash merge PRs that are essentially all changes for a single feature or bug fix. However, if the PR contains a large variety of unrelated changes (which unfortunately we’re occasionally presented with) then do not squash, retaining the individual commit history.

…

On Jun 1, 2022, at 6:49 AM, Michał Fita ***@***.***> wrote:  @tmplt, @tstellanova, @martinmortsell, @jamesmunns It's typical in open source project to squash merge PRs as they're sourced from forks, but that's sometimes not how companies prefer doing. What are your preferences, if any? Thanks. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.

[michalfita]

Let's decide on individual basis then.

[tstellanova]

Sure. That said, on FOSS projects I believe it’s perfectly reasonable for maintainers to ask contributors to submit focused PRs. I’ve typically seen the random bucket-o-changes PRs arriving from upstream or vendor repos.

…

On Jun 1, 2022, at 7:17 AM, Michał Fita ***@***.***> wrote:  Let's decide on individual basis then. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.

[tmplt]

Whatever method that yields a better commit history is the best. The first draft of a module would logically be squashed to omit information about (e.g.) transient issues/refactors fixed during the implementation, so #16 should be squashed. If a PR's commit history contains information of value, it should not be squashed.