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)
Show HN: Vdm, a sane alternative to e.g. Git submodules
41–50 of 64 posts
Re: Show HN: Vdm, a sane alternative to e.g. Git submodules
#42Earlier 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/`.…
Re: Show HN: Vdm, a sane alternative to e.g. Git submodules
#43Probably 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
#44Re: Show HN: Vdm, a sane alternative to e.g. Git submodules
#45https://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.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.
Re: Show HN: Vdm, a sane alternative to e.g. Git submodules
#46Earlier 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.
Re: Show HN: Vdm, a sane alternative to e.g. Git submodules
#47> 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
#48Earlier 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
Re: Show HN: Vdm, a sane alternative to e.g. Git submodules
#49Earlier 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.
Re: Show HN: Vdm, a sane alternative to e.g. Git submodules
#50I 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.