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

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 6, 2022, 21:54 UTC
Message-ID: <xmqqzgm2vjab.fsf@gitster.g>
In-Reply-To: <kl6l4k4ek73o.fsf@chooglen-macbookpro.roam.corp.google.com>

Glen Choo <chooglen@google.com> writes:

Show 30 quoted lines

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