Live data from Hacker News

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

github.com

31–40 of 64 posts

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

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

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

#34
post #17
post #7

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.

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/`.

This gives you the ability to implement `vdm history` or similar command while still keeping the submodule invisible to the parent?

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

#35
post #30

Earlier quoted context omitted.

>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…

I want to update 20+ submodules every day, ensuring i'm always at the tip of all submodules.

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

#36
post #30

Earlier quoted context omitted.

>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…

> I'm more inclined to invest time in git itself.

This is fine until you're working with hundreds of other developers. I believe the reason solutions like this exist is to abstract git away from most devs, because in (my experience) many enterprise devs have only rudimentary git knowledge.

Sure, the devs should "just learn git" - but the same argument applies to a lot of other tech nowadays. Ultimately most folks seem to want to close their ticket off and move to the next one.

Git submodules and git subtrees generally do not fit my org's needs - we have internal tooling similar to this. Happy to expand on that if you have questions.

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

#37
post #36
post #30

Earlier quoted context omitted.

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…

> I'm more inclined to invest time in git itself. This is fine until you're working with hundreds of other developers. I believe the reason solutions like this exist is to abstract git away from most devs, because in (my experience) many enterprise devs have only rudimentary git knowledge. Sure, the devs should "just learn git" - but the same argument applies to a lot of other tech nowadays. Ultimately most folks see…

The risk with that approach is that every other of the hundreds of developers will bring their own tool for X. So now you have hundreds of tools and everyone only knows a subset.

If there is a common operation that people get wrong or don't use often enough but still need to run regularly a five-line bash script will not only do the job it will actively help them learn the tool they are using.

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

#39
post #30

Earlier quoted context omitted.

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…

I want to update 20+ submodules every day, ensuring i'm always at the tip of all submodules.

    git submodule foreach ………
Or is there something I missed?

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

#40
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)
Post reply on HN