summaryrefslogtreecommitdiff
path: root/git-bisect.sh
Commit message (Collapse)AuthorAgeFilesLines
* bisect view: call gitk if Cygwin's SESSIONNAME variable is setJohannes Schindelin2009-01-031-1/+1
| | | | | | | | | | | 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-021-1/+1
| | | | Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
* bisect: fix "git bisect skip <commit>" and add tests casesChristian Couder2008-12-021-2/+2
| | | | | | | | | | | | | | | | | 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-251-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>
* bisect: fix missing "exit"Christian Couder2008-11-091-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>
* bisect: remove "checkout_done" variable used when checking merge basesChristian Couder2008-09-051-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>
* bisect: only check merge bases when neededChristian Couder2008-08-271-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>
* bisect: test merge base if good rev is not an ancestor of bad revChristian Couder2008-08-271-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>
* Merge branch 'maint'Junio C Hamano2008-08-111-1/+2
|\ | | | | | | | | * maint: git-bisect: fix wrong usage of read(1)
| * git-bisect: fix wrong usage of read(1)Francis Moreau2008-08-111-1/+2
| | | | | | | | | | 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-111-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>
* bisect: use "$GIT_DIR/BISECT_START" to check if we are bisectingChristian Couder2008-05-281-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>
* bisect: use a detached HEAD to bisectChristian Couder2008-05-221-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>
* bisect: trap critical errors in "bisect_start"Christian Couder2008-05-221-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>
* bisect: fix left over "BISECT_START" file when starting with junk revChristian Couder2008-05-221-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>
* Merge branch 'gp/bisect-fix'Junio C Hamano2008-05-121-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"
| * bisect: print an error message when "git rev-list --bisect-vars" failsChristian Couder2008-05-081-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>
| * git-bisect.sh: don't accidentally override existing branch "bisect"Gerrit Pape2008-05-051-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>
* | Merge branch 'maint'Junio C Hamano2008-04-161-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
| * Merge branch 'maint-1.5.4' into maintJunio C Hamano2008-04-161-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
| | * git-bisect: make "start", "good" and "skip" succeed or fail atomicallyChristian Couder2008-04-161-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>
| | * bisect: squelch "fatal: ref HEAD not a symref" misleading messageChristian Couder2008-04-151-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>
* | | Merge branch 'maint'Junio C Hamano2008-04-121-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
| * | Merge branch 'maint-1.5.4' into maintJunio C Hamano2008-04-121-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
| | * bisect: report bad rev betterChristian Couder2008-04-121-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>
* | | Merge branch 'maint'Junio C Hamano2008-04-111-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")
| * | Merge branch 'maint-1.5.4' into maintJunio C Hamano2008-04-111-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")
| | * bisect: fix bad rev checking in "git bisect good"Christian Couder2008-04-111-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>
| | * Eliminate confusing "won't bisect on seeked tree" failureCarl Worth2008-02-271-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>
* | | bisect: add "git bisect help" subcommand to get a long usage stringChristian Couder2008-04-111-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>
* | tr portability fixesJeff King2008-03-121-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>
* | Eliminate confusing "won't bisect on seeked tree" failureCarl Worth2008-02-241-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>
* | bisect view: check for MinGW32 and MacOSX in addition to X11Johannes Schindelin2008-02-171-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>
* bisect: use verbatim commit subject in the bisect logJohannes Schindelin2008-02-131-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>
* bisect: allow starting with a detached HEADJohannes Schindelin2008-02-111-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>
* git-bisect visualize: work in non-windowed environments betterJunio C Hamano2007-12-081-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>
* Merge branch 'cc/bisect'Junio C Hamano2007-11-241-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.
| * Bisect reset: do nothing when not bisecting.Christian Couder2007-11-201-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>
| * Bisect: use "$GIT_DIR/BISECT_NAMES" to check if we are bisecting.Christian Couder2007-11-181-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>
| * Bisect visualize: use "for-each-ref" to list all good refs.Christian Couder2007-11-171-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>
| * git-bisect: modernize branch shuffling hackJunio C Hamano2007-11-161-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>
| * git-bisect: use update-ref to mark good/bad commitsJunio C Hamano2007-11-161-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>
| * git-bisect: war on "sed"Junio C Hamano2007-11-161-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>
| * Bisect reset: remove bisect refs that may have been packed.Christian Couder2007-11-161-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>
* | Merge branch 'ph/parseopt-sh'Junio C Hamano2007-11-171-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.
| * scripts: Add placeholders for OPTIONS_SPECJunio C Hamano2007-11-061-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>
* | git-bisect.sh: Fix sed script to work with AIX and BSD sed.Ralf Wildenhues2007-11-091-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>
* Bisect: add "skip" to the short usage string.Christian Couder2007-10-291-3/+3
| | | | | Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Bisect run: "skip" current commit if script exit code is 125.Christian Couder2007-10-261-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>
* Bisect: refactor "bisect_{bad,good,skip}" into "bisect_state".Christian Couder2007-10-261-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>
View Lorry Controller Status