Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref

> On Fri, Nov 02, 2007 at 11:03:36AM +0100, Andreas Ericsson wrote:
>> Steffen Prohaska wrote:
>>> On Nov 1, 2007, at 10:11 AM, Andreas Ericsson wrote:
>>>> It's easier to bisect. If git bisect lands you on a merge-commit,
>>>> you need to start a new bisect for each of the parents included
>>>> in the merge. Hopefully the nature of the merge gives a clue so
>>>> the user can make an educated guess as to which parent introduced
>>>> the bogus commit, but for an "evil octopus" (unusual) or if the
>>>> merge had conflicts which were resolved in a buggy way (not
>>>> exactly uncommon), it can be quite a hassle to get things right.
>>>> With a mostly linear history, this problem goes away.
>>> This is really an interesting point. I did not start to use
>>> git bisect regularly. But I certainly plan to do so in the future.
>>> Couldn't bisect learn to better cope with non-linear history?
>> Perhaps it could, but it's far from trivial. I started hacking on
>> a wrapper for git-bisect which would do just that, but gave up
>> rather quickly as the book-keeping required to remember each and
>> every parent-point tried just got out of hand, and it *still*
>> wouldn't run in full automatic. It broke down because I also
>> wanted merges on non-first-line parents to be delved into. If
>> that didn't happen, I wouldn't *know* the bisect would run fine
>> without me watching it, so then it was as useless as if I'd have
>> had to sit there the entire time anyway.
> 
> I haven't had occasion to use git-bisect much, but I was under the
> impression that bisect could already handle merges, or any other shaped
> history just fine.
>