| > But that's the thing. It's not a "No True Scotsman" fallacy. A "No True Scotsman" fallacy would be to say that someone isn't capable or well versed in git because they do X a certain way. You've constructed a mythical Git user that perfectly knows to handle Git.
When someone points out how a Git user struggles with X, you say - well, true Git users read X in the manual. When no one reads the manual in practice. The same goes for Real Men know to program in C without UB. Then you show all the CVEs from it. So they retort, well, Real Men don't write UB. Same fallacy different target. > Is this boiling down to the user-friendly vs new-user-friendly debate? Because you could argue the exact same for Vim. It's obviously a terrible tool because it expects you to read the instructions to understand how to do things if you've not worked the modal mental model before. It's about better human accessibility. Just because programmers love horrible tools, doesn't make them good. Vim included. > Again, so what? Use the tool that fits the purpose. Again, I'd love to, but I have to use it because Git is all source repositories, today support. Since peer pressuring humanity is impossible, only avenues are:
A) change Git
B) wait for something better to be discovered > That's definitely the intended use case (as I mentioned higher up in the thread). If it caused issues with tooling it's because the tooling wasn't making sure to pull in submodules as well. We replaced the intended usage with local NPM package. It made everything better. So even for its intended usage it was better served by NPM package. The second repository is still on submodules, and it will remain that way for the foreseeable future. > You realize git doesn't install those tools by default right? You have to manually build them and install them separately. You realize that Git doesn't work just on Linux? On Mac it comes with brew and on Windows it comes with installation. Also, if git-subtree doesn't come by "default" then it can't be a replacement by submodules. You can't say I'm not affiliated by Stephen, but I will take all credits for Stephen's work. > Subtree merge is unrelated to git-subtree. I'm talking about merging git subtree to upstream (i.e. what the article was talking about). > However that is entirely unrelated to the expectation that users need to read the documentation and regularly consult it when they have questions as this applies regardless of the VCS tooling used. Anyone trying to mandate reading software manual or documentation (outside government regulation) has already lost. No one sane has that much spare time. |