PostgreSQL 9.6.2, 9.5.6, 9.4.11, 9.3.16 and 9.2.20 released

Merge commits are useful, in my opinion, if there was significant work done to get two branches to "align" with each other. Otherwise, just rebase your work for a cleaner history.

So in short:

Merging: More "accurate" history about the work done to bring the work into the main/dev branch, yet messier.

Rebasing/cherry-picking: cleaner history, potentially at the expense of context and "accurate" history about the work done to bring in code to the main/dev branch.

Re back-branches: It's not particularly practical to use merges from/to stable branches. It may sound nice at first, but there's enough fixes that don't apply to all versions (because a feature didn't exist yet, because refactorings made bugs "accidentally" disappear, ...) that merging either to or from back-branches leads to very very messy merges, where the merge commit has to back out changes and such. I don't know of any larger project that successfully uses merges to merge to/from stable branches. So yes, it's just cherry-picking.

Re development: The case here is a lot less clear. The project used CVS for a long while, and during the migration it was decided to not make the migration harder by changing workflows even more significantly than just CVS->git. So the, enforced, policy became that no merge commits are to appear. It hasn't become a significant problem since, so that policy hasn't evolved at this point. Given the relatively small number of active committers in the project, and the fact that commits in the project are expected to "stand on their own" (i.e. are complete and working), rebasing changes before committing them isn't a problem. Several contributors, including committers, do their development in separate repositories / branches, however. But usually the history there is messy enough that they wouldn't be merged anyway. I think merging is more of a benefit when you have a more hierarchically organized project like the kernel, with subsystem maintainers that aggregate a large volume of changes, which then get pushed to Linus, who then integrates all of those.

Hope that roughly answers your question? If not, feel free to ask more about specifics.

(For context: I'm one of the committers in the project)

  $ git help log
  --graph
    [...]
    This implies the --topo-order option by default

  $ git log --graph --all --decorate  --oneline
  * 86d911ec0f (HEAD -> master, origin/master, origin/HEAD) Allow index AMs to...
  * 7c5d8c16e1 Add explicit ORDER BY to a few tests that exercise hash-join code.
  * 8f93bd8512 Fix roundoff problems in float8_timestamptz() and make_interval().
  * a507b86900 Add WAL consistency checking facility.
  * 115cb31597 Fix relcache leaks in get_object_address_publication_rel()
  * e35bbea7dd doc: Some improvements in CREATE SUBSCRIPTION ref page
  * c3c4f6e174 Revise the way the element allocator for a simplehash is specified.

  | * 1888fad440 (origin/REL9_4_STABLE)