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

From: Glen Choo <chooglen@google.com>
Date: Mar 3, 2022, 22:24 UTC
Message-ID: <kl6l4k4ek73o.fsf@chooglen-macbookpro.roam.corp.google.com>
In-Reply-To: <220303.868rtr42mg.gmgdl@evledraar.gmail.com>

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

Show 29 quoted lines

> 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