Philippe Blain <levraiphilippeblain@xxxxxxxxx> writes: >> git-branch will create the "topic" branch in the superproject and all >> submodules. >> >> recurse_submodules is only supported for creating a branch. git-branch > > small nit: we usually don't refer to the dashed form of commands anymore: 'git branch' > would be preferable. Ah, thanks! I really appreciate the style pointers. > However, I think that for this new feature, I would prefer *also* having > a new config 'branch.recurseSubmodules' (or similar) that would allow > more granular control than 'submodule.recurse', which influences several > commands. Personnally I have 'submodule.recurse' set to true in my '~/.gitconfig', > because I want the submodules working trees to be updated when I use 'git checkout' > to change branches, 'git grep' to search the working tree, etc., but I usually > do not *work* on the submodules in my project and I would not like new branches > being created in them every time I create a new branch in the superproject. > In other words, 'branch.recurseSubmodules=false' would have higher priority > than 'submodule.recurse=true'. That's a good point. This behavior of git branch --recurse-submodules has the potential to directly conflict with established workflows. Opting out via 'branch.recurseSubmodules seems reasonable and I think we definitely want to give users that fine-grained control. I wonder if we should take this even further - perhaps --recurse-submodules is too disruptive to be controlled by the config value as checkout, fetch, pull, etc. Perhaps submodule.recurse should be more fine-grained, so we can ship good defaults for different workflows e.g. options that map to the current true/false behavior and another option that includes branching (I wish I could give these names, but I have no clue what to name them). > Most tests for submodules are usually in separate test files. I don't think > this is a set-in-stone rule, but if more tests are coming in the future, maybe > a new test file t????-branch-submodule.sh would be appropriate ? Just a small suggestion. I think that's a good call. It also looks like the tests in this file are somewhat old, so it would be nice to start on a clean slate :) >> In this patchset, branching works slightly differently between the >> superproject and submodule (skip ahead for specifics). There are two >> very obvious alternatives that can address this: >> * A: only implement --recurse-submodules behavior after we are able to >> eliminate any kind of dependence on the_repository/global state that >> shouldn't be shared. >> * B: implement --recurse-submodules as child processes, which won't be >> bothered by global state. Your comments on the UX make a lot of sense, and I'll think about that more carefully. Let me know if you also have thoughts on the implementation itself, particular on in-process vs child process :)
