From: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
To: Junio C Hamano <gitster@pobox.com>
Cc: Antoine Delaite <antoine.delaite@ensimag.grenoble-inp.fr>,
git@vger.kernel.org, remi.lespinet@ensimag.grenoble-inp.fr,
louis--alexandre.stuber@ensimag.grenoble-inp.fr,
remi.galan-alfonso@ensimag.grenoble-inp.fr,
guillaume.pages@ensimag.grenoble-inp.fr, chriscool@tuxfamily.org,
thomasxnguy@gmail.com, valentinduperray@gmail.com
Subject: Re: [PATCH v2 7/7] bisect: allows any terms set by user
Date: Thu, 11 Jun 2015 11:22:52 +0200 [thread overview]
Message-ID: <vpqoakmoaz7.fsf@anie.imag.fr> (raw)
In-Reply-To: <xmqqk2vbi7rf.fsf@gitster.dls.corp.google.com> (Junio C. Hamano's message of "Wed, 10 Jun 2015 14:16:36 -0700")
Junio C Hamano <gitster@pobox.com> writes:
> Antoine Delaite <antoine.delaite@ensimag.grenoble-inp.fr> writes:
>
>> -USAGE='[help|start|bad|good|new|old|skip|next|reset|visualize|replay|log|run]'
>> +USAGE='[help|start|bad|good|new|old|terms|skip|next|reset|visualize|replay|log|run]'
>
> I think this patch makes the whole series go in the right direction.
>
> I wonder if you can skip the "we only support new/old if you are not
> doing bog-standard bad/good" step and start from this "bisect terms"
> one, though.
While I think we should not hardcode too much in the code, I also think
it makes sense to have hardcoded old/new in the user-interface. If you
give me just
git bisect terms <first-term> <second-term>
then half of the times, I'll use old/new in the wrong order. And if I
hadn't looked to bisect close enough, I'd even complain that the terms
are not usable interchangeably.
At least, a in a flow like
git bisect start
git bisect new
git checkout <old-sha>
git bisect old
there's no ambiguity.
So, to me, having both hardcoded old/new (unambiguous) and "git bisect
terms" (for flexibility) makes sense.
Another important parameter: the students are finishing their project
tomorrow. They may continue on their personnal free time, but at best
their time budget is considerably reduced, and from my past experience,
the time budget usually reaches 0. That's not a reason to merge bad code
in git.git, but an incentive to close the series with something going in
the right direction. Typically:
> - preliminary clean-up steps (e.g. "correct 'mistook'");
This is straightforward
> - use $name_new and $name_old throughout the code, giving them
> 'bad' and 'good' as hardcoded values; finally
This is relatively uncontroversial, and should be easy to finish. I
would consider it a good thing anyway.
> - add 'bisect terms' support.
I'd put this on the low-priority whishlist. If the codebase is ready and
a preliminary patch exists, it will be relatively easy for someone else
to finish the job.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
next prev parent reply other threads:[~2015-06-11 9:23 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-10 19:01 [PATCH v2 5/7] bisect: change read_bisect_terms parameters Antoine Delaite
2015-06-10 19:01 ` [PATCH v2 6/7] revision: fix rev-list --bisect in old/new mode Antoine Delaite
2015-06-10 19:01 ` [PATCH v2 7/7] bisect: allows any terms set by user Antoine Delaite
2015-06-10 21:16 ` Junio C Hamano
2015-06-10 22:19 ` Junio C Hamano
2015-06-11 9:42 ` Matthieu Moy
2015-06-11 14:57 ` Junio C Hamano
2015-06-11 9:22 ` Matthieu Moy [this message]
2015-06-11 15:03 ` Junio C Hamano
2015-06-11 15:28 ` Matthieu Moy
2015-06-14 12:39 ` Louis-Alexandre Stuber
2015-06-14 19:30 ` Antoine Delaite
2015-06-15 8:37 ` Matthieu Moy
2015-06-15 16:08 ` Junio C Hamano
2015-06-16 21:18 ` Antoine Delaite
2015-06-17 7:05 ` Matthieu Moy
2015-06-17 8:01 ` Antoine Delaite
2015-06-17 8:18 ` Matthieu Moy
2015-06-14 19:40 ` Antoine Delaite
2015-06-14 20:05 ` Antoine Delaite
2015-06-15 8:56 ` Matthieu Moy
2015-06-15 8:52 ` Matthieu Moy
2015-06-16 21:07 ` Antoine Delaite
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=vpqoakmoaz7.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=guillaume.pages@ensimag.grenoble-inp.fr \
--cc=louis--alexandre.stuber@ensimag.grenoble-inp.fr \
--cc=remi.galan-alfonso@ensimag.grenoble-inp.fr \
--cc=remi.lespinet@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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.