On Sun, Oct 25, 2015 at 5:56 PM, Chris Packham <judge.pack...@gmail.com> wrote: > On Mon, Oct 26, 2015 at 12:10 PM, John Smith <johsmi9...@inbox.com> wrote: >> I found that I use submodules much, much more often in my git projects than >> I used externals >> in Subversion and the reason is that git encourages/forces to organize large >> projects into >> smaller repositories, one reason for this being that subversion allows to >> check out parts of >> a repository while git does not. >> >> But when I clone a git repository with subprojects, I (and everyone else) >> has to remember to >> add the --recursive option. When switching between branches with different >> versions/commits of the >> submodules everyone has to remember to update the submodules. When updating >> a submodule >> everyone has to remember to recurse there too. > > The config option fetch.recurseSubmodules exists. It's not quite the > same as what git clone --recurse-submodules does but it's a start. > >> >> Basically, everything with submodules has to be done manually every time and >> there seems >> to be no way to change that default. >> >> Why is that? Basically all the time I use submodules I would want automatic >> handling of >> submodules to happen and I cannot remember having had a single situation >> where I would >> not have wanted it to happen. So why does git default to doing nothing?
IIUC at the time submodules were invented, there was need for lots of code to be written. Each command needed new code to deal with submodules. As there was not enough people/time to do it properly, the "do nothing" was the safest action which could be added fast. > > It's hard to pick a default that suits every workflow that submodules > support. Also with submodules there is a chicken-and-egg scenario. > While you can put things in ~/.gitconfig most of what you'd want to > configure when using submodules would be in super/.git/config but that > doesn't exist until you've cloned super.git. > >> Why does it not provide a way to enable automatic >> pulling/updating of submodules e.g. when cloning or switching branches? > > I believe Jens and Stefan (Cc'd) have been doing some great work in > this area. Jens even posted his todo list a few days ago > (https://github.com/jlehmann/git-submod-enhancements/wiki). Yeah I would also point at Jens' wiki today. All I did up to now was rewriting parts of the submodule code in C (git submodule update specifically), while the code/patches you find at Jens' copy of Git includes already lots of useful stuff such as `git checkout --recurse-submodules` (IIRC you don't need to type --recurse-submodules if you configured that to be the default) > >> When would people routinely check out a branch and want to stay with the >> submodules as >> the have been checked out for the old branch? As said above, it was a sane choice which could be implemented fast, IIUC. I mean what would happen if you had commits made in the submodule, or just a dirty working tree? >> >> I honestly do not understand it. >> >> John >> Stefan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
