Fixing rebase rather than avoiding it

[Óscar Fuentes]

Teemu Likonen <tlikonen at iki.fi> writes:

> * 2010-03-04 05:29 (+0100), Óscar Fuentes wrote:
>
>> If you want to use bisect, git forces you too make all commits
>> bisectable.
>
> I don't understand where this "forces" comes from. Perhaps you should be
> talking about the continuum "easy" and "difficult" to find a commit
> which introduced a bug. I'm certainly curious about this "forces" thing.
>
>> With bzr you can limit that policy to merge commits, and then apply
>> more liberal rules for committing on feature branches.
>
> What kind of liberal commit rules would make bisecting with Git
> difficult? How is it difficult?

I use bisect mainly with a project of 100,000+ revisions (and growing
fast) that takes more than 30 minutes to build on a quad core. I write a
script, start automatic bisecting and go away for several hours. You'll
understand that standing on front of the computer for hours just in case
some revision confuses bisect (because it breaks the build, etc) is a
bit inconvenient. This kind of fully automatized bisecting is possible
thanks to strict rules about the quality of each and every commit.

Hope it is clear now.