On Mon, Jan 27, 2020 at 02:20:19PM -0800, Emily Shaffer wrote: > > It would make more sense to me to either (or both): > > > > - make sure that .gitmodules has enough information about which branch > > to use for each submodule > > Hum. I don't work with them day to day, but aren't we already in that > state? Is that not what the 'branch' option for each submodule means? Probably? :) I've never used the feature myself, but it does seem like the right thing (and should definitely take precedence over any "-b" option passed to the superproject). > > - offer an extra option for the default branch to use for any > > submodules. This is still not general enough to cover all situations > > (e.g., the bar/baz you showed above), but it at least makes it > > relatively easy to cover the simple cases, without breaking any > > existing ones. > > Yeah, this is sort of the direction my mind went too - "not > --branch recursively, but --submodule-branch". But that breaks down when you've > got a nontrivial number of submodules, at which point you're gonna have > a hard time unless you've got the .gitmodules configured correctly. Right. Probably the right answer for that bar/baz case is to complain to the superproject owner that they didn't put branch fields into their .gitmodules. So... > Well, as for this patch, let me try it with just --single-branch and see > whether that works for the case the user reported. I can head back to > the drawing board if not. Yeah, that makes perfect sense to me. -Peff
