Live data from Hacker News

I Hate Git Submodules

abildskov.io

61–70 of 73 posts

Re: I Hate Git Submodules

#61

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…

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.)

I mean just having all your dependencies in a mono repo and vendoring the correct version your application depends on.

Re: I Hate Git Submodules

#62

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…

Unfortunately "just switch to svn" is easier said than done and likely to cause more headaches than dealing with git submodules.

Why?

Subversion is way easier to use than git, and it takes minutes to setup a server. Pushing your project history is just a few steps with git-svn, though it may take a while depending on the size of your project.

TortoiseSVN is probably the most straightforward and easy to use version control GUI there is.

Re: I Hate Git Submodules

#63
post #30

You spend all this time figuring out how to make git do what you want using this general format: git [args] You would expect to do the same thing with a submodule, it would be: git submodule [args] But no, submodules have their own set of commands. It's like it's purposefully obtuse for no good reason.

That doesn't really make sense to me. `git submodule` is for managing (adding, removing, updating) the submodule, not for doing any random git operation on the submodule.

Re: I Hate Git Submodules

#64

Earlier quoted context omitted.

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.)

I mean just having all your dependencies in a mono repo and vendoring the correct version your application depends on.

If that's all you want, you can absolutely use git as a monorepo, and you can check in vendored dependencies just as easily.

The main downside (and I admit it can be a big one) to a git monorepo (vs. svn) is that you can't check out a subtree all that easily.

(I do agree with the parent that svn externals is a lot more seamless than git submodules, though.)

Re: I Hate Git Submodules

#65

Earlier quoted context omitted.

Unfortunately "just switch to svn" is easier said than done and likely to cause more headaches than dealing with git submodules.

Why? Subversion is way easier to use than git, and it takes minutes to setup a server. Pushing your project history is just a few steps with git-svn, though it may take a while depending on the size of your project. TortoiseSVN is probably the most straightforward and easy to use version control GUI there is.

My point is that it's easier to manage and maintain a single version control system.

> Subversion is way easier to use than git

That's subjective, I'm more familiar with git thus it's easier for me.

> and it takes minutes to setup a server.

Git doesn't even require a server to use. You can create local repos, you can pull/push to remote repos via SSH/HTTPS/etc. No specialized server software needed.

> TortoiseSVN

TortoiseGIT. (Though I prefer headless)

Re: I Hate Git Submodules

#66
post #54

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

I've been having decent luck managing my dotfiles' dependencies with `git vendor`, which is a nice porcelain around subtrees. The big win is that it keeps track of your subtrees for you and presents a sufficiently-simple interface for adding, removing, and updating vendored dependencies: `git vendor add ` to create, `git vendor update ` to update, `git vendor list` to see what you have installed and where. I haven't…

That sounds promising, but are we talking about https://github.com/brettlangdon/git-vendor ? It looks like it's been abandoned since 2016 and none of the forks on GitHub look like they have much traction. This looks even less like something I'd want to base my workflow off of than git-subrepo.

Re: I Hate Git Submodules

#67
post #54

Earlier quoted context omitted.

I've been having decent luck managing my dotfiles' dependencies with `git vendor`, which is a nice porcelain around subtrees. The big win is that it keeps track of your subtrees for you and presents a sufficiently-simple interface for adding, removing, and updating vendored dependencies: `git vendor add ` to create, `git vendor update ` to update, `git vendor list` to see what you have installed and where. I haven't…

That sounds promising, but are we talking about https://github.com/brettlangdon/git-vendor ? It looks like it's been abandoned since 2016 and none of the forks on GitHub look like they have much traction. This looks even less like something I'd want to base my workflow off of than git-subrepo.

Ugh, hadn't noticed the author went AWOL. Yeah, that's it. I've been using it without apparent issue at least that long. Now I'm not sure if I'd recommend using it, agreed. On the one hand, unmaintained software is always sketchy. On the other hand, it's actually only like two hundred lines of bash, so worst-case you just fork it and pretend you wrote a custom script to manage your subtrees like everyone else does? :/

Re: I Hate Git Submodules

#68
post #36

Earlier 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…

I guess part of the issue. I just don't interact with git enough that it matters much.

I might spend half an hour every now and then trying to figure out right incantation for this specific issue, but overall SourceTree just tells git what it needs to hear and I can carry on with what I really want: code.

Re: I Hate Git Submodules

#69
post #63
post #30

You spend all this time figuring out how to make git do what you want using this general format: git [args] You would expect to do the same thing with a submodule, it would be: git submodule [args] But no, submodules have their own set of commands. It's like it's purposefully obtuse for no good reason.

That doesn't really make sense to me. `git submodule` is for managing (adding, removing, updating) the submodule, not for doing any random git operation on the submodule.

Why is it

    git submodule update
and not

    git submodule pull

I understand pull in this context would be a submodule command, not a git command, but why use different terminology from git for what is the same idea?

Re: I Hate Git Submodules

#70
post #20

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.

I felt the same way. It didn't feel coherent at all.
Post reply on HN