{"thread":{"id":"45884","subject":"Add an option to automatically submodule update on checkout","startedAt":"2017-05-06T08:38:22Z","lastAt":"2017-05-09T13:00:33Z","messageCount":11,"participants":["Ciro Santilli","Randall S. Becker","Stefan Beller","Brandon Williams","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"318926","messageId":"CAFXrp_do8Jn-k18_FSRNeHQrWNydwdj2y3y5gw+XoZPGAzPL-w@mail.gmail.com","threadId":"45884","inReplyTo":null,"subject":"Add an option to automatically submodule update on checkout","fromName":"Ciro Santilli","fromEmail":"ciro.santilli@gmail.com","sentAt":"2017-05-06T08:37:56Z","receivedAt":"2017-05-06T08:38:22Z","isPatch":false,"sender":{"key":"ciro.santilli@gmail.com","avatar":"https://gravatar.com/avatar/24a59ac21bfa4133ba88106940ec03cc546a14b2afd61ff6b810b06b9732a772?d=mp&s=160"},"body":"This is a must if you are working with submodules, otherwise every git\ncheckout requires a git submodule update, and you forget it, and\nthings break, and you understand, and you go to stack overflow\nquestions http://stackoverflow.com/questions/22328053/why-doesnt-git-checkout-automatically-do-git-submodule-update-recursive\n| http://stackoverflow.com/questions/4611512/is-there-a-way-to-make-git-pull-automatically-update-submodules\nand you give up and create aliases :-)\n"},{"id":"319083","messageId":"001b01d2c809$62ac8520$28058f60$@nexbridge.com","threadId":"45884","inReplyTo":"CAFXrp_do8Jn-k18_FSRNeHQrWNydwdj2y3y5gw+XoZPGAzPL-w@mail.gmail.com","subject":"RE: Add an option to automatically submodule update on checkout","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2017-05-08T14:42:52Z","receivedAt":"2017-05-08T14:43:08Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On May 6, 2017 4:38 AM Ciro Santilli wrote:\n> This is a must if you are working with submodules, otherwise every git checkout requires a git submodule update,\n> and you forget it, and things break, and you understand, and you go to stack overflow questions\n> http://stackoverflow.com/questions/22328053/why-doesnt-git-checkout-automatically-do-git-submodule-update-recursive\n> http://stackoverflow.com/questions/4611512/is-there-a-way-to-make-git-pull-automatically-update-submodules\n> and you give up and create aliases :-)\n\nI rather like the concept of supporting --recurse-submodules. The complexity is that the branches in all submodules all have to have compatible semantics when doing the checkout, which is by no means guaranteed. In the scenario where you are including a submodule from a third-party (very common - see gnulib), the branches likely won't be there, so you have a high probability of having the command fail or produce the same results as currently exists if you allow the checkout even with problems (another option?). If you have control of everything, then this makes sense.\n\nCheers,\nRandall\n\n"},{"id":"319091","messageId":"CAGZ79kaES-3ftadorYnx2wMDc-q7qsG376E1zy-C67Ldt2BO5g@mail.gmail.com","threadId":"45884","inReplyTo":"001b01d2c809$62ac8520$28058f60$@nexbridge.com","subject":"Re: Add an option to automatically submodule update on checkout","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-05-08T16:25:29Z","receivedAt":"2017-05-08T16:25:35Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Mon, May 8, 2017 at 7:42 AM, Randall S. Becker\n<rsbecker@nexbridge.com> wrote:\n> On May 6, 2017 4:38 AM Ciro Santilli wrote:\n>> This is a must if you are working with submodules, otherwise every git checkout requires a git submodule update,\n>> and you forget it, and things break, and you understand, and you go to stack overflow questions\n>> http://stackoverflow.com/questions/22328053/why-doesnt-git-checkout-automatically-do-git-submodule-update-recursive\n>> http://stackoverflow.com/questions/4611512/is-there-a-way-to-make-git-pull-automatically-update-submodules\n>> and you give up and create aliases :-)\n\nThe upcoming release (2.13) will have \"git checkout --recurse-submodules\",\nwhich will checkout the submodules at the commit as recorded in the\nsuperproject.\n\nI plan to add an option \"submodule.recurse\" (name is subject to bikeshedding),\nwhich would make the --recurse-submodules flag given by default for all commands\nthat support the flag. (Currently cooking we have reset\n--recurse-submodules, already\nexisting there is push/pull).\n\n> I rather like the concept of supporting --recurse-submodules. The complexity is that the branches in all submodules all have to have compatible semantics when doing the checkout, which is by no means guaranteed. In the scenario where you are including a submodule from a third-party (very common - see gnulib), the branches likely won't be there, so you have a high probability of having the command fail or produce the same results as currently exists if you allow the checkout even with problems (another option?). If you have control of everything, then this makes sense.\n\nI am trying to give the use case of having control over everything\n(or rather mixed) more thought as well,\ne.g. \"checkout --recurse-submodules -b <name>\" may want to\ncreate the branches in a subset of submodules as well.\n\nThanks,\nStefan\n\n>\n> Cheers,\n> Randall\n>\n"},{"id":"319093","messageId":"002201d2c81a$9ff76060$dfe62120$@nexbridge.com","threadId":"45884","inReplyTo":"CAGZ79kaES-3ftadorYnx2wMDc-q7qsG376E1zy-C67Ldt2BO5g@mail.gmail.com","subject":"RE: Add an option to automatically submodule update on checkout","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2017-05-08T16:46:17Z","receivedAt":"2017-05-08T16:46:33Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On May 8, 2017 12:25 PM, Stefan Beller wrote:\n>On Mon, May 8, 2017 at 7:42 AM, Randall S. Becker <rsbecker@nexbridge.com> wrote:\n>> On May 6, 2017 4:38 AM Ciro Santilli wrote:\n>>> This is a must if you are working with submodules, otherwise every \n>>> git checkout requires a git submodule update, and you forget it, and \n>>> things break, and you understand, and you go to stack overflow \n>>> questions \n>>> http://stackoverflow.com/questions/22328053/why-doesnt-git-checkout-a\n>>> utomatically-do-git-submodule-update-recursive\n>>> http://stackoverflow.com/questions/4611512/is-there-a-way-to-make-git\n>>> -pull-automatically-update-submodules\n>>> and you give up and create aliases :-)\n\n> The upcoming release (2.13) will have \"git checkout --recurse-submodules\", which will checkout the submodules\n> at the commit as recorded in the superproject.\n> I plan to add an option \"submodule.recurse\" (name is subject to bikeshedding), which would make the --recurse-submodules\n> flag given by default for all commands that support the flag. (Currently cooking we have reset --recurse-submodules, already\n> existing there is push/pull).\n\nBrilliant! 😊\n\n>> I rather like the concept of supporting --recurse-submodules. The complexity is that the branches in all submodules all have to have compatible >>semantics when doing the checkout, which is by no means guaranteed. In the scenario where you are including a submodule from a third-party (very >>common - see gnulib), the branches likely won't be there, so you have a high probability of having the command fail or produce the same results as >>currently exists if you allow the checkout even with problems (another option?). If you have control of everything, then this makes sense.\n\n>I am trying to give the use case of having control over everything (or rather mixed) more thought as well, e.g. \"checkout --recurse-submodules -b ><name>\" may want to create the branches in a subset of submodules as well.\n\nI have to admit that I just assumed it would have to work that way this would not be particularly useful. However, in thinking about it, we might want to limit the depth of how far -b <name> takes effect. If the super module brings in submodules entirely within control of the development group, having -b <name> apply down to leaf submodules makes sense (in some policies). However, if some submodules span out to, say, gnulib, that might not make particular sense. Some downward limit might be appropriate. Perhaps, in the submodule ref, you might want to qualify it as <commit>:<ref> (but the impact of that is probably and admittedly pretty horrid). I hesitate to suggest a numeric limit, as that assumes that submodules are organized in a balanced tree - which is axiomatically unreasonable. Maybe something in .git/config, like\n\n[branch \"topic*\"]\n\tsubmodules=a,b,c\n\nBut I suspect that would make things even more confusing.\n\nCheers,\nRandall\n\n"},{"id":"319094","messageId":"20170508164821.GA179149@google.com","threadId":"45884","inReplyTo":"CAGZ79kaES-3ftadorYnx2wMDc-q7qsG376E1zy-C67Ldt2BO5g@mail.gmail.com","subject":"Re: Add an option to automatically submodule update on checkout","fromName":"Brandon Williams","fromEmail":"bmwill@google.com","sentAt":"2017-05-08T16:48:21Z","receivedAt":"2017-05-08T16:48:29Z","isPatch":false,"sender":{"key":"bwilliams.eng@gmail.com","avatar":null},"body":"On 05/08, Stefan Beller wrote:\n> On Mon, May 8, 2017 at 7:42 AM, Randall S. Becker\n> <rsbecker@nexbridge.com> wrote:\n> > On May 6, 2017 4:38 AM Ciro Santilli wrote:\n> >> This is a must if you are working with submodules, otherwise every\n> >> git checkout requires a git submodule update, and you forget it,\n> >> and things break, and you understand, and you go to stack overflow\n> >> questions\n> >> http://stackoverflow.com/questions/22328053/why-doesnt-git-checkout-automatically-do-git-submodule-update-recursive\n> >> http://stackoverflow.com/questions/4611512/is-there-a-way-to-make-git-pull-automatically-update-submodules\n> >> and you give up and create aliases :-)\n> \n> The upcoming release (2.13) will have \"git checkout\n> --recurse-submodules\", which will checkout the submodules at the\n> commit as recorded in the superproject.\n> \n> I plan to add an option \"submodule.recurse\" (name is subject to\n> bikeshedding), which would make the --recurse-submodules flag given by\n> default for all commands that support the flag. (Currently cooking we\n> have reset --recurse-submodules, already existing there is push/pull).\n\nWell pull not so much...it'll do a recursive fetch but not a recursive\nmerge/rebase.  That is something on the docket to get done in the next\ncouple months though.\n\n> \n> > I rather like the concept of supporting --recurse-submodules. The\n> > complexity is that the branches in all submodules all have to have\n> > compatible semantics when doing the checkout, which is by no means\n> > guaranteed. In the scenario where you are including a submodule from\n> > a third-party (very common - see gnulib), the branches likely won't\n> > be there, so you have a high probability of having the command fail\n> > or produce the same results as currently exists if you allow the\n> > checkout even with problems (another option?). If you have control\n> > of everything, then this makes sense.\n> \n> I am trying to give the use case of having control over everything (or\n> rather mixed) more thought as well, e.g. \"checkout\n> --recurse-submodules -b <name>\" may want to create the branches in a\n> subset of submodules as well.\n> \n> Thanks, Stefan\n> \n> >\n> > Cheers, Randall\n> >\n\n-- \nBrandon Williams\n"},{"id":"319097","messageId":"CAGZ79kbxdXhhG3+4v9qH_oDi5o_zseGsQf8KCyTN3+axZB9sUA@mail.gmail.com","threadId":"45884","inReplyTo":"002201d2c81a$9ff76060$dfe62120$@nexbridge.com","subject":"Re: Add an option to automatically submodule update on checkout","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-05-08T16:54:55Z","receivedAt":"2017-05-08T16:55:03Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Mon, May 8, 2017 at 9:46 AM, Randall S. Becker\n<rsbecker@nexbridge.com> wrote:\n> On May 8, 2017 12:25 PM, Stefan Beller wrote:\n>>On Mon, May 8, 2017 at 7:42 AM, Randall S. Becker <rsbecker@nexbridge.com> wrote:\n>>> On May 6, 2017 4:38 AM Ciro Santilli wrote:\n>>>> This is a must if you are working with submodules, otherwise every\n>>>> git checkout requires a git submodule update, and you forget it, and\n>>>> things break, and you understand, and you go to stack overflow\n>>>> questions\n>>>> http://stackoverflow.com/questions/22328053/why-doesnt-git-checkout-a\n>>>> utomatically-do-git-submodule-update-recursive\n>>>> http://stackoverflow.com/questions/4611512/is-there-a-way-to-make-git\n>>>> -pull-automatically-update-submodules\n>>>> and you give up and create aliases :-)\n>\n>> The upcoming release (2.13) will have \"git checkout --recurse-submodules\", which will checkout the submodules\n>> at the commit as recorded in the superproject.\n>> I plan to add an option \"submodule.recurse\" (name is subject to bikeshedding), which would make the --recurse-submodules\n>> flag given by default for all commands that support the flag. (Currently cooking we have reset --recurse-submodules, already\n>> existing there is push/pull).\n>\n> Brilliant! 😊\n>\n>>> I rather like the concept of supporting --recurse-submodules. The complexity is that the branches in all submodules all have to have compatible >>semantics when doing the checkout, which is by no means guaranteed. In the scenario where you are including a submodule from a third-party (very >>common - see gnulib), the branches likely won't be there, so you have a high probability of having the command fail or produce the same results as >>currently exists if you allow the checkout even with problems (another option?). If you have control of everything, then this makes sense.\n>\n>>I am trying to give the use case of having control over everything (or rather mixed) more thought as well, e.g. \"checkout --recurse-submodules -b ><name>\" may want to create the branches in a subset of submodules as well.\n>\n> I have to admit that I just assumed it would have to work that way this would not be particularly useful. However, in thinking about it, we might want to limit the depth of how far -b <name> takes effect. If the super module brings in submodules entirely within control of the development group, having -b <name> apply down to leaf submodules makes sense (in some policies). However, if some submodules span out to, say, gnulib, that might not make particular sense. Some downward limit might be appropriate. Perhaps, in the submodule ref, you might want to qualify it as <commit>:<ref> (but the impact of that is probably and admittedly pretty horrid). I hesitate to suggest a numeric limit, as that assumes that submodules are organized in a balanced tree - which is axiomatically unreasonable. Maybe something in .git/config, like\n>\n> [branch \"topic*\"]\n>         submodules=a,b,c\n>\n> But I suspect that would make things even more confusing.\n\nI thought about having yet-another-flag in the .gitmodules file, which\nstates if the submodule is extern or internal.\n\n[submodule \"gnulib\"]\n    path=./gnulib\n    external = true # implies no branch for checkout -b --recurse-submodules\n\nI think there are a couple more situations where such \"external\" submodules\nare treated differently, so maybe we'd want to think carefully about\nthe actual name\nas different workflows would want to have different features for an\ninternal/external\nsubmodule.\n\nThanks,\nStefan\n"},{"id":"319100","messageId":"002301d2c81d$4728aae0$d57a00a0$@nexbridge.com","threadId":"45884","inReplyTo":"CAGZ79kbxdXhhG3+4v9qH_oDi5o_zseGsQf8KCyTN3+axZB9sUA@mail.gmail.com","subject":"RE: Add an option to automatically submodule update on checkout","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2017-05-08T17:05:16Z","receivedAt":"2017-05-08T17:05:33Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On May 8, 2017 12:55 PM, Stefan Beller wrote:\n>On Mon, May 8, 2017 at 9:46 AM, Randall S. Becker <rsbecker@nexbridge.com> wrote:\n>> On May 8, 2017 12:25 PM, Stefan Beller wrote:\n>>>On Mon, May 8, 2017 at 7:42 AM, Randall S. Becker <rsbecker@nexbridge.com> wrote:\n>>>> On May 6, 2017 4:38 AM Ciro Santilli wrote:\n>>>>> This is a must if you are working with submodules, otherwise every \n>>>>> git checkout requires a git submodule update, and you forget it, \n>>>>> and things break, and you understand, and you go to stack overflow \n>>>>> questions \n>>>>> http://stackoverflow.com/questions/22328053/why-doesnt-git-checkout\n>>>>> -a utomatically-do-git-submodule-update-recursive\n>>>>> http://stackoverflow.com/questions/4611512/is-there-a-way-to-make-g\n>>>>> it -pull-automatically-update-submodules\n>>>>> and you give up and create aliases :-)\n>>\n>>> The upcoming release (2.13) will have \"git checkout \n>>> --recurse-submodules\", which will checkout the submodules at the commit as recorded in the superproject.\n>>> I plan to add an option \"submodule.recurse\" (name is subject to \n>>> bikeshedding), which would make the --recurse-submodules flag given \n>>> by default for all commands that support the flag. (Currently cooking we have reset --recurse-submodules, already existing there is push/pull).\n>>\n>> Brilliant! 😊\n>>\n>>>> I rather like the concept of supporting --recurse-submodules. The complexity is that the branches in all submodules all have to have compatible >>>semantics when doing the checkout, which is by no means guaranteed. In the scenario where you are including a submodule from a third-party (very >>>common - see gnulib), the branches likely won't be there, so you have a high probability of having the command fail or produce the same results as >>>currently exists if you allow the checkout even with problems (another option?). If you have control of everything, then this makes sense.\n>>\n>>>I am trying to give the use case of having control over everything (or rather mixed) more thought as well, e.g. \"checkout --recurse-submodules -b >><name>\" may want to create the branches in a subset of submodules as well.\n>>\n>> I have to admit that I just assumed it would have to work that way \n>> this would not be particularly useful. However, in thinking about it, \n>> we might want to limit the depth of how far -b <name> takes effect. If \n>> the super module brings in submodules entirely within control of the \n>> development group, having -b <name> apply down to leaf submodules \n>> makes sense (in some policies). However, if some submodules span out \n>> to, say, gnulib, that might not make particular sense. Some downward \n>> limit might be appropriate. Perhaps, in the submodule ref, you might \n>> want to qualify it as <commit>:<ref> (but the impact of that is \n>> probably and admittedly pretty horrid). I hesitate to suggest a \n>> numeric limit, as that assumes that submodules are organized in a \n>> balanced tree - which is axiomatically unreasonable. Maybe something \n>> in .git/config, like\n>>\n>> [branch \"topic*\"]\n>>         submodules=a,b,c\n>>\n>> But I suspect that would make things even more confusing.\n\n>I thought about having yet-another-flag in the .gitmodules file, which states if the submodule is extern or internal.\n\n>[submodule \"gnulib\"]\n>    path=./gnulib\n>    external = true # implies no branch for checkout -b --recurse-submodules\n\n>I think there are a couple more situations where such \"external\" submodules are treated differently, so maybe we'd want to think carefully about the >actual name as different workflows would want to have different features for an internal/external submodule.\n\nI didn't want to open up that one, but yes. That makes sense. However, I don't like overloading what \"external\" means or might mean in the future. Would you consider a distinct Boolean for that, like inherit-branch=true?\n\nCheers,\nRandall\n\n"},{"id":"319101","messageId":"20170508170846.GD179149@google.com","threadId":"45884","inReplyTo":"002301d2c81d$4728aae0$d57a00a0$@nexbridge.com","subject":"Re: Add an option to automatically submodule update on checkout","fromName":"Brandon Williams","fromEmail":"bmwill@google.com","sentAt":"2017-05-08T17:08:46Z","receivedAt":"2017-05-08T17:09:00Z","isPatch":false,"sender":{"key":"bwilliams.eng@gmail.com","avatar":null},"body":"On 05/08, Randall S. Becker wrote:\n> On May 8, 2017 12:55 PM, Stefan Beller wrote:\n> >On Mon, May 8, 2017 at 9:46 AM, Randall S. Becker <rsbecker@nexbridge.com> wrote:\n> >> On May 8, 2017 12:25 PM, Stefan Beller wrote:\n> >>>On Mon, May 8, 2017 at 7:42 AM, Randall S. Becker <rsbecker@nexbridge.com> wrote:\n> >>>> On May 6, 2017 4:38 AM Ciro Santilli wrote:\n> >>>>> This is a must if you are working with submodules, otherwise every \n> >>>>> git checkout requires a git submodule update, and you forget it, \n> >>>>> and things break, and you understand, and you go to stack overflow \n> >>>>> questions \n> >>>>> http://stackoverflow.com/questions/22328053/why-doesnt-git-checkout\n> >>>>> -a utomatically-do-git-submodule-update-recursive\n> >>>>> http://stackoverflow.com/questions/4611512/is-there-a-way-to-make-g\n> >>>>> it -pull-automatically-update-submodules\n> >>>>> and you give up and create aliases :-)\n> >>\n> >>> The upcoming release (2.13) will have \"git checkout \n> >>> --recurse-submodules\", which will checkout the submodules at the commit as recorded in the superproject.\n> >>> I plan to add an option \"submodule.recurse\" (name is subject to \n> >>> bikeshedding), which would make the --recurse-submodules flag given \n> >>> by default for all commands that support the flag. (Currently cooking we have reset --recurse-submodules, already existing there is push/pull).\n> >>\n> >> Brilliant! 😊\n> >>\n> >>>> I rather like the concept of supporting --recurse-submodules. The complexity is that the branches in all submodules all have to have compatible >>>semantics when doing the checkout, which is by no means guaranteed. In the scenario where you are including a submodule from a third-party (very >>>common - see gnulib), the branches likely won't be there, so you have a high probability of having the command fail or produce the same results as >>>currently exists if you allow the checkout even with problems (another option?). If you have control of everything, then this makes sense.\n> >>\n> >>>I am trying to give the use case of having control over everything (or rather mixed) more thought as well, e.g. \"checkout --recurse-submodules -b >><name>\" may want to create the branches in a subset of submodules as well.\n> >>\n> >> I have to admit that I just assumed it would have to work that way \n> >> this would not be particularly useful. However, in thinking about it, \n> >> we might want to limit the depth of how far -b <name> takes effect. If \n> >> the super module brings in submodules entirely within control of the \n> >> development group, having -b <name> apply down to leaf submodules \n> >> makes sense (in some policies). However, if some submodules span out \n> >> to, say, gnulib, that might not make particular sense. Some downward \n> >> limit might be appropriate. Perhaps, in the submodule ref, you might \n> >> want to qualify it as <commit>:<ref> (but the impact of that is \n> >> probably and admittedly pretty horrid). I hesitate to suggest a \n> >> numeric limit, as that assumes that submodules are organized in a \n> >> balanced tree - which is axiomatically unreasonable. Maybe something \n> >> in .git/config, like\n> >>\n> >> [branch \"topic*\"]\n> >>         submodules=a,b,c\n> >>\n> >> But I suspect that would make things even more confusing.\n> \n> >I thought about having yet-another-flag in the .gitmodules file, which states if the submodule is extern or internal.\n> \n> >[submodule \"gnulib\"]\n> >    path=./gnulib\n> >    external = true # implies no branch for checkout -b --recurse-submodules\n> \n> >I think there are a couple more situations where such \"external\" submodules are treated differently, so maybe we'd want to think carefully about the >actual name as different workflows would want to have different features for an internal/external submodule.\n> \n> I didn't want to open up that one, but yes. That makes sense. However, I don't like overloading what \"external\" means or might mean in the future. Would you consider a distinct Boolean for that, like inherit-branch=true?\n\nSomething like that kind of already exists.  The 'branch' field.\nInternal repos would most likely use the '.' value to indicate that the\nsubmodules should track the superproject's branch.  While a value of say\n'foo' would indicate that the submodule should always be on branch\n'foo'; this could be used for external repositories.\n\n> \n> Cheers,\n> Randall\n> \n\n-- \nBrandon Williams\n"},{"id":"319105","messageId":"CAGZ79kbNEAL6dYFPzquDDAsMNqpFsE3_VEHXeKu1VuaLV+m8_w@mail.gmail.com","threadId":"45884","inReplyTo":"20170508170846.GD179149@google.com","subject":"Re: Add an option to automatically submodule update on checkout","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-05-08T17:15:35Z","receivedAt":"2017-05-08T17:15:51Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Mon, May 8, 2017 at 10:08 AM, Brandon Williams <bmwill@google.com> wrote:\n>>\n>> >[submodule \"gnulib\"]\n>> >    path=./gnulib\n>> >    external = true # implies no branch for checkout -b --recurse-submodules\n>>\n>> >I think there are a couple more situations where such \"external\" submodules are treated differently, so maybe we'd want to think carefully about the >actual name as different workflows would want to have different features for an internal/external submodule.\n>>\n>> I didn't want to open up that one, but yes. That makes sense. However, I don't like overloading what \"external\" means or might mean in the future. Would you consider a distinct Boolean for that, like inherit-branch=true?\n>\n> Something like that kind of already exists.  The 'branch' field.\n> Internal repos would most likely use the '.' value to indicate that the\n> submodules should track the superproject's branch.  While a value of say\n> 'foo' would indicate that the submodule should always be on branch\n> 'foo'; this could be used for external repositories.\n\nso for external repos you'd keep the branch unset, such that\nyou strictly checkout the sha1 object into a detached HEAD.\n\nMakes sense.\n\nThanks,\nStefan\n"},{"id":"319148","messageId":"xmqqtw4u4tz6.fsf@gitster.mtv.corp.google.com","threadId":"45884","inReplyTo":"002201d2c81a$9ff76060$dfe62120$@nexbridge.com","subject":"Re: Add an option to automatically submodule update on checkout","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-05-09T02:58:05Z","receivedAt":"2017-05-09T02:58:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Randall S. Becker\" <rsbecker@nexbridge.com> writes:\n\n> I have to admit that I just assumed it would have to work that way\n> this would not be particularly useful. However, in thinking about\n> it, we might want to limit the depth of how far -b <name> takes\n> effect. If the super module brings in submodules entirely within\n> control of the development group, having -b <name> apply down to\n> leaf submodules makes sense (in some policies). However, if some\n> submodules span out to, say, gnulib, that might not make\n> particular sense.\n\nI do not see a strong reason to avoid your own branches in \"other\npeople's project\" like this.\n\nThe submodule's upstream may be a project you have no control over,\nbut the repository you have locally is under your total control and\nyou can use any branch names to suit the need of your project as the\nwhole (i.e. the superproject and submodules bound to it).\n\nThe fact that local branch names are under your control and for your\nown use is true even when you are not using submodules, by the way.\n\n"},{"id":"319195","messageId":"000c01d2c8c4$336c3380$9a449a80$@nexbridge.com","threadId":"45884","inReplyTo":"xmqqtw4u4tz6.fsf@gitster.mtv.corp.google.com","subject":"RE: Add an option to automatically submodule update on checkout","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2017-05-09T13:00:09Z","receivedAt":"2017-05-09T13:00:33Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On May 8, 2017 10:58 PM, Junio C Hamano wrote:\n>\"Randall S. Becker\" <rsbecker@nexbridge.com> writes:\n>> I have to admit that I just assumed it would have to work that way \n>> this would not be particularly useful. However, in thinking about it, \n>> we might want to limit the depth of how far -b <name> takes effect. If \n>> the super module brings in submodules entirely within control of the \n>> development group, having -b <name> apply down to leaf submodules \n>> makes sense (in some policies). However, if some submodules span out \n>> to, say, gnulib, that might not make particular sense.\n\n>I do not see a strong reason to avoid your own branches in \"other people's\nproject\" like this.\n>The submodule's upstream may be a project you have no control over, but the\nrepository you have locally is under your total control and you can use >any\nbranch names to suit the need of your project as the whole (i.e. the\nsuperproject and submodules bound to it).\n\n>The fact that local branch names are under your control and for your own\nuse is true even when you are not using submodules, by the way.\n\nI agree with the technical aspects of this, but doing a checkout -b into\nsomething like gnulib will pin the code you are using in that submodule to\nwhatever commit was referenced when you did the checkout. Example: In a\nsituation like that, I would want gnulib to stay on 'master'. It is my\nopinion, FWIW, that this is a matter of policy or standards within the\norganization using git that we should not be imposing one way or another. In\nthe current state of affairs (2.12.x), when I checkout, I make sure that\npeople are aware of which branch each submodule is on because git won't go\ninto the submodules - I'm fine with imposing that as a policy at present\nbecause it takes positive action by the developers and I keep the master\nbranch on my own repositories locked down and it's obvious when they are\naccidentally on it. But we're talking changing this so that checkout\nbranches can apply recursively. This changes the policy requirements so that\npeople have to further act to undo what git will do by default on recursion.\nThe policy will be at a high level the same (i.e., always make sure you know\nwhat branch you are on in submodules), but the implementation of it will\nneed to be different (i.e., after you checkout recursive, go into each\nsubmodule and undo what git just did by checking out the default branch on\nsome submodules ___ ___ ___, which depends on which super repository they\nare using, is onerous for me to manage, and for my developers to remember to\ndo).\n\nWith Respect,\nRandall\n\n"}]}