Re: [PATCH v7 0/5] git bisect old/new

[Matthieu Moy <Matthieu.Moy@Grenoble-INP.fr>]

Junio C Hamano <gitster@pobox.com> writes:

> Matthieu Moy <Matthieu.Moy@imag.fr> writes:
>
>> I fixed a few minor issues in v6. Patch between my version and v6 is
>> below. I also pushed my branch here:
>>
>>   https://github.com/moy/git/tree/bisect-terms
>
> It is somewhat confusing to see v3 yesterday and then this v7 next
> day.  How did I miss v4 thru v6?

Oops, I pattern-matched the wrong part when reading [PATCH v3 6/6].
Indeed, this should have been numberred v4, I should have s/v6/v3/ in my
sentence above.

> Regarding the second and third one, the messages they give when the
> user marked one tip of a side branch as old and the other new gave
> me a hiccup while reading them, though.
>
> 	if (!strcmp(name_bad, "bad")) {
> 		fprintf(stderr, "The merge base %s is bad.\n"
> 			"This means the bug has been fixed "
> 			"between %s and [%s].\n",
> 			bad_hex, bad_hex, good_hex);
> 	} else {
> 		fprintf(stderr, "The merge base %s is %s.\n"
> 			"This means the first commit marked %s is "
> 			"between %s and [%s].\n",
> 			bad_hex, name_bad, name_bad, bad_hex, good_hex);
>
> The "bad" side is inherited from the original and not your fault,
> but it was already very hard to understand. The other side is not
> just unreadable, but I think is incorrect and confusing to say
> "first commit marked %(name_bad)s"; you know there are history
> segments whose oldest ends (i.e. merge base that is bad) are marked
> as 'bad', and the other ends are marked as 'good', and you haven't
> marked any of the commits in between yet.  So there is no "first
> commit marked" either as bad or good there between these endpoints
> (yet).

The situation is (the bisection started with bad=branch1 and
good=branch2):

---- base (name_bad) ------ branch1 (name_bad)
        \
         `----------------- branch2 (name_good)

So, the first commit having property name_good is between base and
branch2. So, the message seems wrong in two ways:

* As you say, the wording "marked as" seem to imply that we did mark the
  commit, while we actually did not explore base..branch2
  I'd write "the first '%s' commit" (the important is to remove
  "marked").

* The message uses 'name_bad' where it should use 'name_good'. Indeed,
  the original message talks about "bug fixed", i.e. the first _good_
  commit is in base..branch2.

Is this what you meant?

(Sorry, I need drawings and bullet lists to think properly ;-) ).

Actually, I think it would make sense to include my drawing above in a
comment in the code.

> Also I was somewhat puzzled and disappointed to still see
> name_{bad,good} not name_{new,old} used as variable names even in
> the endgame patch, though.  Is that intended?

I still think that name_old/name_new would have been much better names
if we were to write bisect from scratch, but I got convinced by
Christian that name_bad/name_good made sense too. Even if we adopted
old/new in these variables, we would still have e.g. a variable
"bad_seen" in the code. So, moving the codebase to adopt the old/new
convention internally is more than just chosing the name of variables to
avoid hardcoded "good"/"bad" string litterals. Moving the brain of
developpers to adopt the old/new convention is even another debate.

I don't know if this is the reason why Antoine did not change it, but
that's why I did not insist further and did not do the change myself.

> Yeah, if I may rephrase to make sure we are on the same page, in
> order for 5/5 to be done sanely, 1-4/5 must be giving a good
> foundation to build on.  I agree with that, I agree that including a
> polished 5/5 would be a good thing, and then I further agree that
> 1-4/5 could be delivered before 5/5 is ready.

Yes.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/