Hacker News Reader

Comment by flohofwoe | Hacker News Reader

IME submodules are mostly fine for external dependencies that only very rarely change and remain pinned at a specific version over weeks or months.

Giving submodules a special set of git commands, and providing the users so many easy opportunities to shoot themselves in the foot are baffling design decisions though.

E.g. I'd really like to know why "git clone --recursive" isn't the default.

View on HN

And then you always forget what you need to do after you didn't do it for months. I have a blog project (written with pelican) where I submodule the whole pelican-plugins project which is, basically, again a compendium of submodules.

Now when running Python creates pycache-folders in the submodules and other stuff in the directories sometimes changes a bit while running.

When it comes to updating the plugins-submodule, I have to go through every sub-submodule and git clean it and reset it so that I can pin a new version for the submodule, and then update all sub-submodules. Mind you, I have not found it easier to delete the whole submodule-tree and re-initialise it.

Wouldn't this be resolved by a good README.md?

Of course, the correct way would be to write down all the steps, operationalise them, and then implements parts and then the whole as a shell script.

The question I would ask is, whether this should be necessary to pin the version of some project dependency? That's basically all we're talking about here.

Code is the best documentation. update-submodules-latest.sh (well, PS1 for my team, we're a .net shop) to move to latest along their branch and stage the submodule change

Both --recursive not being default and then using --recurse-submodules when pulling are my top annoyances in git.

At the very least, it could warn you when you pull a repo with submodules without —recurse-submodules. But it doesn’t, it just silently does nothing.

Another tip: you can do a deep clone of the main repo, then do `git submodule update --init --recursive --depth=1` to just pull the heads of your dependencies to cut down on times. Especially useful if you don't work within the submodules at all.

IMO this should be the default!

No. History is the whole point of git. It would be antithetical to make this the default.

I'm more on board with the recursive options, though.

I can't for the life of me understand why this isn't at least a config option. That and an option for setting --upstream in git push by default. Those could at least preserve backwards compatibility.

Are the Git maintainers so stringent on maintaining backwards compatibility that the implementation of submodules has remained in such a dire state for so long? I find it hard to believe that a VCS this widely adopted would fall over so easily for this relatively popular use case.

You can now set it for pull but not for clone.

    git config --global submodule.recurse true

I’ve found that setting submodule.recurse to true makes submodules behave closer to how you’d expect them to.

Mercurial's subrepos implement the exact same functionality as git submodules, but they do it without being as bafflingly broken as git's attempt.

Reply on news.ycombinator.com