From: Andreas Ericsson Date: Fri, 02 Nov 2007 13:52:15 GMT Subject: Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref Message-ID: <472B2B8F.1060203@op5.se> In-Reply-To: <20071102132446.GA31758@hermes.priv> Tom Prince wrote: > 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. > It appears the code supports your statement. I started writing on my hack-around about a year ago, and the merge-handling code got in with 1c4fea3a40e836dcee2f16091bf7bfba96c924d0 at Wed Mar 21 22:16:24 2007. Perhaps I shouldn't be so paranoid about useless merges anymore then. Hmm. I shall have to look into it. Perhaps Junio can clarify how it works? The man-page was terribly silent about how git-bisect handles merges. -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231