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
"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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk