Boost logo

Boost :

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at