On Wednesday 04 November 2009, Junio C Hamano wrote: > Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > > On Wed, 4 Nov 2009, Linus Torvalds wrote: > >> Yes, it is a behavioral change, but is it a bad one? > > > > .. and perhaps we could introduce --bisect-refs as the "old behavior" > > of '--bisect' to git rev-list? > > > > I kind of suspect that it is unlikely that people are using 'git > > rev-list --bisect' while _inside_ a bisection, but then wanting to > > bisect someting that is outside the set of commits we're currently > > actively bisecting. > > > > But maybe I'm wrong. > > Maybe I'm wrong too, but I do not think that is plausible that people are > doing nested bisection that way. It is probably a useful thing to do, > but if somebody has thought of doing so we would have at least seen a > request to add a way to tell "git-bisect" what names to use to record the > good/bad set of commits under to make their implementation easier. I > haven't, and I take it an indication that it is very implausible that > such scripts by people exist to be broken by this change. > > I was more worried about people who reinvented the wheel and are using > their own git-bisect.sh derivative. It probably was forked from the > version that still used 'git rev-list --bisect", manually feeding good > and bad set of commits to it from the command line. But then what they > are feeding would be the same as the new --bisect option implicitly gives > them anyway, so there won't be a regression either. I don't remember exactly when, but at one time some people talked about parallelizing bisection. The idea was that if it takes a long time to test one commit but you can test many commits at the same time (for example on different machines), then you can bisect faster by testing at the same time the current commit that git bisect checked out for you and for example the commit that git bisect would give you if the current commit is bad and the commit it would give you if the current commit is good. So to do that you would use "git bisect start ..." and then you could use: $ git rev-list --bisect HEAD --not $GOOD_COMMITS to get the commit that you would have to test if the current commit is bad and: $ git rev-list --bisect $BAD --not $GOOD_COMMITS HEAD to get the commit that you would have to test if the current commit is good. Ok, perhaps nobody is doing that. And yes I agree that it would be probably better to have --bisect be the name of the revision machinery option and --bisect-refs or perhaps another name like --bisect-compute be the name of the special option to "git rev-list". But perhaps we can introduce --bisect-compute to do the same thing that --bisect currently does and deprecate --bisect with a warning and then a few versions later remove it and after a few more versions introduce --bisect to do the same as --bisect-refs. Best regards, Christian. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html