git subtree
They came about because everyone hates submodules.
I Hate Git Submodules
41–50 of 73 posts
Re: I Hate Git Submodules
#42I've been the git fixer for a few different teams. I want to like submodules, but there's something that doesn't fit my brain the way the rest of git does. It feels half-baked. I think we're still missing the best way to model the problem as a tree of related states.
They feel like an unfinished tool provided by a third-party, not a built-in component of git.
The simple fact that switching branches doesn't auto update the submodule is awful.
Re: I Hate Git Submodules
#43I've been the git fixer for a few different teams. I want to like submodules, but there's something that doesn't fit my brain the way the rest of git does. It feels half-baked. I think we're still missing the best way to model the problem as a tree of related states.
Everything about git feels half-baked tbh
Re: I Hate Git Submodules
#44Clickbait title. The author literally says "Spoiler alert. I do not hate submodules." and also later recommends submodules for language ecosystems that don't have built-in package managers.
The author also gives (IMO) 2 weak reasons against submodules.
(1) He says its hard to know which repo you're editing (main repo or submodule). I agree, but in practice this hasn't been an issue for me. A simple `git status` or `pwd` is usually enough to know which repo I'm editing.
(2) The author also says that committing changes with submodules can be confusing since it involves multiple commits: one commit in the submodule, and another in the main repo to update the commit it points to. I agree this is a little confusing at first and definitely tedious, but conceptually I think it is pretty simple.
That said, I do agree that submodules are confusing -- just for different reasons.
My main gripe with submodules are that they don't work well with the rest of git. Why isn't adding a submodule just a `git add` to a directory with a git repo inside of it? If there are new commits in a submodule, why doesn't `git checkout .` reset it back to the commit the main repo points to? If I clone a repo with submodules, why do I need to run additional submodule commands to get an exact copy of the codebase? Basically, to me it feels like submodules were slapped onto git as an afterthought and little care was taken to think the git CLI experience as a whole. I think submodules would be a lot less confusing if git had designed a better CLI for it.
Re: I Hate Git Submodules
#45I don't see the point of submodules. If you want to make a change in another repo, do that. If you want to reference a specific version of another package in your code, do that. When would I want submodules?
Re: I Hate Git Submodules
#46What do people think of git subtrees? https://codewinsarguments.co/2016/05/01/git-submodules-vs-gi... Or the non-standard git-subrepo? https://github.com/ingydotnet/git-subrepo
I tried subrepo and ran into some dumb error right away. I went with subtree and it worked well, but I needed to write a script for others to use it to update (but the system already had one, just didn't work well). I just can't say it is okay to not have a script like nobody has a script for git pull.
Re: I Hate Git Submodules
#47I can only speak for myself. In the roughly 12 years I've been using git at multiple different companies and for my own projects, I have never used git submodules. I feel like I have a good, well rounded set of experiences too. Code bases big and small, massive monorepos, and many microrepos all separate. In none of them have we used submodules.
That being said, maybe submodules would have solved some problem here or there that we had. I'm open to arguments in favor of them in that case. But we've always been able to get the work done without them, so I don't personally think they're indispensable.
Re: I Hate Git Submodules
#48I've been the git fixer for a few different teams. I want to like submodules, but there's something that doesn't fit my brain the way the rest of git does. It feels half-baked. I think we're still missing the best way to model the problem as a tree of related states.
Everything about git feels half-baked tbh
I agree with a half baked UI. It feels like they kept on tacking on more and more commands and flags to get to where we are today. But the fundamental data structures the UI operates on are rock solid though. I'm actually surprised more software doesn't use git's internals for things besides version control.
Re: I Hate Git Submodules
#49Earlier quoted context omitted.
> 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…
The Git command line interface is confusing, but Git's data structure design — a content addressable store — is relatively simple (and very interesting!).
I went through the book Pro Git three times leading three different training groups, and I was pretty comfortable with it. But what took me to the next level was prepping a talk for Papers We Love San Diego which explores everything that happens inside the `.git` directory when you initialize a repo and perform a couple basic commits: https://www.youtube.com/watch?v=fHSZz_Mx-Uo
Re: I Hate Git Submodules
#50I've been the git fixer for a few different teams. I want to like submodules, but there's something that doesn't fit my brain the way the rest of git does. It feels half-baked. I think we're still missing the best way to model the problem as a tree of related states.
They feel like an unfinished tool provided by a third-party, not a built-in component of git. The simple fact that switching branches doesn't auto update the submodule is awful.
You can change that behavior now in newer versions of git:
git config --global submodule.recurse true