From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Thu, 03 Mar 2022 12:54:38 GMT
Subject: Re: What does it mean to have multiple upstream tracking branches?
Message-ID: <220303.868rtr42mg.gmgdl@evledraar.gmail.com>
In-Reply-To: <CAPMMpoiTJAuadBEOPWOVa-kguSXMDvAhvD22B63QwYpu=H7xEw@mail.gmail.com>


On Thu, Mar 03 2022, Tao Klerks wrote:

>  Hi,
>
> In my recent attempt to create a "simple" branch.autosetupmerge
> option, I have repeatedly been confused by the enforced rules around
> what is and isn't valid for the branch.<name>.merge and
> branch.<name>.remote configs.
>
> Until Josh Steadman's recent work on --track=inherit, the "automatic"
> addition of branch.<name>.merge could only ever result in a single
> entry.
>
> Now we support multiple entries being added as a perpetuation of an
> existing branch's setup - but what does it *mean*? I could understand
> if the idea was to have transparent tracking across multiple remotes
> that are supposed to have the same content (eg a single server set up
> over multiple protocols), but that does not appear to be possible -
> branch.<name>.remote can only have one value.
>
> Is there any documentation (or could someone provide pointers) as to
> when multiple branch.<name>.merge values can make sense and what that
> means / what it does?

Can you point out some existing tests where we end up with multiple
*.merge values? I looked a bit and couldn't find any.

Or maybe it's only possible to get into that state with some command we
have a test blind spot for?