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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).