3 ms·

It's not really so much that _git_ is lacking the functionality -- it's actually much more possible to do reasonable vendoring with git than with (say) subversi

It's not really so much that _git_ is lacking the functionality -- it's actually much more possible to do reasonable vendoring with git than with (say) subversion, as you can use submodules to point at your fork. To my mind the issue is more with tooling: you don't typically want to vendor your code, most of the time you want to use a published module. And the process for publishing your fork is too complex to be worthwhile. Also, the work to keep the fork itself up-to-date when you realise it's necessary is minimal, but by switching away from the original you lose tooling support for telling you when you need to make that update.

chiefalchemist 9y ago
I understand there are workarounds, but they are just that. I mean, for example, I'm working away but hit a bug in a dependency. Now i have to fork, submodule, etc. I'm not expecting frictionless per se. But it just feels like there's more overhead than there needs to be. Also, it's possible (in rare cases) the vendor folder is not .gitignore'd. Now what? Submodules is out. Again, given the nature of most modern dev (i.e., dependencies) vit feels underprepared. Re: "...but by switching away from the original you lose tooling support for telling you when you need to make that update..." Yes. But doesn't this actually support the idea (mentioned above) not to treat your dependencies like black boxes? That is, no pain no gain? Yeah, perhaps some sort of simple notification your fork needs an update. Just the same, ALL code should, in theory, be treated as your own. You wouldn't blindly merge/commit a colleague's work, so why shouldn't your dependencies be semi thoroughly reviewed as well? Are we too busy to do the right thing(s)?
- bsimpson 9y ago
  Here are approaches I use: a) Make changes in the minified source to understand the problem, then go make changes in the original; or: b) git clone dependency.git cd dependency yarn yarn link cd project yarn link dependency make changes in dependency yarn run build test my app repeat until fixed clean up, commit, and PR I prefer B, but I'll do A first if the build step is annoying or slow.

chiefalchemist 9y ago

I understand there are workarounds, but they are just that. I mean, for example, I'm working away but hit a bug in a dependency. Now i have to fork, submodule, etc. I'm not expecting frictionless per se. But it just feels like there's more overhead than there needs to be. Also, it's possible (in rare cases) the vendor folder is not .gitignore'd. Now what? Submodules is out. Again, given the nature of most modern dev (i.e., dependencies) vit feels underprepared. Re: "...but by switching away from the original you lose tooling support for telling you when you need to make that update..." Yes. But doesn't this actually support the idea (mentioned above) not to treat your dependencies like black boxes? That is, no pain no gain? Yeah, perhaps some sort of simple notification your fork needs an update. Just the same, ALL code should, in theory, be treated as your own. You wouldn't blindly merge/commit a colleague's work, so why shouldn't your dependencies be semi thoroughly reviewed as well? Are we too busy to do the right thing(s)?

bsimpson 9y ago
Here are approaches I use: a) Make changes in the minified source to understand the problem, then go make changes in the original; or: b) git clone dependency.git cd dependency yarn yarn link cd project yarn link dependency make changes in dependency yarn run build test my app repeat until fixed clean up, commit, and PR I prefer B, but I'll do A first if the build step is annoying or slow.