On Thu, Jan 16, 2020 at 02:38:00PM -0800, Emily Shaffer wrote: > > I have no idea how common this kind of thing would be, and I expect in > > most cases your patch would do what people want. But we might need to be > > better about retrying without those options when the first clone fails. > > Yeah, that's interesting. A retry sounds like a pretty solid approach, > although if someone's being cautious and using --single-branch I wonder > if that's really something they want (since that's avoiding grabbing > extraneous branches). > > I suppose at the very least, --single-branch without --branch should > become recursive. Whether --branch should become recursive, I'm not > totally sure. Yeah, I think it may be worth separating out how to think about the two options. It's a lot more plausible to me that --single-branch would want to recurse than --branch. > The two scenarios I see in conflict are this: > - Superproject branch "foo" > - submodule A branch "foo" > - submodule B branch "foo" > and > - Superproject branch "foo" > - submodule A branch "bar" > - submodule B branch "baz" > > If we propagate --branch, the first scenario Just Works, and the second > scenario requires something like: > > git clone --recurse-submodules=no --single-branch --branch foo https://superproject > git submodule update --init --single-branch --branch bar A/ > git submodule update --init --single-branch --branch baz B/ > > (I guess if the superproject knows what branch it wants for all the submodules, > you could also just do "git submodule update --init --single-branch" and > have it go and ask for all of them.) > > If we don't propagate --branch, the second scenario Just Works, and the > first scenario requires something like: > > git clone --recurse-submodules=no --single-branch --branch foo https://superproject > git submodule update --init --single-branch --branch foo > > (That is, I think as long as 'update' takes --branch, even if it's not > passed along by 'clone', it should still work OK when delegating to > everyone.) > > Let me know if I misunderstood what you were worried about. Right, that's exactly my concern. You're making one case work but breaking the other. It really seems like there's no particular reason to assume that the superproject branch corresponds to the submodule branch (or even submodules of submodules). I imagine it would in some cases (like trying to replace the use of "repo" in Android), but that's just one model. 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 - 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. -Peff
