Re: What does it mean to have multiple upstream tracking branches?

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Thu, Mar 03 2022, Glen Choo wrote:

> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>> 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?
>
> Based on the discussion on that thread you mentioned, I don't think we
> have any such tests. I think the only way to get into this state is to
> manually modify the config.
>
> The only docs I could find on 'multiple values' are from
> Documentation/config/branch.txt:
>
>   branch.<name>.merge::
>     [...]
>     Specify multiple values to get an octopus merge.
>
> So I'd imagine a use case would be something like:
>
> - I'm preparing a feature on the branch 'topic'
> - It will get merged into 'origin/master'
> - The feature also depends on 'origin/other-topic'
>
> I'd have entries like:
>
> branch.topic.remote = origin
> branch.topic.merge = master
> branch.topic.merge = other-topic
>
> That way, if either 'origin/master' or 'origin/other-topic' changes, I
> can pull updates into 'topic' with "git pull".
>
> Not that I would ever _recommend_ someone to work like this though.
> Junio also wondered whether anyone uses this [1].
>
> [1] https://lore.kernel.org/git/xmqqbl2hw10h.fsf@gitster.g

Sure, maybe we should use it for something, maybe not, and maybe we
should use our (keep using?) default "last config set wins" rule here,
and maybe not.

What I'm asking about is that Tao Klerks notes upthread:

    Now we support multiple entries being added as a perpetuation of an
    existing branch's setup - but what does it *mean*?

As far as I can tell this isn't the case, but I only dug into it a bit
(I instrumented the relevant tests to start dying if there were multiple
"merge" entries).

So I couldn't find what if anything changed here recently, but I'm not
saying it didn't, just asking for a clarification. I.e. I didn't find
how "what should we do with this config, if any" had to do with "Josh
Steadman's[sic] recent work on --track=inherit" (re "[sic]": it's
"Steadmon" :).