Re: [PATCH v7 0/5] git bisect old/new
- From
Matthieu Moy <matthieu.moy@grenoble-inp.fr>
- Date
- Jun 23, 2015, 20:16 UTC
- Message-ID
- <vpqsi9imb8d.fsf@anie.imag.fr>
- In-Reply-To
- <xmqq381idz59.fsf@gitster.dls.corp.google.com>
Junio C Hamano <gitster@pobox.com> writes:
Show 9 quoted lines
> 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.
Show 24 quoted lines
> 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.
Show 5 quoted lines
> 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/