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

Subject: Re: [boost] [Git] Pull requests and rebasing
From: Dmitry Moskalchuk (dm_at_[hidden])
Date: 2015-04-16 09:44:57

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