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 <name> <repo URI> <path>` to create, `git vendor update <name> <commit-spec>` to update, `git vendor list` to see what you have installed and where. I haven't yet had to do any dev work on my vendored deps, but I suspect it wouldn't be much more difficult than anything else I've done with it.
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? :/
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?
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.
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.
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)?
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].