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

[Junio C Hamano <gitster@pobox.com>]

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.