Boost logo

Boost :

Subject: Re: [boost] [git] Pushing commit(s) after pulling
From: Vladimir Prus (ghost_at_[hidden])
Date: 2014-08-19 10:53:55


On 08/19/2014 11:58 AM, Gavin Lambert wrote:
> 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.

Thanks for writing this down in detail! It's indeed a matter of preference, although:

- For Boost.Build specifically, I prefer to avoid merge commits as much as possible.
- In most cases of a single commit, or a few unrelated commits, using "git pull" and
   creating merge commits results in rather noisy and unclear history. I'd imagine
   maintainers of other components might prefer to avoid that - although it's up to them,
   of course.


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