git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Glen Choo <chooglen@google.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"Glen Choo via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Jonathan Tan <jonathantanmy@google.com>
Subject: Re: [PATCH 3/4] branch --set-upstream-to: be consistent when advising
Date: Thu, 31 Mar 2022 09:52:38 -0700	[thread overview]
Message-ID: <kl6l1qyit67d.fsf@chooglen-macbookpro.roam.corp.google.com> (raw)
In-Reply-To: <220331.867d8bt6i6.gmgdl@evledraar.gmail.com>

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> On Tue, Mar 29 2022, Glen Choo via GitGitGadget wrote:
>
>> From: Glen Choo <chooglen@google.com>
>>
>> "git branch --set-upstream-to" behaves differently when advice is
>> enabled/disabled:
>>
>> |                 | error prefix | exit code |
>> |-----------------+--------------+-----------|
>> | advice enabled  | error:       |         1 |
>> | advice disabled | fatal:       |       128 |
>>
>> Make both cases consistent by using die_message() when advice is
>> enabled (this was first proposed in [1]).
>>
>> [1] https://lore.kernel.org/git/211210.86ee6ldwlc.gmgdl@evledraar.gmail.com
>
> Thanks for following up on this :)

:)

>> Signed-off-by: Glen Choo <chooglen@google.com>
>> ---
>>  branch.c | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/branch.c b/branch.c
>> index 133e6047bc6..4a8796489c7 100644
>> --- a/branch.c
>> +++ b/branch.c
>> @@ -389,9 +389,10 @@ static void dwim_branch_start(struct repository *r, const char *start_name,
>>  	if (get_oid_mb(start_name, &oid)) {
>>  		if (explicit_tracking) {
>>  			if (advice_enabled(ADVICE_SET_UPSTREAM_FAILURE)) {
>> -				error(_(upstream_missing), start_name);
>> +				int code = die_message(_(upstream_missing),
>> +						       start_name);
>>  				advise(_(upstream_advice));
>> -				exit(1);
>> +				exit(code);
>>  			}
>>  			die(_(upstream_missing), start_name);
>>  		}
>
> This is really close to being much better, i.e. we can now just do this
> (this is on top of your branch):
> 	
> 	diff --git a/branch.c b/branch.c
> 	index eb231b950bb..5b648cb27ed 100644
> 	--- a/branch.c
> 	+++ b/branch.c
> 	@@ -342,8 +342,6 @@ static int validate_remote_tracking_branch(char *ref)
> 	 
> 	 static const char upstream_not_branch[] =
> 	 N_("cannot set up tracking information; starting point '%s' is not a branch");
> 	-static const char upstream_missing[] =
> 	-N_("the requested upstream branch '%s' does not exist");
> 	 static const char upstream_advice[] =
> 	 N_("\n"
> 	 "If you are planning on basing your work on an upstream\n"
> 	@@ -388,13 +386,11 @@ static void dwim_branch_start(struct repository *r, const char *start_name,
> 	 	real_ref = NULL;
> 	 	if (get_oid_mb(start_name, &oid)) {
> 	 		if (explicit_tracking) {
> 	-			if (advice_enabled(ADVICE_SET_UPSTREAM_FAILURE)) {
> 	-				int code = die_message(_(upstream_missing),
> 	-						       start_name);
> 	-				advise(_(upstream_advice));
> 	-				exit(code);
> 	-			}
> 	-			die(_(upstream_missing), start_name);
> 	+			int code = die_message(_("the requested upstream branch '%s' does not exist"),
> 	+					       start_name);
> 	+			advise_if_enabled(ADVICE_SET_UPSTREAM_FAILURE,
> 	+					  _(upstream_advice));
> 	+			exit(code);
> 	 		}
> 	 		die(_("not a valid object name: '%s'"), start_name);
> 	 	}
> 	
> I.e. the only reason we needed to mention upstream_missing multiple
> times is because we didn't have something like die_message() before, now
> we can just skip that other "die" entirely.

Oh, good point. Yeah I like this better, I'll do that.

> The advise_if_enabled() might be worthwhile to change while at it, maybe
> not.

I think it's worthwhile; this does exactly what we want. I would have
used it if I had known it existed.

>
> But also useful, is that we can now simply inline the "upstream_missing"
> string, which will give us type checks for the printf format. The reason
> we had a variable before was also because of the lack of die_message()>
>
> I notice that we can do likewise with the advice itself, and with
> "upstream_not_branch" if we either make that a "goto", or add a trivial
> helper function.

Interesting, I hadn't considered type checking. So in general we prefer
to inline the strings and not use variables? I'll keep that in mind.

  reply	other threads:[~2022-03-31 16:52 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-29 20:01 [PATCH 0/4] branch --recurse-submodules: Bug fixes and clean ups Glen Choo via GitGitGadget
2022-03-29 20:01 ` [PATCH 1/4] branch: support more tracking modes when recursing Glen Choo via GitGitGadget
2022-03-30 21:13   ` Junio C Hamano
2022-03-30 23:29     ` Glen Choo
2022-03-29 20:01 ` [PATCH 2/4] branch: give submodule updating advice before exit Glen Choo via GitGitGadget
2022-03-30 21:15   ` Junio C Hamano
2022-03-29 20:01 ` [PATCH 3/4] branch --set-upstream-to: be consistent when advising Glen Choo via GitGitGadget
2022-03-30 22:28   ` Ævar Arnfjörð Bjarmason
2022-03-31 16:52     ` Glen Choo [this message]
2022-03-29 20:01 ` [PATCH 4/4] branch: remove negative exit code Glen Choo via GitGitGadget
2022-03-31 18:49 ` [PATCH v2 0/4] branch --recurse-submodules: Bug fixes and clean ups Glen Choo via GitGitGadget
2022-03-31 18:49   ` [PATCH v2 1/4] branch: support more tracking modes when recursing Glen Choo via GitGitGadget
2022-03-31 18:49   ` [PATCH v2 2/4] branch: give submodule updating advice before exit Glen Choo via GitGitGadget
2022-03-31 18:50   ` [PATCH v2 3/4] branch --set-upstream-to: be consistent when advising Glen Choo via GitGitGadget
2022-03-31 18:50   ` [PATCH v2 4/4] branch: remove negative exit code Glen Choo via GitGitGadget
2022-03-31 22:39   ` [PATCH v2 0/4] branch --recurse-submodules: Bug fixes and clean ups Junio C Hamano
2022-03-31 22:41     ` [PATCH 1/2] branch: rework comments for future developers Junio C Hamano
2022-03-31 22:41       ` [PATCH 2/2] branch.c: simplify advice-and-die sequence Junio C Hamano
2022-04-01 10:03         ` Ævar Arnfjörð Bjarmason
2022-04-01 16:59     ` [PATCH v2 0/4] branch --recurse-submodules: Bug fixes and clean ups Glen Choo
2022-04-01 20:14       ` Junio C Hamano

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=kl6l1qyit67d.fsf@chooglen-macbookpro.roam.corp.google.com \
    --to=chooglen@google.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=jonathantanmy@google.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).