git/bisect.c, branch v2.37.2

revisions API users: use release_revisions() needing REV_INFO_INIT

2022-04-14T06:56:08Z

Use release_revisions() to various users of "struct rev_list" which need to have their "struct rev_info" zero-initialized before we can start using it. For the bundle.c code see the early exit case added in 3bbbe467f29 (bundle verify: error out if called without an object database, 2019-05-27). For the relevant bisect.c code see 45b6370812c (bisect: libify `check_good_are_ancestors_of_bad` and its dependents, 2020-02-17). For the submodule.c code see the "goto" on "(!left || !right || !sub)" added in 8e6df65015f (submodule: refactor show_submodule_summary with helper function, 2016-08-31). Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

revisions API users: add straightforward release_revisions()

2022-04-14T06:56:08Z

Add a release_revisions() to various users of "struct rev_list" in those straightforward cases where we only need to add the release_revisions() call to the end of a block, and don't need to e.g. refactor anything to use a "goto cleanup" pattern. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

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