In most cases a PR should be squashed into a single commit, but we should always send PRs
and merge using GitHub as that runs Travis on the PR before committing.
----- Original Message -----
From: "Scott Rossillo" <srossillo(a)smartling.com>
To: "Marek Posolda" <mposolda(a)redhat.com>, "keycloak-dev"
Sent: Saturday, 11 July, 2015 2:40:52 PM
Subject: Re: [keycloak-dev] Git History w/merges of upstream/master
Not a problem with PRs. I'd just say rebase before sending w PR rather than
I was just suggesting anyway. Not a real issue.
On Sat, Jul 11, 2015 at 5:06 AM Marek Posolda < mposolda(a)redhat.com > wrote:
I don't have strong opinion on it. I am personally always doing rebase
before sending PR to the master. And I agree that rebase is cleaner than
But unfortunately if you want to merge pull requests automatically on
github (Clicking on button "Merge pull request" ), github will always
merge the PR, not rebase. For the really linear commit history, we will
need to avoid merging PRs in the github UI, which is more work for the
person, who is merging the PR...
On 11.7.2015 03:54, Scott Rossillo wrote:
> Not the biggest deal, but always see commits like:
> "Merge remote-tracking branch 'upstream/master’ commits"
> If you `git pull —rebase` you can avoid these and the project history will
> be a lot cleaner.
> ~ Scott
> keycloak-dev mailing list
keycloak-dev mailing list