5 ms·

> 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 whateve

> 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 ago
Its just confusing if you don't expect it and are thrown to submodules without any guidance
ChrisMarshallNY 4y ago
Same 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 ago
  Alone 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 ago
    I'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 ago
What 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 ago
  1. 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 ago
Why 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 ago
  I 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.

tough 4y ago

Its just confusing if you don't expect it and are thrown to submodules without any guidance

ChrisMarshallNY 4y ago

Same 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 ago
Alone 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 ago
  I'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 ago

What 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 ago
1. 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 ago

Why 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 ago
I 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.