Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

21–30 of 64 posts

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

#21

Post by jayd16 »

samtheprogram wrote: post #14

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.

Yup, submodules are actually ok. Like with most git issues, it's more of a tooling UX problem then an architecture deficiency.

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

#22

Post by est »

TekMol wrote: post #16

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 ?

3. copy everything into vendor/lib folder.

version pinning, no extra install needed, works offline, zero deps headaches.

Example: requests.packages.*

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

#23

Post by TekMol »

skribanto wrote: post #18
TekMol wrote: post #16

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 ?

I like to wrap it in a venv (pure python project) or nix flake (mixed languages)

That seems to be about isolation, not about dependency management, right? I use Docker containers for that.

But my question was about dependency management.

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

#24

Post by TekMol »

est wrote: post #22
TekMol wrote: post #16

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 ?

3. copy everything into vendor/lib folder. version pinning, no extra install needed, works offline, zero deps headaches. Example: requests.packages.*

Do you mean a completely manual workflow where you copy dependencies into the vendor dir by hand and then they are part of your project? If so, you back them up with your project backups and they also go into your repos history?

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.

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

#25

Post by est »

TekMol wrote: post #24
est wrote: post #22

Earlier quoted context omitted.

3. copy everything into vendor/lib folder. version pinning, no extra install needed, works offline, zero deps headaches. Example: requests.packages.*

Do you mean a completely manual workflow where you copy dependencies into the vendor dir by hand and then they are part of your project? If so, you back them up with your project backups and they also go into your repos history? 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. Ho…

> Do you mean a completely manual workflow

Coding is a manual process anyway, no? It's no different than writing code on your local machine and you decides to use some third-party modules.

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

#26

Post by alex7734 »

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.

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

#29

Post by beagle3 »

alex7734 wrote: post #26

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…

This sounds like git-subtree, which has been part of git for a quite a few years now.

https://www.atlassian.com/git/tutorials/git-subtree

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

#30

Post by tjoff »

foooorsyth wrote: post #6
iveqy wrote: post #4

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…

>I don’t really care 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…

You update your submodules every day?

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.

Post reply on HN