this post was submitted on 04 Jul 2025
45 points (100.0% liked)
Programming
21417 readers
331 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities [email protected]
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Tbh these aren't things that are big issues with Git. The biggest issues I have are:
Fix those and it will take over Git in a very short time. Otherwise it's just going to hang around as a slightly nicer but niche alternative.
Well, git is for source control, not binary artefacts. There are indeed projects whose size is not a good match to git, but not everyone is Google or CERN.
What are your requirements? What do you need this for? And why do you think everyone else needs the same?
It's quite possible you are doing it wrong. What you want as a FOSS project are probably libraries which are build, versioned, and packaged separately. Perhaps using Debian packaging tools or Guix. Splitting it into real libraries with a concise API ensures that the API surface does not becomes too large, that the components stay relatively compact and maintainable, and that other parts of the FOSS community can re-use that library.
Companies - especially large companies - sometimes promote vendoring instead. But this promotes their interests, not those of the FOSS community on which creations they are building on.
Yes, git is designed to match the needs of the Open Source community! If you have a deeply intertwined multi-billion code base for a commercial product, a smartphone with closed firmware, or yet another TV , it might not be the best match. But who cares? Is the open source community obliged to meet such needs?
Only because it is bad at binary artefacts. There's no fundamental reason you shouldn't be able to put them in version control.
It's not much of an argument to say "VCSes shouldn't be able to store binaries because they aren't good at it".
Typically there's a third or first party project that I want to use in my project. Sometimes I want to be able to modify it too (soft fork).
Because I've worked in at least 3 companies who want to do this. Nobody had a good solution. I've talked to colleagues that also worked in other companies that wanted this. Often they come up with their own hacky solutions (git subtree, git subrepo, Google's
repo, etc. etc. - there are at least half a dozen of these tools).No offence, but your instinctive defence of Git and your instant leap to "you're holding it wrong" are a pretty dead giveaway that you haven't stopped to think about how it could be better.
Just to jump in here, git submodules and similar are a terrible design pattern that needs killed, not expanded. Create a library properly and stop cutting corners that will bite you in the ass.
Three seperate companies wanting to do it the lazy, wrong way doesn't suddenly make it a good idea.
Libraries are not always a suitable solution. You just haven't worked on the same projects I have and you can't imagine all the things submodules are used for.
On top of that, I can't force all third party projects to turn their repos into nice easily installable packages. Especially if they're using a language that doesn't have a package manager.
I think the point the user was making is that, if it isn’t already distributed as a library, you can just fork it and deploy it as a library artifact to your company’s internal artifact repository. You shouldn’t be pulling an external project as a submodule, that’s just coupling yourself way way too tightly to external code. So you turn that code internal and into a library.
You're no more tightly coupled than if you zip that repo up, and put it on an internal server. It's the exact same code you've just changed the distribution method.
And my whole point is that wouldn't be necessary if Git had a version of submodules that worked properly!
You guys seriously lack imagination.
I mean you are more tightly coupled. It’s way more likely that someone is going to pull the git submodule (especially if you’re doing this with multiple projects) than the someone updating the version of the library inadvertently. This applies even more if you’ve created the library and deployed it to your own artifactory yourself.