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:

quoted

On Nov 1, 2007, at 10:11 AM, Andreas Ericsson wrote:

quoted

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.

If you test a merge and it is bad, git (eventually) picks a commit on one of
the branches. If that commit is good, then the merge-base is good, so that the
bug lies on some other branch. If that commit is bad, then the bug is on some
ancestor of the branch. Thus, no need for special book keeping.

  Tom