Disagree. Package managers cause more headache than anything. I have used submodules for almost all of my projects (aside from e.g. Node.js projects). Not once have had issues with them.
I don't know why people raise such a stink about them.
> I have used submodules for almost all of my projects (aside from e.g. Node.js projects). Not once have had issues with them.
Do you do things with git beside the trivial operations (add/commit/etc.)? Like rebasing/merging and such across commits that introduce or remove submodules? Do you never encounter friction when e.g. removing submodules? Do you never run into the errors people complain about?
I absolutely despise submodules, but under many use cases you don't add or remove that often. We definitely run into errors people complain about. In fact there are errors that the average user (that doesn't really care about SVC) pretty much can't fix... or with much difficulty. I don't know that I'd still say it's a dealbreaker, but that's definitely very bad. Very much does break some of the spirit of git and what makes it "nice".
We've been using them, and our system is still very usable (obviously this is a ridiculous thing to brag about, but worth pointing out).
I'm wondering if there's a better way to handle shared code between two repos, where the users of either don't have access to the other parent? You might be able to use subtrees? Email source code and just create n separate commits for n projects, with a standardized commit message?
I'd be happy to do something different, but I never had some idea that I could sell in a meeting, and didn't really have the energy or clout to fight this.
Basically is what (I think) submodules should have been. Creates a vendored copy with metadata about what commit it came from. Normal operations like clone, commit (even touching multiple main/subrepo files which subtree struggles with) are unaffected (normal files from git's point of view).
Pull, push, branching all work as expected on main project (most devs don't even need to know there's a subrepo). If you want to pull/push vendored changes from subrepo, there's a new command, but that's it.
As Izkata mentions, the superproject has _all_ the files for a given commit without any need for users to have access other repos, additional submodule init commands, etc.
Basically, after a subrepo clone, you've copied the file tree for the subrepo and can make commits on it in the superproject to your heart's content (branching, etc). This is basically a fork/mirror, but adds a single metadata file to track the last upstream commit you pushed/pulled from to allow reconciling later. So with git subrepo, you make commits in the superproject first and can choose (at some later point, if at all) to merge with the subrepo upstream. This is arguably consistent with the git model writ large (make local commits, later choose if/how to integrate those with upstream). Importantly, people that clone your superproject repo don't have to know anything about subrepo or special commands to send changes back to you.
For submodules, changes flow in the other direction. If you want to make a change to the child repo, you must 1) commit in the submodule, 2) push the submodule commit to its upstream, 3) make a commit in the super project that changes the commit the submodule is pointing to. When someone pulls, switches branches, etc in the superproject, they need to do a submodule update with various failure modes or else they end up with empty/out-of-date content.
Subtrees are a bit similar to subrepos, but in practice you still need to be aware of their boundaries since you can't mix subtree/superproject modifications in the same commit. Moreover, you need to use a special merge strategy rather than git default merge/rebase which subrepo uses.
I can't answer in general, but I do see one possible misunderstanding: "vendored" means the code is copied into the parent repo.
If a submodule's original source goes offline, a new clone of the parent repo won't be able to retrieve it, since it just stores a reference to where to clone from. If subrepo really vendors the code, that'll never be a problem since a full copy is committed directly to the parent repo.
> I'd be happy to do something different, but I never had some idea that I could sell in a meeting, and didn't really have the energy or clout to fight this.
Would the alternative I suggested here work? I think you might even be able to do it in tandem with submodules so you try out both and see what works for you:
> Do you do things with git beside the trivial operations (add/commit/etc.)? Like rebasing/merging and such across commits that introduce or remove submodules?
Yes, often (I'm a stickler for clean histories on my projects). The trick is to only work with submodule refs during any sort of complex series of commands, then update the submodules once all of the ref munging is done.
If you have a ref conflict or something (rare IME, unless you're running git commands haphazardly, without understanding them), the error message tells you exactly which ref it couldn't check out and why - in which case, simply cd in and fix it manually.
If you need to move submodules around, `git submodule --deinit` it first, then re-add it.
If you need to remove one, deinit it then make sure it's purged from .gitmodules.
> Do you never encounter friction when e.g. removing submodules?
Nope, though admittedly the commands need some polish here. Worst case, remove the directory in the working tree, remove the entry from .gitmodules, delete .git/module/x/y/z/, then add -A the now-deleted worktree path and your .gitmodules.
> Do you never run into the errors people complain about?
Not since I sat down and read through the concepts section on the official Git docs, which outline what e.g. objects, trees, commits, tags and refs were, no.
Git submodules are up there on the list of the most misunderstood (but entirely useful) features ever, in my opinion.
> The trick is to only work with submodule refs during any sort of complex series of commands, then update the submodules once all of the ref munging is done.
So you don't actually check out the submodule, ok. But this means you can't actually use the correct submodule commit during the rebase? Like trying to build with it to check if it works before continuing?
> Nope, though admittedly the commands need some polish here. Worst case, remove the directory in the working tree, remove the entry from .gitmodules, delete .git/module/x/y/z/, then add -A the now-deleted worktree path and your .gitmodules.
How do you admit this and yet simultaneously say "I don't know why people raise such a stink about them" and "Not once have had issues with them"? You somehow know there are pain points, you know the various workarounds which can consist of N hoops to jump through, and yet you claim you haven't encountered issues even once and don't even understand what people dislike about submodules? Aren't these clearly contradictory?
> Not since I sat down and read through the concepts section on the official Git docs, which outline what e.g. objects, trees, commits, tags and refs were, no.
I'm pretty sure I know what all of those are and still find submodules painful.
> But this means you can't actually use the correct submodule commit during the rebase?
You can update during an interactive rebase if you need to, why not? I've never personally needed this but given how rebases work then an update should be possible if you need to.
> How do you admit this and yet simultaneously say "I don't know why people raise such a stink about them"
Because the lack of a simple removal command does not warrant the "avoid submodules at all costs" sentiment currently the top voted comment on this thread.
> You somehow know there are pain points, you know the various workarounds which can consist of N hoops to jump through,
There are places to improve commands. That's it. And the only hoop I have to jump through is a removal of a stubborn submodule the need arises.
> Aren't these clearly contradictory?
No. The world isn't a dichotomy; both things can be true.
> I'm pretty sure I know what all of those are and still find submodules painful.
A submodule is just a ref, just like a tag. Init and deinit can be finicky, that's about it. If you fully understood refs, then submodules shouldn't be that difficult to reason about.
> You can update during an interactive rebate if you need to, why not?
You said your "trick" is to explicitly not update the submodules until you've finished the rebase? By definition that means you're not updating the submodules during the rebase...
> Because the lack of a simple removal command does not warrant the "avoid submodules at all costs" sentiment currently the top voted comment on this thread.
It's not just removal, though removal is definitely a big chunk of it. See last paragraph.
> No. The world isn't a dichotomy; both things can be true.
The world isn't a dichotomy, but you "admit the commands need some polish" and then propose a 4-step workaround for issues you've "not once had"? Did you not encounter issues at some point to lead you to propose workarounds and conclude commands need polishing?
> A submodule is just a ref, just like a tag. Init and deinit can be finicky, that's about it. If you fully understood refs, then submodules shouldn't be that difficult to reason about. What, specifically, do you find "painful"?
I don't think you understand how annoying it is for submodules not to add/remove/update seamlessly. Maybe you only use submodules for your own personal projects and rarely modify them so you rarely see the effect. But especially in a team project that's evolving constantly and the submodules aren't frozen, and especially in projects where you have to go mess with your own submodules to figure out if to-be-proposed changes to dependencies will actually do what you want, having to constantly go out of your way to make sure everything is committed and synced properly every single time you check out a new commit gets annoying fast. Especially when you don't even know what commits contain submodule changes to begin with.
You're assuming a lot about me so I don't really feel like spending time answering in depth. You seem to hold a strong opinion you're not willing to change, and while that's fine, I don't appreciate being told I'm somehow not qualified to have a differing opinion when that is very clearly not the case.
> You said your "trick" is to explicitly not update the submodules until you've finished the rebase? By definition that means you're not updating the submodules during the rebase...
A "trick", not a rule. If you need to check submodules during an interactive rebase, fine, do it. Nothing is stopping you, and it should work fine.
> The world isn't a dichotomy, but you "admit the commands need some polish" and then propose a 4-step workaround for issues you've "not once had"? Did you not encounter issues at some point to lead you to propose workarounds and conclude commands need polishing?
For 1 issue, of which I feel could definitely have a better command. You're arguing semantics at this point. I've not had issues where I'm so stuck they're impossible to use or to fix, like so many others here claim they do.
> I don't think you understand how annoying it is for submodules not to add/remove/update seamlessly.
I don't think you understand how submodules work, at all.
> Maybe you only use submodules for your own personal projects and rarely modify them so you rarely see the effect.
You assume incorrectly.
> But especially in a team project . . . and . . . projects where you have to go mess with your own submodules . . . having to constantly go out of your way to make sure everything is committed and synced . . . single time you check out a new commit
You're using submodules incorrectly, then. Learn what worktrees are if you don't. Learn what directory remotes are. Learn how to use multiple remotes, even.
None of what you're saying is a result of bad Git design. It's a result of you not knowing how Git works, or how to use it effectively. Git gives you all of the tools to use submodules effectively (e.g. testing changes without commiting, or testing changes directly in a submodule, etc.)
Wow. I'm not "assuming" anything about you, I'm going literally off what you wrote ("I'm a stickler for clean histories on my projects" when I asked if you use git non trivially...) and even then I said maybe this is why, and even then its truth or falsehood had absolutely zero bearing on the correctness of my points. And that was literally just 1 thing, not "a lot". For someone trying to be accurate you exaggerate like there's no tomorrow, and that's been part of the very issue from the very beginning of the discussion.
Meanwhile the person who's been patronizing me and everybody else this entire time is you. Pretending like you're the only one who understands git and me and the rest of the world doesn't. You both go out of your way to trash my understanding of the entirety of git (not only do I not understand how submodules work but I don't understand remotes either? seriously?) with absolutely zero basis and also get offended that I said maybe you're simply not using git in the same kinds of projects that others do and hence that might be why you're not realizing why the problems are such a big deal to other people you've been looking down on before I even started replying? Your entire thesis is always that nobody but you has read the manuals or understood git, and yet I'm the one with a strong opinion unwilling to change? Really?
Yes, obviously I don't understand anything in git and the problem is in fact that nobody understands anything about git except you; it can't be any other way.
I don't know why people raise such a stink about them.