2 ms·

This is an argument that Git has serious limitation (it does). It's not an argument against the theory of dependencies in VCS.

pinkgolem 3y ago
1/2 are pretty universal, and would make any VCS which includes dependencys basically look like any other package manager today. Every other existing VCS btw to my knowledge has the same limits
reactordev 3y ago
Here's an argument for not having your dependencies in your repo as hard source. Any CVE's will need to be patched by you or you'll need to check-in a huge diff tree for the latest version patched and then figure out of you've made modifications to your local blob of libidiot that you now have to rectify. If you want to use git for version control of dependencies, for the love of god use git submodules. It's what they were designed for. If you want to check-in single file stb_lib fine but checking in MESA into your source tree is just plain stupid.
- forrestthewoods 3y ago
  Git Submodules are a well known source of pain and suffering. For CVEs, if you use docker images you need to rebuild and redeploy all images which isn’t particularly different from updating committed code. If you’ve modified a library you have to merge changes any which way. So not sure what difference it makes. Checking in GPU drivers probably doesn’t make sense. That’s closer to Docker territory at least. Haven’t run into a case where I’ve wanted/needed to do that so no strong opinion.
  - reactordev 3y ago
    Git submodules work flawlessly for me because I use them correctly. So YMMV. There’s plenty of documentation out there on how to do a git clone —recursive or git submodule update —init —recursive Never edit the code in the submodules, edit them in the parent repos where they properly live. Your repo is for your code only. Don’t go wandering:editing in those submodules.
- deleted 3y ago
  [deleted]

pinkgolem 3y ago

1/2 are pretty universal, and would make any VCS which includes dependencys basically look like any other package manager today. Every other existing VCS btw to my knowledge has the same limits

reactordev 3y ago

Here's an argument for not having your dependencies in your repo as hard source. Any CVE's will need to be patched by you or you'll need to check-in a huge diff tree for the latest version patched and then figure out of you've made modifications to your local blob of libidiot that you now have to rectify. If you want to use git for version control of dependencies, for the love of god use git submodules. It's what they were designed for. If you want to check-in single file stb_lib fine but checking in MESA into your source tree is just plain stupid.

forrestthewoods 3y ago
Git Submodules are a well known source of pain and suffering. For CVEs, if you use docker images you need to rebuild and redeploy all images which isn’t particularly different from updating committed code. If you’ve modified a library you have to merge changes any which way. So not sure what difference it makes. Checking in GPU drivers probably doesn’t make sense. That’s closer to Docker territory at least. Haven’t run into a case where I’ve wanted/needed to do that so no strong opinion.
- reactordev 3y ago
  Git submodules work flawlessly for me because I use them correctly. So YMMV. There’s plenty of documentation out there on how to do a git clone —recursive or git submodule update —init —recursive Never edit the code in the submodules, edit them in the parent repos where they properly live. Your repo is for your code only. Don’t go wandering:editing in those submodules.
deleted 3y ago
[deleted]