Junio C Hamano <gitster@xxxxxxxxx> writes: > Matthieu Moy <Matthieu.Moy@xxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html