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