Boost logo

Boost :

Subject: Re: [boost] [git] Pushing commit(s) after pulling
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2014-08-19 03:58:31

On 19/08/2014 16:18, Edward Diener wrote:
>> Lost in what way?
> The message in the log for my push says:
> 'Merge branch 'develop' of into develop'
> rather than the actual commit message for my local repository change.

That's actually correct though (albeit confusingly worded). Have
another look at this:

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

Your current head will be F, so that's the commit message you're seeing,
which is just a merge of D & E. The commit messages for C, D, and E
themselves are still intact and you should see them if you look at the
log. (When you push F, C & E come along for the ride automatically.)

> I think I was supposed to do the "git pull --rebase" so that my change
> is applied on top of the pull's latest.

Possibly. As I said this tends to be one of those bikeshed arguments,
with some people arguing that it should always be used and others
arguing that it should never be used. (It mostly revolves around the
commit messages being more readable with rebase, but the actual
development timeline being more visible without.)

Coming from an SVN background I think a rebased pull is the easiest
option to get your head around, since it's similar to how SVN itself
works (it does an invisible merge between your uncommitted changes and
the incoming changes whenever you do an Update); the difference is just
while in SVN you have a single clump of uncommitted changes when this
invisible merge happens, in Git you can have many separate committed
clumps of changes.

The other related option is "squash"; it's similar to a rebase except
that all your changes are folded into a single commit, ie. instead of
this graph:

   A - B - D - C' - E'

you get this one:

   A - B - D - F

where F contains both C & E in a single commit. This is probably the
variant that's the most like an SVN Update&Commit cycle, and again some
people prefer this (particularly if their local commits aren't logically
divided, maybe just multiple parking commits that don't all compile or
pass tests) while others (perhaps more organised with their commits)
prefer to retain each individual commit as a logical unit.

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