[HN Gopher] I Hate Git Submodules
___________________________________________________________________
I Hate Git Submodules
Author : Addono
Score : 76 points
Date : 2021-03-28 19:32 UTC (3 hours ago)
(HTM) web link (abildskov.io)
(TXT) w3m dump (abildskov.io)
| qznc wrote:
| It believe it is a question of maturity. If the subcomponent is
| mature enough, then turning it into a package is fine. The cost
| is that patching the subcomponent and testing the main component
| takes more effort (though you can script it). With submodules at
| least the build and test cycle is as quick as if it is in the
| same repo.
|
| So there is a scale from quicker iteration to less coupled: same
| repo, submodule, different package. The question is in which
| cases the middle step "submodule" is worth it or if you should
| rather switch to one of the others always.
| weitzj wrote:
| Exactly what I am thinking. My use case is to have a shared api
| repository containing an IDL (here protobuf/grpc) and you hook
| it up as submodules for iOS, android, Golang. The round trip
| time is reduced compared to creating and publishing modules for
| each generated code. This makes it far easier to experiment
| with a new api feature so one gets a better feeling how this
| behaves in each language. And if the api is mature enough you
| might as well change your development flow into publishing
| modules instead of using git submodules.
|
| Therefore I like submodules and would argue that people might
| underestimate the increased round trip time for publishing
| modules and then referencing them in code compared to using
| submodules
| ChrisMarshallNY wrote:
| I use them (occasionally), but only when the pain of not using
| them would be greater, because they are a blue-assed bitch.
|
| But they really do enforce a very strict version control. If we
| want to be absolutely sure of a version, Git submodules will give
| that to you.
|
| But I only use them in one PHP backend project that I plan to
| barely ever change, because every change means that I have to
| crawl through a raft of repos, updating a submodule chain.
|
| It's exactly the kind of operation that calls for a scripting
| solution, but it is also one of those projects, where I change it
| so seldom, that it isn't worth it to write a script.
|
| For my frontend (Swift) work, I use SPM (Swift Package Manager).
| Much easier on my nerves.
| erik_seaberg wrote:
| I'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.
| Pxtl wrote:
| 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.
| kasbah wrote:
| You can change that behavior now in newer versions of git:
| git config --global submodule.recurse true
|
| https://stackoverflow.com/questions/1899792/why-is-git-
| submo...
| neolog wrote:
| Everything about git feels half-baked tbh
| spicybright wrote:
| 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.
| [deleted]
| colechristensen wrote:
| Agreed. I also want to like submodules but every encounter with
| them has been an awkward confusing mess.
|
| They're fine if they are completely hidden from human
| interaction and used in a programmatic way, but the human
| interface with the concept seems to always be so awkward.
| cryptica wrote:
| I also hate monorepos. I consider the monorepo to be an anti-
| pattern.
|
| It's an architectural advantage to separate each module into a
| different repo as it encourages careful separation of concerns.
|
| If you find that you often need to update many modules together
| every time you want to add a new feature to your project, this is
| often an indication that your modules do not have proper
| separation of concerns and your abstractions are leaking. It
| means your project exhibits low cohesion and/or tight coupling
| between modules.
|
| The difficulty in maintaining separate modules is actually a very
| useful signal to you as a developer that your code was poorly
| designed and it needs to be refactored.
|
| Monorepos are a bandaid patch solution which covers up the root
| problem. The real problem is incorrect separation of concerns,
| AKA low cohesion which leads to tight coupling between your
| components.
|
| It's not possible to design simple interfaces between components
| when these components have overlapping responsibilities.
| colesantiago wrote:
| then don't use them?
| PaulBGD_ wrote:
| > Spoiler alert. I do not hate submodules. I do how ever have
| an instant oh oh response when people mention they want to
| solve a problem with Git submodules.
|
| First line of the article explains the title.
| colesantiago wrote:
| > Why I hate submodules.
|
| > Spoiler alert. I do not hate submodules.
|
| Clickbait much? Make up your mind?
| allo37 wrote:
| About the point of it not being obvious where you're working: I
| find using zsh or another shell that prints git information as
| part of the shell prompt helps immensely with this.
| yuppie_scum wrote:
| They are a nightmare
| [deleted]
| audunw wrote:
| It might be worth looking at West, used by Zephyr (embedded
| RTOS): https://github.com/zephyrproject-rtos/west
|
| Not sure how mature it is or if any other projects use it. But
| seems to be working well for Zephyr.
| SavantIdiot wrote:
| I was hoping to see better solutions to this problem in the
| comments, but the paucity of a solid solution means the problem
| isn't solved yet. I agree with `qznc` below, in that once
| maturity is achieved, the monorepo should x-furcate and create
| packages, but up until that point there really is no clean
| solution for this relational concept.
| skyfaller wrote:
| What 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
| attah_ wrote:
| Terrible. You can't tell that they are there and no tool
| support in remembering the remote.
| new_realist wrote:
| +1 for subrepo.
| skyfaller wrote:
| My concern with subrepo is that I have no idea who is
| developing it and how much resources they have. I'd hate to
| learn to use a tool central to my development workflow and
| then have it discontinued.
|
| Is git-subrepo good enough that it's worth the risk of using
| something not built into git (and the hassle of installing
| something extra)?
| Kinrany wrote:
| For a minute I confused this with another external tool:
| git-filter-repo [0]. It's recommended by the official
| manual as replacement for git-filter-branch [1].
|
| [0] https://github.com/newren/git-filter-repo/
|
| [1] https://git-scm.com/docs/git-filter-branch
| ddevault wrote:
| I came here to recommend subtrees. They're pretty good.
| skyfaller wrote:
| I guess my concern about subtrees is that they seem like they
| can result in unnecessary duplication / use of disk space.
| But the ability to work offline with a complete copy of the
| code seems worth the tradeoff in most cases, and git-lfs
| should help deal with large file sizes.
|
| Have you run into any "slow push speeds" with subtrees, as
| the person complains about in the first article I linked?
| ddevault wrote:
| No, I haven't run into any such issue, though I have only
| used it with small to medium sized repositories. The repo
| simply grows linearly with the size of the secondary
| repository. With a submodule, you would have to clone it
| just the same. In fact, you might enjoy some benefits from
| cross-compression by using subtrees that would not be
| available to submodules, and it's faster to reuse the same
| clone connection you were already getting the source from.
| coryrc wrote:
| 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.
| suzzer99 wrote:
| They are a pain but they come in handy for us.
|
| The main thing I learned is if you mess up any part of your
| submodule during creation - do not try to fix it. Just delete it
| from the parent repo and start over.
|
| Also do not bother deleting it using git commands. Delete it in
| the .gitmodules file, then search your .git folder for every
| reference of the repo you want to delete (including folders named
| after it) and delete everything.
|
| Either that or start with a clean parent repo clone.
| attah_ wrote:
| At least it is better than subtrees, which cannot tell you what
| they are even if you ask. Also, ClearCase isn't atomic beyond
| file level even... you use labels to make "versions".
| timzaman wrote:
| I've been maintaining a git repo at my current and previous
| employer - both started out with submodules, and got axed due to
| added complexity and cognitive load. After removal, they were not
| missed. Case closed.
| tarkin2 wrote:
| git subtree
|
| They came about because everyone hates submodules.
| zffr wrote:
| Clickbait 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.
| ajkjk wrote:
| This post is really hard to read. It mentions git submodules and
| then sharply veers into a bunch of seemingly barely-related
| paragraphs. If each section had one sentence at the top saying
| something about git submodules it would be a lot more coherent.
| snarfy wrote:
| You spend all this time figuring out how to make git do what you
| want using this general format: git <git-
| command> [args]
|
| You would expect to do the same thing with a submodule, it would
| be: git submodule <git-command> [args]
|
| But no, submodules have their own set of commands. It's like it's
| purposefully obtuse for no good reason.
| magicalhippo wrote:
| > 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.
| ghayes wrote:
| 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 you'll have a better model of what
| they should do and can check if they are doing it right.
| rectang wrote:
| 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 what
| 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
| neolog wrote:
| I 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?
| rc_mob wrote:
| i wish git would implement a built in subsplit feature
| fiddlerwoaroof wrote:
| That's basically what the subtree commands are, no?
| geuis wrote:
| I 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.
| crb002 wrote:
| Also hate them. Far better to have a dependency pulling shell
| script - no overhead of git yak shaving - just maintaining the
| URIs.
| tadfisher wrote:
| If you can wrap your build in Nix, I highly recommend it. The
| upcoming "flakes" feature handles pinning Git-hosted
| dependencies and locking revisions, even if they aren't Nix
| flakes themselves.
| omarish wrote:
| Everybody hates git submodules.
| rubyist5eva wrote:
| If you get to a point where you think you _absoultely_ need git
| submodules...just switch to svn, so much pain in misery can be
| avoided if you just use the right tool for the right job and SVN
| handles the git submodule use-case effortlessly (for C++ at
| least).
|
| For languages with proper package management (ruby, python, go,
| node, etc...) put in the extra effort to utilize your package
| manager to update your dependencies instead of bothering with
| submodules. If you're still set on doing submodules, I'm willing
| to be you're just "doing it wrong" (TM).
| paulryanrogers wrote:
| Are you suggesting Svn with externals? If so how is it better
| than Git and submodules?
|
| (Having used both I'd say I dislike both equally.)
| pfundstein wrote:
| Unfortunately "just switch to svn" is easier said than done and
| likely to cause more headaches than dealing with git
| submodules.
| nix23 wrote:
| Me too, and that's why i work whenever possible with BitKeeper
| and nested repositories.
___________________________________________________________________
(page generated 2021-03-28 23:00 UTC)