5 ms·
For avoidance of confusion, a submodule is just: - committing a commit hash from a foreign repository in a text file (.gitmodules), along with - some convenie
by juped 4y ago
For avoidance of confusion, a submodule is just:
- committing a commit hash from a foreign repository in a text file (.gitmodules), along with
- some convenience tooling to check out that repository's tree at that commit in a subdirectory.
It is useful exactly when you want both of those things at once. Wanting the first is common enough, it's wanting the second that's more rare.
For example, you wouldn't submodule a Rust dependency, because you get what you want by committing the hash to a text file (Cargo.toml), and tooling to check it out in a subdirectory of your project gets you nothing.
I think the error the Git project made with submodules is trying to make them transparent, i.e., allowing you to use Git inside the submodule checkout. This is basically never a good idea; it is understandable that people get confused trying it (the thing they are trying to do is inherently confusing; if you have already been traumatized by submodules, imagine doing it with Cargo.toml or similar - it would be a mess!).
You probably don't want submodules. But they're useful, and not at all broken or poorly specified.
- michaelmior 4y ago> This is basically never a good idea I find this to be one of the most useful features of git submodules. I can easily just cd into the module and do whatever related work I need to do there and then commit to both projects when I'm ready.
- tough 4y agoIts just confusing if you don't expect it and are thrown to submodules without any guidance
- ChrisMarshallNY 4y agoSame here. Like I said above [below?], I generally despise submodules, but that is one thing that makes them easier to deal with, than packages. For example, in the project that I'm working on now, I have refined the app's "business logic" to an SPM module that I integrate, through GitHub. The idea is that I don't change the logic, and I enforce that, by using it as an SPM module. However, every now and then, I encounter a bug in this module, or I find the need to add something to its API. When that happens, I need to exclude the module from the dependency list in the project, include it directly, as a local link, and work on it that way. Committing is a separate task from the main app (Xcode allows aggregate commits, but Xcode's Git integration is so poor, that I don't use it). It actually works well. A submodule would also work well, with more Git integration, but the drawbacks far outweigh the advantages.
- jeffreygoesto 4y agoAlone is ok. You know what you want and own that work flow. North of maybe five people this tends to break down fast.
- galangalalgol 4y agoI've had it work fine on large teams. The rule for me is that if contributors to the repo are as likely to change the submodule as the repo itself to resolve any given issue. More succinctly, submodules are for internal dependencies we might change. The reason being that with some package managers and languages doing small incremental changes to a dependency as you try to resolve an issue is a lot of extra typing vs it just being in a submodule.
- Izkata 4y agoWhat confuses me is that people complain so much about git submodules, but I can't recall ever hearing complaints about svn externals. They're pretty much the same thing. Co-workers who have moved from svn to git have had no trouble understanding and working with git submodules.
- Macha 4y ago1. Git is much more common in the wild, so more people have opinions on it. 2. Git submodules are occasionally used, but svn externals is something I'd never seen used back when I was on svn using teams. To be complained about, something must be known about, and I think for most developers, svn externals isn't known about
- luc_ 4y agoWhy wouldn't you just keep a local version? Do you have a "top git project" for checking out others? Seems like it could be convenient, I suppose.
- michaelmior 4y agoI usually do this when I'm developing one project that has a third-party dependency which either doesn't have a release, or I need to make modifications. That way I can work on the dependency and easily keep track of what version is used in the parent project at any point in history.
- solarkraft 4y agoI have a convenience project that sets up several others repositories for ease of development and the things you call rare/a bad idea are perfect for this use case. It's working very well so far.
- dezgeg 4y agoFor that use case, how often do you want the other repositories to be fixed to some particular hash, however? At least every time I've wanted such multi-clone behaviour I've wanted to have all the repositories on HEAD of some branch, and very rarely some fixed commit.
- k0k0r0 4y agoI do generally want a fixed commit. I often want to improve the code in the submodule possibly (voluntarily or accidently) introducing breaking changes without worrying about breaking repos that contain it as submodule.
- solarkraft 4y agoDuring development I don't really care, but every once in a while I commit them so that there's a known-good configuration to start over with.
- baby 4y agoI don't think I would agree with that statement. I would say that both are actually what most people want when using submodules, otherwise you would just vendor your dependency. I would also agree with OP that submodules are horrible. Source: I have to deal with them everyday in my company's repo and they cause issues pretty much every time I pull, switch branches, merge/rebase, etc. IMO, one of the MAIN issues with submodules is that there isn't an actual FILE, checked in the repository, and understood by Git, that lists the hash of all the submodules used. So diffs and PRs on Github, git, etc. don't show the actual changes in a way that we're already used to with files.
- stefantalpalaru 4y ago> committing a commit hash from a foreign repository in a text file (.gitmodules) No, that file is just for submodule URL, path, branch and options. The submodule's target commit hash is stored in the superproject's ".git/modules/[path here]/HEAD".
- juped 4y agowell, no, it's an entry in the tree object