git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Josh Steadmon <steadmon@google.com>
Cc: git@vger.kernel.org, chooglen@google.com,
	emilyshaffer@google.com, avarab@gmail.com
Subject: Re: [PATCH v5 1/2] branch: accept multiple upstream branches for tracking
Date: Tue, 07 Dec 2021 11:28:00 -0800	[thread overview]
Message-ID: <xmqqk0gg6wqn.fsf@gitster.g> (raw)
In-Reply-To: <ba7d557725e70f2ae8f10ae5992c8168eb97f2fc.1638859949.git.steadmon@google.com> (Josh Steadmon's message of "Mon, 6 Dec 2021 23:12:07 -0800")

Josh Steadmon <steadmon@google.com> writes:

> +static int install_branch_config_multiple_remotes(int flag, const char *local, const char *origin,
> +		struct string_list *remotes)

The line got overly long so perhaps cut the line after "*local,",
as "origin" and "remotes" conceptually are closer together.

What is in the string list?  Names of refs at the remote "origin",
instead of a single ref there?

>  {
>  	const char *shortname = NULL;
>  	struct strbuf key = STRBUF_INIT;
> -	int rebasing = should_setup_rebase(origin);
> -
> -	if (skip_prefix(remote, "refs/heads/", &shortname)
> -	    && !strcmp(local, shortname)
> -	    && !origin) {
> -		warning(_("Not setting branch %s as its own upstream."),
> -			local);

When 'origin' is NULL in the original caller, it means a local
tracking, and making sure we do not say "my 'master' branch builds
on top of itself" makes sense.

> -		return 0;
> -	}
> +	int i, rebasing = should_setup_rebase(origin);
> +
> +	if (remotes->nr < 1)
> +		BUG("must provide at least one remote for branch config");
> +
> +	if (!origin)
> +		for (i = 0; i < remotes->nr; i++)
> +			if (skip_prefix(remotes->items[i].string, "refs/heads/", &shortname)
> +			    && !strcmp(local, shortname)) {
> +				warning(_("Not setting branch %s as its own upstream."),
> +					local);
> +				return 0;

I am a bit surprised with this warning and early return before
inspecting the remainder of the list.  When 'origin' is NULL,
i.e. we are talking about the local building on top of another local
branch, if the function is called for the local branch 'main' with
'main' in the remotes list alone, we do want to issue the warning
and exit without doing anything (i.e. degenerating to the original
behaviour of taking a single string variable, when a string list
with a single element is given).  But if the remotes list has 'main'
and 'master', would we want to just "skip" the same one, but still
handle the other ones as if the "same" branch were not in the list?

> @@ -75,8 +80,17 @@ int install_branch_config(int flag, const char *local, const char *origin, const
>  
>  	strbuf_reset(&key);
>  	strbuf_addf(&key, "branch.%s.merge", local);
> -	if (git_config_set_gently(key.buf, remote) < 0)
> +	/*
> +	 * We want to overwrite any existing config with all the branches in
> +	 * "remotes". Override any existing config with the first branch, but if
> +	 * more than one is provided, use CONFIG_REGEX_NONE to preserve what
> +	 * we've written so far.
> +	 */
> +	if (git_config_set_gently(key.buf, remotes->items[0].string) < 0)
>  		goto out_err;
> +	for (i = 1; i < remotes->nr; i++)
> +		if (git_config_set_multivar_gently(key.buf, remotes->items[i].string, CONFIG_REGEX_NONE, 0) < 0)
> +			goto out_err;
>  
>  	if (rebasing) {
>  		strbuf_reset(&key);
> @@ -87,29 +101,62 @@ int install_branch_config(int flag, const char *local, const char *origin, const
>  	strbuf_release(&key);
>  
>  	if (flag & BRANCH_CONFIG_VERBOSE) {
> -		if (shortname) {
> -			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);
> +		int plural = remotes->nr > 1;
> +		int all_shortnames = 1;
> +		const char *msg_fmt;
> +		struct strbuf ref_string = STRBUF_INIT;
> +
> +		for (i = 0; i < remotes->nr; i++)
> +			if (skip_prefix(remotes->items[i].string, "refs/heads/", &shortname)) {
> +				strbuf_addf(&ref_string, "'%s', ", shortname);
> +			} else {
> +				all_shortnames = 0;
> +				strbuf_addf(&ref_string, "'%s', ", remotes->items[i].string);

So, all_shortnames == true means everything was a local branch in
the 'origin' remote, and when it has a non-branch (like a tag),
all_shortnames becomes false?

> +			}
> +		/* The last two characters are an extraneous ", ", so trim those. */
> +		strbuf_setlen(&ref_string, ref_string.len - 2);

As you are starting from an empty ref_string, a more idiomatic way
to build concatenated string would be to prefix when you add a new
item, e.g.

	loop {
		if (ref_string already has items)
			ref_string.append(", ");
		ref_string.append(this_item);
	}

> +		if (all_shortnames && origin) {
> +			if (rebasing && plural)
> +				msg_fmt = "Branch '%s' set up to track remote branches %s from '%s' by rebasing.";

What does it mean to keep my 'topic' branch up-to-date by rebasing
on top of more than one remote sources?  By merging, I can sort-of
understand (i.e. creating an octopus), but would it make sense to
track more than one remote sources in general?  Is it common?

When the benefit is not clear, it might make more sense not to do
this when there are already multiple tracking sources defined for
the original; it might be a mistake that we may not want to spread
with the new option.

Of course, it is very possible that I am missing a perfectly valid
use case where having more than one makes good sense.  If so, please
do not take the above comments as an objection, but adding some
comments before the function to explain when having remote list with
more than one items makes sense and how such a setting can be used
to avoid future readers asking the same (stupid) question as I just
did.


> +			else if (rebasing && !plural)
> +				msg_fmt = "Branch '%s' set up to track remote branch %s from '%s' by rebasing.";
> +			else if (!rebasing && plural)
> +				msg_fmt = "Branch '%s' set up to track remote branches %s from '%s'.";
> +			else if (!rebasing && !plural)
> +				msg_fmt = "Branch '%s' set up to track remote branch %s from '%s'.";
> +
> +			printf_ln(_(msg_fmt), local, ref_string, origin);

I am not sure how well the "plural" thing works with i18n.  It may
suffice for the original in English to have only two choices between
one or more-than-one, but not all languages are English.  Counting
the actual number (I guess remotes->nr is it) and using Q_() to
choose between the possible variants.  I think Ævar knows about this
much better than I do.

But if we are not doing this "set multiple" and instead go the
"detect existing multiple and refrain from spreading the damage"
route, all of that is moot.

Thanks.

  parent reply	other threads:[~2021-12-07 19:28 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 [this message]
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
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=xmqqk0gg6wqn.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=avarab@gmail.com \
    --cc=chooglen@google.com \
    --cc=emilyshaffer@google.com \
    --cc=git@vger.kernel.org \
    --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).