Boost logo

Boost :

Subject: Re: [boost] [git] Mercurial?
From: Julian Gonggrijp (j.gonggrijp_at_[hidden])
Date: 2012-03-22 07:54:56


Martin Geisler wrote:

> Julian Gonggrijp <j.gonggrijp_at_[hidden]> writes:
>
>> There is no point in arguing that one mental model is superior to the
>> other until you fully grasp both of them. I urge anyone who feels
>> tempted to make agitated remarks to let this sink in for at least a
>> few hours.
>>
>> That said, I'm confident enough to think that I can give two solid
>> arguments why the units-of-work model is ultimately more productive.
>
> I also prefer people to do five units-of-work (commits) instead of one
> huge. Smaller commits should be more self-contained and will be easier
> to review.
>
> But I much prefer that the project is in a working state after every
> single unit-of-work. This is because I think of each commit as a
> snapshot that might be checked out alone.
>
> This commonly happens when using the bisect command: the tool (Git or
> Mercurial) will assist you in a binary search for a faulty commit. They
> update to the middle of the unchecked range and you have to build and
> test the commit. When doing that, it's annoying if you run into commits
> that fail because of other problems than the one you're investigating.
> Such false positives makes automated bisecting impossible.
>
> Each project must make up its own policy here.

I think what you describe here is covered by integration branches on
one hand, and the possibility to automate bisection with a custom
program that checks only for a single aspect of the code on the other
hand. Most projects will adopt those possibilities, especially the
integration branch. Automated, specialised bisection is something
that many people might not know about, but it's very useful.

-Julian


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk