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

100 点作者 ryapric10 个月前

Hey folks! I've been working on something on & (mostly) off for a little over a year, and picked it back up recently because of yet another related frustration at work.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!vdm: <a href="https://github.com/opensourcecorp/vdm">https://github.com/opensourcecorp/vdm</a>

25 条评论

posix8610 个月前

Nice!!If you're looking for alternatives, here's something we've built (hope I'm not hijacking this): <a href="https://github.com/audiotool/pasta">https://github.com/audiotool/pasta</a>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_TOKENWe 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.

glandium10 个月前

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)

评论 #41099015 未加载

评论 #41108978 未加载

评论 #41128303 未加载

评论 #41106536 未加载

comex10 个月前

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.

评论 #41098251 未加载

quilombodigital10 个月前

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.

评论 #41107385 未加载

评论 #41114095 未加载

greatgib10 个月前

If you are looking for something very light and efficient, let me suggest you to give a try to:<a href="https://github.com/fviard/svn_xternals">https://github.com/fviard/svn_xternals</a>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<pre><code> 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 </code></pre> Then, you can simply run: python3 externalsup.pyAnd 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.

lioeters10 个月前

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.<a href="https://github.com/ingydotnet/git-subrepo">https://github.com/ingydotnet/git-subrepo</a>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.

djha-skin10 个月前

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: <a href="https://github.com/djhaskin987/degasolv">https://github.com/djhaskin987/degasolv</a>2: <a href="https://degasolv.readthedocs.io" rel="nofollow">https://degasolv.readthedocs.io</a>

foooorsyth10 个月前

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.

评论 #41098065 未加载

评论 #41097975 未加载

iFire10 个月前

I've have great experiences with <a href="https://github.com/ingydotnet/git-subrepo">https://github.com/ingydotnet/git-subrepo</a>

prpl10 个月前

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.

rendaw10 个月前

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

lmz10 个月前

I previously saw <a href="https://github.com/buildinspace/peru">https://github.com/buildinspace/peru</a> in use. Seems somewhat similar.

t_believ-er87310 个月前

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.

sebastienbeau10 个月前

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 : <a href="https://github.com/acsone/git-aggregator">https://github.com/acsone/git-aggregator</a>

keithnz10 个月前

I quite like <a href="https://github.com/ingydotnet/git-subrepo">https://github.com/ingydotnet/git-subrepo</a>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.

samtheprogram10 个月前

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.

评论 #41098302 未加载

评论 #41098321 未加载

7e10 个月前

How does this compare to git-subrepo?

评论 #41098421 未加载

kadoban10 个月前

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.

alex773410 个月前

For projects where I can't trust that the people involved can deal with submodule bullshit correctly I just use these git aliases:<pre><code> 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 </code></pre> 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.

评论 #41098460 未加载

TekMol10 个月前

For a Python project, what are the pros/cons of1: A setup.py that installs dependencies like this:<pre><code> pip install git+https://github.com/dependency/repo </code></pre> 2: Git submodules?

评论 #41098325 未加载

评论 #41098295 未加载

000ooo00010 个月前

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.

frizlab10 个月前

The project looks interesting.Regarding the name, I’m French, and VDM basically means FML in French.

anakaiti10 个月前

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

neeh010 个月前

Another solution that "nix" solved years ago.

iveqy10 个月前

This seems to be almost the same as androids repo tool. <a href="https://android.googlesource.com/tools/repo" rel="nofollow">https://android.googlesource.com/tools/repo</a>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?

评论 #41097929 未加载

评论 #41098106 未加载