3 ms·

In case you are serious, and I am not super sure about that. - depencys include blobs, or other blob like things(big code bases, think react) - there is littl

In case you are serious, and I am not super sure about that. - depencys include blobs, or other blob like things(big code bases, think react) - there is little value in seeing changes in a blob or blob like things as changes in those have a bad signal to noise ratio. Version information (minor/major) + changelog is much more interesting for the average dev - there is a performance penalty for having to many things/big things in git - there is no nice way to keep dependencies up to date in git - the discoverability of git/GitHub has not been great You can use git as a package provider, see pip for example, but using git alone is painfull.

forrestthewoods 3y ago
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]
cxr 3y ago
> In case you are serious, and I am not super sure about that. What's unclear? I linked directly to a comment thread where we had this exact exchange. Yes, I'm being serious. Do you have solid backing for your position or not? Can you state it clearly or not? "Seriously?" is not an argument. And in this context it is—ironically—a very unserious way to respond. If I had to guess, I'd say it's probably geared more towards being a vehicle for communicating some sort of subtext in the vein of, "You should abstain from asking these sorts of questions because the reasons are so obvious and so well-known that it is a foolish and embarrassing thing to ask, which makes anyone who is asking those questions look foolish and embarrassing." > dependencys include [...] other blob like things(big code bases, think react) [...] there is a performance penalty for having to many things/big things in git This is not a self-contained argument. A performance penalty compared to what? > there is no nice way to keep dependencies up to date in git Huh? (Alternatively: "How is this relevant?") When you check your dependencies in to the Git repo, you have all the same tools to update your dependencies that you have when you don't check them in.
- pinkgolem 3y ago
  >What's unclear? You linking to Ra and going on other tangends make you seem very trollish/edgelord like. >This is not a self-contained argument. A performance penalty compared to what? Compared to not checking them in? I don't understand what you are trying to say here. >Git repo, you have all the same tools to update So I still need a package manager of my choice & a dependency file to install & update dependencys? That also makes it easy to modify single source files which then only get overwriten on an dependency update as you have no clear separation between source code and dependencys.
  - cxr 3y ago
    > You linking to Ra and going on other tangends make you seem very trollish/edgelord like. Huh? Did you read the essay? There's nothing trollish or edgy about it. It describes exactly the type of response I got in the other thread (and now from you here). > Compared to not checking them in? I don't think you're thinking clearly. You can opt not to check your dependencies in—there's certainly less overhead involved when you don't have your dependencies around compared to having them checked into your repo. But the question then becomes, "How are you going to get your app to build/run if you don't have your dependencies?" We are not talking about building projects with dependencies versus projects that don't have dependencies. Same project, same dependencies. You need these dependencies. That's why they're dependencies. When you say there are performance problems when you have a big Git repo, what are you actually comparing that _to_? > I don't understand what you are trying to say here. I haven't strayed from my goal. I am looking for someone to provide a clear answer to the question, "What is the NPM hypothesis?" In other words, state clearly in quantitative terms how it is that keeping e.g. 12% of your source code in Git and leaving the other 88% (or whatever) to be fetched after you clone the repo and run `npm install` is better than keeping 100% of the source code, dependencies included, in Git? I'll give you an example by what I mean: if I see that you're trying to email someone some artwork and it's a bunch of Windows BMP files or raw TIFFs, I could say something like, "If you save these as PNGs and JPEGs, they will take up less space on disk and will be quicker to download." We can test this. We can figure out if it's true or not. We have a hypothesis that is falsifiable. This is the basis of science. We're doing computer science. We are not asking people their favorite cheeses. We are not even asking them whether static types are better than dynamic types or if functional programming is good and object-oriented is bad. We are talking about version control systems. There are beliefs involved here, but they are not mere beliefs—I'd guess that you have some sort of belief about what makes NPM + Git the "right" way to do things and just checking the dependencies into Git the "wrong" way that can be stated in the form of one or more fact claims that we can scrutinize, do some measurements, work out the math, etc. and figure out whether those claims are true or untrue. I'm asking you to state clearly what your claims are. What are they? > So I still need a package manager of my choice & a dependency file to install & update dependencys? I don't understand this question. Is it a question? It looks like a declarative statement followed by a question mark instead of a period.

forrestthewoods 3y ago

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]

cxr 3y ago

> In case you are serious, and I am not super sure about that. What's unclear? I linked directly to a comment thread where we had this exact exchange. Yes, I'm being serious. Do you have solid backing for your position or not? Can you state it clearly or not? "Seriously?" is not an argument. And in this context it is—ironically—a very unserious way to respond. If I had to guess, I'd say it's probably geared more towards being a vehicle for communicating some sort of subtext in the vein of, "You should abstain from asking these sorts of questions because the reasons are so obvious and so well-known that it is a foolish and embarrassing thing to ask, which makes anyone who is asking those questions look foolish and embarrassing." > dependencys include [...] other blob like things(big code bases, think react) [...] there is a performance penalty for having to many things/big things in git This is not a self-contained argument. A performance penalty compared to what? > there is no nice way to keep dependencies up to date in git Huh? (Alternatively: "How is this relevant?") When you check your dependencies in to the Git repo, you have all the same tools to update your dependencies that you have when you don't check them in.

pinkgolem 3y ago
>What's unclear? You linking to Ra and going on other tangends make you seem very trollish/edgelord like. >This is not a self-contained argument. A performance penalty compared to what? Compared to not checking them in? I don't understand what you are trying to say here. >Git repo, you have all the same tools to update So I still need a package manager of my choice & a dependency file to install & update dependencys? That also makes it easy to modify single source files which then only get overwriten on an dependency update as you have no clear separation between source code and dependencys.
- cxr 3y ago
  > You linking to Ra and going on other tangends make you seem very trollish/edgelord like. Huh? Did you read the essay? There's nothing trollish or edgy about it. It describes exactly the type of response I got in the other thread (and now from you here). > Compared to not checking them in? I don't think you're thinking clearly. You can opt not to check your dependencies in—there's certainly less overhead involved when you don't have your dependencies around compared to having them checked into your repo. But the question then becomes, "How are you going to get your app to build/run if you don't have your dependencies?" We are not talking about building projects with dependencies versus projects that don't have dependencies. Same project, same dependencies. You need these dependencies. That's why they're dependencies. When you say there are performance problems when you have a big Git repo, what are you actually comparing that _to_? > I don't understand what you are trying to say here. I haven't strayed from my goal. I am looking for someone to provide a clear answer to the question, "What is the NPM hypothesis?" In other words, state clearly in quantitative terms how it is that keeping e.g. 12% of your source code in Git and leaving the other 88% (or whatever) to be fetched after you clone the repo and run `npm install` is better than keeping 100% of the source code, dependencies included, in Git? I'll give you an example by what I mean: if I see that you're trying to email someone some artwork and it's a bunch of Windows BMP files or raw TIFFs, I could say something like, "If you save these as PNGs and JPEGs, they will take up less space on disk and will be quicker to download." We can test this. We can figure out if it's true or not. We have a hypothesis that is falsifiable. This is the basis of science. We're doing computer science. We are not asking people their favorite cheeses. We are not even asking them whether static types are better than dynamic types or if functional programming is good and object-oriented is bad. We are talking about version control systems. There are beliefs involved here, but they are not mere beliefs—I'd guess that you have some sort of belief about what makes NPM + Git the "right" way to do things and just checking the dependencies into Git the "wrong" way that can be stated in the form of one or more fact claims that we can scrutinize, do some measurements, work out the math, etc. and figure out whether those claims are true or untrue. I'm asking you to state clearly what your claims are. What are they? > So I still need a package manager of my choice & a dependency file to install & update dependencys? I don't understand this question. Is it a question? It looks like a declarative statement followed by a question mark instead of a period.