On Tue, Jun 9, 2015 at 8:45 AM, Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> wrote: > Antoine Delaite <antoine.delaite@xxxxxxxxxxxxxxxxxxxxxxx> writes: > >> --- a/git-bisect.sh >> +++ b/git-bisect.sh >> @@ -32,6 +32,8 @@ OPTIONS_SPEC= >> >> _x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]' >> _x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40" >> +NAME_BAD="bad" >> +NAME_GOOD="good" > > I would have written > > NAME_NEW=bad > NAME_OLD=good > > "old/new" are the generic wording, so I think it would make more sense > for the codebase to use it when we don't hardcode old/new. I don't agree with NAME_NEW and NAME_OLD instead of NAME_BAD and NAME_OLD, for me it is easier when reasonning about the code to always think as if we want to find a bug. This is especially true when thinking about cases when we are given a "good" commit that is not an ancestor of the "bad" commit (and we have to find the merge base and so on), because in this case the "good" commit might be newer than the "bad" commit. "old/new" is not more generic than "good/bad". It just has a different kind of drawbacks, and as "good/bad" is older and is the default we should keep that in the names. -- 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