Re: [boost] [git] Mercurial?

Subject: Re: [boost] [git] Mercurial?
From: Dave Abrahams (dave_at_[hidden])
Date: 2012-03-20 11:44:32

on Tue Mar 20 2012, Thomas Heller <thom.heller-AT-googlemail.com> wrote:

> On 03/20/2012 04:12 PM, Dave Abrahams wrote:
>>
>> on Tue Mar 20 2012, Sergiu Dotenco<sergiu.dotenco-AT-gmail.com>  wrote:
>>
>>>> When you want history to be readable and logical to other contributors,
>>>> you will likely want to use "git rebase -i" to tidy up or roll up your
>
>>>> *local* commits *before* you share them with others. It is your private
>>>> repository and private changes, until you share it.
>>>>
>>>> This enables tight private iteration loop while keeping the noise off
>>>> public repository. Eg. you can do commit small change, run test, commit
>>>> more changes, run more tests, to eventually find out that the first
>>>> change had a fatal bug. Edit first commit, add necessary comment, rinse
>>>> and repeat as necessary. When done and tested, roll up your commits and
>>>> share with others.
>>>>
>>>> Just an example of style really, the important point is that your
>>>> development style will not create unnecessary commits in shared
>>>> repository. Well at least this is my experience from using git, and it
>>>> seems to work well for my (very distributed) team.
>>>
>>> Everything you described works in Mercurial as well, probably much better.
>>
>> For what it's worth, I found history rewriting to be quite a bit more
>> difficult in Mercurial than in Git.  I don't know why; it may be that I
>> never learned the magic incantation that made it easy.  Like I said,
>> these stories exist in both directions.
>
> I am curios now ... I get the feeling that history rewriting is one of
> the git killer features. Can someone enlighten me what the fuss is
> about? What is the usecase?

It's primarily about presenting a logical series of changes to the world
without exposing distracting hiccups like fixes for typos and bugs,
decisions to try a different approach in one part of your new material,
etc.  Rebasing in particular (a special case of history rewriting) is
useful for removing merge commits, presenting a linear history, and
making it easier for upstream maintainers to evaluate your changes.
After rebasing your series of changes on the latest upstream work
(during which process you resolve any conflicts that arise) you have
incorporated upstream work and are left with a clean set of changes on
top of it.

I believe sophisticated branch management tools like topgit may rely on
this capability, but I admit that I'm not 100% sure.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com