Re: [boost] [git] Pushing commit(s) after pulling

Subject: Re: [boost] [git] Pushing commit(s) after pulling
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2014-08-18 23:35:59

On 19/08/2014 14:53, Edward Diener wrote:
> I share a library with others and make some commit to a branch of that
> library. Then I try to 'push' the commit, only to be told that there are
> changes that have been made which I need to 'pull'. So I 'pull' the
> latest changes for that branch, and luckily there is no conflict(s) with
> my local commit(s).
>
> What do I do now ?
>
> I can 'push' my changes successfully but then the history of my
> particular changes appears to be lost.

Lost in what way?

> Am I supposed to revert my changes to the local repository by doing a
> 'reset' and then reapply those changes ? That seems onerous.
>
> What is the right way to 'push' my changes and still preserve the
> history of each one of them on the remote repository ?

What should have happened is something like this:

A - B - D - F
      \     /
       C - E

Where A/B are the common ancestors of the changes (B is the version that 
you last fetched).  You made commits C & E in your local copy, but in 
the meantime your collaborators made commit D and pushed it.  When you 
try to push E, git will warn you that you don't have the latest code and 
you should pull.

When you "git pull", you will fetch D and then git will merge this to 
create F.  You should now be able to push F and it will include all 
changes from both sides and the revision graph will look like the above. 
  (git's revision graph is a very powerful and handy thing, completely 
unlike svn's graph, which is fairly useless; if in doubt, always look at 
the graph.)

There's an alternate method of merging changes ("git pull --rebase") 
that would instead result in this graph:

A - B - D - C' - E'

ie. git fetches D, then rebases your original changes C and E onto it, 
thereby pretending that you created them after D as far as the history 
is concerned.  Some people prefer this, others dislike it, but it's 
important to note that rebasing is a history-modifying action and you 
should never do it on anything that has already been pushed publicly 
(note that the original C and E are "destroyed" during the course of the 
above -- this means that if anyone else had based further work on one of 
these they would be forced to rebase in turn to get their copy back into 
a sane state).  Which sounds a little scary when you first read it, but 
once you get your head around it can be quite handy when used correctly.