git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Matthieu Moy <Matthieu.Moy@imag.fr>
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 v11 00/10] bisect terms
Date: Mon, 29 Jun 2015 09:44:33 -0700	[thread overview]
Message-ID: <xmqq4mlqcvm6.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <1435592435-27914-1-git-send-email-Matthieu.Moy@imag.fr> (Matthieu Moy's message of "Mon, 29 Jun 2015 17:40:25 +0200")

Matthieu Moy <Matthieu.Moy@imag.fr> writes:

> So, here's a reroll that tries to address the ongoing discussion.
>
> The first patches are preparatory steps, which are IMHO good
> regardless of the features. I kept the user-interface to chose terms
> at the end, and tried to keep the UI patches as small as possible.
>
> I have the feeling that "bisect: add the terms old/new" should be
> dropped, but I have no strong opinion on that. If you like the
> feature, say so. If you think the feature doesn't bring enough, and
> should eventually be obsoleted by "guess which commit is old and which
> is new", say so too.

I personally do not mind having old/new, as long as it does not make
it harder to build on top of the codebase (and existing user
experience) to eventually transition to "you can always say good or
bad and we'll figure out which of old/new they map to".  Obviously
we will never guess which is old/new when the user uses old/new as
the chosen terms, and having to special case that might complicat
things, which is where that "as long as it does not make it harder"
above comes from.

> The beginning of the series didn't change much since v10. The major
> change is that I gave up using "git bisect terms <foo> <bar>", and
> implemented the same feature in "git bisect start". We're losing the
> ability to run "git bisect terms" several times to change the terms
> before we use them, but I'm not sure this was a useful feature. OTOH,
> we're back to the principle "git bisect start" starts from a fresh
> state, this avoids confusing the situation where the user has leftover
> from yesterday's "git bisect terms". And the code is much, much
> simpler.

I like that direction.  But let's first wait to see what others say.

Thanks.

>
> Antoine Delaite (4):
>   bisect: correction of typo
>   bisect: replace hardcoded "bad|good" by variables
>   bisect: simplify the addition of new bisect terms
>   bisect: add the terms old/new
>
> Matthieu Moy (5):
>   Documentation/bisect: move getting help section to the end
>   bisect: don't mix option parsing and non-trivial code
>   bisect: sanity check on terms
>   bisect: add 'git bisect terms' to view the current terms
>   bisect: allow setting any user-specified in 'git bisect start'
>
> Michael Haggerty (1):
>   Documentation/bisect: revise overall content
>
>  Documentation/git-bisect.txt | 236 ++++++++++++++++++++++++++++-----------
>  bisect.c                     |  94 ++++++++++++----
>  git-bisect.sh                | 255 +++++++++++++++++++++++++++++++++++--------
>  revision.c                   |  19 +++-
>  t/t6030-bisect-porcelain.sh  | 137 ++++++++++++++++++++++-
>  5 files changed, 612 insertions(+), 129 deletions(-)

      parent reply	other threads:[~2015-06-29 16:44 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-29 15:40 [PATCH v11 00/10] bisect terms Matthieu Moy
2015-06-29 15:40 ` [PATCH v11 01/10] bisect: correction of typo Matthieu Moy
2015-06-29 15:40 ` [PATCH v11 02/10] Documentation/bisect: move getting help section to the end Matthieu Moy
2015-06-29 15:40 ` [PATCH v11 03/10] Documentation/bisect: revise overall content Matthieu Moy
2015-06-29 15:40 ` [PATCH v11 04/10] bisect: replace hardcoded "bad|good" by variables Matthieu Moy
2015-06-29 15:40 ` [PATCH v11 05/10] bisect: simplify the addition of new bisect terms Matthieu Moy
2015-06-29 15:40 ` [PATCH v11 06/10] bisect: don't mix option parsing and non-trivial code Matthieu Moy
2015-06-29 20:28   ` Junio C Hamano
2015-06-30 11:46     ` Matthieu Moy
2015-06-30 15:56       ` Junio C Hamano
2015-06-29 15:40 ` [PATCH v11 07/10] bisect: sanity check on terms Matthieu Moy
2015-06-29 15:40 ` [PATCH v11 08/10] bisect: add the terms old/new Matthieu Moy
2015-06-29 15:40 ` [PATCH v11 09/10] bisect: add 'git bisect terms' to view the current terms Matthieu Moy
2015-06-29 15:40 ` [PATCH v11 10/10] bisect: allow setting any user-specified in 'git bisect start' Matthieu Moy
2015-06-29 16:44 ` Junio C Hamano [this message]

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=xmqq4mlqcvm6.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=Matthieu.Moy@imag.fr \
    --cc=antoine.delaite@ensimag.grenoble-inp.fr \
    --cc=chriscool@tuxfamily.org \
    --cc=git@vger.kernel.org \
    --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).