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