| Message ID | 20200120143800.900-11-mirucam@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Finish converting git bisect to C part 1 | expand |
Hi Miriam, On Mon, 20 Jan 2020, Miriam Rubio wrote: > From: Pranit Bauva <pranit.bauva@gmail.com> > > Since we want to get rid of git-bisect.sh it would be necessary to > convert those exit() calls to return statements so that errors can be > reported. > > Emulate try catch in C by converting `exit(<positive-value>)` to > `return <negative-value>`. Follow POSIX conventions to return > <negative-value> to indicate error. > > Turn `exit()` to `return` calls in `handle_bad_merge_base()`. > > Handle the return value in dependent function check_merge_bases(). This is again a lot of essentially repeated text from earlier commit messages, but the most pressing question is not addressed... > > Mentored-by: Christian Couder <chriscool@tuxfamily.org> > Mentored-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> > Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com> > Signed-off-by: Tanushree Tumane <tanushreetumane@gmail.com> > Signed-off-by: Miriam Rubio <mirucam@gmail.com> > --- > bisect.c | 9 +++++---- > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/bisect.c b/bisect.c > index 2b80597a1d..acb5a13911 100644 > --- a/bisect.c > +++ b/bisect.c > @@ -756,7 +756,7 @@ static struct commit **get_bad_and_good_commits(struct repository *r, > return rev; > } > > -static void handle_bad_merge_base(void) > +static int handle_bad_merge_base(void) > { > if (is_expected_rev(current_bad_oid)) { > char *bad_hex = oid_to_hex(current_bad_oid); > @@ -777,14 +777,14 @@ static void handle_bad_merge_base(void) > "between %s and [%s].\n"), > bad_hex, term_bad, term_good, bad_hex, good_hex); > } > - exit(3); > + return -3; ... which is: what does `3` stand for? Thanks, Johannes > } > > fprintf(stderr, _("Some %s revs are not ancestors of the %s rev.\n" > "git bisect cannot work properly in this case.\n" > "Maybe you mistook %s and %s revs?\n"), > term_good, term_bad, term_good, term_bad); > - exit(1); > + return -1; > } > > static void handle_skipped_merge_base(const struct object_id *mb) > @@ -823,7 +823,8 @@ static int check_merge_bases(int rev_nr, struct commit **rev, int no_checkout) > for (; result; result = result->next) { > const struct object_id *mb = &result->item->object.oid; > if (oideq(mb, current_bad_oid)) { > - handle_bad_merge_base(); > + res = handle_bad_merge_base(); > + break; > } else if (0 <= oid_array_lookup(&good_revs, mb)) { > continue; > } else if (0 <= oid_array_lookup(&skipped_revs, mb)) { > -- > 2.21.1 (Apple Git-122.3) > >
On Mon, Jan 20, 2020 at 11:23 PM Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote: > On Mon, 20 Jan 2020, Miriam Rubio wrote: > > @@ -777,14 +777,14 @@ static void handle_bad_merge_base(void) > > "between %s and [%s].\n"), > > bad_hex, term_bad, term_good, bad_hex, good_hex); > > } > > - exit(3); > > + return -3; > > ... which is: what does `3` stand for? Maybe the question should have been answered by adding a comment to the previous patch that added the `exit(3)` statement. So yeah we could here add a separate patch that just adds such a comment. Or maybe we can add such a comment in this patch and say something like "while at it let's explain a bit the '3' error code" in the commit message.
Hi, El mar., 21 ene. 2020 a las 8:05, Christian Couder (<christian.couder@gmail.com>) escribió: > > On Mon, Jan 20, 2020 at 11:23 PM Johannes Schindelin > <Johannes.Schindelin@gmx.de> wrote: > > > On Mon, 20 Jan 2020, Miriam Rubio wrote: > > > > @@ -777,14 +777,14 @@ static void handle_bad_merge_base(void) > > > "between %s and [%s].\n"), > > > bad_hex, term_bad, term_good, bad_hex, good_hex); > > > } > > > - exit(3); > > > + return -3; > > > > ... which is: what does `3` stand for? > > Maybe the question should have been answered by adding a comment to > the previous patch that added the `exit(3)` statement. > > So yeah we could here add a separate patch that just adds such a comment. > > Or maybe we can add such a comment in this patch and say something > like "while at it let's explain a bit the '3' error code" in the > commit message. I like most your first option because we explain the code in the patch where it is added, but the second one is also ok for me :). Thanks. Best, Miriam
diff --git a/bisect.c b/bisect.c index 2b80597a1d..acb5a13911 100644 --- a/bisect.c +++ b/bisect.c @@ -756,7 +756,7 @@ static struct commit **get_bad_and_good_commits(struct repository *r, return rev; } -static void handle_bad_merge_base(void) +static int handle_bad_merge_base(void) { if (is_expected_rev(current_bad_oid)) { char *bad_hex = oid_to_hex(current_bad_oid); @@ -777,14 +777,14 @@ static void handle_bad_merge_base(void) "between %s and [%s].\n"), bad_hex, term_bad, term_good, bad_hex, good_hex); } - exit(3); + return -3; } fprintf(stderr, _("Some %s revs are not ancestors of the %s rev.\n" "git bisect cannot work properly in this case.\n" "Maybe you mistook %s and %s revs?\n"), term_good, term_bad, term_good, term_bad); - exit(1); + return -1; } static void handle_skipped_merge_base(const struct object_id *mb) @@ -823,7 +823,8 @@ static int check_merge_bases(int rev_nr, struct commit **rev, int no_checkout) for (; result; result = result->next) { const struct object_id *mb = &result->item->object.oid; if (oideq(mb, current_bad_oid)) { - handle_bad_merge_base(); + res = handle_bad_merge_base(); + break; } else if (0 <= oid_array_lookup(&good_revs, mb)) { continue; } else if (0 <= oid_array_lookup(&skipped_revs, mb)) {