Show HN: Vdm, a sane alternative to e.g. Git submodules

Nice!!

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.

Probably unpopular opinion: git submodules are just fine. They're "just" lacking a consistent UI. They have improved over the years, but the default config sucks because the defaults emulate the original, awful, UX. With proper configuration, it's much better, although there are still pain points (like rebase conflicts in non-submodule parts messing things up if you don't git submodule update)

If it just clones the repos and removes the .git directories, then I assume it doesn't keep their commit history? So if you use e.g. `git blame` or `git log` to look at file history, you will see when changes were introduced to the parent repo, but not when/why those changes were made in the first place.

In that respect, it resembles git-subtree with --squash, but differs from git-submodule or regular git-subtree.

To me, the biggest indicator that all the links being posted here about Git submodule systems come from people who don't know what they're doing is the fact that all of them (vdm, pasta, peru, git-aggregator, etc.) are using YAML as a config. Anyone who has worked at least a few years with Git and YAML knows that this type of file is not Git/diff friendly. I've seen too many disastrous merges, and the developers in the company have to keep using unityyamlmerge to resolve a foolish decision by Unity. Moreover, if anyone here has tried to parse YAML, they understand how unnecessary it is to use this format 99% of the time. In your case, the only advice I can give is to use a complete repo config per line, so it doesn't spread across different lines. This ensures the atomicity and integrity of your information.

If you are looking for something very light and efficient, let me suggest you to give a try to:

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

Then, you can simply run: python3 externalsup.py

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.

Git Subrepo is another alternative to submodules and subtree.

> 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 made a full dependency manager called Degasolv[1] capable of managing arbitrary code in zip files some years back. I wrote it in Clojure. It has features for hosting zip repositories, version comparison, transitive dependency resolution, the whole nine yards.

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.

1: https://github.com/djhaskin987/degasolv

2: https://degasolv.readthedocs.io

Looks cool! Seems functionally similar to AOSP’s git-repo, but already feels more approachable with that simple yaml remote list.

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.

I've have great experiences with https://github.com/ingydotnet/git-subrepo

I think you’re going to find that, out there, somebody has already built this. I’ve built one, and worked on two others that somebody built. Usually they have names like workspace manager or repo manager or whatever. Most will probably have something to build a dag and code to do a topological sort for the recursive projects. The better ones will use the topological sort to pull repos and build in parallel.

In addition, other tools can also do this to varying degrees of success, like Bazel and cmake.

What problems are there with git submodules and how does this solve them? The readme isn't forthcoming in this respect.

I previously saw https://github.com/buildinspace/peru in use. Seems somewhat similar.

Nice! As an alternative backup tool, you can look at GitProtect Backup & Disaster Recovery for GitHub, Bitbucket, and GitLab. It allows you to pick up the storage (Cloud/local or both), automate backups by scheduling them at the most appropriate time, avoiding throttling, and restore data immediately from any point in time in case of failure, and many other features that meet pain points.

In our case we do not use submodules, because we need to apply some patch or PR to the dependency.

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

Source : https://github.com/acsone/git-aggregator

I quite like https://github.com/ingydotnet/git-subrepo

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.

I think submodules make sense in a lot of use cases, but a gotcha I saw with a team introduced to them recently is that pulling down from a branch or switching branches doesn’t update the submodule and/or stop you from changing branches if it is modified without being committed in some way.

If I could have submodules that operated that way I think submodules would be a lot more straightforward to newcomers.

How does this compare to git-subrepo?

Does it do anything to help manage the .gitignore file(s)? Otherwise I'd think you have to specify the dependency in both places consistently, which sounds a bit tedious.

For projects where I can't trust that the people involved can deal with submodule bullshit correctly I just use these git aliases:

    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

Then I add the .gitbox folder to gitignore. Whenever I need to interact with the "submodule" repo I unbox, otherwise I leave it boxed and as far as everyone else in the project is concerned, the dependency was just copied n pasted in the project.

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.

For a Python project, what are the pros/cons of

1: A setup.py that installs dependencies like this:

    pip install git+https://github.com/dependency/repo

2: Git submodules

?

Not so much of a hot take as some confusion: what are the pain points of Git submodules that lead to this tool? You imply they're 'not sane', worse but don't mention any of the deficiencies that your tool overcomes.

The project looks interesting.

Regarding the name, I’m French, and VDM basically means FML in French.

nice! I've been using jsonnet-bundler for this, even for non-jsonnet projects.

Another solution that "nix" solved years ago.

This seems to be almost the same as androids repo tool. https://android.googlesource.com/tools/repo

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?