git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Glen Choo <chooglen@google.com>
To: Josh Steadmon <steadmon@google.com>
Cc: git@vger.kernel.org, gitster@pobox.com, avarab@gmail.com,
	Johannes.Schindelin@gmx.de
Subject: Re: [PATCH v6 1/3] branch: accept multiple upstream branches for tracking
Date: Mon, 20 Dec 2021 10:29:08 -0800	[thread overview]
Message-ID: <kl6lzgovyvt7.fsf@chooglen-macbookpro.roam.corp.google.com> (raw)
In-Reply-To: <Ybwb4UkQwAVRcJp5@google.com>

Josh Steadmon <steadmon@google.com> writes:

>> > @@ -87,29 +112,42 @@ int install_branch_config(int flag, const char *local, const char *origin, const
>> >  	strbuf_release(&key);
>> >  
>> >  	if (flag & BRANCH_CONFIG_VERBOSE) {
>> > -		if (shortname) {
>> > +		const char *name;
>> > +		struct strbuf ref_string = STRBUF_INIT;
>> > +
>> > +		for_each_string_list_item(item, remotes) {
>> > +			name = item->string;
>> > +			skip_prefix(name, "refs/heads/", &name);
>> > +			strbuf_addf(&ref_string, "  %s\n", name);
>> > +		}
>> > +
>> > +		if (remotes->nr == 1) {
>> > +			struct strbuf refname = STRBUF_INIT;
>> > +
>> >  			if (origin)
>> > -				printf_ln(rebasing ?
>> > -					  _("Branch '%s' set up to track remote branch '%s' from '%s' by rebasing.") :
>> > -					  _("Branch '%s' set up to track remote branch '%s' from '%s'."),
>> > -					  local, shortname, origin);
>> > -			else
>> > -				printf_ln(rebasing ?
>> > -					  _("Branch '%s' set up to track local branch '%s' by rebasing.") :
>> > -					  _("Branch '%s' set up to track local branch '%s'."),
>> > -					  local, shortname);
>> > +				strbuf_addf(&refname, "%s/", origin);
>> > +			strbuf_addstr(&refname, remotes->items[0].string);
>> > +
>> > +			/*
>> > +			 * Rebasing is only allowed in the case of a single
>> > +			 * upstream branch.
>> > +			 */
>> > +			printf_ln(rebasing ?
>> > +				_("branch '%s' set up to track '%s' by rebasing.") :
>> > +				_("branch '%s' set up to track '%s'."),
>> > +				local, refname.buf);
>> > +
>> > +			strbuf_release(&refname);
>> > +		} else if (origin) {
>> > +			printf_ln(_("branch '%s' set up to track from '%s':"),
>> > +				local, origin);
>> > +			printf("%s", ref_string.buf);
>> 
>> It's not clear to me why the hint contains the word 'from' when it is a
>> remote ref...
>
> Because in the multiple-branch case, we don't prepend the origin to each
> ref, so we need to let users know which remote the refs are coming from.

I see. So if I'm reading this correctly, the error message in the remote
case would read something like:

  branch 'main' set up to track from 'origin':
    main
    topic1
    topic2

Is there any reason why we couldn't append the origin to the ref to make
it consistent? I think this could be as simple as:


	for_each_string_list_item(item, remotes) {
		name = item->string;
		skip_prefix(name, "refs/heads/", &name);
			if (origin)
+         strbuf_addf(&ref_string, "%s/", origin);
		strbuf_addf(&ref_string, "  %s\n", name);
	}

and the resulting list could look like:

  branch 'main' set up to track from 'origin':
    origin/main
    origin/topic1
    origin/topic2

This looks repetitive, but I suggest this because, as I understand it,
we are omitting the "{local,remote} ref" phrase based on conventions
around ref names, like "origin/main" is probably a remote ref and not an
oddly named local ref. However, when we print the list like so,

  branch 'main' set up to track from 'origin':
    main
    topic1
    topic2

we now expect the user to understand that 'main', 'topic1' and 'topic2'
to implicitly have 'origin/' prepended to them. This behavior seems
inconsistent to me; I'd anticipate most users responding "Wait, I was
supposed to be tracking 'origin' branches right? Why am I looking at
local branches?". Some users would be able to recover because they can
figure out what we mean, but others might just give up.

Prepending 'origin/' would get rid of this problem altogether, and it
would let us drop the 'from'.

>> >  		} else {
>> > -			if (origin)
>> > -				printf_ln(rebasing ?
>> > -					  _("Branch '%s' set up to track remote ref '%s' by rebasing.") :
>> > -					  _("Branch '%s' set up to track remote ref '%s'."),
>> > -					  local, remote);
>> > -			else
>> > -				printf_ln(rebasing ?
>> > -					  _("Branch '%s' set up to track local ref '%s' by rebasing.") :
>> > -					  _("Branch '%s' set up to track local ref '%s'."),
>> > -					  local, remote);
>> > +			printf_ln(_("branch '%s' set up to track:"), local);
>> > +			printf("%s", ref_string.buf);
>> 
>> but does not have the word 'from' when it is a local ref. As far as I
>> can tell, this is the only difference between remote and local refs, and
>> adding the word 'from' does not seem like a good enough reason to add an
>> 'if' condition. Maybe I missed something here?
>> 
>> This motivates my answer to the question you asked in [1]:
>> 
>>   I removed as many distinctions as possible, as most can still be
>>   inferred from context. [...] Likewise, we don't need to specify whether
>>   refs are remote or local: "some-remote/some-branch" vs.
>>   "a-local-branch" should be understandable without us spelling it out.
>> 
>> I agree that there is adequate context, so I would be ok with the
>> simplification if there was corresponding code simplification e.g.
>> dropping "if (origin)". But in its current form, I don't think there is
>> good enough reason to simplify the message.
>
> I think the proper point of comparison is not the original code, but the
> code from V5 where we try to preserve the same level of detail in output
> as the original code. If we are committed to both having multiple
> remotes and keeping similar styles of output as the original
> implementation, then something like the massive conditional in V5 is
> unavoidable.

I see. So for instance, post-simplification you have:

  printf_ln(rebasing ?
    _("branch '%s' set up to track '%s' by rebasing.") :
    _("branch '%s' set up to track '%s'."),
    local, refname.buf);

if you preserve the same amount of detail as before, you'd have to
distinguish between local/remote, which doubles the number of cases to
4, which is why the conditional v5 is so complicated.

That said, I think that it's already much simpler than v5 because you've
split the singular and plural cases. I wonder if you have considered
building the final string purely from format strings, like:

  char *message_format = _("branch %s set up to track %s%s%s%s");
  char *ref_type_clause = origin ? " remote ref " : " local ref ";
  char *rebasing_clause = rebasing ? " by rebasing." : ".";
  char *branch_names = "<branch names>";
  printf_ln(message_format, local, ref_type_clause, branch_names, rebasing_clause);

This sounds potentially unfriendly to i18n, but it would make the
conditional simpler. What do you think?

  reply	other threads:[~2021-12-20 18:29 UTC|newest]

Thread overview: 103+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-08 20:15 [RFC PATCH] branch: add "inherit" option for branch.autoSetupMerge Josh Steadmon
2021-09-08 20:44 ` Josh Steadmon
2021-09-11  0:25 ` [PATCH v2] " Josh Steadmon
2021-09-11  0:52   ` Junio C Hamano
2021-10-17  4:35     ` Josh Steadmon
2021-10-17  5:50       ` Junio C Hamano
2021-11-15 21:57         ` Josh Steadmon
2021-10-17  4:45 ` [PATCH v3] branch: add flags and config to inherit tracking Josh Steadmon
2021-10-18 18:31   ` Ævar Arnfjörð Bjarmason
2021-10-18 21:44     ` Junio C Hamano
2021-10-18 22:11       ` Ævar Arnfjörð Bjarmason
2021-11-15 22:22     ` Josh Steadmon
2021-10-18 17:50 ` [RFC PATCH] branch: add "inherit" option for branch.autoSetupMerge Glen Choo
2021-10-18 18:08   ` Glen Choo
2021-11-15 21:44   ` Josh Steadmon
2021-11-16 18:25 ` [PATCH v4] branch: add flags and config to inherit tracking Josh Steadmon
2021-11-17  0:33   ` Glen Choo
2021-11-18 22:29   ` Junio C Hamano
2021-11-30 22:05     ` Josh Steadmon
2021-11-19  6:47   ` Ævar Arnfjörð Bjarmason
2021-11-30 21:34     ` Josh Steadmon
2021-12-01  9:11       ` Ævar Arnfjörð Bjarmason
2021-12-07  7:12 ` [PATCH v5 0/2] branch: inherit tracking configs Josh Steadmon
2021-12-07  7:12   ` [PATCH v5 1/2] branch: accept multiple upstream branches for tracking Josh Steadmon
2021-12-07  8:57     ` Ævar Arnfjörð Bjarmason
2021-12-09 23:03       ` Josh Steadmon
2021-12-10  1:00         ` Ævar Arnfjörð Bjarmason
2021-12-07 19:28     ` Junio C Hamano
2021-12-14 20:35       ` Josh Steadmon
2021-12-08  0:16     ` Glen Choo
2021-12-08  0:17     ` Glen Choo
2021-12-09 22:45       ` Josh Steadmon
2021-12-09 23:47         ` Glen Choo
2021-12-10  1:03           ` Ævar Arnfjörð Bjarmason
2021-12-10 17:32             ` Glen Choo
2021-12-11  2:18               ` Ævar Arnfjörð Bjarmason
2021-12-08 23:53     ` Glen Choo
2021-12-09  0:08       ` Glen Choo
2021-12-09 22:49         ` Josh Steadmon
2021-12-09 23:43           ` Glen Choo
2021-12-07  7:12   ` [PATCH v5 2/2] branch: add flags and config to inherit tracking Josh Steadmon
2021-12-07  9:08     ` Ævar Arnfjörð Bjarmason
2021-12-08  0:35       ` Glen Choo
2021-12-14 22:15         ` Josh Steadmon
2021-12-14 22:27       ` Josh Steadmon
2021-12-07 19:41     ` Junio C Hamano
2021-12-14 20:37       ` Josh Steadmon
2021-12-08  1:02     ` Glen Choo
2021-12-14 22:10       ` Josh Steadmon
2021-12-07 18:52   ` [PATCH v5 0/2] branch: inherit tracking configs Junio C Hamano
2021-12-08 17:06     ` Glen Choo
2021-12-10 22:48     ` Johannes Schindelin
2021-12-14 22:11       ` Josh Steadmon
2021-12-14 23:44 ` [PATCH v6 0/3] " Josh Steadmon
2021-12-14 23:44   ` [PATCH v6 1/3] branch: accept multiple upstream branches for tracking Josh Steadmon
2021-12-15 21:30     ` Junio C Hamano
2021-12-16 19:57     ` Glen Choo
2021-12-17  5:10       ` Josh Steadmon
2021-12-20 18:29         ` Glen Choo [this message]
2021-12-21  3:27           ` Josh Steadmon
2021-12-14 23:44   ` [PATCH v6 2/3] branch: add flags and config to inherit tracking Josh Steadmon
2021-12-16 21:27     ` Glen Choo
2021-12-17  5:11       ` Josh Steadmon
2021-12-14 23:44   ` [PATCH v6 3/3] config: require lowercase for branch.autosetupmerge Josh Steadmon
2021-12-15  0:43   ` [PATCH v6 0/3] branch: inherit tracking configs Josh Steadmon
2021-12-16  0:02   ` Junio C Hamano
2021-12-16  0:37     ` Glen Choo
2021-12-16  1:20       ` Junio C Hamano
2021-12-17  5:12 ` [PATCH v7 " Josh Steadmon
2021-12-17  5:12   ` [PATCH v7 1/3] branch: accept multiple upstream branches for tracking Josh Steadmon
2021-12-17  5:12   ` [PATCH v7 2/3] branch: add flags and config to inherit tracking Josh Steadmon
2021-12-17  5:12   ` [PATCH v7 3/3] config: require lowercase for branch.*.autosetupmerge Josh Steadmon
2021-12-20 21:05   ` [PATCH v7 0/3] branch: inherit tracking configs Glen Choo
2021-12-21  3:30 ` [PATCH v8 " Josh Steadmon
2021-12-21  3:30   ` [PATCH v8 1/3] branch: accept multiple upstream branches for tracking Josh Steadmon
2021-12-21  6:55     ` Junio C Hamano
2021-12-21 18:25       ` Glen Choo
2021-12-21  3:30   ` [PATCH v8 2/3] branch: add flags and config to inherit tracking Josh Steadmon
2021-12-21 18:17     ` Glen Choo
2022-01-11  1:57     ` incorrect 'git (checkout|branch) -h' output with new --track modes (was: [PATCH v8 2/3] branch: add flags and config to inherit tracking) Ævar Arnfjörð Bjarmason
2022-01-18 20:49       ` [PATCH] branch,checkout: fix --track usage strings Josh Steadmon
2022-01-18 22:26         ` Junio C Hamano
2022-01-19 10:56           ` [PATCH] parse-options: document automatic PARSE_OPT_LITERAL_ARGHELP René Scharfe
2022-01-19 14:41             ` Ævar Arnfjörð Bjarmason
     [not found]             ` <CA++g3E-azP3wFTtNkbFdmT7VW3hvULL0WkkAdwfrMb6HDtcXdg@mail.gmail.com>
2022-01-19 15:30               ` René Scharfe
2022-01-19 18:16             ` Junio C Hamano
2022-01-20 10:30               ` René Scharfe
2022-01-20 18:25                 ` Junio C Hamano
2022-01-21  9:42                   ` René Scharfe
2022-01-21 20:59                     ` Junio C Hamano
2022-01-20 12:05         ` [PATCH] branch,checkout: fix --track usage strings Ævar Arnfjörð Bjarmason
2022-01-20 12:18           ` Andreas Schwab
2022-01-20 14:00             ` Ævar Arnfjörð Bjarmason
2022-01-20 18:38           ` Junio C Hamano
2022-01-21 11:27             ` Ævar Arnfjörð Bjarmason
2022-01-21 21:12               ` Junio C Hamano
2022-01-19 10:20       ` incorrect 'git (checkout|branch) -h' output with new --track modes (was: [PATCH v8 2/3] branch: add flags and config to inherit tracking) René Scharfe
2022-01-20 12:00         ` Ævar Arnfjörð Bjarmason
2022-01-20 12:35           ` [PATCH] branch,checkout: fix --track documentation René Scharfe
2022-01-20 13:57             ` Ævar Arnfjörð Bjarmason
2022-01-20 19:08             ` Junio C Hamano
2021-12-21  3:30   ` [PATCH v8 3/3] config: require lowercase for branch.*.autosetupmerge Josh Steadmon
2021-12-21 18:13   ` [PATCH v8 0/3] branch: inherit tracking configs Glen Choo

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=kl6lzgovyvt7.fsf@chooglen-macbookpro.roam.corp.google.com \
    --to=chooglen@google.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=steadmon@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).