- 06 8月, 2011 1 次提交
-
-
由 Jon Seymour 提交于
All leading whitespace is now encoded with tabs. After this patch, the following is true: RAW=$(cat git-bisect.sh | md5sum) && ROUNDTRIP=$(cat git-bisect.sh | expand -i - | unexpand --first-only - | md5sum) && LEADING=$(sed -n "/^ */p" < git-bisect.sh | wc -l) && test $RAW = $ROUNDTRIP && test $LEADING = 0 && test -z "$(git diff -w HEAD~1 HEAD)" Signed-off-by: NJon Seymour <jon.seymour@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 05 8月, 2011 3 次提交
-
-
由 Jon Seymour 提交于
git-bisect can now perform bisection of a history without performing a checkout at each stage of the bisection process. Instead, HEAD is updated. One use-case for this function is allow git bisect to be used with damaged repositories where git checkout would fail because the tree referenced by the commit is damaged. It can also be used in other cases where actual checkout of the tree is not required to progress the bisection. Improved-by: NChristian Couder <chriscool@tuxfamily.org> Improved-by: NJunio C Hamano <gitster@pobox.com> Improved-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJon Seymour <jon.seymour@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jon Seymour 提交于
Christian Couder pointed out that the existing eval strategy swallows an initial non-zero return. Using && to connect the statements should fix this. Signed-off-by: NJon Seymour <jon.seymour@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jon Seymour 提交于
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: NJon Seymour <jon.seymour@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 22 5月, 2011 11 次提交
-
-
由 Ævar Arnfjörð Bjarmason 提交于
Gettextize the "You need to start by" message in bisect_next_check. This message assembled English output by hand so it needed to be split up to make it translatable. Signed-off-by: NÆvar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Ævar Arnfjörð Bjarmason 提交于
Gettextize the [Y/n] questions git-bisect presents, and leave a note in a TRANSLATORS comment explaining that translators have to preserve a mention of the Y/n characters since the program will expect them, and not their localized equivalents. Signed-off-by: NÆvar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Ævar Arnfjörð Bjarmason 提交于
Gettextize bisect_replay messages that use the $1 variable. Since it's subroutine local we have to provide an alias for it for eval_gettext. Since I was doing that anyway I've changed all other uses of $1 variable to use the alias variable for clarity. Signed-off-by: NÆvar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Ævar Arnfjörð Bjarmason 提交于
ettextize bisect_reset messages that use the $1 variable. Since it's subroutine local we have to provide an alias for it for eval_gettext. Signed-off-by: NÆvar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Ævar Arnfjörð Bjarmason 提交于
Gettextize bisect_run messages that use the $@ variable. Since it's subroutine local we have to provide an alias for it for eval_gettext. Signed-off-by: NÆvar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Ævar Arnfjörð Bjarmason 提交于
Signed-off-by: NÆvar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Ævar Arnfjörð Bjarmason 提交于
Signed-off-by: NÆvar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Ævar Arnfjörð Bjarmason 提交于
Signed-off-by: NÆvar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Ævar Arnfjörð Bjarmason 提交于
Signed-off-by: NÆvar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Ævar Arnfjörð Bjarmason 提交于
Signed-off-by: NÆvar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Ævar Arnfjörð Bjarmason 提交于
Signed-off-by: NÆvar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 22 3月, 2011 1 次提交
-
-
由 Jeff King 提交于
If gitk is not available in the PATH, bisect ends up exiting with the shell's 127 error code, confusing the git wrapper into thinking that bisect is not a git command. We already fallback to git-log if there doesn't seem to be a graphical display available. We should do the same if gitk is not available in our PATH at all. This not only fixes the ugly error message, but is a much more sensible default than failing to show the user anything. Reported by Maxin John. Tested-by: NMaxin B. John <maxin@maxinbjohn.info> Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 14 10月, 2010 3 次提交
-
-
由 SZEDER Gábor 提交于
'git bisect replay' has a mandatory logfile argument, but the current implementation doesn't check whether the user has specified one. When the user omits the logfile argument, this leads to the following unhelpful error message: cannot read for replaying So, check for the mandatory argument first, and provide a more meaningful error message when it is omitted. Signed-off-by: NSZEDER Gábor <szeder@ira.uka.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 SZEDER Gábor 提交于
'git bisect reset' (without the optional <commit> argument) returns to the original HEAD from where the bisection was started. However, when, for whatever reason, the user deleted the original HEAD before invoking 'git bisect reset', then all he gets is an error message from 'git checkout': fatal: invalid reference: somebranch Let's try to be more helpful with an error message better describing what went wrong and a suggestion about how to resolve the situation: Could not check out original HEAD 'somebranch'. Try 'git bisect reset <commit>'. Signed-off-by: NSZEDER Gábor <szeder@ira.uka.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 SZEDER Gábor 提交于
'git bisect log' is implemented by a direct invocation of 'cat "$GIT_DIR/BISECT_LOG"', without any sanity checks. Consequently, running 'git bisect log' while not bisecting leads to an error, because the bisect logfile doesn't exists. The accompanying error message cat: /path/to/repo/.git/BISECT_LOG: No such file or directory is neither very helpful nor very friendly. Instead of blindly trying to cat the log file, first check whether there is a bisection going on (i.e. the bisect logfile exists), and die with a more appropriate error message when not. Signed-off-by: NSZEDER Gábor <szeder@ira.uka.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 24 11月, 2009 1 次提交
-
-
由 Junio C Hamano 提交于
If the user has exported the GREP_OPTIONS environment variable, the output from "grep" and "egrep" in scripted Porcelains may be different from what they expect. For example, we may want to count number of matching lines, by "grep" piped to "wc -l", and GREP_OPTIONS=-C3 will break such use. The approach taken by this change to address this issue is to protect only our own use of grep/egrep. Because we do not unset it at the beginning of our scripts, hook scripts run from the scripted Porcelains are exposed to the same insanity this environment variable causes when grep/egrep is used to implement logic (e.g. "grep | wc -l"), and it is entirely up to the hook scripts to protect themselves. On the other hand, applypatch-msg hook may want to show offending words in the proposed commit log message using grep to the end user, and the user might want to set GREP_OPTIONS=--color to paint the match more visibly. The approach to protect only our own use without unsetting the environment variable globally will allow this use case. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 23 11月, 2009 1 次提交
-
-
由 Christian Couder 提交于
In commit ad3f9a71 (Add '--bisect' revision machinery argument) the '--bisect' option was added to easily pass bisection refs to commands using the revision machinery. So it is now shorter and safer to use the new '--bisect' revision machinery option, than to compute the refs that we must pass. Signed-off-by: NChristian Couder <chriscool@tuxfamily.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 14 10月, 2009 1 次提交
-
-
由 Anders Kaseorg 提交于
‘git bisect reset’ accepts an optional argument specifying a branch to check out after cleaning up the bisection state. This lets you specify an arbitrary commit. In particular, this provides a way to clean the bisection state without moving HEAD: ‘git bisect reset HEAD’. This may be useful if you are not interested in the state before you began a bisect, especially if checking out the old commit would be expensive and invalidate most of your compiled tree. Clarify the ‘git bisect reset’ documentation to explain this optional argument, which was previously mentioned only in the usage message. Signed-off-by: NAnders Kaseorg <andersk@mit.edu> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 27 8月, 2009 1 次提交
-
-
由 Nanako Shiraishi 提交于
Signed-off-by: NNanako Shiraishi <nanako3@lavabit.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 11 5月, 2009 1 次提交
-
-
由 Christian Couder 提交于
This patch replace the "--next-exit" option of "git bisect--helper" with a "--next-all" option that does merge base checking using the "check_good_are_ancestors_of_bad" function implemented in "bisect.c" in a former patch. The new "--next-all" option is then used in "git-bisect.sh" instead of the "--next-exit" option, and all the shell functions in "git-bisect.sh" that are now unused are removed. Signed-off-by: NChristian Couder <chriscool@tuxfamily.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 10 5月, 2009 2 次提交
-
-
由 Christian Couder 提交于
As the "sq" function was the only place using Perl in "git-bisect.sh", this removes the Perl dependency in this script. While at it, we also remove the sed instruction in the Makefile that substituted @@PERL@@ with the Perl path in shell scripts, as this is not needed anymore. (It is now only needed in "git-instaweb.sh" but this command is dealt with separately in the Makefile.) Signed-off-by: NChristian Couder <chriscool@tuxfamily.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Christian Couder 提交于
instead of "git bisect--helper --next-vars". Signed-off-by: NChristian Couder <chriscool@tuxfamily.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 05 4月, 2009 3 次提交
-
-
由 Christian Couder 提交于
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: NChristian Couder <chriscool@tuxfamily.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Christian Couder 提交于
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: NChristian Couder <chriscool@tuxfamily.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Christian Couder 提交于
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: NChristian Couder <chriscool@tuxfamily.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 04 3月, 2009 1 次提交
-
-
由 Christian Couder 提交于
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: NChristian Couder <chriscool@tuxfamily.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 28 2月, 2009 1 次提交
-
-
由 Christian Couder 提交于
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: NChristian Couder <chriscool@tuxfamily.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 27 2月, 2009 1 次提交
-
-
由 Christian Couder 提交于
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: NChristian Couder <chriscool@tuxfamily.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 04 1月, 2009 1 次提交
-
-
由 Johannes Schindelin 提交于
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: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 03 12月, 2008 2 次提交
-
-
由 Christian Couder 提交于
Signed-off-by: NChristian Couder <chriscool@tuxfamily.org>
-
由 Christian Couder 提交于
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: NChristian Couder <chriscool@tuxfamily.org>
-
- 26 11月, 2008 1 次提交
-
-
由 Christian Couder 提交于
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: NChristian Couder <chriscool@tuxfamily.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 10 11月, 2008 1 次提交
-
-
由 Christian Couder 提交于
Check to see given bad/good/skip sets are valid commit and to exit otherwise was broken by 6a54d976 (bisect: remove "checkout_done" variable used when checking merge bases, 2008-09-06). Signed-off-by: NChristian Couder <chriscool@tuxfamily.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 06 9月, 2008 1 次提交
-
-
由 Christian Couder 提交于
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: NChristian Couder <chriscool@tuxfamily.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 28 8月, 2008 2 次提交
-
-
由 Christian Couder 提交于
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: NChristian Couder <chriscool@tuxfamily.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Christian Couder 提交于
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: NChristian Couder <chriscool@tuxfamily.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-