From: Junio C Hamano <gitster@pobox.com>
To: "Rubén Justo" <rjusto@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v2 1/2] branch: refactor "edit_description" code path
Date: Wed, 07 Sep 2022 13:25:59 -0700 [thread overview]
Message-ID: <xmqq7d2fszhk.fsf@gitster.g> (raw)
In-Reply-To: <d2624238-048c-ac5b-1d45-e08051202c79@gmail.com> ("Rubén Justo"'s message of "Wed, 7 Sep 2022 11:52:26 +0200")
Rubén Justo <rjusto@gmail.com> writes:
> Minor refactoring to reduce the number of returns in the switch case
> handling the "edit_description" option, so the calls to strbuf_release
> can also be reduced. New resources to be added also do not need to be
> released in multiple places.
>
> Signed-off-by: Rubén Justo <rjusto@gmail.com>
> ---
> builtin/branch.c | 17 ++++++++---------
> 1 file changed, 8 insertions(+), 9 deletions(-)
>
> diff --git a/builtin/branch.c b/builtin/branch.c
> index 55cd9a6e99..5229cb796f 100644
> --- a/builtin/branch.c
> +++ b/builtin/branch.c
> @@ -614,7 +614,7 @@ static int edit_branch_description(const char *branch_name)
> strbuf_reset(&buf);
> if (launch_editor(edit_description(), &buf, NULL)) {
> strbuf_release(&buf);
> - return -1;
> + return 1;
> }
> strbuf_stripspace(&buf, 1);
Our API convention is to signal a failure with negative return
value. Granted that this is not a general API but is merely a
helper function in the implementation of a single command, it would
be less confusing if you sticked to the convention.
Unless there is a compelling reason not to, that is.
> @@ -791,6 +791,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
> } else if (edit_description) {
> const char *branch_name;
> struct strbuf branch_ref = STRBUF_INIT;
> + int ret = 0;
>
> if (!argc) {
> if (filter.detached)
> @@ -803,19 +804,17 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
>
> strbuf_addf(&branch_ref, "refs/heads/%s", branch_name);
> if (!ref_exists(branch_ref.buf)) {
> - strbuf_release(&branch_ref);
> -
> if (!argc)
> - return error(_("No commit on branch '%s' yet."),
> + ret = error(_("No commit on branch '%s' yet."),
> branch_name);
> else
> - return error(_("No branch named '%s'."),
> + ret = error(_("No branch named '%s'."),
> branch_name);
OK. These are good uses of a new variable 'ret'. Note that error()
returns negative one.
> - }
> - strbuf_release(&branch_ref);
> + } else
> + ret = edit_branch_description(branch_name);
>
> - if (edit_branch_description(branch_name))
> - return 1;
> + strbuf_release(&branch_ref);
> + return ret;
When editor failed, we leaked branch_ref strbuf, but we no longer
do.
Which is good.
This makes cmd_branch() return -1 (when we see error() call) or 1
(when edit_branch_description() fails and returns 1). I would
suggest to
* Fix the return value of edit_branch_description() so that it
signals a failure by returning -1
* cmd_branch() to return (or call exit() with) -ret, as ret has 0
when everything is peachy, and negative in any error code paths.
next prev parent reply other threads:[~2022-09-07 20:26 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-05 14:34 [PATCH 0/2] branch: support for at-refs like @{-1} in --edit-description, --set-upstream-to and --unset-upstream Rubén Justo via GitGitGadget
2022-09-05 14:34 ` [PATCH 1/2] branch: refactor edit_description command switch case Rubén Justo via GitGitGadget
2022-09-05 14:34 ` [PATCH 2/2] branch: support for at-refs like @{-1} Rubén Justo via GitGitGadget
2022-09-07 9:45 ` [PATCH v2 0/2] branch: support for shortcuts like @{-1}, completed Rubén Justo
2022-09-07 9:52 ` [PATCH v2 1/2] branch: refactor "edit_description" code path Rubén Justo
2022-09-07 20:25 ` Junio C Hamano [this message]
2022-09-07 21:24 ` Rubén Justo
2022-09-08 4:32 ` Rubén Justo
2022-09-07 9:53 ` [PATCH v2 2/2] branch: support for shortcuts like @{-1} completed Rubén Justo
2022-09-08 4:47 ` [PATCH v3 0/2] branch: support for shortcuts like @{-1}, completed Rubén Justo
2022-09-08 4:51 ` [PATCH v3 1/2] branch: refactor "edit_description" code path Rubén Justo
2022-09-08 20:57 ` [PATCH] branch: error codes for "edit_description" Rubén Justo
2022-09-08 21:45 ` Junio C Hamano
2022-09-08 4:53 ` [PATCH v3 2/2] branch: support for shortcuts like @{-1} completed Rubén Justo
2022-10-08 1:00 ` [PATCH v4] branch: support for shortcuts like @{-1}, completed Rubén Justo
2022-10-08 3:17 ` Eric Sunshine
2022-10-08 4:23 ` Junio C Hamano
2022-10-08 7:07 ` Rubén Justo
2022-10-08 7:23 ` Eric Sunshine
2022-10-08 9:12 ` Rubén Justo
2022-10-08 17:10 ` Eric Sunshine
2022-10-08 17:46 ` Junio C Hamano
2022-10-08 20:48 ` Rubén Justo
2022-10-08 23:28 ` Rubén Justo
2022-10-09 6:46 ` Eric Sunshine
2022-10-09 19:33 ` Junio C Hamano
2022-10-09 22:27 ` Rubén Justo
2022-10-08 4:17 ` Junio C Hamano
2022-10-08 9:04 ` Rubén Justo
2022-10-08 22:32 ` [PATCH v5] " Rubén Justo
2022-10-09 5:37 ` Junio C Hamano
2022-10-09 19:11 ` Junio C Hamano
2022-10-09 21:26 ` Rubén Justo
2022-10-10 0:38 ` Junio C Hamano
2022-10-10 6:05 ` Rubén Justo
2022-10-10 16:55 ` Junio C Hamano
2022-10-10 18:08 ` Rubén Justo
2022-10-10 23:24 ` [PATCH v6] " Rubén Justo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqq7d2fszhk.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=rjusto@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.