git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v5 1/2] branch: accept multiple upstream branches for tracking

From
Josh Steadmon <steadmon@google.com>
Date
Dec 14, 2021, 20:35 UTC
Message-ID
<Ybj//dzRfvyuPZOv@google.com>
In-Reply-To
<xmqqk0gg6wqn.fsf@gitster.g>
On 2021.12.07 11:28, Junio C Hamano wrote:
Show 10 quoted lines
> 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.
Show 40 quoted lines
> >  {
> >  	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.

Show 63 quoted lines
> > @@ -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.

Show 21 quoted lines
> > +		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.

Show 21 quoted lines
> > +			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!
Previous: Junio C HamanoNext: Glen Choo
Message 29 of 103 in “branch: add "inherit" option for branch.autoSetupMerge”
  1. branch: add "inherit" option for branch.autoSetupMergeJosh Steadmon, Sep 8, 2021
  2. Josh SteadmonSep 8, 2021
  3. branch: add "inherit" option for branch.autoSetupMergeJosh Steadmon, Sep 11, 2021
  4. Junio C HamanoSep 11, 2021
  5. Josh SteadmonOct 17, 2021
  6. Junio C HamanoOct 17, 2021
  7. Josh SteadmonNov 15, 2021
  8. branch: add flags and config to inherit trackingJosh Steadmon, Oct 17, 2021
  9. Ævar Arnfjörð BjarmasonOct 18, 2021
  10. Junio C HamanoOct 18, 2021
  11. Ævar Arnfjörð BjarmasonOct 18, 2021
  12. Josh SteadmonNov 15, 2021
  13. Glen ChooOct 18, 2021
  14. Glen ChooOct 18, 2021
  15. Josh SteadmonNov 15, 2021
  16. branch: add flags and config to inherit trackingJosh Steadmon, Nov 16, 2021
  17. Glen ChooNov 17, 2021
  18. Junio C HamanoNov 18, 2021
  19. Josh SteadmonNov 30, 2021
  20. Ævar Arnfjörð BjarmasonNov 19, 2021
  21. Josh SteadmonNov 30, 2021
  22. Ævar Arnfjörð BjarmasonDec 1, 2021
  23. 0/2 branch: inherit tracking configsJosh Steadmon, Dec 7, 2021
  24. 1/2 branch: accept multiple upstream branches for trackingJosh Steadmon, Dec 7, 2021
  25. Ævar Arnfjörð BjarmasonDec 7, 2021
  26. Josh SteadmonDec 9, 2021
  27. Ævar Arnfjörð BjarmasonDec 10, 2021
  28. Junio C HamanoDec 7, 2021
  29. Josh SteadmonDec 14, 2021
  30. Glen ChooDec 8, 2021
  31. Glen ChooDec 8, 2021
  32. Josh SteadmonDec 9, 2021
  33. Glen ChooDec 9, 2021
  34. Ævar Arnfjörð BjarmasonDec 10, 2021
  35. Glen ChooDec 10, 2021
  36. Ævar Arnfjörð BjarmasonDec 11, 2021
  37. Glen ChooDec 8, 2021
  38. Glen ChooDec 9, 2021
  39. Josh SteadmonDec 9, 2021
  40. Glen ChooDec 9, 2021
  41. 2/2 branch: add flags and config to inherit trackingJosh Steadmon, Dec 7, 2021
  42. Ævar Arnfjörð BjarmasonDec 7, 2021
  43. Glen ChooDec 8, 2021
  44. Josh SteadmonDec 14, 2021
  45. Josh SteadmonDec 14, 2021
  46. Junio C HamanoDec 7, 2021
  47. Josh SteadmonDec 14, 2021
  48. Glen ChooDec 8, 2021
  49. Josh SteadmonDec 14, 2021
  50. Junio C HamanoDec 7, 2021
  51. Glen ChooDec 8, 2021
  52. Johannes SchindelinDec 10, 2021
  53. Josh SteadmonDec 14, 2021
  54. 0/3 branch: inherit tracking configsJosh Steadmon, Dec 14, 2021
  55. 1/3 branch: accept multiple upstream branches for trackingJosh Steadmon, Dec 14, 2021
  56. Junio C HamanoDec 15, 2021
  57. Glen ChooDec 16, 2021
  58. Josh SteadmonDec 17, 2021
  59. Glen ChooDec 20, 2021
  60. Josh SteadmonDec 21, 2021
  61. 2/3 branch: add flags and config to inherit trackingJosh Steadmon, Dec 14, 2021
  62. Glen ChooDec 16, 2021
  63. Josh SteadmonDec 17, 2021
  64. 3/3 config: require lowercase for branch.autosetupmergeJosh Steadmon, Dec 14, 2021
  65. Josh SteadmonDec 15, 2021
  66. Junio C HamanoDec 16, 2021
  67. Glen ChooDec 16, 2021
  68. Junio C HamanoDec 16, 2021
  69. 0/3 branch: inherit tracking configsJosh Steadmon, Dec 17, 2021
  70. 1/3 branch: accept multiple upstream branches for trackingJosh Steadmon, Dec 17, 2021
  71. 2/3 branch: add flags and config to inherit trackingJosh Steadmon, Dec 17, 2021
  72. 3/3 config: require lowercase for branch.*.autosetupmergeJosh Steadmon, Dec 17, 2021
  73. Glen ChooDec 20, 2021
  74. 0/3 branch: inherit tracking configsJosh Steadmon, Dec 21, 2021
  75. 1/3 branch: accept multiple upstream branches for trackingJosh Steadmon, Dec 21, 2021
  76. Junio C HamanoDec 21, 2021
  77. Glen ChooDec 21, 2021
  78. 2/3 branch: add flags and config to inherit trackingJosh Steadmon, Dec 21, 2021
  79. Glen ChooDec 21, 2021
  80. 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, Jan 11, 2022
  81. branch,checkout: fix --track usage stringsJosh Steadmon, Jan 18, 2022
  82. Junio C HamanoJan 18, 2022
  83. parse-options: document automatic PARSE_OPT_LITERAL_ARGHELPRené Scharfe, Jan 19, 2022
  84. Ævar Arnfjörð BjarmasonJan 19, 2022
  85. Junio C HamanoJan 19, 2022
  86. René ScharfeJan 20, 2022
  87. Junio C HamanoJan 20, 2022
  88. René ScharfeJan 21, 2022
  89. Junio C HamanoJan 21, 2022
  90. Ævar Arnfjörð BjarmasonJan 20, 2022
  91. Andreas SchwabJan 20, 2022
  92. Ævar Arnfjörð BjarmasonJan 20, 2022
  93. Junio C HamanoJan 20, 2022
  94. Ævar Arnfjörð BjarmasonJan 21, 2022
  95. Junio C HamanoJan 21, 2022
  96. René ScharfeJan 19, 2022
  97. Ævar Arnfjörð BjarmasonJan 20, 2022
  98. branch,checkout: fix --track documentationRené Scharfe, Jan 20, 2022
  99. Ævar Arnfjörð BjarmasonJan 20, 2022
  100. Junio C HamanoJan 20, 2022
  101. 3/3 config: require lowercase for branch.*.autosetupmergeJosh Steadmon, Dec 21, 2021
  102. Glen ChooDec 21, 2021
  103. René ScharfeJan 19, 2022

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.