user/sven/git.git/git-bisect.sh, branch v2.7.0-rc2

bisect: allow setting any user-specified in 'git bisect start'

2015-08-03T18:42:43Z

This allows a natural user-interface when looking for any change in the code, not just regression. For example: git bisect start --term-old fast --term-new slow git bisect fast git bisect slow ... There were several proposed user-interfaces for this feature. This patch implements it as options to 'git bisect start' for the following reasons: * By construction, the terms will be valid for one and only one bisection. * Unlike positional arguments, using named options avoid having to remember an order. * We can combine user-defined terms and passing old/new commits as argument to "git bisect start". * The implementation is relatively simple. See previous discussions: http://mid.gmane.org/1435337896-20709-3-git-send-email-Matthieu.Moy@imag.fr Signed-off-by: Matthieu Moy Signed-off-by: Junio C Hamano

bisect: add 'git bisect terms' to view the current terms

2015-08-03T18:42:42Z

Signed-off-by: Matthieu Moy Signed-off-by: Junio C Hamano

bisect: add the terms old/new

2015-08-03T18:42:42Z

When not looking for a regression during a bisect but for a fix or a change in another given property, it can be confusing to use 'good' and 'bad'. This patch introduce `git bisect new` and `git bisect old` as an alternative to 'bad' and good': the commits which have a certain property must be marked as `new` and the ones which do not as `old`. The output will be the first commit after the change in the property. During a new/old bisect session you cannot use bad/good commands and vice-versa. Some commands are still not available for old/new: * git rev-list --bisect does not treat the revs/bisect/new and revs/bisect/old-SHA1 files. Old discussions: - http://thread.gmane.org/gmane.comp.version-control.git/86063 introduced bisect fix unfixed to find fix. - http://thread.gmane.org/gmane.comp.version-control.git/182398 discussion around bisect yes/no or old/new. - http://thread.gmane.org/gmane.comp.version-control.git/199758 last discussion and reviews New discussions: - http://thread.gmane.org/gmane.comp.version-control.git/271320 ( v2 1/7-4/7 ) - http://comments.gmane.org/gmane.comp.version-control.git/271343 ( v2 5/7-7/7 ) Signed-off-by: Antoine Delaite Signed-off-by: Louis Stuber Signed-off-by: Valentin Duperray Signed-off-by: Franck Jonas Signed-off-by: Lucien Kong Signed-off-by: Thomas Nguy Signed-off-by: Huynh Khoi Nguyen Nguyen Signed-off-by: Matthieu Moy Signed-off-by: Junio C Hamano

bisect: sanity check on terms

2015-08-03T18:42:42Z

This is currently only a defensive check since the only terms are bad/good and new/old, which pass it, but this is a preparation step for accepting user-supplied terms. Signed-off-by: Matthieu Moy Signed-off-by: Junio C Hamano

bisect: don't mix option parsing and non-trivial code

2015-08-03T18:42:42Z

As-is, the revisions that appear on the command-line are processed in order. This would mix badly with code that changes the configuration (e.g. change $TERM_GOOD and $TERM_BAD) while processing the options. Signed-off-by: Matthieu Moy Signed-off-by: Junio C Hamano

bisect: simplify the addition of new bisect terms

2015-08-03T18:42:41Z

We create a file BISECT_TERMS in the repository .git to be read during a bisection. There's no user-interface yet, but "git bisect" works if terms other than old/new or bad/good are set in .git/BISECT_TERMS. The fonctions to be changed if we add new terms are quite few. In git-bisect.sh: check_and_set_terms bisect_voc Co-authored-by: Louis Stuber Tweaked-by: Matthieu Moy Signed-off-by: Antoine Delaite Signed-off-by: Louis Stuber Signed-off-by: Valentin Duperray Signed-off-by: Franck Jonas Signed-off-by: Lucien Kong Signed-off-by: Thomas Nguy Signed-off-by: Huynh Khoi Nguyen Nguyen Signed-off-by: Matthieu Moy Signed-off-by: Junio C Hamano

bisect: replace hardcoded "bad|good" by variables

2015-06-29T20:19:12Z

To add new tags like old/new and have keywords less confusing, the first step is to avoid hardcoding the keywords. The default mode is still bad/good. Signed-off-by: Antoine Delaite Signed-off-by: Louis Stuber Signed-off-by: Valentin Duperray Signed-off-by: Franck Jonas Signed-off-by: Lucien Kong Signed-off-by: Thomas Nguy Signed-off-by: Huynh Khoi Nguyen Nguyen Signed-off-by: Matthieu Moy Signed-off-by: Junio C Hamano

standardize usage info string format

2015-01-14T17:32:04Z

This patch puts the usage info strings that were not already in docopt- like format into docopt-like format, which will be a litle easier for end users and a lot easier for translators. Changes include: - Placing angle brackets around fill-in-the-blank parameters - Putting dashes in multiword parameter names - Adding spaces to [-f|--foobar] to make [-f | --foobar] - Replacing * with [...] Signed-off-by: Alex Henrie Reviewed-by: Matthieu Moy Signed-off-by: Junio C Hamano

bisect: parse revs before passing them to check_expected_revs()

2014-12-29T19:19:55Z

When running for example "git bisect bad HEAD" or "git bisect good master", the parameter passed to "git bisect (bad|good)" has to be parsed into a commit hash before checking if it is the expected commit or not. We could do that in is_expected_rev() or in check_expected_revs(), but it is already done in bisect_state(). Let's just store the hash values that result from this parsing, and then reuse them after all the parsing is done. This way we can also use a for loop over these values to call bisect_write() on them, instead of using eval. Signed-off-by: Christian Couder Signed-off-by: Junio C Hamano

grammofix in user-facing messages

2014-09-02T19:00:30Z

Signed-off-by: Alex Henrie Acked-by: Johan Herland Signed-off-by: Junio C Hamano