Thread (69 messages) flat view 69 messages, 5 authors, 2022-01-20

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

From: Glen Choo <hidden>
Date: 2021-12-09 23:47:06

Josh Steadmon [off-list ref] writes:
quoted
quoted
@@ -121,11 +168,18 @@ int install_branch_config(int flag, const char *local, const char *origin, const
 	advise(_(tracking_advice),
 	       origin ? origin : "",
 	       origin ? "/" : "",
-	       shortname ? shortname : remote);
+	       remotes->items[0].string);
 
 	return -1;
 }
When there is more than one item in remotes->items, this advice is
_technically_ incorrect because --set-upstream-to only takes a single
upstream branch. I think that supporting multiple upstreams in
--set-upstream-to is a fairly niche use case and is out of scope of this
series, so let's not pursue that option.

Another option would be to replace the mention of --set-upstream-to with
"git config add", but that's unfriendly to the >90% of the user
population that doesn't want multiple merge entries.

If we leave the advice as-is, even though it is misleading, a user who
is sophisticated enough to set up multiple merge entries should also
know that --set-upstream-to won't solve their problems, and would
probably be able to fix their problems by mucking around with
.git/config or git config.

So I think it is ok to not change the advice and to only mention the
first merge item. However, it might be worth marking this as NEEDSWORK
so that subsequent readers of this file understand that this advice is
overly-simplistic and might be worth fixing.
Sounds like we should just have separate advice strings for single vs.
multiple merge configs?
That sounds like a good idea if it's not too much work. Otherwise, a
NEEDSWORK is still acceptable to me (but that said, I'm not an authority
on this matter).
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help