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

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