Re: [PATCH v10.1 7/7] bisect: allow any terms set by user

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 29, 2015, 16:40 UTC
Message-ID: <xmqq8ub2cvth.fsf@gitster.dls.corp.google.com>
In-Reply-To: <vpqegkvnfe5.fsf@anie.imag.fr>

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

> So, my proposal would be to remove the "old/new" patch from the series,
> and keep the other patches.
>
> What do you think?

Let me answer after reading v11 through.

Show 11 quoted lines

>> but now it would be more clear that $name_good and $name_bad is a bad
>> way to name internal variables and files in $GIT_DIR. The inferred 'ah
>> you are hunting for regression' mode would call old ones 'bad' and new
>> ones 'good', they have to be given value neutral names, e.g. $name_old
>> and $name_new.
>
> Ideally, the whole code would be ported to use old/new, but the more I
> read the code the more I agree with Christian actually: we still have
> many more instances of good/bad in the code (e.g. functions
> check_good_are_ancestors_of_bad, for_each_good_bisect_ref, ...), so
> having just name_new/name_old would make the code very inconsistant.

Oh, no question about that. I was hoping that we would at least get the concensus that we should move all to old/new and these good/bad in code no longer make sense.

It just was that introducing new variables and functions whose names follow the convention that reflects the world view that is no longer valid (i.e. good is always old and bad is always new) in a series that introduces the new world view somehow felt wrong.