6 ms·

Are Git submodules really that bad? Really? Maybe it's me that haven't yet discovered their true dark side. They're not perfect, but works well for mid-sized pr

by vodou 4y ago

Are Git submodules really that bad? Really? Maybe it's me that haven't yet discovered their true dark side. They're not perfect, but works well for mid-sized projects at least.

antonvs 4y ago
They have a reputation for being bad, which is enough for a company like the one in the OP to use as a marketing hook.
xmorse 4y ago
The most annoying problem is CI, i cannot even use a private git submodule in Github Actions without creating a personal token, passing it to secret and use some git command
- dirkt 4y ago
  Which seems more a problem with Github tooling, and less with git submodules.
Dm_Linov 4y ago
That's because you haven't had all code messed up when someone pushed in the wrong order :-)
- Denvercoder9 4y ago
  How can pushing in the wrong order mess up all code? The worst thing I can imagine is pushing the superproject with a subproject update, but not pushing the subproject. That would end up with an unbuildable commit in the superproject, as you can never check out its associated commit from the subproject, but I don't see how that's close to "messing up all code".
  - Dm_Linov 4y ago
    https://codingkilledthecat.wordpress.com/2012/04/28/why-your-company-shouldnt-use-git-submodules/ https://codingkilledthecat.wordpress.com/2012/04/28/why-your... - there's a good example here
    - _jplc 4y ago
      Notice the post is 10 years old and some of the complaints can get solved with the config `submodule.recurse true` https://stackoverflow.com/a/49427199 https://stackoverflow.com/a/49427199
hobo_mark 4y ago
They're fine, so long as you do not have to fork them. Very often we have to work on multiple submodules in parallel, to make that work we use the same name for all feature branches, then our CI and tools understand that these unrelated branches in unrelated repos actually belong together, but I'd prefer not to have to do that. At least it taught me why so many big companies use monorepos.
lbhdc 4y ago
Good question, I was wondering the same. I have never really had an issue with submodules, and I am not sure what the killer feature that this adds over submodules.
witcher_rat 4y ago
They're better now than they were years ago, but yes they're still bad. And they're still second-class citizens for git commands. Git has been adding more config settings to try to make it less painful, such as submodule.recurse, but that slows down most git-command significantly and the truth is most repos don't actually need to recurse - they just need the top level. So instead people end up writing aliases to try to handle it, which works ok, but it's brittle and people have to know to do it. And if you have your repo on GitHub, they don't do some simple things that could have made it easier. For example, they could let the repo owner make the git-clone copy-to-clipboard thing have --recurse-submodules in the command you copy, so that cloning will do the right thing. But they don't. I understand why git itself doesn't want to make such things automatic, but GitHub could do it for at least private enterprise account repos. BTW, I am _not_ advocating whatever this "Git X-Modules" thing is that the link points to. I have no idea what that is, never used it, and don't plan to.
jayd16 4y ago
They're much easier to consume now than they used to be but at the same time they're usually broken by default. Adding them to a project is not seamless or invisible. They do not "just work" with the same commands your team was previously using. They're still pretty annoying to actively work in.
- ozim 4y ago
  Maybe that is the problem - you should not use them for stuff that needs to be actively changed all the time. We keep only DTOs in sub-modules so you really update it if you change property on some communication objects. This way you also don't want them to be invisible - you really want to see and have people notice this was updated and actively choose what to do with it.
Groxx 4y ago
They are implemented in a maximally safe way, which generally means they leave files / folders / etc lying around when you least expect it which goes on to cause later annoyances, because doing otherwise could mean deleting data you didn't know would be deleted. Say you're git, and someone has a submodule that goes from having: sub/ .gitignore = a/ignored.txt a/ tracked.txt ignored.txt to this, when they `git checkout` some other newer or older or totally-separate-history branch (possibly several layers above this submodule): sub/ b/ tracked.txt what do you do with sub/a/ignored.txt? What if the whole submodule was removed? Git's answer to every single question like this is to either fail to perform the submodule version change, or leave a now-untracked-and-not-ignored sub/a/ignored.txt file in the directory, which leaves you with an un-clean checkout that it'll warn and complain and possibly conflict on. It's highly unergonomic, but reliably avoids silently doing anything that might cause you to lose data. The awful ergonomics are what people generally hate about it. They'd rather it made some consistent decisions so it Just Worked™ in nearly all cases. But that's not Git-like.

by vodou 4y ago

Are Git submodules really that bad? Really? Maybe it's me that haven't yet discovered their true dark side. They're not perfect, but works well for mid-sized projects at least.

antonvs 4y ago

They have a reputation for being bad, which is enough for a company like the one in the OP to use as a marketing hook.

xmorse 4y ago

The most annoying problem is CI, i cannot even use a private git submodule in Github Actions without creating a personal token, passing it to secret and use some git command

dirkt 4y ago
Which seems more a problem with Github tooling, and less with git submodules.

Dm_Linov 4y ago

That's because you haven't had all code messed up when someone pushed in the wrong order :-)

Denvercoder9 4y ago
How can pushing in the wrong order mess up all code? The worst thing I can imagine is pushing the superproject with a subproject update, but not pushing the subproject. That would end up with an unbuildable commit in the superproject, as you can never check out its associated commit from the subproject, but I don't see how that's close to "messing up all code".
- Dm_Linov 4y ago
  https://codingkilledthecat.wordpress.com/2012/04/28/why-your-company-shouldnt-use-git-submodules/ https://codingkilledthecat.wordpress.com/2012/04/28/why-your... - there's a good example here
  - _jplc 4y ago
    Notice the post is 10 years old and some of the complaints can get solved with the config `submodule.recurse true` https://stackoverflow.com/a/49427199 https://stackoverflow.com/a/49427199

hobo_mark 4y ago

They're fine, so long as you do not have to fork them. Very often we have to work on multiple submodules in parallel, to make that work we use the same name for all feature branches, then our CI and tools understand that these unrelated branches in unrelated repos actually belong together, but I'd prefer not to have to do that. At least it taught me why so many big companies use monorepos.

lbhdc 4y ago

Good question, I was wondering the same. I have never really had an issue with submodules, and I am not sure what the killer feature that this adds over submodules.

witcher_rat 4y ago

They're better now than they were years ago, but yes they're still bad. And they're still second-class citizens for git commands. Git has been adding more config settings to try to make it less painful, such as submodule.recurse, but that slows down most git-command significantly and the truth is most repos don't actually need to recurse - they just need the top level. So instead people end up writing aliases to try to handle it, which works ok, but it's brittle and people have to know to do it. And if you have your repo on GitHub, they don't do some simple things that could have made it easier. For example, they could let the repo owner make the git-clone copy-to-clipboard thing have --recurse-submodules in the command you copy, so that cloning will do the right thing. But they don't. I understand why git itself doesn't want to make such things automatic, but GitHub could do it for at least private enterprise account repos. BTW, I am _not_ advocating whatever this "Git X-Modules" thing is that the link points to. I have no idea what that is, never used it, and don't plan to.

jayd16 4y ago

They're much easier to consume now than they used to be but at the same time they're usually broken by default. Adding them to a project is not seamless or invisible. They do not "just work" with the same commands your team was previously using. They're still pretty annoying to actively work in.

ozim 4y ago
Maybe that is the problem - you should not use them for stuff that needs to be actively changed all the time. We keep only DTOs in sub-modules so you really update it if you change property on some communication objects. This way you also don't want them to be invisible - you really want to see and have people notice this was updated and actively choose what to do with it.

Groxx 4y ago

They are implemented in a maximally safe way, which generally means they leave files / folders / etc lying around when you least expect it which goes on to cause later annoyances, because doing otherwise could mean deleting data you didn't know would be deleted. Say you're git, and someone has a submodule that goes from having: sub/ .gitignore = a/ignored.txt a/ tracked.txt ignored.txt to this, when they `git checkout` some other newer or older or totally-separate-history branch (possibly several layers above this submodule): sub/ b/ tracked.txt what do you do with sub/a/ignored.txt? What if the whole submodule was removed? Git's answer to every single question like this is to either fail to perform the submodule version change, or leave a now-untracked-and-not-ignored sub/a/ignored.txt file in the directory, which leaves you with an un-clean checkout that it'll warn and complain and possibly conflict on. It's highly unergonomic, but reliably avoids silently doing anything that might cause you to lose data. The awful ergonomics are what people generally hate about it. They'd rather it made some consistent decisions so it Just Worked™ in nearly all cases. But that's not Git-like.