aboutsummaryrefslogtreecommitdiff
path: root/git-bisect.sh
Commit message (Collapse)AuthorAge
* Merge branch 'cc/bisect-filter'Junio C Hamano2009-04-12
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * cc/bisect-filter: (21 commits) rev-list: add "int bisect_show_flags" in "struct rev_list_info" rev-list: remove last static vars used in "show_commit" list-objects: add "void *data" parameter to show functions bisect--helper: string output variables together with "&&" rev-list: pass "int flags" as last argument of "show_bisect_vars" t6030: test bisecting with paths bisect: use "bisect--helper" and remove "filter_skipped" function bisect: implement "read_bisect_paths" to read paths in "$GIT_DIR/BISECT_NAMES" bisect--helper: implement "git bisect--helper" bisect: use the new generic "sha1_pos" function to lookup sha1 rev-list: call new "filter_skip" function patch-ids: use the new generic "sha1_pos" function to lookup sha1 sha1-lookup: add new "sha1_pos" function to efficiently lookup sha1 rev-list: pass "revs" to "show_bisect_vars" rev-list: make "show_bisect_vars" non static rev-list: move code to show bisect vars into its own function rev-list: move bisect related code into its own file rev-list: make "bisect_list" variable local to "cmd_rev_list" refs: add "for_each_ref_in" function to refactor "for_each_*_ref" functions quote: add "sq_dequote_to_argv" to put unwrapped args in an argv array ...
| * bisect--helper: string output variables together with "&&"Christian Couder2009-04-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When doing: eval "git bisect--helper --next-vars" | { while read line do echo "$line &&" done echo ':' } the result code comes from the last "echo ':'", not from running "git bisect--helper --next-vars". This patch gets rid of the need to string together the line from the output of "git bisect--helper" with "&&" in the calling script by making "git bisect--helper --next-vars" return output variables already in that format. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * bisect: use "bisect--helper" and remove "filter_skipped" functionChristian Couder2009-04-05
| | | | | | | | | | | | | | | | | | | | | | | | Use the new "git bisect--helper" builtin. It should be faster and safer instead of the old "filter_skipped" shell function. And it is a first step to move more shell code to C. As the output is a little bit different we have to change the code that interpret the results. But these changes improve code clarity. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | bisect: improve error message when branch checkout failsChristian Couder2009-04-05
|/ | | | | | | | | | | | | | | | | | | | | | | | | In "git-bisect.sh" the "git checkout" command is only used to change the current branch, but it is used like this: git checkout "$branch" which will output the following misleading error message when it fails: error: pathspec 'foo' did not match any file(s) known to git. This patch change the way we use "git checkout" like this: git checkout "$branch" -- so that we will get the following error message: fatal: invalid reference: foo which is better. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* rev-list: estimate number of bisection step leftChristian Couder2009-03-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch teaches "git rev-list --bisect-vars" to output an estimate of the number of bisection step left _after the current one_ along with the other variables it already outputs. This patch also makes "git-bisect.sh" display this number of steps left _after the current one_, along with the estimate of the number of revisions left to test (after the current one). Here is a table to help analyse what should be the best estimate for the number of bisect steps left. N : linear case --> probabilities --> best ------------------------------------------------------------- 1 : G-B --> 0 --> 0 2 : G-U1-B --> 0 --> 0 3 : G-U1-U2-B --> 0(1/3) 1(2/3) --> 1 4 : G-U1-U2-U3-B --> 1 --> 1 5 : G-U1-U2-U3-U4-B --> 1(3/5) 2(2/5) --> 1 6 : G-U1-U2-U3-U4-U5-B --> 1(2/6) 2(4/6) --> 2 7 : G-U1-U2-U3-U4-U5-U6-B --> 1(1/7) 2(6/7) --> 2 8 : G-U1-U2-U3-U4-U5-U6-U7-B --> 2 --> 2 9 : G-U1-U2-U3-U4-U5-U6-U7-U8-B --> 2(7/9) 3(2/9) --> 2 10: G-U1-U2-U3-U4-U5-U6-U7-U8-U9-B --> 2(6/10)3(4/10)--> 2 In the column "N", there is the number of revisions that could _now_ be the first bad commit we are looking for. The "linear case" column describes the linear history corresponding to the number in column N. G means good, B means bad, and Ux means unknown. Note that the first bad revision we are looking for can be any Ux or B. In the "probabilities" column, there are the different outcomes in number of steps with the odds of each outcome in parenthesis corresponding to the linear case. The "best" column gives the most accurate estimate among the different outcomes in the "probabilities" column. We have the following: best(2^n) == n - 1 and for any x between 0 included and 2^n excluded, the probability for n - 1 steps left looks like: P(2^n + x) == (2^n - x) / (2^n + x) and P(2^n + x) < 0.5 means 2^n < 3x So the algorithm used in this patch calculates 2^n and x, and then choose between returning n - 1 and n. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'cc/maint-1.6.0-bisect-fix'Junio C Hamano2009-02-27
|\ | | | | | | | | | | | | | | * cc/maint-1.6.0-bisect-fix: bisect: fix another instance of eval'ed string Conflicts: git-bisect.sh
| * bisect: fix another instance of eval'ed stringChristian Couder2009-02-27
| | | | | | | | | | | | | | | | | | | | | | | | When there is nothing to be skipped, the output from rev-list --bisect-vars was eval'ed without first being strung together with &&; this is probably not a problem as it is much less likely to be a bad input than the list handcrafted by the filter_skip function, but it still is a good discipline. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'cc/maint-1.6.0-bisect-fix'Junio C Hamano2009-02-27
|\ \ | |/ | | | | | | | | | | | | * cc/maint-1.6.0-bisect-fix: bisect: fix quoting TRIED revs when "bad" commit is also "skip"ped Conflicts: git-bisect.sh
| * bisect: fix quoting TRIED revs when "bad" commit is also "skip"pedChristian Couder2009-02-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | bisect view: call gitk if Cygwin's SESSIONNAME variable is setJohannes Schindelin2009-01-03
| | | | | | | | | | | | | | | | | | | | | | It seems that Cygwin sets the variable SESSIONNAME when an interactive desktop session is running, and does not set it when you log in via ssh. So we can use this variable to determine whether to run gitk or git log in git bisect view. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Documentation: describe how to "bisect skip" a range of commitsChristian Couder2008-12-02
| | | | | | | | Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
* | bisect: fix "git bisect skip <commit>" and add tests casesChristian Couder2008-12-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | bisect: teach "skip" to accept special arguments like "A..B"Christian Couder2008-11-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | bisect: fix missing "exit"Christian Couder2008-11-09
| | | | | | | | | | | | | | | | | | 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>
* | bisect: remove "checkout_done" variable used when checking merge basesChristian Couder2008-09-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | bisect: only check merge bases when neededChristian Couder2008-08-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | bisect: test merge base if good rev is not an ancestor of bad revChristian Couder2008-08-27
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Merge branch 'maint'Junio C Hamano2008-08-11
|\ | | | | | | | | * maint: git-bisect: fix wrong usage of read(1)
| * git-bisect: fix wrong usage of read(1)Francis Moreau2008-08-11
| | | | | | | | | | Signed-off-by: Francis Moreau <francis.moro@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | git-bisect: use dash-less form on git bisect logMiklos Vajna2008-07-11
|/ | | | | | | | 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>
* bisect: use "$GIT_DIR/BISECT_START" to check if we are bisectingChristian Couder2008-05-28
| | | | | | | | | | | | | | | | | | | 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>
* bisect: use a detached HEAD to bisectChristian Couder2008-05-22
| | | | | | | | | | | | | | | | | | | 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>
* bisect: trap critical errors in "bisect_start"Christian Couder2008-05-22
| | | | | | | | | | | | | | | | | | 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>
* bisect: fix left over "BISECT_START" file when starting with junk revChristian Couder2008-05-22
| | | | | | | | | | | | | | | | | 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>
* Merge branch 'gp/bisect-fix'Junio C Hamano2008-05-12
|\ | | | | | | | | | | * 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"
| * bisect: print an error message when "git rev-list --bisect-vars" failsChristian Couder2008-05-08
| | | | | | | | | | | | | | | | | | | | | | 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>
| * git-bisect.sh: don't accidentally override existing branch "bisect"Gerrit Pape2008-05-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge branch 'maint'Junio C Hamano2008-04-16
|\ \ | |/ | | | | | | | | | | | | | | | | * 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
| * Merge branch 'maint-1.5.4' into maintJunio C Hamano2008-04-16
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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
| | * git-bisect: make "start", "good" and "skip" succeed or fail atomicallyChristian Couder2008-04-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * bisect: squelch "fatal: ref HEAD not a symref" misleading messageChristian Couder2008-04-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | Merge branch 'maint'Junio C Hamano2008-04-12
|\ \ \ | |/ / | | | | | | | | | | | | | | | | | | | | | | | | * 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
| * | Merge branch 'maint-1.5.4' into maintJunio C Hamano2008-04-12
| |\ \ | | |/ | | | | | | | | | | | | | | | * maint-1.5.4: Docs gitk: Explicitly mention the files that gitk uses (~/.gitk) Document -w option to shortlog bisect: report bad rev better
| | * bisect: report bad rev betterChristian Couder2008-04-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | Merge branch 'maint'Junio C Hamano2008-04-11
|\ \ \ | |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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")
| * | Merge branch 'maint-1.5.4' into maintJunio C Hamano2008-04-11
| |\ \ | | |/ | | | | | | | | | | | | | | | | | | | | | * 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")
| | * bisect: fix bad rev checking in "git bisect good"Christian Couder2008-04-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * Eliminate confusing "won't bisect on seeked tree" failureCarl Worth2008-02-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | bisect: add "git bisect help" subcommand to get a long usage stringChristian Couder2008-04-11
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | tr portability fixesJeff King2008-03-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Eliminate confusing "won't bisect on seeked tree" failureCarl Worth2008-02-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | bisect view: check for MinGW32 and MacOSX in addition to X11Johannes Schindelin2008-02-17
|/ | | | | | | | | | | | | 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>
* bisect: use verbatim commit subject in the bisect logJohannes Schindelin2008-02-13
| | | | | | | | | | 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>
* bisect: allow starting with a detached HEADJohannes Schindelin2008-02-11
| | | | | | | | 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>
* git-bisect visualize: work in non-windowed environments betterJunio C Hamano2007-12-08
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* Merge branch 'cc/bisect'Junio C Hamano2007-11-24
|\ | | | | | | | | | | | | | | | | | | | | * 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.
| * Bisect reset: do nothing when not bisecting.Christian Couder2007-11-20
| | | | | | | | | | | | | | | | | | | | | | 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>
| * Bisect: use "$GIT_DIR/BISECT_NAMES" to check if we are bisecting.Christian Couder2007-11-18
| | | | | | | | | | | | | | | | | | | | | | | | 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>
| * Bisect visualize: use "for-each-ref" to list all good refs.Christian Couder2007-11-17
| | | | | | | | | | | | | | | | | | | | | | | | 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>
| * git-bisect: modernize branch shuffling hackJunio C Hamano2007-11-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>