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

List:       boost
Subject:    Re: [boost] [git] Pushing commit(s) after pulling
From:       Vladimir Prus <ghost () cs ! msu ! su>
Date:       2014-08-19 14:53:55
Message-ID: lsvoe3$q4b$1 () ger ! gmane ! org
[Download RAW message or body]


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



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost


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