Junio C Hamano <gits...@pobox.com> writes:
> Matthieu Moy <matthieu....@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/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
