Re: [boost] [Git] Pull requests and rebasing

Subject: Re: [boost] [Git] Pull requests and rebasing
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2015-04-16 18:52:09

On 16/04/2015 23:00, John Maddock wrote:
> So I have a rebase vs pull question:
>
> Lets say I have a PR, if I merge that to my local tree using "git pull
> --rebase remote-repro branch-name" then I get a nice clean history
> locally without those pesky merge commits cluttering everything up.  But...
>
> Now I can't fast-forward when I push to the remote, *because I've
> changed the existing history of the develop branch*.  Would this not be
> a) bad form, and b) potentially dangerous to push to the remote develop
> branch?

"git pull --rebase" is for updating "feature" branches -- ie. it's what 
the submitter of the PR would do on the PR branch itself to incorporate 
changes made on the parent branch (eg. "develop") into the PR branch, to 
make it easier to merge.

You should never ever run that command on your mainline branches (master 
and develop).

If you want to merge a PR without a merge commit, then you should 
cherry-pick it, as others have said.  It's not unreasonable to have a 
merge commit in this case, though, since you are merging some 
third-party work.  Typically the case where you want to avoid merge 
commits is when you're doing work yourself on a local feature branch.

Also note that Github has convenience tools for automatically merging 
PRs, although the downside of that is that you don't get to test the 
results before they end up on your mainline branch.