From: Josh Steadmon <steadmon@google.com>
To: Junio C Hamano <gitster@pobox.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, 14 Dec 2021 12:35:09 -0800 [thread overview]
Message-ID: <Ybj//dzRfvyuPZOv@google.com> (raw)
In-Reply-To: <xmqqk0gg6wqn.fsf@gitster.g>
On 2021.12.07 11:28, Junio C Hamano wrote:
> 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?
Added a comment explaining the purpose and arguments.
> > {
> > 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?
The inheritance case when creating a new branch is the only time we get
multiple branches, and I think it is a sign of a wider misconfiguration
if we have our own branch name listed as upstream in this case.
When inheriting, `local` should always be a new branch, and `remotes`
should contain the `branch.<name>.merge` entries of the branch we're
inheriting from. For this check to trigger would mean that the parent
branch has configured a local upstream branch that doesn't actually
exist. So it seems that something has gone wrong; perhaps we can assume
what the user wanted such as in your case above, but it seems to me that
it's safer to warn when this happens.
> > @@ -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);
> }
Ack, although changes to address other review feedback has made this
point moot.
> > + 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.
No, that's an oversight on my part. This will now exit with an error if
we try to rebase onto multiple branches.
> > + 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.
Thanks for the feedback!
next prev parent reply other threads:[~2021-12-14 20:35 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 [this message]
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=Ybj//dzRfvyuPZOv@google.com \
--to=steadmon@google.com \
--cc=avarab@gmail.com \
--cc=chooglen@google.com \
--cc=emilyshaffer@google.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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).