From: Matthieu Moy <Matthieu.Moy@Grenoble-INP.fr>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, antoine.delaite@ensimag.grenoble-inp.fr,
louis--alexandre.stuber@ensimag.grenoble-inp.fr,
chriscool@tuxfamily.org, thomasxnguy@gmail.com,
valentinduperray@gmail.com
Subject: Re: [PATCH v7 0/5] git bisect old/new
Date: Tue, 23 Jun 2015 22:16:34 +0200 [thread overview]
Message-ID: <vpqsi9imb8d.fsf@anie.imag.fr> (raw)
In-Reply-To: <xmqq381idz59.fsf@gitster.dls.corp.google.com> (Junio C. Hamano's message of "Tue, 23 Jun 2015 12:04:50 -0700")
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/
next prev parent reply other threads:[~2015-06-23 20:16 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-22 21:00 [PATCH v3 1/6] bisect: correction of typo Antoine Delaite
2015-06-22 21:00 ` [PATCH v3 2/6] bisect: replace hardcoded "bad|good" by variables Antoine Delaite
2015-06-22 21:00 ` [PATCH v3 3/6] bisect: simplify the addition of new bisect terms Antoine Delaite
2015-06-22 21:00 ` [PATCH v3 4/6] bisect: add the terms old/new Antoine Delaite
2015-06-22 21:00 ` [PATCH v3 5/6] revision: fix rev-list --bisect in old/new mode Antoine Delaite
2015-06-22 21:00 ` [PATCH v3 6/6] bisect: allows any terms set by user Antoine Delaite
2015-06-23 12:54 ` [PATCH v7 0/5] git bisect old/new Matthieu Moy
2015-06-23 12:54 ` [PATCH v7 1/5] bisect: correction of typo Matthieu Moy
2015-06-23 12:54 ` [PATCH v7 2/5] bisect: replace hardcoded "bad|good" by variables Matthieu Moy
2015-06-23 12:54 ` [PATCH v7 3/5] bisect: simplify the addition of new bisect terms Matthieu Moy
2015-06-23 17:49 ` Eric Sunshine
2015-06-23 18:18 ` Matthieu Moy
2015-06-23 12:54 ` [PATCH v7 4/5] bisect: add the terms old/new Matthieu Moy
2015-06-23 19:27 ` Remi Galan Alfonso
2015-06-23 20:26 ` Matthieu Moy
2015-06-23 12:54 ` [PATCH v7 5/5] bisect: allows any terms set by user Matthieu Moy
2015-06-23 18:48 ` Junio C Hamano
2015-06-23 19:04 ` [PATCH v7 0/5] git bisect old/new Junio C Hamano
2015-06-23 20:16 ` Matthieu Moy [this message]
2015-06-23 20:34 ` Junio C Hamano
2015-06-24 15:17 ` [PATCH v8 0/5] Bisect terms Matthieu Moy
2015-06-24 15:17 ` [PATCH v8 1/5] bisect: correction of typo Matthieu Moy
2015-06-24 15:17 ` [PATCH v8 2/5] bisect: replace hardcoded "bad|good" by variables Matthieu Moy
2015-06-24 15:17 ` [PATCH v8 3/5] bisect: simplify the addition of new bisect terms Matthieu Moy
2015-06-24 17:29 ` Junio C Hamano
2015-06-24 21:26 ` Matthieu Moy
2015-06-24 15:17 ` [PATCH v8 4/5] bisect: add the terms old/new Matthieu Moy
2015-06-24 15:17 ` [PATCH v8 5/5] bisect: allow any terms set by user Matthieu Moy
2015-06-24 17:46 ` Junio C Hamano
2015-06-24 21:23 ` Matthieu Moy
2015-06-24 17:27 ` [PATCH v8 0/5] Bisect terms Junio C Hamano
2015-06-24 19:41 ` Junio C Hamano
2015-06-25 18:50 ` [PATCH v9 0/5] bisect terms Matthieu Moy
2015-06-25 18:50 ` [PATCH v9 1/5] bisect: correction of typo Matthieu Moy
2015-06-25 18:50 ` [PATCH v9 2/5] bisect: replace hardcoded "bad|good" by variables Matthieu Moy
2015-06-25 18:50 ` [PATCH v9 3/5] bisect: simplify the addition of new bisect terms Matthieu Moy
2015-06-25 18:50 ` [PATCH v9 4/5] bisect: add the terms old/new Matthieu Moy
2015-06-26 4:11 ` Christian Couder
2015-06-26 7:00 ` Matthieu Moy
2015-06-25 18:50 ` [PATCH v9 5/5] bisect: allow any terms set by user Matthieu Moy
2015-06-25 21:41 ` Junio C Hamano
2015-06-25 22:10 ` Junio C Hamano
2015-06-26 8:20 ` Matthieu Moy
2015-06-26 16:48 ` Junio C Hamano
2015-06-26 17:08 ` Matthieu Moy
2015-06-26 18:08 ` Junio C Hamano
2015-06-26 20:18 ` Matthieu Moy
2015-06-26 6:59 ` Matthieu Moy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=vpqsi9imb8d.fsf@anie.imag.fr \
--to=matthieu.moy@grenoble-inp.fr \
--cc=antoine.delaite@ensimag.grenoble-inp.fr \
--cc=chriscool@tuxfamily.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=louis--alexandre.stuber@ensimag.grenoble-inp.fr \
--cc=thomasxnguy@gmail.com \
--cc=valentinduperray@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).