On 16/04/15 14:00, John Maddock wrote:

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?

This is exactly what I warned about couple of days ago in boost-build list. Doing rebase you edit history, which is dangerous operation by definition. I understand why you guys want to see plain clean history - but this is wrong in most cases. Think about it - real history _is_ _not_ _plain_ in case of distributed development, but you're trying to make it plain (i.e. rewrite). Such rewriting may work without problems in trivial cases, but generally you shouldn't expect it would be always smooth. I'll try to explain it. If Alice and Bob started from some commit C and did several commits in their local repositories, they already have two different histories. Now, if they want contribute their changes back to upstream, first one (Alice) just push to remote branch, and remote history becomes like below (left-to-right): -*-*-C-*-*-*-A (here A is Alice's top commit) Now Bob want commit too, but his local history looks like this one: -*-*-C-*-*-*-B (here B is Bob's top commit) So Bob has two choices. First - merge remote branch to his local and push back merged changes (default git behavior). Final history will look then like this one: -*-*-C-*-*-*-A-M(here M is newly added "merge" commit) \ / *-*-*-B Second choice: rebase his history on top of current remote HEAD. History will be plain then: -*-*-C-*-*-*-A-*-*-*-B This looks good, right? But think about two things: (a) what if rebase will not be smooth and there would be conflicts in process of rebasing? Git will break rebasing on first conflict (i.e. somewhere in middle of process) and you'd be enforced to fix it manually. On this step you should be _very_ concentrated to fix it and resume rebasing process properly, because otherwise you can easily corrupt anything (accidentally throw away several commits, for example). (b) what if Bob's commits depends on something which was broken in Alice's history? If history was merged, Bob (or someone else) can easily revert merge commit, fix issue in Bob's or Alice's local branch, and then merge again - without worrying other developers. In case of rebase, Bob (or someone else) enforced to revert all Bob's (or all Alice's) commits one-by-one (in proper order!), making history much more dirty; or, alternatively, all other developers would wait while Bob fix bug and make one more commit to the common repository. Shortly speaking, if you're doing rebase, you must know what you're doing, because it's dangerous. Otherwise you'll break something, sooner or later. -- Dmitry Moskalchuk

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.