GH-2011 back to merge-commits as our preferred strategy

[abrokenjester]

GitHub issue resolved: #2011

Briefly describe the changes proposed in this PR:

• back to specifying 'merge-commit' as our PR merge strategy

---

PR Author Checklist (see the contributor guidelines for more details):

• my pull request is self-contained
• I've added tests for the changes I made
• I've applied code formatting (you can use mvn process-resources to format from the command line)
• every commit message starts with the issue number (GH-xxxx) followed by a meaningful description of the change
• every commit has been signed off

Note: we merge all feature pull requests using squash and merge. See RDF4J git merge strategy for more details.

[abrokenjester]

I briefly thought about also adding rebase again as a merge option, and while I would personally like it, I think in the end we're better off just keeping it simple, and doing everything using merge-commits.

[hmottestad]

It's fine with me. Do you have any tips for squashing a branch together that has develop merged into it several times?

[abrokenjester]

It's fine with me. Do you have any tips for squashing a branch together that has develop merged into it several times?

I think this is only a problem if there are merge conflicts involved. In any case, the simplest way to deal with it is probably to use rebase instead of merge to bring your branch up to date with develop. Also has the advantage of making the history easier to read after your branch has been merged back.

[hmottestad]

Bit late to start rebasing it now. Haven't bothered much with rebasing since we squash and merge anyway.

[abrokenjester]

Bit late to start rebasing it now. Haven't bothered much with rebasing since we squash and merge anyway.

I'm fine with still using squash and merge for your existing feature branch. Just for any future work, we go back to manual squash + merge commit.

[hmottestad]

We can probably keep both methods. For our own work we can squash and merge if we want, while for other committers we use normal merge.

[abrokenjester]

We can probably keep both methods. For our own work we can squash and merge if we want, while for other committers we use normal merge.

I thought of that, but it makes things more error-prone, having two separate merge methods in play. Also, there is a fundamental problem with git overwriting the author field that can affect core committers as well.

So I'm really not in favour of keeping squash-and-merge as an option.