From: Matthieu Moy <Matthieu.Moy@grenoble-inp•fr>
To: Christian Couder <christian.couder@gmail•com>
Cc: Junio C Hamano <gitster@pobox•com>, git <git@vger•kernel.org>,
Antoine Delaite <antoine.delaite@ensimag•grenoble-inp.fr>,
Louis Stuber <stuberl@ensimag•grenoble-inp.fr>,
Michael Haggerty <mhagger@alum•mit.edu>
Subject: Re: [PATCH v10.1 7/7] bisect: allow any terms set by user
Date: Sat, 27 Jun 2015 10:32:10 +0200 [thread overview]
Message-ID: <vpq7fqppn5h.fsf@anie.imag.fr> (raw)
In-Reply-To: <CAP8UFD0Zzjcc94qcUJOpfSrTej-o6hRKzZOuTufzAbOPkjUr_A@mail.gmail.com> (Christian Couder's message of "Sat, 27 Jun 2015 06:51:20 +0200")
Christian Couder <christian.couder@gmail•com> writes:
> On Sat, Jun 27, 2015 at 6:25 AM, Junio C Hamano <gitster@pobox•com> wrote:
>> On Fri, Jun 26, 2015 at 9:10 PM, Christian Couder
>> <christian.couder@gmail•com> wrote:
>>>
>>> If we don't want to support positional arguments, then I would suggest
>>> supporting first the following instead:
>>>
>>> git bisect terms --name-good=fast --name-bad=slow
>>> git bisect terms --name-bad=slow --name-good=fast
>>>
>>> This would make the interface consistent with the code.
>>
>> Which somewhat defeats the point of introducing "old" and "new", though.
>> The "terms" support is for people who feel that good/bad would be too confusing
>> for the particular bisect session (e.g. because they are hunting for a fix).
>
> Well if --name-old and --name-new are also available as synonyms, it
> would not be too bad I think.
> People could use the option names that fit their mental model or their
> use case better.
OK, I'll add both.
>>>> We may want to start supporting
>>>>
>>>> git bisect start --new=master --old=maint
>>>
>>> Maybe we could also support:
>>>
>>> git bisect start --name-good=fast --name-bad=slow --fast=maint --slow=master
>>
>> The same comment for the token after --name-, but allowing the terms to be set
>> at "start" could be a type-saver. With need for added "--name-"
>> prefix (worse, twice),
>> I am not sure if it would be seen as a useful type-saver, though.
>
> At least people don't need to remember if they have to use "git bisect
> term" before or after starting :-)
OK, first lesson learnt: the UI is controversial. So, I'm working on a
series that splits the last patch into several preparation steps, and a
very simple patch to implement the UI.
I have a draft here https://github.com/moy/git/commits/bisect-terms
I'll go through it once more and send it later.
As a teaser, the patch implementing the UI is just:
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -70,6 +70,26 @@ bisect_autostart() {
}
}
+parse_name_args() {
+ while [ $# -gt 0 ]; do
+ arg="$1"
+ case "$arg" in
+ --name-good|--name-old)
+ shift
+ must_write_terms=1
+ NAME_GOOD=$1
+ shift ;;
+ --name-bad|--name-new)
+ shift
+ must_write_terms=1
+ NAME_BAD=$1
+ shift ;;
+ *)
+ shift ;;
+ esac
+ done
+}
+
bisect_start() {
#
# Check for one bad and then some good revisions.
@@ -88,6 +108,9 @@ bisect_start() {
else
mode=''
fi
+ # Parse --name-* options before the other to allow any mix of
+ # --name-* and revisions on the command-line.
+ parse_name_args "$@"
while [ $# -gt 0 ]; do
arg="$1"
case "$arg" in
@@ -98,6 +121,8 @@ bisect_start() {
--no-checkout)
mode=--no-checkout
shift ;;
+ --name-good|--name-old|--name-bad|--name-new)
+ shift 2 ;;
--*)
die "$(eval_gettext "unrecognised option: '\$arg'")" ;;
*)
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
next prev parent reply other threads:[~2015-06-27 8:32 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-26 16:58 [PATCH v10 0/7] bisect terms Matthieu Moy
2015-06-26 16:58 ` [PATCH v10 1/7] bisect: correction of typo Matthieu Moy
2015-06-26 16:58 ` [PATCH v10 2/7] Documentation/bisect: move getting help section to the end Matthieu Moy
2015-06-26 16:58 ` [PATCH v10 3/7] Documentation/bisect: revise overall content Matthieu Moy
2015-06-26 16:58 ` [PATCH v10 4/7] bisect: replace hardcoded "bad|good" by variables Matthieu Moy
2015-06-26 16:58 ` [PATCH v10 5/7] bisect: simplify the addition of new bisect terms Matthieu Moy
2015-06-26 19:22 ` Christian Couder
2015-06-26 20:32 ` [PATCH v10.1 " Matthieu Moy
2015-06-26 21:27 ` Junio C Hamano
2015-06-26 21:37 ` Matthieu Moy
2015-06-26 16:58 ` [PATCH v10 6/7] bisect: add the terms old/new Matthieu Moy
2015-06-26 16:58 ` [PATCH v10 7/7] bisect: allow any terms set by user Matthieu Moy
2015-06-26 18:16 ` Junio C Hamano
2015-06-26 20:39 ` [PATCH v10.1 " Matthieu Moy
2015-06-26 22:25 ` Junio C Hamano
2015-06-27 4:10 ` Christian Couder
2015-06-27 4:25 ` Junio C Hamano
2015-06-27 4:51 ` Christian Couder
2015-06-27 8:32 ` Matthieu Moy [this message]
2015-06-27 18:41 ` Junio C Hamano
2015-06-29 9:51 ` Matthieu Moy
2015-06-29 16:35 ` Junio C Hamano
2015-06-28 5:51 ` Michael Haggerty
2015-06-28 6:15 ` Junio C Hamano
2015-06-28 6:46 ` Michael Haggerty
2015-06-28 7:32 ` Junio C Hamano
2015-06-28 11:31 ` Michael Haggerty
2015-06-28 18:51 ` Junio C Hamano
2015-06-29 7:27 ` Matthieu Moy
2015-06-29 16:40 ` Junio C Hamano
2015-06-29 5:08 ` Christian Couder
2015-06-29 7:34 ` Matthieu Moy
2015-06-29 8:08 ` Christian Couder
2015-06-29 9:32 ` Matthieu Moy
2015-06-29 10:55 ` Christian Couder
2015-06-29 15:19 ` Matthieu Moy
2015-06-26 20:29 ` [PATCH v10 " Christian Couder
2015-06-26 20: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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=vpq7fqppn5h.fsf@anie.imag.fr \
--to=matthieu.moy@grenoble-inp$(echo .)fr \
--cc=antoine.delaite@ensimag$(echo .)grenoble-inp.fr \
--cc=christian.couder@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=mhagger@alum$(echo .)mit.edu \
--cc=stuberl@ensimag$(echo .)grenoble-inp.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox