Junio C Hamano <gitster@xxxxxxxxx> writes: > Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> writes: > >> Junio C Hamano <gitster@xxxxxxxxx> writes: >> >>> * ad/bisect-terms (2015-08-03) 4 commits >>> - bisect: allow setting any user-specified in 'git bisect start' >>> - bisect: add 'git bisect terms' to view the current terms >>> - bisect: add the terms old/new >>> - bisect: sanity check on terms >>> >>> The use of 'good/bad' in "git bisect" made it confusing to use when >>> hunting for a state change that is not a regression (e.g. bugfix). >>> The command learned 'old/new' and then allows the end user to >>> say e.g. "bisect start --term-old=fast --term=new=slow" to find a >>> performance regression. >>> >>> Michael's idea to make 'good/bad' more intelligent does have >>> certain attractiveness ($gname/272867), and makes some of the work >>> on this topic a moot point. >>> >>> Will hold. >> >> This topic has been there for a while and unless I missed a discussion, >> nothing happened. While I agree that Michael's idea is good and makes >> this series less useful, I think this topic also makes sense. >> >> I'd be in favor of merging it. > > "Nothing happened" is never a good enough reason to argue for > merging new stuff, but now you are starting a discussion here, let's > see where it takes us to. I am neutral myself at this moment. Right, but my feeling after the previous discussion was that people were mostly in favor of merging the changes (i.e. allowing user-defined bisect terms), but we wanted to make sure we didn't get any objection on second thought, hence it was a good thing to have an extended cooking period. To add arguments in favor of merging: even if we get the "auto swap good/bad", having user-defined terms can still help for situations where the change between states does not correspond to a situation where one state is 'good' and one is 'bad' eg. --term-old=red --term-new=blue. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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