Moving away from squash merge

[ivnsch]

I've re-evaluated squash merge as default merging strategy and came to the conclusion that it mostly just generates inconveniences. When branching from a feature branch and merging the later, git can't figure out the common history, which makes us solve unnecessary conflicts.

Squash merge is used to keep a clean history, but this is a presentation problem: By using appropriate queries we can get this same history, without messing up the internals. Examples:

Show only merge commits (equivalent to history after squash merge):
git log has --merges

Change log for a release:
git log --first-parent <last_version>..<current_version>

With proper merges, we can also merge locally and push, which will automatically close the PR in Github. Note: in these cases we should use --no-ff (which Github should use by default), in order to make always a merge commit (which is useful when using e.g. git log has --merges).

Needless to say, preserving the feature branches history in the main branches can also be useful, without relying on Github's nice to have, non-git-native feature of preserving it after the branches were deleted.

This would apply to the app's repos as well.

[scottleibrand]

I don't have a strong opinion about what's best for this project, but here are some notes from my previous experience maintaining open-source projects on GitHub:

In my experience with OpenAPS, squash merge has worked best primarily because of how it works with GitHub (not git). Specifically, it allows feature branches to be merged as a single commit, so the diff for the release PR contains only a manageable set of PR merge commits, not every commit made on every feature branch. You note that it's possible to get a similar behavior on the command-line, but that doesn't solve for being able to review things in GitHub itself.

Our workaround for the inconvenience you note has been to make sure to merge the upstream branch back to the downstream branch, so that the squash-merged commits upstream get merged in and you're left with only the diffs actually made on the downstream branch when you PR back upstream.

[ivnsch]

The release history doesn't seem very useful for our project though, since the main development is in this repo and it would be probably impractical to use git flow. In the app's repos we see only "Updated core to x". We need (probably non-Github) tooling anyway.

[scottleibrand]

Ok. No objections to either approach.