{"thread":{"id":"57500","subject":"What does it mean to have multiple upstream tracking branches?","startedAt":"2022-03-03T06:17:03Z","lastAt":"2022-03-08T19:44:10Z","messageCount":10,"participants":["Tao Klerks","Ævar Arnfjörð Bjarmason","Glen Choo","Junio C Hamano","Josh Steadmon"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"450244","messageId":"CAPMMpoiTJAuadBEOPWOVa-kguSXMDvAhvD22B63QwYpu=H7xEw@mail.gmail.com","threadId":"57500","inReplyTo":null,"subject":"What does it mean to have multiple upstream tracking branches?","fromName":"Tao Klerks","fromEmail":"tao@klerks.biz","sentAt":"2022-03-03T06:16:47Z","receivedAt":"2022-03-03T06:17:03Z","isPatch":false,"sender":{"key":"tao@klerks.biz","avatar":"https://avatars.githubusercontent.com/u/531704?v=4"},"body":" Hi,\n\nIn my recent attempt to create a \"simple\" branch.autosetupmerge\noption, I have repeatedly been confused by the enforced rules around\nwhat is and isn't valid for the branch..merge and\nbranch..remote configs.\n\nUntil Josh Steadman's recent work on --track=inherit, the \"automatic\"\naddition of branch..merge could only ever result in a single\nentry.\n\nNow we support multiple entries being added as a perpetuation of an\nexisting branch's setup - but what does it *mean*? I could understand\nif the idea was to have transparent tracking across multiple remotes\nthat are supposed to have the same content (eg a single server set up\nover multiple protocols), but that does not appear to be possible -\nbranch..remote can only have one value.\n\nIs there any documentation (or could someone provide pointers) as to\nwhen multiple branch..merge values can make sense and what that\nmeans / what it does?\n\nThanks,\nTao\n"},{"id":"450263","messageId":"220303.868rtr42mg.gmgdl@evledraar.gmail.com","threadId":"57500","inReplyTo":"CAPMMpoiTJAuadBEOPWOVa-kguSXMDvAhvD22B63QwYpu=H7xEw@mail.gmail.com","subject":"Re: What does it mean to have multiple upstream tracking branches?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-03-03T12:54:38Z","receivedAt":"2022-03-03T12:55:27Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, Mar 03 2022, Tao Klerks wrote:\n\n> Hi,\n>\n> In my recent attempt to create a \"simple\" branch.autosetupmerge\n> option, I have repeatedly been confused by the enforced rules around\n> what is and isn't valid for the branch..merge and\n> branch..remote configs.\n>\n> Until Josh Steadman's recent work on --track=inherit, the \"automatic\"\n> addition of branch..merge could only ever result in a single\n> entry.\n>\n> Now we support multiple entries being added as a perpetuation of an\n> existing branch's setup - but what does it *mean*? I could understand\n> if the idea was to have transparent tracking across multiple remotes\n> that are supposed to have the same content (eg a single server set up\n> over multiple protocols), but that does not appear to be possible -\n> branch..remote can only have one value.\n>\n> Is there any documentation (or could someone provide pointers) as to\n> when multiple branch..merge values can make sense and what that\n> means / what it does?\n\nCan you point out some existing tests where we end up with multiple\n*.merge values? I looked a bit and couldn't find any.\n\nOr maybe it's only possible to get into that state with some command we\nhave a test blind spot for?\n"},{"id":"450314","messageId":"kl6l4k4ek73o.fsf@chooglen-macbookpro.roam.corp.google.com","threadId":"57500","inReplyTo":"220303.868rtr42mg.gmgdl@evledraar.gmail.com","subject":"Re: What does it mean to have multiple upstream tracking branches?","fromName":"Glen Choo","fromEmail":"chooglen@google.com","sentAt":"2022-03-03T22:24:11Z","receivedAt":"2022-03-03T22:24:24Z","isPatch":false,"sender":{"key":"glencbz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/58092771?v=4"},"body":"Ævar Arnfjörð Bjarmason writes:\n\n> On Thu, Mar 03 2022, Tao Klerks wrote:\n>\n>> Hi,\n>>\n>> In my recent attempt to create a \"simple\" branch.autosetupmerge\n>> option, I have repeatedly been confused by the enforced rules around\n>> what is and isn't valid for the branch..merge and\n>> branch..remote configs.\n>>\n>> Until Josh Steadman's recent work on --track=inherit, the \"automatic\"\n>> addition of branch..merge could only ever result in a single\n>> entry.\n>>\n>> Now we support multiple entries being added as a perpetuation of an\n>> existing branch's setup - but what does it *mean*? I could understand\n>> if the idea was to have transparent tracking across multiple remotes\n>> that are supposed to have the same content (eg a single server set up\n>> over multiple protocols), but that does not appear to be possible -\n>> branch..remote can only have one value.\n>>\n>> Is there any documentation (or could someone provide pointers) as to\n>> when multiple branch..merge values can make sense and what that\n>> means / what it does?\n>\n> Can you point out some existing tests where we end up with multiple\n> *.merge values? I looked a bit and couldn't find any.\n>\n> Or maybe it's only possible to get into that state with some command we\n> have a test blind spot for?\n\nBased on the discussion on that thread you mentioned, I don't think we\nhave any such tests. I think the only way to get into this state is to\nmanually modify the config.\n\nThe only docs I could find on 'multiple values' are from\nDocumentation/config/branch.txt:\n\n branch..merge::\n [...]\n Specify multiple values to get an octopus merge.\n\nSo I'd imagine a use case would be something like:\n\n- I'm preparing a feature on the branch 'topic'\n- It will get merged into 'origin/master'\n- The feature also depends on 'origin/other-topic'\n\nI'd have entries like:\n\nbranch.topic.remote = origin\nbranch.topic.merge = master\nbranch.topic.merge = other-topic\n\nThat way, if either 'origin/master' or 'origin/other-topic' changes, I\ncan pull updates into 'topic' with \"git pull\".\n\nNot that I would ever _recommend_ someone to work like this though.\nJunio also wondered whether anyone uses this [1].\n\n[1] https://lore.kernel.org/git/xmqqbl2hw10h.fsf@gitster.g\n"},{"id":"450503","messageId":"220306.86lexm3lvr.gmgdl@evledraar.gmail.com","threadId":"57500","inReplyTo":"kl6l4k4ek73o.fsf@chooglen-macbookpro.roam.corp.google.com","subject":"Re: What does it mean to have multiple upstream tracking branches?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-03-06T19:42:35Z","receivedAt":"2022-03-06T19:46:09Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, Mar 03 2022, Glen Choo wrote:\n\n> Ævar Arnfjörð Bjarmason writes:\n>\n>> On Thu, Mar 03 2022, Tao Klerks wrote:\n>>\n>>> Hi,\n>>>\n>>> In my recent attempt to create a \"simple\" branch.autosetupmerge\n>>> option, I have repeatedly been confused by the enforced rules around\n>>> what is and isn't valid for the branch..merge and\n>>> branch..remote configs.\n>>>\n>>> Until Josh Steadman's recent work on --track=inherit, the \"automatic\"\n>>> addition of branch..merge could only ever result in a single\n>>> entry.\n>>>\n>>> Now we support multiple entries being added as a perpetuation of an\n>>> existing branch's setup - but what does it *mean*? I could understand\n>>> if the idea was to have transparent tracking across multiple remotes\n>>> that are supposed to have the same content (eg a single server set up\n>>> over multiple protocols), but that does not appear to be possible -\n>>> branch..remote can only have one value.\n>>>\n>>> Is there any documentation (or could someone provide pointers) as to\n>>> when multiple branch..merge values can make sense and what that\n>>> means / what it does?\n>>\n>> Can you point out some existing tests where we end up with multiple\n>> *.merge values? I looked a bit and couldn't find any.\n>>\n>> Or maybe it's only possible to get into that state with some command we\n>> have a test blind spot for?\n>\n> Based on the discussion on that thread you mentioned, I don't think we\n> have any such tests. I think the only way to get into this state is to\n> manually modify the config.\n>\n> The only docs I could find on 'multiple values' are from\n> Documentation/config/branch.txt:\n>\n> branch..merge::\n> [...]\n> Specify multiple values to get an octopus merge.\n>\n> So I'd imagine a use case would be something like:\n>\n> - I'm preparing a feature on the branch 'topic'\n> - It will get merged into 'origin/master'\n> - The feature also depends on 'origin/other-topic'\n>\n> I'd have entries like:\n>\n> branch.topic.remote = origin\n> branch.topic.merge = master\n> branch.topic.merge = other-topic\n>\n> That way, if either 'origin/master' or 'origin/other-topic' changes, I\n> can pull updates into 'topic' with \"git pull\".\n>\n> Not that I would ever _recommend_ someone to work like this though.\n> Junio also wondered whether anyone uses this [1].\n>\n> [1] https://lore.kernel.org/git/xmqqbl2hw10h.fsf@gitster.g\n\nSure, maybe we should use it for something, maybe not, and maybe we\nshould use our (keep using?) default \"last config set wins\" rule here,\nand maybe not.\n\nWhat I'm asking about is that Tao Klerks notes upthread:\n\n Now we support multiple entries being added as a perpetuation of an\n existing branch's setup - but what does it *mean*?\n\nAs far as I can tell this isn't the case, but I only dug into it a bit\n(I instrumented the relevant tests to start dying if there were multiple\n\"merge\" entries).\n\nSo I couldn't find what if anything changed here recently, but I'm not\nsaying it didn't, just asking for a clarification. I.e. I didn't find\nhow \"what should we do with this config, if any\" had to do with \"Josh\nSteadman's[sic] recent work on --track=inherit\" (re \"[sic]\": it's\n\"Steadmon\" :).\n"},{"id":"450504","messageId":"xmqqzgm2vjab.fsf@gitster.g","threadId":"57500","inReplyTo":"kl6l4k4ek73o.fsf@chooglen-macbookpro.roam.corp.google.com","subject":"Re: What does it mean to have multiple upstream tracking branches?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-03-06T21:54:36Z","receivedAt":"2022-03-06T21:54:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Glen Choo writes:\n\n> Based on the discussion on that thread you mentioned, I don't think we\n> have any such tests. I think the only way to get into this state is to\n> manually modify the config.\n>\n> The only docs I could find on 'multiple values' are from\n> Documentation/config/branch.txt:\n>\n> branch..merge::\n> [...]\n> Specify multiple values to get an octopus merge.\n>\n> So I'd imagine a use case would be something like:\n>\n> - I'm preparing a feature on the branch 'topic'\n> - It will get merged into 'origin/master'\n> - The feature also depends on 'origin/other-topic'\n>\n> I'd have entries like:\n>\n> branch.topic.remote = origin\n> branch.topic.merge = master\n> branch.topic.merge = other-topic\n>\n> That way, if either 'origin/master' or 'origin/other-topic' changes, I\n> can pull updates into 'topic' with \"git pull\".\n>\n> Not that I would ever _recommend_ someone to work like this though.\n> Junio also wondered whether anyone uses this [1].\n>\n> [1] https://lore.kernel.org/git/xmqqbl2hw10h.fsf@gitster.g\n\nI actually think the current octopus behaviour is a sensible one\n(after all, that was what we envisioned how it would be used when we\ndid the mechanism long time ago). If you have mutliple, say source\nand docs, groups working for you and you are taking their work from\ntime to time, something like this:\n\n [branch \"main\"]\n remote = central-repo\n merge = sources\n merge = docs\n\nwould let your folks push into the central-repo, and a \"git pull\"\nwill help you advance your main branch that you'll publish later.\n\nYou can explain multiple .merge entries for such an integration\nbranch like I just did and I think such an explanation makes perfect\nsense, but these are quite different from what we view as \"upstream\"\nin the traditional sense. In the setting illustrated here, yours is\nthe main integration repository, the center of the universe, and\nthose folks working in the 'sources' and 'docs' groups view yours as\ntheir \"upstream\".\n\nSo, \"what does it mean to have multiple branch.*.merge entries\" has\na good answer: you are integrating from these contributors and these\nentries are not your \"upstream\" in the usual sense---you do not even\npush back to them. Asking \"what does it mean to have multiple\nupstream\" makes little sense, I would think.\n\nNow, with the 'main' branch used in such a manner, if you did\n\n $ git branch --track=inherit topic main\n\nand worked on the \"topic\" branch, you do not push back to either the\nsources or docs of the central-repo, of course, but it is unclear if\nyou even want to \"pull\" to create octopus from these two branches at\nthe central-repo, which essentially duplicates the pull's you would\ndo on your 'main' branch. I suspect that you'd rather want to merge\nupdates 'main' accumulated (or rebase on them).\n\nThe reason why I asked what Josh's plans are for the multiple .merge\nentries in that thread [1] when the \"--inherit\" feature was being\ninvented was exactly about this point. I wondered if last-one-wins\nmay make sense (and as the above octopus set-up tells us, it may\nnot), but if we want to keep \"multiple .merge entries means an\nintegrator making octpus merges\", then it may make sense not to copy\nthem when there are multiple with \"--track=inherit\", to avoid\nspreading the \"curious\" nature of the branch like 'main' depicted\nabove.\n\n\n"},{"id":"450511","messageId":"CAPMMpoh96fHi7RbcMxrwkinyXiy-to6cnVACNKQV8C-7_vZH=g@mail.gmail.com","threadId":"57500","inReplyTo":"kl6l4k4ek73o.fsf@chooglen-macbookpro.roam.corp.google.com","subject":"Re: What does it mean to have multiple upstream tracking branches?","fromName":"Tao Klerks","fromEmail":"tao@klerks.biz","sentAt":"2022-03-07T06:09:28Z","receivedAt":"2022-03-07T06:09:44Z","isPatch":false,"sender":{"key":"tao@klerks.biz","avatar":"https://avatars.githubusercontent.com/u/531704?v=4"},"body":"On Thu, Mar 3, 2022 at 11:24 PM Glen Choo wrote:\n>\n> Ævar Arnfjörð Bjarmason writes:\n>\n> >\n> > Can you point out some existing tests where we end up with multiple\n> > *.merge values? I looked a bit and couldn't find any.\n> >\n> > Or maybe it's only possible to get into that state with some command we\n> > have a test blind spot for?\n>\n> Based on the discussion on that thread you mentioned, I don't think we\n> have any such tests. I think the only way to get into this state is to\n> manually modify the config.\n\nThere is now a way to get into such a state for a new branch, assuming\nyou were in such a state for an existing branch, and that is to use\n\"--track=inherit\" when creating a new branch, branching from one\npreviously manually set up that way.\n\n>\n> The only docs I could find on 'multiple values' are from\n> Documentation/config/branch.txt:\n>\n> branch..merge::\n> [...]\n> Specify multiple values to get an octopus merge.\n>\n\nCool, hadn't seen that, thank you.\n"},{"id":"450513","messageId":"CAPMMpojkNuO6f8Q6qZL=gkJzBi2Rr5qZd+qs7ZXD9Syz5214Vw@mail.gmail.com","threadId":"57500","inReplyTo":"220306.86lexm3lvr.gmgdl@evledraar.gmail.com","subject":"Re: What does it mean to have multiple upstream tracking branches?","fromName":"Tao Klerks","fromEmail":"tao@klerks.biz","sentAt":"2022-03-07T06:16:49Z","receivedAt":"2022-03-07T06:17:10Z","isPatch":false,"sender":{"key":"tao@klerks.biz","avatar":"https://avatars.githubusercontent.com/u/531704?v=4"},"body":"On Sun, Mar 6, 2022 at 8:46 PM Ævar Arnfjörð Bjarmason wrote:\n>\n> What I'm asking about is that Tao Klerks notes upthread:\n>\n> Now we support multiple entries being added as a perpetuation of an\n> existing branch's setup - but what does it *mean*?\n>\n> As far as I can tell this isn't the case, but I only dug into it a bit\n> (I instrumented the relevant tests to start dying if there were multiple\n> \"merge\" entries).\n>\n> So I couldn't find what if anything changed here recently, but I'm not\n> saying it didn't, just asking for a clarification. I.e. I didn't find\n> how \"what should we do with this config, if any\" had to do with \"Josh\n> Steadman's[sic] recent work on --track=inherit\" (re \"[sic]\": it's\n> \"Steadmon\" :).\n\nSorry - the code that handles branch merge entry creation during new\nbranch creation was modified by Josh (my apologies for the surname\nmistype) as part of the \"--track=inherit\" work. The previous existing\nfunctionality only ever dealt with one tracking branch to be created,\nbut the *concept* of inheritance had to deal with \"what if there is\nmore than one to inherit\".\n"},{"id":"450514","messageId":"CAPMMpoh38fm-jNi=GD+uf6O+JLiJz-ue2zh5ceWpwmTYBRKzvw@mail.gmail.com","threadId":"57500","inReplyTo":"xmqqzgm2vjab.fsf@gitster.g","subject":"Re: What does it mean to have multiple upstream tracking branches?","fromName":"Tao Klerks","fromEmail":"tao@klerks.biz","sentAt":"2022-03-07T06:17:27Z","receivedAt":"2022-03-07T06:17:45Z","isPatch":false,"sender":{"key":"tao@klerks.biz","avatar":"https://avatars.githubusercontent.com/u/531704?v=4"},"body":"On Sun, Mar 6, 2022 at 10:54 PM Junio C Hamano wrote:\n>\n> Glen Choo writes:\n>\n> > Not that I would ever _recommend_ someone to work like this though.\n> > Junio also wondered whether anyone uses this [1].\n> >\n> > [1] https://lore.kernel.org/git/xmqqbl2hw10h.fsf@gitster.g\n>\n> I actually think the current octopus behaviour is a sensible one\n> (after all, that was what we envisioned how it would be used when we\n> did the mechanism long time ago). If you have mutliple, say source\n> and docs, groups working for you and you are taking their work from\n> time to time, something like this:\n>\n> [branch \"main\"]\n> remote = central-repo\n> merge = sources\n> merge = docs\n>\n> would let your folks push into the central-repo, and a \"git pull\"\n> will help you advance your main branch that you'll publish later.\n>\n> You can explain multiple .merge entries for such an integration\n> branch like I just did and I think such an explanation makes perfect\n> sense, but these are quite different from what we view as \"upstream\"\n> in the traditional sense. In the setting illustrated here, yours is\n> the main integration repository, the center of the universe, and\n> those folks working in the 'sources' and 'docs' groups view yours as\n> their \"upstream\".\n>\n> So, \"what does it mean to have multiple branch.*.merge entries\" has\n> a good answer: you are integrating from these contributors and these\n> entries are not your \"upstream\" in the usual sense---you do not even\n> push back to them. Asking \"what does it mean to have multiple\n> upstream\" makes little sense, I would think.\n>\n> Now, with the 'main' branch used in such a manner, if you did\n>\n> $ git branch --track=inherit topic main\n>\n> and worked on the \"topic\" branch, you do not push back to either the\n> sources or docs of the central-repo, of course, but it is unclear if\n> you even want to \"pull\" to create octopus from these two branches at\n> the central-repo, which essentially duplicates the pull's you would\n> do on your 'main' branch. I suspect that you'd rather want to merge\n> updates 'main' accumulated (or rebase on them).\n>\n> The reason why I asked what Josh's plans are for the multiple .merge\n> entries in that thread [1] when the \"--inherit\" feature was being\n> invented was exactly about this point. I wondered if last-one-wins\n> may make sense (and as the above octopus set-up tells us, it may\n> not), but if we want to keep \"multiple .merge entries means an\n> integrator making octpus merges\", then it may make sense not to copy\n> them when there are multiple with \"--track=inherit\", to avoid\n> spreading the \"curious\" nature of the branch like 'main' depicted\n> above.\n\nGiven that the notion of \"inherit\"ing the tracking configuration is a\n(relatively) new one anyway, and given the slightly esoteric nature of\nthe \"multiple branch merge entries lead to octopus merges\"\nfunctionality, I would argue that it makes more sense to die when\nbranching under this specific configuration, saying something like\n\"inheriting the tracking configuration of a branch with multiple\nbranch merge entries is not supported - we think you're making a\nmistake\".\n\nSkipping the creation of tracking entries in this case, even with a\nwarning/explanation output to stdout, would be a \"slightly hidden\nsurprise\", in that git command output is often not read by, or even\nvisible to users when a command is successful, eg in a GUI.\n\nIf we think this will basically never happen and really makes no sense\nanyway, as Junio seems to suggest, then I would argue the extra\ncomplexity in the codebase to support the \"inheriting multiple branch\nmerge entries\" is unwarranted.\n\nEither way, I will happily drop this topic as it does not appear to\nrequire follow-up in direct relation to my \"--track=simple\"\nwork/proposal. On the other hand, I'd be happy to work on a patch to\neliminate this multi-tracking-branch-inheritance path/support (undoing\nsome of Josh's work here) if the team believes this makes sense.\n"},{"id":"450535","messageId":"220307.86a6e20xi2.gmgdl@evledraar.gmail.com","threadId":"57500","inReplyTo":"CAPMMpoh38fm-jNi=GD+uf6O+JLiJz-ue2zh5ceWpwmTYBRKzvw@mail.gmail.com","subject":"Re: What does it mean to have multiple upstream tracking branches?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-03-07T12:12:13Z","receivedAt":"2022-03-07T12:15:38Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Mon, Mar 07 2022, Tao Klerks wrote:\n\n> On Sun, Mar 6, 2022 at 10:54 PM Junio C Hamano wrote:\n>>\n>> Glen Choo writes:\n>>\n>> > Not that I would ever _recommend_ someone to work like this though.\n>> > Junio also wondered whether anyone uses this [1].\n>> >\n>> > [1] https://lore.kernel.org/git/xmqqbl2hw10h.fsf@gitster.g\n>>\n>> I actually think the current octopus behaviour is a sensible one\n>> (after all, that was what we envisioned how it would be used when we\n>> did the mechanism long time ago). If you have mutliple, say source\n>> and docs, groups working for you and you are taking their work from\n>> time to time, something like this:\n>>\n>> [branch \"main\"]\n>> remote = central-repo\n>> merge = sources\n>> merge = docs\n>>\n>> would let your folks push into the central-repo, and a \"git pull\"\n>> will help you advance your main branch that you'll publish later.\n>>\n>> You can explain multiple .merge entries for such an integration\n>> branch like I just did and I think such an explanation makes perfect\n>> sense, but these are quite different from what we view as \"upstream\"\n>> in the traditional sense. In the setting illustrated here, yours is\n>> the main integration repository, the center of the universe, and\n>> those folks working in the 'sources' and 'docs' groups view yours as\n>> their \"upstream\".\n>>\n>> So, \"what does it mean to have multiple branch.*.merge entries\" has\n>> a good answer: you are integrating from these contributors and these\n>> entries are not your \"upstream\" in the usual sense---you do not even\n>> push back to them. Asking \"what does it mean to have multiple\n>> upstream\" makes little sense, I would think.\n>>\n>> Now, with the 'main' branch used in such a manner, if you did\n>>\n>> $ git branch --track=inherit topic main\n>>\n>> and worked on the \"topic\" branch, you do not push back to either the\n>> sources or docs of the central-repo, of course, but it is unclear if\n>> you even want to \"pull\" to create octopus from these two branches at\n>> the central-repo, which essentially duplicates the pull's you would\n>> do on your 'main' branch. I suspect that you'd rather want to merge\n>> updates 'main' accumulated (or rebase on them).\n>>\n>> The reason why I asked what Josh's plans are for the multiple .merge\n>> entries in that thread [1] when the \"--inherit\" feature was being\n>> invented was exactly about this point. I wondered if last-one-wins\n>> may make sense (and as the above octopus set-up tells us, it may\n>> not), but if we want to keep \"multiple .merge entries means an\n>> integrator making octpus merges\", then it may make sense not to copy\n>> them when there are multiple with \"--track=inherit\", to avoid\n>> spreading the \"curious\" nature of the branch like 'main' depicted\n>> above.\n>\n> Given that the notion of \"inherit\"ing the tracking configuration is a\n> (relatively) new one anyway, and given the slightly esoteric nature of\n> the \"multiple branch merge entries lead to octopus merges\"\n> functionality, I would argue that it makes more sense to die when\n> branching under this specific configuration, saying something like\n> \"inheriting the tracking configuration of a branch with multiple\n> branch merge entries is not supported - we think you're making a\n> mistake\".\n\nI don't know if this is plausible in this case, but we need to be very\ncareful with that in general. I.e. some people might set the \"sensible\"\ndefault remote config for \"origin\" in their ~/.gitconfig or whatever,\nincluding \"merge\" for a \"master\" and all.\n\nThen expect that if they have a local repo that we'll take whatever\ncustom values there to override them, if any.\n\nSo for most config variables that take a \"last set wins\" it's a feature\nto ignore any previous entries.\n\nBut in this case it might be different due to the odditity of the remote\nconfig, how we almost always manage it with \"git remote\" or \"git clone\"\netc.\n\n> Skipping the creation of tracking entries in this case, even with a\n> warning/explanation output to stdout, would be a \"slightly hidden\n> surprise\", in that git command output is often not read by, or even\n> visible to users when a command is successful, eg in a GUI.\n>\n> If we think this will basically never happen and really makes no sense\n> anyway, as Junio seems to suggest, then I would argue the extra\n> complexity in the codebase to support the \"inheriting multiple branch\n> merge entries\" is unwarranted.\n>\n> Either way, I will happily drop this topic as it does not appear to\n> require follow-up in direct relation to my \"--track=simple\"\n> work/proposal. On the other hand, I'd be happy to work on a patch to\n> eliminate this multi-tracking-branch-inheritance path/support (undoing\n> some of Josh's work here) if the team believes this makes sense.\n\nJust on my side: Don't take any of my comments in this thread as a \"we\nshouldn't do this\", it was genuine confusion, thanks for clearing it up\n:)\n\nPerhaps a gently step into adding validation for this (if needed) is to\ndo the die()/advise() or whatever or the write (i.e. when we copy\nbranches, or use --track=inherit) v.s. when we use the config (in \"git\nfetch\" et al) ?\n"},{"id":"450769","messageId":"Yiex/y8s7mlHTydz@google.com","threadId":"57500","inReplyTo":"220307.86a6e20xi2.gmgdl@evledraar.gmail.com","subject":"Re: What does it mean to have multiple upstream tracking branches?","fromName":"Josh Steadmon","fromEmail":"steadmon@google.com","sentAt":"2022-03-08T19:43:59Z","receivedAt":"2022-03-08T19:44:10Z","isPatch":false,"sender":{"key":"steadmon@google.com","avatar":"https://avatars.githubusercontent.com/u/2654920?v=4"},"body":"On 2022.03.07 13:12, Ævar Arnfjörð Bjarmason wrote:\n> \n> On Mon, Mar 07 2022, Tao Klerks wrote:\n> \n> > On Sun, Mar 6, 2022 at 10:54 PM Junio C Hamano wrote:\n> >>\n> >> Glen Choo writes:\n> >>\n> >> > Not that I would ever _recommend_ someone to work like this though.\n> >> > Junio also wondered whether anyone uses this [1].\n> >> >\n> >> > [1] https://lore.kernel.org/git/xmqqbl2hw10h.fsf@gitster.g\n> >>\n> >> I actually think the current octopus behaviour is a sensible one\n> >> (after all, that was what we envisioned how it would be used when we\n> >> did the mechanism long time ago). If you have mutliple, say source\n> >> and docs, groups working for you and you are taking their work from\n> >> time to time, something like this:\n> >>\n> >> [branch \"main\"]\n> >> remote = central-repo\n> >> merge = sources\n> >> merge = docs\n> >>\n> >> would let your folks push into the central-repo, and a \"git pull\"\n> >> will help you advance your main branch that you'll publish later.\n> >>\n> >> You can explain multiple .merge entries for such an integration\n> >> branch like I just did and I think such an explanation makes perfect\n> >> sense, but these are quite different from what we view as \"upstream\"\n> >> in the traditional sense. In the setting illustrated here, yours is\n> >> the main integration repository, the center of the universe, and\n> >> those folks working in the 'sources' and 'docs' groups view yours as\n> >> their \"upstream\".\n> >>\n> >> So, \"what does it mean to have multiple branch.*.merge entries\" has\n> >> a good answer: you are integrating from these contributors and these\n> >> entries are not your \"upstream\" in the usual sense---you do not even\n> >> push back to them. Asking \"what does it mean to have multiple\n> >> upstream\" makes little sense, I would think.\n> >>\n> >> Now, with the 'main' branch used in such a manner, if you did\n> >>\n> >> $ git branch --track=inherit topic main\n> >>\n> >> and worked on the \"topic\" branch, you do not push back to either the\n> >> sources or docs of the central-repo, of course, but it is unclear if\n> >> you even want to \"pull\" to create octopus from these two branches at\n> >> the central-repo, which essentially duplicates the pull's you would\n> >> do on your 'main' branch. I suspect that you'd rather want to merge\n> >> updates 'main' accumulated (or rebase on them).\n> >>\n> >> The reason why I asked what Josh's plans are for the multiple .merge\n> >> entries in that thread [1] when the \"--inherit\" feature was being\n> >> invented was exactly about this point. I wondered if last-one-wins\n> >> may make sense (and as the above octopus set-up tells us, it may\n> >> not), but if we want to keep \"multiple .merge entries means an\n> >> integrator making octpus merges\", then it may make sense not to copy\n> >> them when there are multiple with \"--track=inherit\", to avoid\n> >> spreading the \"curious\" nature of the branch like 'main' depicted\n> >> above.\n> >\n> > Given that the notion of \"inherit\"ing the tracking configuration is a\n> > (relatively) new one anyway, and given the slightly esoteric nature of\n> > the \"multiple branch merge entries lead to octopus merges\"\n> > functionality, I would argue that it makes more sense to die when\n> > branching under this specific configuration, saying something like\n> > \"inheriting the tracking configuration of a branch with multiple\n> > branch merge entries is not supported - we think you're making a\n> > mistake\".\n> \n> I don't know if this is plausible in this case, but we need to be very\n> careful with that in general. I.e. some people might set the \"sensible\"\n> default remote config for \"origin\" in their ~/.gitconfig or whatever,\n> including \"merge\" for a \"master\" and all.\n> \n> Then expect that if they have a local repo that we'll take whatever\n> custom values there to override them, if any.\n> \n> So for most config variables that take a \"last set wins\" it's a feature\n> to ignore any previous entries.\n> \n> But in this case it might be different due to the odditity of the remote\n> config, how we almost always manage it with \"git remote\" or \"git clone\"\n> etc.\n> \n> > Skipping the creation of tracking entries in this case, even with a\n> > warning/explanation output to stdout, would be a \"slightly hidden\n> > surprise\", in that git command output is often not read by, or even\n> > visible to users when a command is successful, eg in a GUI.\n> >\n> > If we think this will basically never happen and really makes no sense\n> > anyway, as Junio seems to suggest, then I would argue the extra\n> > complexity in the codebase to support the \"inheriting multiple branch\n> > merge entries\" is unwarranted.\n> >\n> > Either way, I will happily drop this topic as it does not appear to\n> > require follow-up in direct relation to my \"--track=simple\"\n> > work/proposal. On the other hand, I'd be happy to work on a patch to\n> > eliminate this multi-tracking-branch-inheritance path/support (undoing\n> > some of Josh's work here) if the team believes this makes sense.\n> \n> Just on my side: Don't take any of my comments in this thread as a \"we\n> shouldn't do this\", it was genuine confusion, thanks for clearing it up\n> :)\n> \n> Perhaps a gently step into adding validation for this (if needed) is to\n> do the die()/advise() or whatever or the write (i.e. when we copy\n> branches, or use --track=inherit) v.s. when we use the config (in \"git\n> fetch\" et al) ?\n\nSorry for the late response to this thread. I don't have strong feelings\nregarding either keeping the current --track=inherit behavior or\ndisallowing inheritance of multiple merge options. However, here is my\noriginal thinking that led me to the current implementation:\n\nIf someone is using multiple merge branches, they are already treating\nthe \"upstream\" config in a somewhat non-standard manner, as Junio\nalready mentioned. Presumably, they know what they're doing. While the\n--track=inherit mode is intended for automatically setting up *push*\nconfiguration, there may be some unforeseen-by-me benefit to also\ninheriting this non-standard setup. Since there's nothing technical\npreventing inheriting multiple merge branches, it seems better to trust\nthe user to know what they're doing, rather than put a die() in place to\nstop them.\n\nIf folks feel that I'm wrong in my reasoning here, I'm happy to help\nreview patches to fix the issue, and wouldn't feel like anyone is\nstepping on my toes if they do so :).\n"}]}