> I'm just stating how a logical fallacy works. Adding conditionals to the No True Scotsman Fallacy, still makes it a fallacy. Albeit a more convoluted one.
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. I never once claimed that. I am just saying that there are intended uses and unintended uses. The manual and documentation illustrate these uses and if users want to use the tool without unexpected complications they need to refer to the documentation before using it.
> And I noted that sure for an obscure tool, used by few, it's fine. Not when it's used by millions, if not tens of millions, of developers. As you scale up in popularity, your reliance on RTFM is less and less excusable.
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. And it's a tool that's used by millions of developers at minimum so it must clearly be a failure of a piece of software. But that's obviously not the case. It works perfectly well but you have to read the instructions and align your mental model. Not everything has the same mental model and that's perfectly acceptable. That's what manuals are for.
> If for nothing than else, just for a fact that rather than making your CLI easier/more consistent, you are just forcing mass of developers to learn ins/outs of your program in essence rather than making a good UI/mental model that serves you fairly well, you waste X hours times number of developers using it.
Again, so what? Use the tool that fits the purpose. If the history graph oriented VCS approach git takes isn't to your taste, why not use mercurial instead? And if a decentralised VCS isn't fitting your needs, why not just use one of the many, many centralised offerings available?
There is no reason why all tools should need to be tailored to one specific UX model. The tools are built for a purpose and you are free to use a different one. But at the end of the day if you want to onboard with any tool, you are going to want to RTFM. Or alternatively you can bumble in with the mental model of whatever previous tool you used and waste tons of time struggling if the two mental models differ at all.
> The few projects that used submodules definitely didn't use it like that. One used it to point to a version of code that was stationary, that was the less problematic one, but it caused problems with other tooling.
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. That of course can be mitigated by changing the git config to default to recursing into submodules. I consider the fact that submodule recursion isn't the default to be a wart but it's something that is trivial to work around and something you'd have insight on if you read the docs.
> The second was a project that used dozens of submodules, and they were very recursive, very deeply nested and various active branches, pointed to various other git submodule branches. It was a nightmare to change branches, and switching branches turned into a chore.
This honestly seems like a misuse of submodules. But that a tool can be abused doesn't make the tool bad. Just like unmaintainable code exists in all languages, unmaintainable repositories exist in some form in all VCS tools.
> How is it not a complaint against Git? Git is distributing for better or worse those tools. If Git started shipping malware in its distributions, should I just let Git devs off the hook because it was donated by a phisher prince?
You realize git doesn't install those tools by default right? You have to manually build them and install them separately. Most distros however do build those and include them because they are popular even though they aren't part of git. So if you have an issue with that, it should be taken up with the distro package maintainers for your distro of choice rather than with the git project/devs.
> Also, you can't recommend Git subtree merge and then insist subtree is not a complaint about Git. One or the other.
Subtree merge is unrelated to git-subtree. Subtree merges are just one of the merge strategies built into git and like the other merge strategies is automatically selected when the merge fits certain criteria. Git-subtree however is a contributed tool that builds off of subtree merges to act as an alternative to the git-submodule command. That may sound like an inconsequential difference but Git-subtree has a lot of moving parts like git-submodule does so it is massively more complex relative to your standard subtree merges.
> Finally, my criticism of Git's model points towards the failings of the Git inner model that people have managed to paper over with lots of effort. I.e. file-based Merkel tree VCS will get you far, but partial checkouts, commits and binary files are places where Git starts to lose ground to different abstractions.
Sure those are perfectly valid critiques and projects should weigh the abstraction's tradeoffs against other tool's abstractions before deciding to adopt it as their VCS. 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.
> 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.
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. I never once claimed that. I am just saying that there are intended uses and unintended uses. The manual and documentation illustrate these uses and if users want to use the tool without unexpected complications they need to refer to the documentation before using it.
> And I noted that sure for an obscure tool, used by few, it's fine. Not when it's used by millions, if not tens of millions, of developers. As you scale up in popularity, your reliance on RTFM is less and less excusable.
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. And it's a tool that's used by millions of developers at minimum so it must clearly be a failure of a piece of software. But that's obviously not the case. It works perfectly well but you have to read the instructions and align your mental model. Not everything has the same mental model and that's perfectly acceptable. That's what manuals are for.
> If for nothing than else, just for a fact that rather than making your CLI easier/more consistent, you are just forcing mass of developers to learn ins/outs of your program in essence rather than making a good UI/mental model that serves you fairly well, you waste X hours times number of developers using it.
Again, so what? Use the tool that fits the purpose. If the history graph oriented VCS approach git takes isn't to your taste, why not use mercurial instead? And if a decentralised VCS isn't fitting your needs, why not just use one of the many, many centralised offerings available?
There is no reason why all tools should need to be tailored to one specific UX model. The tools are built for a purpose and you are free to use a different one. But at the end of the day if you want to onboard with any tool, you are going to want to RTFM. Or alternatively you can bumble in with the mental model of whatever previous tool you used and waste tons of time struggling if the two mental models differ at all.
> The few projects that used submodules definitely didn't use it like that. One used it to point to a version of code that was stationary, that was the less problematic one, but it caused problems with other tooling.
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. That of course can be mitigated by changing the git config to default to recursing into submodules. I consider the fact that submodule recursion isn't the default to be a wart but it's something that is trivial to work around and something you'd have insight on if you read the docs.
> The second was a project that used dozens of submodules, and they were very recursive, very deeply nested and various active branches, pointed to various other git submodule branches. It was a nightmare to change branches, and switching branches turned into a chore.
This honestly seems like a misuse of submodules. But that a tool can be abused doesn't make the tool bad. Just like unmaintainable code exists in all languages, unmaintainable repositories exist in some form in all VCS tools.
> How is it not a complaint against Git? Git is distributing for better or worse those tools. If Git started shipping malware in its distributions, should I just let Git devs off the hook because it was donated by a phisher prince?
You realize git doesn't install those tools by default right? You have to manually build them and install them separately. Most distros however do build those and include them because they are popular even though they aren't part of git. So if you have an issue with that, it should be taken up with the distro package maintainers for your distro of choice rather than with the git project/devs.
> Also, you can't recommend Git subtree merge and then insist subtree is not a complaint about Git. One or the other.
Subtree merge is unrelated to git-subtree. Subtree merges are just one of the merge strategies built into git and like the other merge strategies is automatically selected when the merge fits certain criteria. Git-subtree however is a contributed tool that builds off of subtree merges to act as an alternative to the git-submodule command. That may sound like an inconsequential difference but Git-subtree has a lot of moving parts like git-submodule does so it is massively more complex relative to your standard subtree merges.
> Finally, my criticism of Git's model points towards the failings of the Git inner model that people have managed to paper over with lots of effort. I.e. file-based Merkel tree VCS will get you far, but partial checkouts, commits and binary files are places where Git starts to lose ground to different abstractions.
Sure those are perfectly valid critiques and projects should weigh the abstraction's tradeoffs against other tool's abstractions before deciding to adopt it as their VCS. 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.