Live data from Hacker News

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

github.com

41–50 of 64 posts

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

#41

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)

Can we see your `git config -l`? I sparingly use git submodules, and don't really suffer from any of the common issues as I have a very strict update routine, but I'd love to see where things could be improved.

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

#42
post #17

Earlier quoted context omitted.

Yep, you have it correct. I've got a note at the bottom of the README that I'm considering adding a config field to keep the .git directory, but I'm trying to keep pretty far away from git-in-git consequences/use cases. I said the same in another comment here, but I don't envision vdm becoming something that's git-specific or developmental -- it's really just intended to be a getter, not a writer, and the functionali…

> I've got a note at the bottom of the README that I'm considering adding a config field to keep the .git directory, but I'm trying to keep pretty far away from git-in-git consequences/use cases. 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/`.…

Git would then version that .vdm/ directory - the repo would grow exponentially.

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

#43

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)

Can we see your `git config -l`? I sparingly use git submodules, and don't really suffer from any of the common issues as I have a very strict update routine, but I'd love to see where things could be improved.

I'm on mobile, so I don't have that, but search for submodule in the git-config manual page.

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

#45
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.

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

#46

Earlier quoted context omitted.

> I've got a note at the bottom of the README that I'm considering adding a config field to keep the .git directory, but I'm trying to keep pretty far away from git-in-git consequences/use cases. 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/`.…

Git would then version that .vdm/ directory - the repo would grow exponentially.

you'd want vdm to be a superset of git commands and then alias git=vdm, or something to avoid that

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

#47
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.

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

#48

Earlier quoted context omitted.

Git would then version that .vdm/ directory - the repo would grow exponentially.

you'd want vdm to be a superset of git commands and then alias git=vdm, or something to avoid that

No, I mean that the larger Git repo, of the main project, would version the .vdm directory.

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

#49

Earlier quoted context omitted.

> I've got a note at the bottom of the README that I'm considering adding a config field to keep the .git directory, but I'm trying to keep pretty far away from git-in-git consequences/use cases. 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/`.…

Git would then version that .vdm/ directory - the repo would grow exponentially.

The vdm submodule directories would probably have to be entered in the gitignore anyway. You wouldn't want to commit the submodule source files either. Won't the .git directory get excluded that way?

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

#50
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

Post reply on HN