I've spent a lot of time ripping out git submodules from repos my teams use, but I've spent an equally large amount of time wondering why there doesn't seem to be a better option for managing arbitrary dependencies across repos in the Year of Our Lord 2024. So, I put together a really early version of such an arbitrary-dependency manager. It's called vdm, and you can find it in the linked URL above & below.
I'm sharing mostly because I'm curious if I'm blatantly missing some other tool that exists that isn't language-specific (like Bit for JS seems to be, for example), but also in case people have any hot-takes or feedback on the functionality as listed in the README.
Also of note is that I'm not sharing to potentially monetize or "generate customer interest" or anything -- I'm just another builder on the internet.
Thanks for looking, and let me know if you have any questions!
If you're looking for alternatives, here's something we've built (hope I'm not hijacking this): https://github.com/audiotool/pasta
It's called "pasta" for copy pasta. It was built with exactly the same motivation aa yours, also has a yaml config file, and is also implemented in go, kinda interesting. If yours takes off and we can drop ours, that'd be awesome!
For some feedback in features we have which we thinkg we'd be missing:
- we have the ability to copy individual files and specific subdirectories of other repos, not the entire repos
- mechanics to "clear" the target directory, in case a file gets deleted upstream, to keep the directories in sync
- we've modelled it with a plugin API, so you can implement new "copiers" for bitbucket, google drive, subversion, ...
- the github plugin we have uses the Github API for better performance, and you can add auth by setting an env var GITHUB_TOKEN
We also create a "result" file of every copy, noting the exact commit that was copied, which might or might not be a useful... Were thinking of posting it here at some point but never got around to it. Again, if yours takes off, that'd be the best option :)
We're using it mostly to copy .proto definitions from one repo to another.
They have a ton of problems in my experience, a few off the top of my head:
- They force the specific repo url, e.g. ssh github even if you prefer to clone by http.
- Pulling from remote becomes difficult when submodules change, e.g. when a submodule is merged into main repo and becomes a proper subdir.
- git commands such as `git checkout -- .` don't work properly on them and I don't see how configs could change that.
I second the sentiment. Git submodules work just fine. The UX could use some work. It baffles me why bolting on convoluted tools is considered a preferable alternative.
In that respect, it resembles git-subtree with --squash, but differs from git-submodule or regular git-subtree.
Cool info though, thanks for sharing!
Maybe a better approach would be to rename the `.git/` to (for example) `.vdm` in each submodule? Each `vdm` command would first rename it back to `.git`, execute the git commands needed, and then rename it back to `.vdm/`.
This gives you the ability to implement `vdm history` or similar command while still keeping the submodule invisible to the parent?
https://github.com/fviard/svn_xternals
Despite the README saying that it is a work in progress, the tool is functional for a few years already. Also, again despite the name, it works with GIT.
The idea is to be able to use the concept of "externals" from SVN transparently with svn or GIT. It does something similar to what Google "gclient" was doing but in a more efficient way (ie a lot faster and consuming a lot less resources).
To use it, you just need to create a file ("externals.conf" in your project for example), in a format like that:
externals.conf
git@github.com:user/myproject_core.git myproject/core
git@github.com:user/myproject_plugins_onething.git myproject/plugins/onething
git@github.com:anotheruser/another_thing.git@mybranch myproject/plugins/another_thing
git@github.com:corpuser/random_library.git@release-tag-123 myproject/vendor/random_library
And it will take care to do automatically the git clone, or pull, or "switch" if you change a branch/tag indicator in the externals file.
Like that, you can easily commit a externals.conf file in a root project folder, and individually manage the version of sub-components that can be hosted anywhere.
The "externals.conf" file is a plain text file so easily to read and diff to compare different versions of your project.
> This git command clones an external git repo into a subdirectory of your repo. Later on, upstream changes can be pulled in, and local changes can be pushed back. Simple.
https://github.com/ingydotnet/git-subrepo
After trying many similar solutions, it gets the closest to what I want to achieve, which is nested Git repositories. A project with subprojects, each of which can be an independent Git repo with its own history to push/pull, while the project itself has the entire codebase and history.
It's written in Bash, so fairly portable.
---
Edit: After skimming through the project vdm, I see the problems it aims to solve are different from what git-subrepo does. The latter is more about monorepos. Ah well, that's what I get for commenting before reading the post.
vdm does look useful for managing a project with external dependencies, which are Git repos owned by others or oneself. Maybe like a language-agnostic package manager.
I poured my heart and soul into it[2] but it wasn't very popular. I guess there's not much need for a dependency manager that's not tailored to the needs of a particular community, like a platform or language.
What collaborative tool would you recommend using with vdm? AOSP has gerrit which is sort of specifically designed for this multi-remote meta setup. GitHub/GitLab don’t play nice with this type of environment.
Repo seriously sucks to use, but I also can't imagine many tools living up to AOSP-type workloads without being specifically designed for it. My gripe with repo is that it's really hard to pin the entire repo state if you have a bunch of prototype patches across multiple subrepos. I usually end up having to modify the XML directly.
I think you nailed how I was feeling in much fewer words!
I actually haven't really put much thought into collaborative/mutlirepo development work using vdm -- the original intent was for it to strictly be a retriever of what the user specifies. I think the majority of both my frustration and complexity of other tools is because they're trying to solve for a lot more than at least I personally usually want to use them for. It's like, I just want a `pip install/requirements.txt/go.{mod,sum}` for any kind of tool, not just the language that takes up the majority of my codebase.
One of the thoughts I had, though, was to maybe add a field for each remote section called e.g. `try_local` that takes a filesystem path, and if that doesn't exist then fetch the remote. That way, your development workflow is exactly the same as usual -- developing a dependency is just doing work in the actual repo directory nearby. I'm not married to the idea though. I just REALLY don't want to have it be in the business of managing git-repos-in-git-repos, because vdm isn't really intended to be a Git tool, if that makes sense.
In addition, other tools can also do this to varying degrees of success, like Bazel and cmake.
To solve it we use git-aggregator (I am not the autor) (language agnostic too). It seem to have the same features as VDM + some extra one (possiblity to have a frozen file, possibly to apply patch/pr...)
This allows you to treat common code in a repo as just a normal part of the repo. However, the common code is also in a repo of its own. This tool then allows you to push / merge your changes back to the common repo.
Check the git page for a list of the benefits.
If I could have submodules that operated that way I think submodules would be a lot more straightforward to newcomers.
box = !cd ${GIT_PREFIX:-.} && git config --get remote.origin.url > .gitboxinfo && git rev-parse --abbrev-ref HEAD >> .gitboxinfo && git rev-parse HEAD >> .gitboxinfo && mv .git .gitbox && git add -f .gitboxinfo && true
unbox = !cd ${GIT_PREFIX:-.} && mv .gitbox .git && true
If you ever need to regenerate the gitbox folder from scratch you can take a peek at the gitboxinfo file and git clone and reset the dependency repo in a temp folder, then move the git folder next to the gitboxinfo file.
Plus unlike submodules with this you can have local changes to the submodule files without having to fork the submodule itself.
1: A setup.py that installs dependencies like this:
pip install git+https://github.com/dependency/repo
?
version pinning, no extra install needed, works offline, zero deps headaches.
Example: requests.packages.*
Otherwise, I would be interested, how you "copy" a git repo that goes into your vendor dir. Where you put the list of repos that need to get copied. Which command you run to copy them all. How you handle it if they have sub-dependencies and how those get installed in your workflow.
Regarding the name, I’m French, and VDM basically means FML in French.
Personally I don't see the difference between this and submodules. Repo stores the information in xml files, vdm stores it in yaml files and git submodules in the git database. I don't really care.
The real headache for me is the trouble of traceability vs ease of use. You need to specify your dependencies with a sha1 to have traceable SLSA compliant builds, but that also means that you'll need to update all superrepos once a submodule is updated. Gerrit has support for this, but it's not atomic, and what about CI? What about CI that fails?
I care about the aesthetics and the convenience that the tool provides. git-repo at least has a simple command to get all the latest stuff (repo sync). Git submodules is a mess in this regard. Just look at this stack overflow thread:
https://stackoverflow.com/questions/1030169/pull-latest-chan...
People are confused at how to do THE most basic command that you’d have to do every single day with a multi-repo environment. There’s debating in the comments about what flags you should actually use. No thanks.
There’s a lot of room for improvement in this space. git-repo isn’t widely used outside of aosp. Lots of organizations are struggling with proper tooling for this type of setup.
Also, the discussions are there because it's been more than a decade and the options have evolved over time.
Submodules are a bit clunky but the problem it solves is itself clunky. Bringing in another tool doesn't really feel like its going to reduce the burden.
I have yet to be in a situation where I blindly want to update all submodules. It is a conscious action, X has updated and I want to bring that change(s) in.
cd submodule, update, test, commit.
I haven't seen anything in this thread that really motivates me to learn another bespoke tool just for this. I'm sure it varies for different projects though.
Fast forward 15 years and see how the tooling this thread has been evolved and how many different tools people will have used and compare that to the stackoverflow post. I'm more inclined to invest time in git itself.