From: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PUB]What's cooking in git.git (Jul 2015, #01; Wed, 1)
Date: Thu, 02 Jul 2015 11:33:12 +0200 [thread overview]
Message-ID: <vpqbnfudhuv.fsf@anie.imag.fr> (raw)
In-Reply-To: <xmqqzj3f5wtr.fsf@gitster.dls.corp.google.com> (Junio C. Hamano's message of "Wed, 01 Jul 2015 15:37:04 -0700")
Junio C Hamano <gitster@pobox.com> writes:
> * ad/bisect-terms (2015-06-29) 10 commits
> - bisect: allow setting any user-specified in 'git bisect start'
> - bisect: add 'git bisect terms' to view the current terms
> - bisect: add the terms old/new
> - bisect: sanity check on terms
> - bisect: don't mix option parsing and non-trivial code
> - bisect: simplify the addition of new bisect terms
> - bisect: replace hardcoded "bad|good" by variables
> - Documentation/bisect: revise overall content
> - Documentation/bisect: move getting help section to the end
> - bisect: correction of typo
>
> The use of 'good/bad' in "git bisect" made it confusing to use when
> hunting for a state change that is not a regression (e.g. bugfix).
> The command learned 'old/new' and then allows the end user to
> say e.g. "bisect start --term-old=fast --term=new=slow" to find a
> performance regression.
>
> The bottom part has been quite well cooked. Perhaps split it into
> two topisc and merge the earlier ones to 'next' before the rest
> settles. Michael's idea to make 'good/bad' more intelligent does
> have certain attractiveness ($gname/272867).
I think it makes sense to merge the first patches soon:
- bisect: don't mix option parsing and non-trivial code
- bisect: simplify the addition of new bisect terms
- bisect: replace hardcoded "bad|good" by variables
- Documentation/bisect: revise overall content
- Documentation/bisect: move getting help section to the end
- bisect: correction of typo
I have nothing to add on the last ones, but they can cook in pu a bit
longer.
Do you expect anything from my side?
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
next prev parent reply other threads:[~2015-07-02 9:33 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-01 22:37 What's cooking in git.git (Jul 2015, #01; Wed, 1) Junio C Hamano
2015-07-02 9:33 ` Matthieu Moy [this message]
2015-07-03 17:57 ` [PUB]What's " Junio C Hamano
2015-07-21 18:09 ` What's " Jakub Narębski
2015-07-22 10:05 ` Tony Finch
2015-07-22 11:16 ` Jakub Narębski
2015-07-22 13:19 ` Tony Finch
2015-07-22 19:32 ` Jakub Narębski
2015-07-22 21:14 ` Tony Finch
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=vpqbnfudhuv.fsf@anie.imag.fr \
--to=matthieu.moy@grenoble-inp.fr \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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.