[prev in list] [next in list] [prev in thread] [next in thread] 

List:       boost
Subject:    Re: [boost] [git] Pushing commit(s) after pulling
From:       Gavin Lambert <gavinl () compacsort ! com>
Date:       2014-08-19 7:58:31
Message-ID: lsv038$ije$1 () ger ! gmane ! org
[Download RAW message or body]

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.



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[prev in list] [next in list] [prev in thread] [next in thread]