summaryrefslogtreecommitdiff
path: root/git-bisect.sh
AgeCommit message (Collapse)AuthorFilesLines
2008-11-25bisect: teach "skip" to accept special arguments like "A..B"Libravatar Christian Couder1-1/+18
The current "git bisect skip" syntax is "git bisect skip [<rev>...]" so it's already possible to skip a range of revisions using something like: $ git bisect skip $(git rev-list A..B) where A and B are the bounds of the range we want to skip. This patch teaches "git bisect skip" to accept: $ git bisect skip A..B as an abbreviation for the former command. This is done by checking each argument to see if it contains two dots one after the other ('..'), and by expending it using "git rev-list" if that is the case. Note that this patch will not make "git bisect skip" accept all that "git rev-list" accepts, as things like "^A B" for exemple will not work. But things like "A B..C D E F.. ..G H...I" should work as expected. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-11-09bisect: fix missing "exit"Libravatar Christian Couder1-1/+1
Check to see given bad/good/skip sets are valid commit and to exit otherwise was broken by 6a54d97 (bisect: remove "checkout_done" variable used when checking merge bases, 2008-09-06). Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-05bisect: remove "checkout_done" variable used when checking merge basesLibravatar Christian Couder1-5/+27
Using return values from the following functions: - check_merge_bases - check_good_are_ancestors_of_bad seems simpler. While at it, let's add some comments to better document the above functions. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-27bisect: only check merge bases when neededLibravatar Christian Couder1-14/+34
When one good revision is not an ancestor of the bad revision, the merge bases between the good and the bad revision should be checked to make sure that they are also good revisions. A previous patch takes care of that, but it may check the merge bases more often than really needed. In fact the previous patch did not try to optimize this as much as possible because it is not so simple. So this is the purpose of this patch. One may think that when all the merge bases have been checked then we can save a flag, so that we don't need to check the merge bases again during the bisect process. The problem is that the user may choose to checkout and test something completely different from what the bisect process suggested. In this case we have to check the merge bases again, because there may be new merge bases relevant to the bisect process. That's why, in this patch, when we detect that the user tested something else than what the bisect process suggested, we remove the flag that says that we don't need to check the merge bases again. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-27bisect: test merge base if good rev is not an ancestor of bad revLibravatar Christian Couder1-25/+102
Before this patch, "git bisect", when it was given some good revs that are not ancestor of the bad rev, didn't check if the merge bases were good. "git bisect" just supposed that the user knew what he was doing, and that, when he said the revs were good, he knew that it meant that all the revs in the history leading to the good revs were also considered good. But in pratice, the user may not know that a good rev is not an ancestor of the bad rev, or he may not know/remember that all revs leading to the good rev will be considered good. So he may give a good rev that is a sibling, instead of an ancestor, of the bad rev, when in fact there can be one rev becoming good in the branch of the good rev (because the bug was already fixed there, for example) instead of one rev becoming bad in the branch of the bad rev. For example, if there is the following history: A--B--C--D \ E--F and we launch "git bisect start D F" then only C and D would have been considered as possible first bad commit before this patch. This could invite user errors; F could be the commit that fixes the bug that exists everywhere else. The purpose of this patch is to detect when "git bisect" is passed some good revs that are not ancestors of the bad rev, and then to first ask the user to test the merge bases between the good and bad revs. If the merge bases are good then all is fine, we can continue bisecting. Otherwise, if one merge base is bad, it means that the assumption that all revs leading to the good one are good too is wrong and we error out. In the case where one merge base is skipped we issue a warning and then continue bisecting anyway. These checks will also catch the case where good and bad have been mistaken. This means that we can remove the check that was done latter on the output of "git rev-list --bisect-vars". Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-11Merge branch 'maint'Libravatar Junio C Hamano1-1/+2
* maint: git-bisect: fix wrong usage of read(1)
2008-08-11git-bisect: fix wrong usage of read(1)Libravatar Francis Moreau1-1/+2
Signed-off-by: Francis Moreau <francis.moro@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-11git-bisect: use dash-less form on git bisect logLibravatar Miklos Vajna1-4/+8
Given that users are supposed to type 'git bisect' now, make the output of 'git bisect log' consistent with this. Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-28bisect: use "$GIT_DIR/BISECT_START" to check if we are bisectingLibravatar Christian Couder1-16/+13
It seems simpler and safer to use the BISECT_START file everywhere to decide if we are bisecting or not, instead of using it in some places and BISECT_NAMES in other places. In commit 6459c7c6786aa9bda0c7a095c9db66c36da0e5f0 (Nov 18 2007, Bisect: use "$GIT_DIR/BISECT_NAMES" to check if we are bisecting.), we decided to use BISECT_NAMES but code changed a lot and we now have to check BISECT_START first in the "bisect_start" function anyway. This patch also makes things a little bit safer by creating the BISECT_START file first and deleting it last, and also by adding checks in "bisect_clean_state". Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-22bisect: use a detached HEAD to bisectLibravatar Christian Couder1-28/+26
When "git bisect" was first written, it was not possible to checkout a detached HEAD. The detached feature appeared latter. That's why before this patch the "git bisect" process used a "bisect" branch to checkout new revisions to be tested (and also a "new-bisect" one to check if the checkouts could work). This patch makes "git bisect" checkout revisions to be tested on a detached HEAD. This simplifies the code a bit. The tests to check that "git bisect" does not start if a "bisect" or a "new-bisect" branch exists are removed as they are not relevant any more. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-22bisect: trap critical errors in "bisect_start"Libravatar Christian Couder1-6/+24
Before this patch, when using "git bisect start" with mistaken revs or when the checkout of the branch we want to test failed, we exited after having written files like ".git/BISECT_START", ".git/BISECT_NAMES" and after having written "refs/bisect/bad" and "refs/bisect/good-*" refs. With this patch we trap all errors that can happen when writing the new state and when we are in "bisect_next". So that we can try to clean up everything in case of problems, using "bisect_clean_state". This patch also contains a "bisect_write" cleanup to make it exit on error and return 0 otherwise. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-22bisect: fix left over "BISECT_START" file when starting with junk revLibravatar Christian Couder1-9/+7
Before this patch, when using for example: $ git bisect start <stuff1> <stuff2> with <stuff1> or <stuff2> that cannot be parsed as a revision, we could leave a ".git/BISECT_START" file, from a previous "git bisect start", alone. This patch makes sure that it does not happen by removing the "BISECT_START" file in "bisect_clean_state" and then always writing it again at the end of "bisect_start". Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-12Merge branch 'gp/bisect-fix'Libravatar Junio C Hamano1-9/+29
* gp/bisect-fix: bisect: print an error message when "git rev-list --bisect-vars" fails git-bisect.sh: don't accidentally override existing branch "bisect"
2008-05-08bisect: print an error message when "git rev-list --bisect-vars" failsLibravatar Christian Couder1-2/+17
Before this patch no error was printed when "git rev-list --bisect-vars" failed. This can happen when bad and good revs are mistaken. This patch prints an error message on stderr that describe the likely failure cause. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-05git-bisect.sh: don't accidentally override existing branch "bisect"Libravatar Gerrit Pape1-7/+12
If a branch named "bisect" or "new-bisect" already was created in the repo by other means than git bisect, doing a git bisect used to override the branch without a warning. Now if the branch "bisect" or "new-bisect" already exists, and it was not created by git bisect itself, git bisect start fails with an appropriate error message. Additionally, if checking out a new bisect state fails due to a merge problem, git bisect cleans up the temporary branch "new-bisect". The accidental override has been noticed by Andres Salomon, reported through http://bugs.debian.org/478647 Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-16Merge branch 'maint'Libravatar Junio C Hamano1-5/+11
* maint: git-bisect: make "start", "good" and "skip" succeed or fail atomically git-am: cope better with an empty Subject: line Ignore leading empty lines while summarizing merges bisect: squelch "fatal: ref HEAD not a symref" misleading message builtin-apply: Show a more descriptive error on failure when opening a patch Clarify documentation of git-cvsserver, particularly in relation to git-shell
2008-04-16Merge branch 'maint-1.5.4' into maintLibravatar Junio C Hamano1-5/+11
* maint-1.5.4: git-bisect: make "start", "good" and "skip" succeed or fail atomically git-am: cope better with an empty Subject: line Ignore leading empty lines while summarizing merges bisect: squelch "fatal: ref HEAD not a symref" misleading message builtin-apply: Show a more descriptive error on failure when opening a patch Clarify documentation of git-cvsserver, particularly in relation to git-shell
2008-04-16git-bisect: make "start", "good" and "skip" succeed or fail atomicallyLibravatar Christian Couder1-4/+10
Before this patch, when "git bisect start", "git bisect good" or "git bisect skip" were called with many revisions, they could fail after having already marked some revisions as "good", "bad" or "skip". This could be especilally bad for "git bisect start" because as the file ".git/BISECT_NAMES" would not have been written, there would have been no attempt to clear the marked revisions on a "git bisect reset". That's because if there is no ".git/BISECT_NAMES" file, nothing is done to clean things up, as the bisect session is not supposed to have started. While at it, let's also create the ".git/BISECT_START" file, only after ".git/BISECT_NAMES" as been created. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-15bisect: squelch "fatal: ref HEAD not a symref" misleading messageLibravatar Christian Couder1-1/+1
To get the current HEAD when we start bisecting using for example "git bisect start", we first try "git symbolic-ref HEAD" to get a nice name, and if it fails, we fall back to "git rev-parse --verify HEAD". The problem is that when "git symbolic-ref HEAD" fails, it displays "fatal: ref HEAD not a symref", so it looks like "git bisect start" failed and does not accept detached HEAD, even if in fact it worked fine. This patch adds "-q" option to the "git symbolic-ref" call to get rid of the misleading error message. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-12Merge branch 'maint'Libravatar Junio C Hamano1-2/+2
* maint: t7401: squelch garbage output Documentation/git-submodule: typofix Fix config key miscount in url.*.insteadOf Docs gitk: Explicitly mention the files that gitk uses (~/.gitk) Document -w option to shortlog bisect: report bad rev better
2008-04-12Merge branch 'maint-1.5.4' into maintLibravatar Junio C Hamano1-2/+2
* maint-1.5.4: Docs gitk: Explicitly mention the files that gitk uses (~/.gitk) Document -w option to shortlog bisect: report bad rev better
2008-04-12bisect: report bad rev betterLibravatar Christian Couder1-2/+2
The previous one overwrote the variable used to report the bad input when the input is actually bad, and we did not give a useful enough information. This corrects it. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-11Merge branch 'maint'Libravatar Junio C Hamano1-9/+5
* maint: bisect: fix bad rev checking in "git bisect good" revision.c: make --date-order overriddable git-submodule: Avoid 'fatal: cannot describe' message Force the medium pretty format on calls to git log Fix section about backdating tags in the git-tag docs Document option --only of git commit Documentation/git-request-pull: Fixed a typo ("send" -> "end")
2008-04-11Merge branch 'maint-1.5.4' into maintLibravatar Junio C Hamano1-9/+5
* maint-1.5.4: bisect: fix bad rev checking in "git bisect good" revision.c: make --date-order overriddable Fix section about backdating tags in the git-tag docs Document option --only of git commit Documentation/git-request-pull: Fixed a typo ("send" -> "end")
2008-04-11bisect: fix bad rev checking in "git bisect good"Libravatar Christian Couder1-9/+5
It seems that "git bisect good" and "git bisect skip" have never properly checked arguments that have been passed to them. As soon as one of them can be parsed as a SHA1, no error or warning would be given. This is because 'git rev-parse --revs-only --no-flags "$@"' always "exit 0" and outputs all the SHA1 it can found from parsing "$@". This patch fix this by using, for each "bisect good" argument, the same logic as for the "bisect bad" argument. While at it, this patch teaches "bisect bad" to give a meaningfull error message when it is passed more than one argument. Note that if "git bisect good" or "git bisect skip" is given some proper revs and then something that is not a proper rev, then the first proper revs will still have been marked as "good" or "skip". Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-11bisect: add "git bisect help" subcommand to get a long usage stringLibravatar Christian Couder1-3/+9
Users are not often aware of the fact that "git bisect -h" can give them a long usage description, as "git bisect" seems to accept only dashless subcommands like "start", "good", ... That's why this patch adds a "git bisect help" subcommand that just calls "git bisect -h". This new subcommand is also fully documented in the short usage string (that "git bisect" gives), in the long usage string and in the man page (that "git help bisect" gives). Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-12tr portability fixesLibravatar Jeff King1-2/+2
Specifying character ranges in tr differs between System V and POSIX. In System V, brackets are required (e.g., '[A-Z]'), whereas in POSIX they are not. We can mostly get around this by just using the bracket form for both sets, as in: tr '[A-Z] '[a-z]' in which case POSIX interpets this as "'[' becomes '['", which is OK. However, this doesn't work with multiple sequences, like: # rot13 tr '[A-Z][a-z]' '[N-Z][A-M][n-z][a-m]' where the POSIX version does not behave the same as the System V version. In this case, we must simply enumerate the sequence. This patch fixes problematic uses of tr in git scripts and test scripts in one of three ways: - if a single sequence, make sure it uses brackets - if multiple sequences, enumerate - if extra brackets (e.g., tr '[A]' 'a'), eliminate brackets Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-27Eliminate confusing "won't bisect on seeked tree" failureLibravatar Carl Worth1-5/+9
This error message is very confusing---it doesn't tell the user anything about how to fix the situation. And the actual fix for the situation ("git bisect reset") does a checkout of a potentially random branch, (compared to what the user wants to be on for the bisect she is starting). The simplest way to eliminate the confusion is to just make "git bisect start" do the cleanup itself. There's no significant loss of safety here since we already have a general safety in the form of the reflog. Note: We preserve the warning for any cogito users. We do this by switching from .git/head-name to .git/BISECT_START for the extra state, (which is a more descriptive name anyway). Signed-off-by: Carl Worth <cworth@cworth.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-24Eliminate confusing "won't bisect on seeked tree" failureLibravatar Carl Worth1-5/+9
This error message is very confusing---it doesn't tell the user anything about how to fix the situation. And the actual fix for the situation ("git bisect reset") does a checkout of a potentially random branch, (compared to what the user wants to be on for the bisect she is starting). The simplest way to eliminate the confusion is to just make "git bisect start" do the cleanup itself. There's no significant loss of safety here since we already have a general safety in the form of the reflog. Note: We preserve the warning for any cogito users. We do this by switching from .git/head-name to .git/BISECT_START for the extra state, (which is a more descriptive name anyway). Signed-off-by: Carl Worth <cworth@cworth.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-17bisect view: check for MinGW32 and MacOSX in addition to X11Libravatar Johannes Schindelin1-2/+2
When deciding if gitk or git-log should be used to visualize the current state, the environment variable DISPLAY was checked. Now, we check MSYSTEM (for MinGW32/MSys) and SECURITYSESSIONID (for MacOSX) in addition. Note that there is currently no way to ssh into MinGW32, and that SECURITYSESSIONID is not set automatically on MacOSX when ssh'ing into it. So this patch should be safe. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-13bisect: use verbatim commit subject in the bisect logLibravatar Johannes Schindelin1-1/+1
Due to a typo, the commit subject was shell expanded in the bisect log. That is, if you had some shell pattern in the commit subject, bisect would happily put all matching file names into the log. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Tested-by: Frans Pop <elendil@planet.nl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-11bisect: allow starting with a detached HEADLibravatar Johannes Schindelin1-2/+6
Instead of insisting on a symbolic ref, bisect now accepts detached HEADs, too. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-08git-bisect visualize: work in non-windowed environments betterLibravatar Junio C Hamano1-2/+17
This teaches "git bisect visualize" to be more useful in non-windowed environments. (1) When no option is given, and $DISPLAY is set, it continues to spawn gitk as before; (2) When no option is given, and $DISPLAY is unset, "git log" is run to show the range of commits between the bad one and the good ones; (3) If only "-flag" options are given, "git log <options>" is run. E.g. "git bisect visualize --stat" (4) Otherwise, all of the given options are taken as the initial part of the command line and the commit range expression is given to that command. E.g. "git bisect visualize tig" will run "tig" history viewer to show between the bad one and the good ones. As "visualize" is a bit too long to type, we also give it a shorter synonym "view". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-24Merge branch 'cc/bisect'Libravatar Junio C Hamano1-14/+19
* cc/bisect: Bisect reset: do nothing when not bisecting. Bisect: use "$GIT_DIR/BISECT_NAMES" to check if we are bisecting. Bisect visualize: use "for-each-ref" to list all good refs. git-bisect: modernize branch shuffling hack git-bisect: use update-ref to mark good/bad commits git-bisect: war on "sed" Bisect reset: remove bisect refs that may have been packed.
2007-11-20Bisect reset: do nothing when not bisecting.Libravatar Christian Couder1-0/+4
Before this patch, using "git bisect reset" when not bisecting did a "git checkout master" for no good reason. This also happened using "git bisect replay" when not bisecting because "bisect_replay" starts by calling "bisect_reset". Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-18Bisect: use "$GIT_DIR/BISECT_NAMES" to check if we are bisecting.Libravatar Christian Couder1-5/+2
Previously we tested if the "$GIT_DIR/refs/bisect" directory existed, to check if we were bisecting. Now with packed refs, it is simpler to check if the file "$GIT_DIR/BISECT_NAMES" exists, as it is already created when starting bisection and removed when reseting bisection. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-17Merge branch 'ph/parseopt-sh'Libravatar Junio C Hamano1-0/+1
* ph/parseopt-sh: git-quiltimport.sh fix --patches handling git-am: -i does not take a string parameter. sh-setup: don't let eval output to be shell-expanded. git-sh-setup: fix parseopt `eval` string underquoting Give git-am back the ability to add Signed-off-by lines. git-rev-parse --parseopt scripts: Add placeholders for OPTIONS_SPEC Migrate git-repack.sh to use git-rev-parse --parseopt Migrate git-quiltimport.sh to use git-rev-parse --parseopt Migrate git-checkout.sh to use git-rev-parse --parseopt --keep-dashdash Migrate git-instaweb.sh to use git-rev-parse --parseopt Migrate git-merge.sh to use git-rev-parse --parseopt Migrate git-am.sh to use git-rev-parse --parseopt Migrate git-clone to use git-rev-parse --parseopt Migrate git-clean.sh to use git-rev-parse --parseopt. Update git-sh-setup(1) to allow transparent use of git-rev-parse --parseopt Add a parseopt mode to git-rev-parse to bring parse-options to shell scripts.
2007-11-17Bisect visualize: use "for-each-ref" to list all good refs.Libravatar Christian Couder1-2/+2
In bisect_visualize, "cd $GIT_DIR/refs && echo bisect/good-*" was still used instead of "git for-each-ref". This patch fix it. We now pass "refs/bisect/bad" and "--not refs/bisect/good-<rev>" instead of "bisect/bad" and "--not bisect/good-<rev>" to gitk, but it seems to work. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-16git-bisect: modernize branch shuffling hackLibravatar Junio C Hamano1-3/+2
When switching to a new rev, we first made "new-bisect" branch to point at the chosen commit, attempt to switch to it, and then finally renamed the new-bisect branch to bisect by hand when successful. This is so that we can catch checkout failure (your local modification may interfere with switching to the chosen version) without losing information on which commit the next attempt should be made. Rewrite it using a more modern form but without breaking the safety. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-16git-bisect: use update-ref to mark good/bad commitsLibravatar Junio C Hamano1-1/+1
This removes the last instance of making a ref by hand with "echo SHA1 >.git/refs/$refname" from the script and replaces it with update-ref. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-16git-bisect: war on "sed"Libravatar Junio C Hamano1-3/+2
We do not need to pipe "echo" to "sed" only to strip refs/heads/ from the beginning. We are assuming not-so-ancient shells these days. Also there is no need to avoid assuming \012 is the LF; we do not run on EBCDIC, sorry. Other parts of the script already uses tr to convert separator to LF that way. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-16Bisect reset: remove bisect refs that may have been packed.Libravatar Christian Couder1-1/+7
If refs were ever packed in the middle of bisection, the bisect refs were not removed from the "packed-refs" file. This patch fixes this problem by using "git update-ref -d $ref $hash" in "bisect_clean_state". Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-09git-bisect.sh: Fix sed script to work with AIX and BSD sed.Libravatar Ralf Wildenhues1-1/+2
\n is not portable in a s/// replacement string, only in the regex part. backslash-newline helps. Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-06scripts: Add placeholders for OPTIONS_SPECLibravatar Junio C Hamano1-0/+1
--text follows this line-- These commands currently lack OPTIONS_SPEC; allow people to easily list with "git grep 'OPTIONS_SPEC=$'" what they can help improving. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-29Bisect: add "skip" to the short usage string.Libravatar Christian Couder1-3/+3
Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-26Bisect run: "skip" current commit if script exit code is 125.Libravatar Christian Couder1-1/+10
This is incompatible with previous versions because an exit code of 125 used to mark current commit as "bad". But hopefully this exit code is not much used by test scripts or other programs. (126 and 127 are used by POSIX compliant shells to mean "found but not executable" and "command not found", respectively.) Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-26Bisect: refactor "bisect_{bad,good,skip}" into "bisect_state".Libravatar Christian Couder1-51/+31
Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-26Bisect: refactor some logging into "bisect_write".Libravatar Christian Couder1-33/+14
Also use "die" instead of "echo >&2 something ; exit 1". And simplify "bisect_replay". Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-26Bisect: refactor "bisect_write_*" functions.Libravatar Christian Couder1-26/+20
Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-26Bisect: implement "bisect skip" to mark untestable revisions.Libravatar Christian Couder1-6/+119
When there are some "skip"ped revisions, we add the '--bisect-all' option to "git rev-list --bisect-vars". Then we filter out the "skip"ped revisions from the result of the rev-list command, and we modify the "bisect_rev" var accordingly. We don't always use "--bisect-all" because it is slower than "--bisect-vars" or "--bisect". When we cannot find for sure the first bad commit because of "skip"ped commits, we print the hash of each possible first bad commit and then we exit with code 2. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>