git/bisect.c, branch v2.36.2

bisect--helper: double-check run command on exit code 126 and 127

2022-01-19T17:35:03Z

When a run command cannot be executed or found, shells return exit code 126 or 127, respectively. Valid run commands are allowed to return these codes as well to indicate bad revisions, though, for historical reasons. This means typos can cause bogus bisect runs that go over the full distance and end up reporting invalid results. The best solution would be to reserve exit codes 126 and 127, like 71b0251cdd (Bisect run: "skip" current commit if script exit code is 125., 2007-10-26) did for 125, and abort bisect run when we get them. That might be inconvenient for those who relied on the documentation stating that 126 and 127 can be used for bad revisions, though. The workaround used by this patch is to run the command on a known-good revision and abort if we still get the same error code. This adds one step to runs with scripts that use exit codes 126 and 127, but keeps them supported, with one exception: It won't work with commands that cannot recognize the (manually marked) known-good revision as such. Run commands that use low exit codes are unaffected. Typos are reported after executing the missing command twice and three checkouts (the first step, the known good revision and back to the revision of the first step). Signed-off-by: René Scharfe Signed-off-by: Junio C Hamano

bisect: simplify return code from bisect_checkout()

2021-07-28T17:57:37Z

The function was designed to return only BISECT_OK (0) or BISECT_FAILED (-1) and no other values, but there were two issues: - The comment misspelled BISECT_FAILED as BISECT_FAILURE, even though the logic it described (i.e. any non-zero return should be reported as a single BISECT_FAILED) was correct. - It took the return value from run_command_v_opt(), and assumed it was either -1 or 1 upon error, which is not the case; it can relay errors from wait_or_whine(), which can report exit status of the child process. Translate any error return from run_command_v_opt() to BISECT_FAILED, and simplify the resulting code by losing the 'res' variable that is no longer needed. Signed-off-by: Junio C Hamano

bisect: do not run show-branch just to show the current commit

2021-07-28T17:57:26Z

In scripted versions of "git bisect", we used "git show-branch" to describe a single commit in the bisect log and also to the interactive user after checking out the next version to be tested. The former use of "git show-branch" was lost when the helper function that wrote bisect log entries was rewritten at 0f30233a (bisect--helper: `bisect_write` shell function in C, 2019-01-02) in C But we've kept the latter ever since 0871984d (bisect: make "git bisect" use new "--next-all" bisect-helper function, 2009-05-09) started using the faithful C-rewrite introduced at ef24c7ca (bisect--helper: add "--next-exit" to output bisect results, 2009-04-19). Showing "[] " is simple enough with our helper pretty.c::format_commit_message() and spawning show-branch is an overkill. Let's lose one external process. Signed-off-by: Junio C Hamano

use CALLOC_ARRAY

2021-03-14T00:00:09Z

Add and apply a semantic patch for converting code that open-codes CALLOC_ARRAY to use it instead. It shortens the code and infers the element size automatically. Signed-off-by: René Scharfe Signed-off-by: Junio C Hamano

Merge branch 'js/params-vs-args'

2021-02-26T00:43:32Z

Messages update. * js/params-vs-args: replace "parameters" by "arguments" in error messages

replace "parameters" by "arguments" in error messages

2021-02-23T21:30:45Z

When an error message informs the user about an incorrect command invocation, it should refer to "arguments", not "parameters". Signed-off-by: Johannes Sixt Signed-off-by: Junio C Hamano

hash-lookup: rename from sha1-lookup

2021-01-04T21:01:55Z

Change all remnants of "sha1" in hash-lookup.c and .h and rename them to reflect that we're not just able to handle SHA-1 these days. Signed-off-by: Martin Ågren Reviewed-by: Derrick Stolee Signed-off-by: Junio C Hamano

Merge branch 'sg/bisect-approximately-halfway'

2020-11-25T23:24:52Z

"git bisect start/next" in a large span of history spends a lot of time trying to come up with exactly the half-way point; this can be optimized by stopping when we see a commit that is close enough to the half-way point. * sg/bisect-approximately-halfway: bisect: loosen halfway() check for a large number of commits

bisect: loosen halfway() check for a large number of commits

2020-11-12T17:36:48Z

'git bisect start ...' and subsequent 'git bisect (good|bad)' commands can take quite a while when the given/remaining revision range between good and bad commits is big and contains a lot of merge commits, e.g. in git.git: $ git rev-list --count v1.6.0..v2.28.0 44284 $ time git bisect start v2.28.0 v1.6.0 Bisecting: 22141 revisions left to test after this (roughly 15 steps) [e197c21807dacadc8305250baa0b9228819189d4] unable_to_lock_die(): rename function from unable_to_lock_index_die() real 0m15.472s user 0m15.220s sys 0m0.255s The majority of the runtime is spent in do_find_bisection(), where we try to find a commit as close as possible to the halfway point between the bad and good revisions, i.e. a commit from which the number of reachable commits that are in the good-bad range is half the total number of commits in that range. So we count how many commits are reachable in the good-bad range for each commit in that range, which is quick and easy for a linear history, even over 300k commits in a linear range are handled in ~0.3s on my machine. Alas, handling merge commits is non-trivial and quite expensive as the algorithm used seems to be quadratic, causing the long runtime shown above. Interestingly, look at what a big difference one additional commit can make: $ git rev-list --count v1.6.0^..v2.28.0 44285 $ time git bisect start v2.28.0 v1.6.0^ Bisecting: 22142 revisions left to test after this (roughly 15 steps) [565301e41670825ceedf75220f2918ae76831240] Sync with 2.1.2 real 0m5.848s user 0m5.600s sys 0m0.252s The difference is caused by one of the optimizations attempting to cut down the runtime added in 1c4fea3a40 (git-rev-list --bisect: optimization, 2007-03-21): Another small optimization is whenever we find a half-way commit (that is, a commit that can reach exactly half of the commits), we stop giving counts to remaining commits, as we will not find any better commit than we just found. In this second 'git bisect start' command we happen to find a commit exactly at the halfway point and can return early, but in the first case there is no such commit, so we can't return early and end up counting the number of reachable commits from all commits in the good-bad range. However, when we have thousands of commits it's not all that important to find the _exact_ halfway point, a few commits more or less doesn't make any real difference for the bisection. So let's loosen the check in the halfway() helper to consider commits within about 0.1% of the exact halfway point as halfway as well, and rename the function to approx_halfway() accordingly. This will allow us to return early on a bigger good-bad range, even when there is no commit exactly at the halfway point, thereby reducing the runtime of the first command above considerably, from ~15s to 4.901s. Furthermore, even if there is a commit exactly at the halfway point, we might still stumble upon a commit within that 0.1% range before finding the exact halfway point, allowing us to return a bit earlier, slightly reducing the runtime of the second command from 5.848s to 5.058s. Note that this change doesn't affect good-bad ranges containing ~2000 commits or less, because that 0.1% tolerance becomes zero due to integer arithmetic; however, if the range is that small then counting the reachable commits for all commits is already fast enough anyway. Naturally, this will likely change which commits get picked at each bisection step, and, in turn, might change how many bisection steps are necessary to find the first bad commit. If the number of necessary bisection steps were to increase often, then this change could backfire, because building and testing at each step might take much longer than the time spared. OTOH, if the number of steps were to decrease, then it would be a double win. So I ran some tests to see how often that happens: picked random good and bad starting revisions at least 50k commits apart and a random first bad commit in between in git.git, and used 'git bisect run git merge-base --is-ancestor HEAD $first_bad_commit' to check the number of necessary bisection steps. After repeating all this 1000 times both with and without this patch I found that: - 146 cases needed one more bisection step than before, 149 cases needed one less step, while in the remaining 705 cases the number of steps didn't change. So the number of bisection steps does indeed change in a non-negligible number of cases, but it seems that the average number of steps doesn't change in the long run. - The first 'git bisect start' command got over 3x faster in 456 cases, so this "no commit at the exact halfway point" case seems to be common enough to care about. Signed-off-by: SZEDER Gábor Signed-off-by: Junio C Hamano

bisect: clear flags in passed repository

2020-10-31T17:46:34Z

69d2cfe6e8 (bisect.c: remove the_repository reference, 2018-11-10) kept the implicit the_repository reference in clear_commit_marks_all, which was made explicit by the previous commit (and which also renamed it to repo_clear_commit_marks). Replace it as well. Signed-off-by: René Scharfe Signed-off-by: Junio C Hamano