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

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

Gavin,

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 https://github.com/boostorg/build 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.

Thanks,
Volodya