On May 8, 2017 10:58 PM, Junio C Hamano wrote: >"Randall S. Becker" <rsbec...@nexbridge.com> writes: >> 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.
>I do not see a strong reason to avoid your own branches in "other people's project" like this. >The submodule's upstream may be a project you have no control over, but the repository you have locally is under your total control and you can use >any branch names to suit the need of your project as the whole (i.e. the superproject and submodules bound to it). >The fact that local branch names are under your control and for your own use is true even when you are not using submodules, by the way. I agree with the technical aspects of this, but doing a checkout -b into something like gnulib will pin the code you are using in that submodule to whatever commit was referenced when you did the checkout. Example: In a situation like that, I would want gnulib to stay on 'master'. It is my opinion, FWIW, that this is a matter of policy or standards within the organization using git that we should not be imposing one way or another. In the current state of affairs (2.12.x), when I checkout, I make sure that people are aware of which branch each submodule is on because git won't go into the submodules - I'm fine with imposing that as a policy at present because it takes positive action by the developers and I keep the master branch on my own repositories locked down and it's obvious when they are accidentally on it. But we're talking changing this so that checkout branches can apply recursively. This changes the policy requirements so that people have to further act to undo what git will do by default on recursion. The policy will be at a high level the same (i.e., always make sure you know what branch you are on in submodules), but the implementation of it will need to be different (i.e., after you checkout recursive, go into each submodule and undo what git just did by checking out the default branch on some submodules ___ ___ ___, which depends on which super repository they are using, is onerous for me to manage, and for my developers to remember to do). With Respect, Randall
