summaryrefslogtreecommitdiff
path: root/t/t6030-bisect-porcelain.sh
AgeCommit message (Collapse)AuthorFilesLines
2011-11-06Merge branch 'ab/i18n-test-fix'Libravatar Junio C Hamano1-1/+1
* ab/i18n-test-fix: t/t7508-status.sh: use test_i18ncmp t/t6030-bisect-porcelain.sh: use test_i18ngrep
2011-11-05t/t6030-bisect-porcelain.sh: use test_i18ngrepLibravatar Ævar Arnfjörð Bjarmason1-1/+1
Change a i18n-specific grep in t/t6030-bisect-porcelain.sh to use test_i18ngrep instead. This was introduced in v1.7.7.2~5^2~11 and has been broken under GETTEXT_POISON=YesPlease since. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-02Merge branch 'bc/bisect-test-use-shell-path'Libravatar Junio C Hamano1-1/+1
* bc/bisect-test-use-shell-path: t6030: use $SHELL_PATH to invoke user's preferred shell instead of bare sh
2011-08-30t6030: use $SHELL_PATH to invoke user's preferred shell instead of bare shLibravatar Brandon Casey1-1/+1
Some platforms (IRIX, Solaris) provide an ancient /bin/sh which chokes on modern shell syntax like $(). SHELL_PATH is provided to allow the user to specify a working sh, let's use it here. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-09bisect: add support for bisecting bare repositoriesLibravatar Jon Seymour1-0/+31
This enhances the support for bisecting history in bare repositories. The "git bisect" command no longer needs to be run inside a repository with a working tree; it defaults to --no-checkout when run in a bare repository. Two tests are included to demonstrate this behaviour. Suggested-by: Junio C Hamano <gitster@pobox.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Jon Seymour <jon.seymour@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04bisect: add tests for the --no-checkout option.Libravatar Jon Seymour1-0/+82
These tests verify that git-bisect --no-checkout can successfully bisect commit histories that reference damaged trees. Signed-off-by: Jon Seymour <jon.seymour@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04bisect: add tests to document expected behaviour in presence of broken trees.Libravatar Jon Seymour1-0/+48
If the repo is broken, we expect bisect to fail. Signed-off-by: Jon Seymour <jon.seymour@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04bisect: move argument parsing before state modification.Libravatar Jon Seymour1-3/+11
Currently 'git bisect start' modifies some state prior to checking that its arguments are valid. This change moves argument validation before state modification with the effect that state modification does not occur unless argument validations succeeds. An existing test is changed to check that new bisect state is not created if arguments are invalid. A new test is added to check that existing bisect state is not modified if arguments are invalid. Signed-off-by: Jon Seymour <jon.seymour@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-09tests: add missing &&Libravatar Jonathan Nieder1-4/+4
Breaks in a test assertion's && chain can potentially hide failures from earlier commands in the chain. Commands intended to fail should be marked with !, test_must_fail, or test_might_fail. The examples in this patch do not require that. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-01Merge branch 'cc/maint-bisect-paths'Libravatar Junio C Hamano1-0/+5
* cc/maint-bisect-paths: bisect: error out when passing bad path parameters
2010-03-01bisect: error out when passing bad path parametersLibravatar Christian Couder1-0/+5
As reported by Mark Lodato, "git bisect", when it was started with path parameters that match no commit was kind of working without taking account of path parameters and was reporting something like: Bisecting: -1 revisions left to test after this (roughly 0 steps) It is more correct and safer to just error out in this case, before displaying the revisions left, so this patch does just that. Note that this bug is very old, it exists at least since v1.5.5. And it is possible to detect that case earlier in the bisect algorithm, but it is not clear that it would be an improvement to error out earlier, on the contrary it may change the behavior of "git rev-list --bisect-all" for example, which is currently correct. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-03Use warning function instead of fprintf(stderr, "Warning: ...").Libravatar Thiago Farina1-1/+1
Signed-off-by: Thiago Farina <tfransosi@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-26git-bisect: call the found commit "*the* first bad commit"Libravatar Nanako Shiraishi1-9/+9
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-13bisect: use a PRNG with a bias when skipping away from untestable commitsLibravatar Christian Couder1-2/+2
Using a PRNG (pseudo random number generator) with a bias should be better than alternating between 3 fixed ratios. In repositories with many untestable commits it should prevent alternating between areas where many commits are untestable. The bias should favor commits that can give more information, so that the bisection process should not loose much efficiency. HPA suggested to use a PRNG and found that the best bias is to raise a ratio between 0 and 1 given by the PRNG to the power 1.5. An integer square root function is implemented to avoid including <math.h> and linking with -lm. A PRNG function is implemented to get the same number sequence on different machines as suggested by "man 3 rand". Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-06t6030: test skipping away from an already skipped commitLibravatar Christian Couder1-0/+12
Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-05-17bisect: check ancestors without forking a "git rev-list" processLibravatar Christian Couder1-12/+1
We must save the pending commits that will be used during revision walking and unparse them after, because we want to leave a clean state for the next revision walking that will try to find the best bisection point. As we don't fork a process anymore to call "git rev-list", we need to remove the use of GIT_TRACE to check how "git rev-list" is called from the t6030 test that uses it. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-05t6030: test bisecting with pathsLibravatar Christian Couder1-0/+60
This patch adds some tests to check that "git bisect" works fine when passing paths to "git bisect start" to reduce the number of bisection steps. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-27Merge branch 'cc/maint-1.6.0-bisect-fix'Libravatar Junio C Hamano1-0/+25
* cc/maint-1.6.0-bisect-fix: bisect: fix quoting TRIED revs when "bad" commit is also "skip"ped Conflicts: git-bisect.sh
2009-02-27bisect: fix quoting TRIED revs when "bad" commit is also "skip"pedLibravatar Christian Couder1-0/+25
When the "bad" commit was also "skip"ped and when more than one commit was skipped, the "filter_skipped" function would have printed something like: bisect_rev=<hash1>|<hash2> (where <hash1> and <hash2> are hexadecimal sha1 hashes) and this would have been evaled later as piping "bisect_rev=<hash1>" into "<hash2>", which would have failed. So this patch makes the "filter_skipped" function properly quote what it outputs, so that it will print something like: bisect_rev='<hash1>|<hash2>' which will be properly evaled later. The caller was not stopping properly because the scriptlet this function returned to be evaled was not strung together with && and because of this, an error in an earlier part of the output was simply ignored. A test case is added to the test suite. And while at it, we also initialize the VARS, FOUND and TRIED variables, so that we protect ourselves from environment variables the user may have with these names. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-02bisect: fix "git bisect skip <commit>" and add tests casesLibravatar Christian Couder1-1/+18
The patch that allows "git bisect skip" to be passed a range of commits using the "<commit1>..<commit2>" notation is flawed because it introduces a regression when it was passed a simple rev or commit. "git bisect skip <commit>" doesn't work any more, because <commit> is quoted but not properly unquoted. This patch fixes that and add tests cases to better check when it is passed commits and range of commits. While at it, this patch also properly quotes the non range arguments using the "sq" function. Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
2008-09-18Merge branch 'cc/bisect'Libravatar Junio C Hamano1-0/+114
* cc/bisect: bisect: remove "checkout_done" variable used when checking merge bases bisect: only check merge bases when needed bisect: test merge base if good rev is not an ancestor of bad rev
2008-09-03tests: use "git xyzzy" form (t3600 - t6999)Libravatar Nanako Shiraishi1-2/+2
Converts tests between t3600-t6300. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-27bisect: only check merge bases when neededLibravatar Christian Couder1-0/+24
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-0/+90
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-07-27t6030 (bisect): work around Mac OS X "ls"Libravatar Jonathan Nieder1-1/+1
t6030-bisect-porcelain.sh relies on "ls" exiting with nonzero status when asked to list nonexistent files. Unfortunately, /bin/ls on Mac OS X 10.3 exits with exit code 0. So look at its output instead. Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu> Acked-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-19/+19
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/+4
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-1/+1
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-22bisect: add test cases to check that "git bisect start" is atomicLibravatar Christian Couder1-0/+43
This patch adds some test cases to check that "git bisect start" doesn't leave us in a bad state, especially when it fails. These test cases show that "git bisect start" is not atomic when it fails and leave some files like .git/BISECT_START, and in some cases some refs, over. The test failures should be fixed in latter commits. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-08bisect: print an error message when "git rev-list --bisect-vars" failsLibravatar Christian Couder1-0/+7
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-0/+18
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-1.5.4' into maintLibravatar Junio C Hamano1-1/+6
* 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-1/+6
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-11Merge branch 'maint-1.5.4' into maintLibravatar Junio C Hamano1-0/+13
* 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-0/+13
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-03-13remove use of "tail -n 1" and "tail -1"Libravatar Jeff King1-3/+3
The "-n" syntax is not supported by System V versions of tail (which prefer "tail -1"). Unfortunately "tail -1" is not actually POSIX. We had some of both forms in our scripts. Since neither form works everywhere, this patch replaces both with the equivalent sed invocation: sed -ne '$p' 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-1/+1
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-1/+1
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-11bisect: allow starting with a detached HEADLibravatar Johannes Schindelin1-0/+12
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-11-20Bisect reset: do nothing when not bisecting.Libravatar Christian Couder1-1/+26
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-16Bisect reset: remove bisect refs that may have been packed.Libravatar Christian Couder1-0/+12
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-10-26Bisect run: "skip" current commit if script exit code is 125.Libravatar Christian Couder1-0/+40
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: add a "bisect replay" test case.Libravatar Christian Couder1-0/+7
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-0/+71
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>
2007-06-07War on whitespaceLibravatar Junio C Hamano1-1/+0
This uses "git-apply --whitespace=strip" to fix whitespace errors that have crept in to our source files over time. There are a few files that need to have trailing whitespaces (most notably, test vectors). The results still passes the test, and build result in Documentation/ area is unchanged. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-04-23t6030: grab commit object name as we goLibravatar Junio C Hamano1-7/+10
Instead of running rev-list and picking earlier lines using head/tail pipeline, grab commit object name as we build commits. This also removes a non POSIX use of tail with -linenum (more posixly-correct way to say it is "-n linenum") Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-16Bisect: rename "t/t6030-bisect-run.sh" to "t/t6030-bisect-porcelain.sh".Libravatar Christian Couder1-0/+102
[jc: also fix 0a5280a9 that incorrectly changed the title of one test.] Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <junkio@cox.net>