What does it mean to have multiple upstream tracking branches?

What does it mean to have multiple upstream tracking branches?

[Tao Klerks]

 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?

Thanks,
Tao

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

[Ævar Arnfjörð Bjarmason]

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?

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

[Glen Choo]

Æ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

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

[Ævar Arnfjörð Bjarmason]

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" :).

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

[Junio C Hamano]

Glen Choo <chooglen@google.com> writes:

> 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

I actually think the current octopus behaviour is a sensible one
(after all, that was what we envisioned how it would be used when we
did the mechanism long time ago).  If you have mutliple, say source
and docs, groups working for you and you are taking their work from
time to time, something like this:

    [branch "main"]
        remote = central-repo
        merge = sources
        merge = docs

would let your folks push into the central-repo, and a "git pull"
will help you advance your main branch that you'll publish later.

You can explain multiple .merge entries for such an integration
branch like I just did and I think such an explanation makes perfect
sense, but these are quite different from what we view as "upstream"
in the traditional sense.  In the setting illustrated here, yours is
the main integration repository, the center of the universe, and
those folks working in the 'sources' and 'docs' groups view yours as
their "upstream".

So, "what does it mean to have multiple branch.*.merge entries" has
a good answer: you are integrating from these contributors and these
entries are not your "upstream" in the usual sense---you do not even
push back to them.  Asking "what does it mean to have multiple
upstream" makes little sense, I would think.

Now, with the 'main' branch used in such a manner, if you did

   $ git branch --track=inherit topic main

and worked on the "topic" branch, you do not push back to either the
sources or docs of the central-repo, of course, but it is unclear if
you even want to "pull" to create octopus from these two branches at
the central-repo, which essentially duplicates the pull's you would
do on your 'main' branch.  I suspect that you'd rather want to merge
updates 'main' accumulated (or rebase on them).

The reason why I asked what Josh's plans are for the multiple .merge
entries in that thread [1] when the "--inherit" feature was being
invented was exactly about this point.  I wondered if last-one-wins
may make sense (and as the above octopus set-up tells us, it may
not), but if we want to keep "multiple .merge entries means an
integrator making octpus merges", then it may make sense not to copy
them when there are multiple with "--track=inherit", to avoid
spreading the "curious" nature of the branch like 'main' depicted
above.

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

[Tao Klerks]

On Thu, Mar 3, 2022 at 11:24 PM Glen Choo <chooglen@google.com> wrote:
>
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
> >
> > 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.

There is now a way to get into such a state for a new branch, assuming
you were in such a state for an existing branch, and that is to use
"--track=inherit" when creating a new branch, branching from one
previously manually set up that way.

>
> 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.
>

Cool, hadn't seen that, thank you.

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

[Tao Klerks]

On Sun, Mar 6, 2022 at 8:46 PM Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
>
> 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" :).

Sorry - the code that handles branch merge entry creation during new
branch creation was modified by Josh (my apologies for the surname
mistype) as part of the "--track=inherit" work. The previous existing
functionality only ever dealt with one tracking branch to be created,
but the *concept* of inheritance had to deal with "what if there is
more than one to inherit".

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

[Tao Klerks]

On Sun, Mar 6, 2022 at 10:54 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Glen Choo <chooglen@google.com> writes:
>
> > 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
>
> I actually think the current octopus behaviour is a sensible one
> (after all, that was what we envisioned how it would be used when we
> did the mechanism long time ago).  If you have mutliple, say source
> and docs, groups working for you and you are taking their work from
> time to time, something like this:
>
>     [branch "main"]
>         remote = central-repo
>         merge = sources
>         merge = docs
>
> would let your folks push into the central-repo, and a "git pull"
> will help you advance your main branch that you'll publish later.
>
> You can explain multiple .merge entries for such an integration
> branch like I just did and I think such an explanation makes perfect
> sense, but these are quite different from what we view as "upstream"
> in the traditional sense.  In the setting illustrated here, yours is
> the main integration repository, the center of the universe, and
> those folks working in the 'sources' and 'docs' groups view yours as
> their "upstream".
>
> So, "what does it mean to have multiple branch.*.merge entries" has
> a good answer: you are integrating from these contributors and these
> entries are not your "upstream" in the usual sense---you do not even
> push back to them.  Asking "what does it mean to have multiple
> upstream" makes little sense, I would think.
>
> Now, with the 'main' branch used in such a manner, if you did
>
>    $ git branch --track=inherit topic main
>
> and worked on the "topic" branch, you do not push back to either the
> sources or docs of the central-repo, of course, but it is unclear if
> you even want to "pull" to create octopus from these two branches at
> the central-repo, which essentially duplicates the pull's you would
> do on your 'main' branch.  I suspect that you'd rather want to merge
> updates 'main' accumulated (or rebase on them).
>
> The reason why I asked what Josh's plans are for the multiple .merge
> entries in that thread [1] when the "--inherit" feature was being
> invented was exactly about this point.  I wondered if last-one-wins
> may make sense (and as the above octopus set-up tells us, it may
> not), but if we want to keep "multiple .merge entries means an
> integrator making octpus merges", then it may make sense not to copy
> them when there are multiple with "--track=inherit", to avoid
> spreading the "curious" nature of the branch like 'main' depicted
> above.

Given that the notion of "inherit"ing the tracking configuration is a
(relatively) new one anyway, and given the slightly esoteric nature of
the "multiple branch merge entries lead to octopus merges"
functionality, I would argue that it makes more sense to die when
branching under this specific configuration, saying something like
"inheriting the tracking configuration of a branch with multiple
branch merge entries is not supported - we think you're making a
mistake".

Skipping the creation of tracking entries in this case, even with a
warning/explanation output to stdout, would be a "slightly hidden
surprise", in that git command output is often not read by, or even
visible to users when a command is successful, eg in a GUI.

If we think this will basically never happen and really makes no sense
anyway, as Junio seems to suggest, then I would argue the extra
complexity in the codebase to support the "inheriting multiple branch
merge entries" is unwarranted.

Either way, I will happily drop this topic as it does not appear to
require follow-up in direct relation to my "--track=simple"
work/proposal. On the other hand, I'd be happy to work on a patch to
eliminate this multi-tracking-branch-inheritance path/support (undoing
some of Josh's work here) if the team believes this makes sense.

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

[Ævar Arnfjörð Bjarmason]

On Mon, Mar 07 2022, Tao Klerks wrote:

> On Sun, Mar 6, 2022 at 10:54 PM Junio C Hamano <gitster@pobox.com> wrote:
>>
>> Glen Choo <chooglen@google.com> writes:
>>
>> > 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
>>
>> I actually think the current octopus behaviour is a sensible one
>> (after all, that was what we envisioned how it would be used when we
>> did the mechanism long time ago).  If you have mutliple, say source
>> and docs, groups working for you and you are taking their work from
>> time to time, something like this:
>>
>>     [branch "main"]
>>         remote = central-repo
>>         merge = sources
>>         merge = docs
>>
>> would let your folks push into the central-repo, and a "git pull"
>> will help you advance your main branch that you'll publish later.
>>
>> You can explain multiple .merge entries for such an integration
>> branch like I just did and I think such an explanation makes perfect
>> sense, but these are quite different from what we view as "upstream"
>> in the traditional sense.  In the setting illustrated here, yours is
>> the main integration repository, the center of the universe, and
>> those folks working in the 'sources' and 'docs' groups view yours as
>> their "upstream".
>>
>> So, "what does it mean to have multiple branch.*.merge entries" has
>> a good answer: you are integrating from these contributors and these
>> entries are not your "upstream" in the usual sense---you do not even
>> push back to them.  Asking "what does it mean to have multiple
>> upstream" makes little sense, I would think.
>>
>> Now, with the 'main' branch used in such a manner, if you did
>>
>>    $ git branch --track=inherit topic main
>>
>> and worked on the "topic" branch, you do not push back to either the
>> sources or docs of the central-repo, of course, but it is unclear if
>> you even want to "pull" to create octopus from these two branches at
>> the central-repo, which essentially duplicates the pull's you would
>> do on your 'main' branch.  I suspect that you'd rather want to merge
>> updates 'main' accumulated (or rebase on them).
>>
>> The reason why I asked what Josh's plans are for the multiple .merge
>> entries in that thread [1] when the "--inherit" feature was being
>> invented was exactly about this point.  I wondered if last-one-wins
>> may make sense (and as the above octopus set-up tells us, it may
>> not), but if we want to keep "multiple .merge entries means an
>> integrator making octpus merges", then it may make sense not to copy
>> them when there are multiple with "--track=inherit", to avoid
>> spreading the "curious" nature of the branch like 'main' depicted
>> above.
>
> Given that the notion of "inherit"ing the tracking configuration is a
> (relatively) new one anyway, and given the slightly esoteric nature of
> the "multiple branch merge entries lead to octopus merges"
> functionality, I would argue that it makes more sense to die when
> branching under this specific configuration, saying something like
> "inheriting the tracking configuration of a branch with multiple
> branch merge entries is not supported - we think you're making a
> mistake".

I don't know if this is plausible in this case, but we need to be very
careful with that in general. I.e. some people might set the "sensible"
default remote config for "origin" in their ~/.gitconfig or whatever,
including "merge" for a "master" and all.

Then expect that if they have a local repo that we'll take whatever
custom values there to override them, if any.

So for most config variables that take a "last set wins" it's a feature
to ignore any previous entries.

But in this case it might be different due to the odditity of the remote
config, how we almost always manage it with "git remote" or "git clone"
etc.

> Skipping the creation of tracking entries in this case, even with a
> warning/explanation output to stdout, would be a "slightly hidden
> surprise", in that git command output is often not read by, or even
> visible to users when a command is successful, eg in a GUI.
>
> If we think this will basically never happen and really makes no sense
> anyway, as Junio seems to suggest, then I would argue the extra
> complexity in the codebase to support the "inheriting multiple branch
> merge entries" is unwarranted.
>
> Either way, I will happily drop this topic as it does not appear to
> require follow-up in direct relation to my "--track=simple"
> work/proposal. On the other hand, I'd be happy to work on a patch to
> eliminate this multi-tracking-branch-inheritance path/support (undoing
> some of Josh's work here) if the team believes this makes sense.

Just on my side: Don't take any of my comments in this thread as a "we
shouldn't do this", it was genuine confusion, thanks for clearing it up
:)

Perhaps a gently step into adding validation for this (if needed) is to
do the die()/advise() or whatever or the write (i.e. when we copy
branches, or use --track=inherit) v.s. when we use the config (in "git
fetch" et al) ?

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

[Josh Steadmon]

On 2022.03.07 13:12, Ævar Arnfjörð Bjarmason wrote:
> 
> On Mon, Mar 07 2022, Tao Klerks wrote:
> 
> > On Sun, Mar 6, 2022 at 10:54 PM Junio C Hamano <gitster@pobox.com> wrote:
> >>
> >> Glen Choo <chooglen@google.com> writes:
> >>
> >> > 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
> >>
> >> I actually think the current octopus behaviour is a sensible one
> >> (after all, that was what we envisioned how it would be used when we
> >> did the mechanism long time ago).  If you have mutliple, say source
> >> and docs, groups working for you and you are taking their work from
> >> time to time, something like this:
> >>
> >>     [branch "main"]
> >>         remote = central-repo
> >>         merge = sources
> >>         merge = docs
> >>
> >> would let your folks push into the central-repo, and a "git pull"
> >> will help you advance your main branch that you'll publish later.
> >>
> >> You can explain multiple .merge entries for such an integration
> >> branch like I just did and I think such an explanation makes perfect
> >> sense, but these are quite different from what we view as "upstream"
> >> in the traditional sense.  In the setting illustrated here, yours is
> >> the main integration repository, the center of the universe, and
> >> those folks working in the 'sources' and 'docs' groups view yours as
> >> their "upstream".
> >>
> >> So, "what does it mean to have multiple branch.*.merge entries" has
> >> a good answer: you are integrating from these contributors and these
> >> entries are not your "upstream" in the usual sense---you do not even
> >> push back to them.  Asking "what does it mean to have multiple
> >> upstream" makes little sense, I would think.
> >>
> >> Now, with the 'main' branch used in such a manner, if you did
> >>
> >>    $ git branch --track=inherit topic main
> >>
> >> and worked on the "topic" branch, you do not push back to either the
> >> sources or docs of the central-repo, of course, but it is unclear if
> >> you even want to "pull" to create octopus from these two branches at
> >> the central-repo, which essentially duplicates the pull's you would
> >> do on your 'main' branch.  I suspect that you'd rather want to merge
> >> updates 'main' accumulated (or rebase on them).
> >>
> >> The reason why I asked what Josh's plans are for the multiple .merge
> >> entries in that thread [1] when the "--inherit" feature was being
> >> invented was exactly about this point.  I wondered if last-one-wins
> >> may make sense (and as the above octopus set-up tells us, it may
> >> not), but if we want to keep "multiple .merge entries means an
> >> integrator making octpus merges", then it may make sense not to copy
> >> them when there are multiple with "--track=inherit", to avoid
> >> spreading the "curious" nature of the branch like 'main' depicted
> >> above.
> >
> > Given that the notion of "inherit"ing the tracking configuration is a
> > (relatively) new one anyway, and given the slightly esoteric nature of
> > the "multiple branch merge entries lead to octopus merges"
> > functionality, I would argue that it makes more sense to die when
> > branching under this specific configuration, saying something like
> > "inheriting the tracking configuration of a branch with multiple
> > branch merge entries is not supported - we think you're making a
> > mistake".
> 
> I don't know if this is plausible in this case, but we need to be very
> careful with that in general. I.e. some people might set the "sensible"
> default remote config for "origin" in their ~/.gitconfig or whatever,
> including "merge" for a "master" and all.
> 
> Then expect that if they have a local repo that we'll take whatever
> custom values there to override them, if any.
> 
> So for most config variables that take a "last set wins" it's a feature
> to ignore any previous entries.
> 
> But in this case it might be different due to the odditity of the remote
> config, how we almost always manage it with "git remote" or "git clone"
> etc.
> 
> > Skipping the creation of tracking entries in this case, even with a
> > warning/explanation output to stdout, would be a "slightly hidden
> > surprise", in that git command output is often not read by, or even
> > visible to users when a command is successful, eg in a GUI.
> >
> > If we think this will basically never happen and really makes no sense
> > anyway, as Junio seems to suggest, then I would argue the extra
> > complexity in the codebase to support the "inheriting multiple branch
> > merge entries" is unwarranted.
> >
> > Either way, I will happily drop this topic as it does not appear to
> > require follow-up in direct relation to my "--track=simple"
> > work/proposal. On the other hand, I'd be happy to work on a patch to
> > eliminate this multi-tracking-branch-inheritance path/support (undoing
> > some of Josh's work here) if the team believes this makes sense.
> 
> Just on my side: Don't take any of my comments in this thread as a "we
> shouldn't do this", it was genuine confusion, thanks for clearing it up
> :)
> 
> Perhaps a gently step into adding validation for this (if needed) is to
> do the die()/advise() or whatever or the write (i.e. when we copy
> branches, or use --track=inherit) v.s. when we use the config (in "git
> fetch" et al) ?

Sorry for the late response to this thread. I don't have strong feelings
regarding either keeping the current --track=inherit behavior or
disallowing inheritance of multiple merge options. However, here is my
original thinking that led me to the current implementation:

If someone is using multiple merge branches, they are already treating
the "upstream" config in a somewhat non-standard manner, as Junio
already mentioned. Presumably, they know what they're doing. While the
--track=inherit mode is intended for automatically setting up *push*
configuration, there may be some unforeseen-by-me benefit to also
inheriting this non-standard setup. Since there's nothing technical
preventing inheriting multiple merge branches, it seems better to trust
the user to know what they're doing, rather than put a die() in place to
stop them.

If folks feel that I'm wrong in my reasoning here, I'm happy to help
review patches to fix the issue, and wouldn't feel like anyone is
stepping on my toes if they do so :).