I checked the GitHub docs. Unfortunately --no-ff is the default when using the "Merge" button in the browser and it cannot be changed! To have use fast-forward, Dave must always pull the change locally and merge it by hand.
So for simplicitly we should live with --no-ff to make Dave's life easier, but I think it should be common to reduce the number of commits per PR to one per feature/bug covered by the PR. -Markus
-----Original Message----- From: pgsql-jdbc-owner@postgresql.org [mailto:pgsql-jdbc-owner@postgresql.org] On Behalf Of Vladimir Sitnikov Sent: Montag, 20. Juli 2015 20:35 To: Dave Cramer Cc: List Subject: Re: [JDBC] Git branching structure: ff or no-ff
I think we'd better keep existing commits as is otherwise everybody will have problems with on-going pull requests.
For new commits I suggest we use certain level of rebasing. I suggest rebasing features on top of master before integration, so the history is linear.
What do you think?
For instance: commit cddcd185 feat: Improved composite/array type support... git checkout -b tmp cddcd185 # git fetch origin pull/ID/head:BRANCHNAME && git checkout head:BRANCHNAME can be used here to fetch a pull request from github git rebase 008f6e8b2f8d # use rebase -i to squash commits as required. 008f6e8b2f8d was origin/master before cddcd185 merged in git checkout master git merge --ff-only tmp git branch -D tmp # remove branch
