Christian Couder <christian.couder@xxxxxxxxx> writes: > "old/new" is not more generic than "good/bad". I disagree with this. In any case, we're looking for a pair of commits where one is a direct parent of the other. So in the end, there's always the old behavior and the new behavior in the end. In natural language, I can write "terms good/bad correspond to the situation where the new behavior is a bug and the old behavior was correct" and "terms fixed/unfixed correspond to the situation where the new behavior does not have a bug and the old one does", so I can describe several pairs of terms with old/new. When looking for a bugfix, saying "NAME_GOOD=new" seems backward. I would read this as "the good behavior is to be new", while I would expect "the new behavior is to be good". > and as "good/bad" is older and is the default we should keep that in > the names. I agree with this part though. If people working with the bisect codebase (which includes you) are more comfortable with good/bad, that's a valid reason to keep it. IOW, I still think old/new is more generic, but that is not a strong objection and should not block the patch. -- 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