Fixing rebase rather than avoiding it

[Teemu Likonen]

* 2010-03-04 14:00 (+0100), Óscar Fuentes wrote:

> 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.

Well, your explanation is clear in itself but I'm not sure how it
relates to this discussion. My fault probably. I know how Git works and
if you are saying that automatic "git bisect" is somehow vulnerable to
build failures then you are just wrong. But maybe I'm not understanding
you. It happens. :-)

So, again, I'm referring to your comments: What kind of "liberal commit
rules" would confuse "git bisect" and perhaps not some other tool? You
said that if one wants to use "git bisect" commits must have this
quality of being bisectable. What kind of commits don't have this
quality, and therefore makes "git bisect" fail even if user wants to use
it?