Live data from Hacker News

I Hate Git Submodules

abildskov.io

31–40 of 73 posts

Re: I Hate Git Submodules

#31
post #30

You spend all this time figuring out how to make git do what you want using this general format: git [args] You would expect to do the same thing with a submodule, it would be: git submodule [args] But no, submodules have their own set of commands. It's like it's purposefully obtuse for no good reason.

> It's like it's purposefully obtuse for no good reason.

At least it's consistent with the rest of git then...

Git is one of those tools I just can't muster the willpower to truly learn. I use SourceTree and hope for the best, and search the web frantically when something weird happens.

I used Mercurial from only the command line for many years, never felt I needed a GUI. But git, there's just something about it.

Re: I Hate Git Submodules

#32
post #10

It believe it is a question of maturity. If the subcomponent is mature enough, then turning it into a package is fine. The cost is that patching the subcomponent and testing the main component takes more effort (though you can script it). With submodules at least the build and test cycle is as quick as if it is in the same repo. So there is a scale from quicker iteration to less coupled: same repo, submodule, differe…

Exactly what I am thinking. My use case is to have a shared api repository containing an IDL (here protobuf/grpc) and you hook it up as submodules for iOS, android, Golang. The round trip time is reduced compared to creating and publishing modules for each generated code. This makes it far easier to experiment with a new api feature so one gets a better feeling how this behaves in each language. And if the api is mature enough you might as well change your development flow into publishing modules instead of using git submodules.

Therefore I like submodules and would argue that people might underestimate the increased round trip time for publishing modules and then referencing them in code compared to using submodules

Re: I Hate Git Submodules

#33
If you get to a point where you think you absoultely need git submodules...just switch to svn, so much pain in misery can be avoided if you just use the right tool for the right job and SVN handles the git submodule use-case effortlessly (for C++ at least).

For languages with proper package management (ruby, python, go, node, etc...) put in the extra effort to utilize your package manager to update your dependencies instead of bothering with submodules. If you're still set on doing submodules, I'm willing to be you're just "doing it wrong" (TM).

Re: I Hate Git Submodules

#34

Earlier quoted context omitted.

+1 for subrepo.

My concern with subrepo is that I have no idea who is developing it and how much resources they have. I'd hate to learn to use a tool central to my development workflow and then have it discontinued. Is git-subrepo good enough that it's worth the risk of using something not built into git (and the hassle of installing something extra)?

For a minute I confused this with another external tool: git-filter-repo [0]. It's recommended by the official manual as replacement for git-filter-branch [1].

[0] https://github.com/newren/git-filter-repo/

[1] https://git-scm.com/docs/git-filter-branch

Re: I Hate Git Submodules

#35
I use them (occasionally), but only when the pain of not using them would be greater, because they are a blue-assed bitch.

But they really do enforce a very strict version control. If we want to be absolutely sure of a version, Git submodules will give that to you.

But I only use them in one PHP backend project that I plan to barely ever change, because every change means that I have to crawl through a raft of repos, updating a submodule chain.

It's exactly the kind of operation that calls for a scripting solution, but it is also one of those projects, where I change it so seldom, that it isn't worth it to write a script.

For my frontend (Swift) work, I use SPM (Swift Package Manager). Much easier on my nerves.

Re: I Hate Git Submodules

#36
post #30

You spend all this time figuring out how to make git do what you want using this general format: git [args] You would expect to do the same thing with a submodule, it would be: git submodule [args] But no, submodules have their own set of commands. It's like it's purposefully obtuse for no good reason.

> It's like it's purposefully obtuse for no good reason. At least it's consistent with the rest of git then... Git is one of those tools I just can't muster the willpower to truly learn. I use SourceTree and hope for the best, and search the web frantically when something weird happens. I used Mercurial from only the command line for many years, never felt I needed a GUI. But git, there's just something about it.

My common advice is: bite the bullet and learn it. Specifically, delve deeper past the porcelain commands and understand what they do. Also, for a while I stopped using “git pull” and used “git fetch” and manually managed merges and branch tracking (a lot of “git reset —-hard origin/branch-name”). Once you get it, you will be a lot more productive. You’ll still have to deal with obtuse commands from time to time, but you’ll have a better model of what they should do and can check if they are doing it right.

Re: I Hate Git Submodules

#37

If you get to a point where you think you absoultely need git submodules...just switch to svn, so much pain in misery can be avoided if you just use the right tool for the right job and SVN handles the git submodule use-case effortlessly (for C++ at least). For languages with proper package management (ruby, python, go, node, etc...) put in the extra effort to utilize your package manager to update your dependencies…

Are you suggesting Svn with externals? If so how is it better than Git and submodules?

(Having used both I'd say I dislike both equally.)

Re: I Hate Git Submodules

#39

If you get to a point where you think you absoultely need git submodules...just switch to svn, so much pain in misery can be avoided if you just use the right tool for the right job and SVN handles the git submodule use-case effortlessly (for C++ at least). For languages with proper package management (ruby, python, go, node, etc...) put in the extra effort to utilize your package manager to update your dependencies…

Unfortunately "just switch to svn" is easier said than done and likely to cause more headaches than dealing with git submodules.
Post reply on HN