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 Hate Git Submodules
61–70 of 73 posts
Re: I Hate Git Submodules
#62If 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.
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
#63You 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.
Re: I Hate Git Submodules
#64Earlier 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.
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
#65Earlier 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.
> 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
#66What 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…
Re: I Hate Git Submodules
#67Earlier 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.
Re: I Hate Git Submodules
#68Earlier 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 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
#69You 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.
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
#70This 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.