[CuriousCosmic]

It's not a matter of "you have to do x dangerous thing to make it work".

That's the issue. To repeat the meme, if you are "doing git properly", you absolutely should not be doing anything dangerous at all. There are a few tools that do unintuitive things for historical reasons that you are recommended to use their replacements instead (prime example: using checkout to change or create branches) but the overwhelming majority of tools in the git suite don't have that issue. And for the tools that do have that issue (like checkout), you'll see that the docs consistently recommend users to use their replacements instead when performing operations.

But what you have is a ton of people who don't know how to safely work in a shop insisting you need to use tools improperly and often for the wrong purpose entirely. Things like "use a push block or push stick (even if it's just made from scrap) when feeding material through a table saw to keep yourself from getting injured", "don't try to use a miter gauge with a rip fence", or "for the love of god don't freehand pieces through the saw".

Just because you can use a tool wrong doesn't mean it's acceptable. There's a lot of standard practice in shops that you'd learn by reading the instructions but plenty of people just wing it either out of laziness or out of ignorance and then get hurt.

That doesn't make RTFM any less relevant, it only makes it more relevant.

[Ygg2]

> That's the issue. To repeat the meme, if you are "doing git properly"

That's not a meme - that's just a True Scotsman fallacy.

What about Submodules? Well, all true Scotsmen™ don't use submodules.

What about pushing upstreams in Subtree? Well, all true Scotsmen™ don't push upstreams in subtrees.

What about ours/theirs? Well, all true Scotsmen™ know how what that refers to.

What about X? Well, all true Scotsmen™ know (not) to use X.

---

This line of thinking glosses over the complaints of many people by constructing a magical Perfect Git User, that instinctively knows the outcome of every command in every situation over a timespan of eons, for any code base.

---

> Just because you can use a tool wrong doesn't mean it's acceptable.

A conscientious toolmaker would ensure that the number of ways a tool is misused it small and will craft affordances to stir people using them into pits of success, rather than just Hole-Hawging[1] the user when they make an error.

[1] "At some point, the drill bit caught in the wall. The Hole Hawg, following its one and only imperative, kept going. It spun the worker's body around like a rag doll, causing him to knock his own ladder down" source: https://web.stanford.edu/class/cs81n/command.txt

[CuriousCosmic]

It's not "don't use X" it's "don't use X without understanding its limitations and without knowing when you should vs shouldn't use it". There's a nuance here and that nuance is in the manual.

Again, it's not "don't do X", it's "don't do X until you've read the manual and you understand what X does and when you should use it versus another tool in your arsenal".

If you want to go through the list:

> What about Submodules? Well, all true Scotsmen™ don't use submodules.

Use submodules. They actually have some pretty justified use cases but for what a lot of people want them for (having a dependency that they don't intend on ever modifying other than updating which version it points to), you shouldn't use them and should use a build system's dep manager (or a script, a branch, and a worktree) for that.

Old submodules had some major warts and were deprecated with everyone quietly moving up to modern submodules. Modern submodules actually aren't that awful and haven't been for at least 5 years. If you need to contribute changes upstream from your embedded repo, you need the entire repo, and you don't intend on having history cross the submodule barrier at all (or extremely rarely at most), then you actually probably want to use submodules and you should use them.

The manual covers basically all of that

> What about pushing upstreams in Subtree? Well, all true Scotsmen™ don't push upstreams in subtrees.

Subtree isn't part of git. They are contributed software. More details as to what that means are linked below but the short of it is that they are included as a convenience and should not be treated as anything less than a third party tool, often an experimental one:

https://github.com/git/git/blob/master/contrib/README

As for subtree merges? Yeah those exist and the manual covers them. You want to push to a subtree upstream? Merge the subtree into a local copy of the upstream branch with the `-Xsubtree=rel/path/to/subtree` option. This will take your whole history with you so you'll need to either squash those changes or rebase them (both approaches are covered in the advanced merges chapter along with the subtree merges).

> What about ours/theirs? Well, all true Scotsmen™ know how what that refers to.

Thank god the manual covers that (chapter: advanced merges).

----

Again, RTFM.

[Ygg2]

> It's not "don't use X" it's "don't use X without understanding its limitations and without knowing when you should vs shouldn't use it". There's a nuance here and that nuance is in the manual.

That's what I was saying. "Don't use X" is same as "Don't use Z when Y and Q" if X is "Z when Y and Q ".

Also that's not how people work. People want to get shit done. They don't care about Git or X or RTFM or Wayland or whatever. Their mental model needs to be close to how Git behaves. Not the other way around.

> having a dependency that they don't intend on ever modifying other than updating which version it points to), you shouldn't use them and should use a build system's dep manager.

Great idea, except that's not how people use it in the wild. Manual is great in theory (like if you and ten of your buddies write code). Not in practice, where millions use it.

First, not all language have build managers nor do people even talented devs use it as instructed.

Know what would make it easier? Either having submodules working in all cases, or not having it at all.

> Thank god the manual covers that (chapter: advanced merges).

That's not the point. If you have 10sec and you are doing a cherry pick what is ours/theirs?

No manual available.

In practice people don't read manual to do X, they have preconceptions/ mental models how Git works and consult manual when things go pear shaped.

> Subtree is contributed software

I don't think you'll find two people doing non-Git programming that care about that factum.

[CuriousCosmic]

> That's what I was saying. "Don't use X" is same as "Don't use Z when Y and Q" if X is "Z when Y and Q ".

If you want to reduce knowing "proper use of tools" ad absurdum, then there's basically no reason to care about the difference between a linked list, an array, a vector, a hashmap, etc. They are all basically the same thing and if you use one that isn't designed for the problem you have, it's not you that is wrong, it's obviously the container is just bad and you shouldn't use it.

Tools have a purpose and different problems have solutions that better fit them. You might run into issues with a tool or solution to the problem if you don't understand its purpose/use and you try to use the wrong tool for the job.

> Also that's not how people work. People want to get shit done. They don't care about Git or X or RTFM or Wayland or whatever. Their mental model needs to be close to how Git behaves. Not the other way around.

Sure and do you know how you get that to happen? You have them RTFM or at minimum skim it so they can understand the tool and construct their mental model in alignment with the tool when they are learning how to use it the first time.

Like I'm not saying you need to sit down and read all 500 pages of the pro-git book in one setting. That's way too much and the user won't retain that. But like whenever you want to do something that you haven't done before, go to https://git-scm.com/, search it in the search bar, and see what comes up. Or just click Documentation, then Book, and pick the chapter for the thing that roughly approximates to what you want to do. A given chapter of the git book (presented as a single page via the HTML version) generally takes less than a minute or two to skim through to find an answer. Then the section that answers your question might take another 2-5 minutes at most to read and digest before you have your answer. Or if it's something relatively trivial, hit the man page/reference for the command. It's enough to solve the overwhelming majority of people's problems while also helping them gradually build/align their mental model with the tool.

> Great idea, except that's not how people use it in the wild. Manual is great in theory (like if you and ten of your buddies write code). Not in practice, where millions use it.

> First, not all language have build managers nor do people even talented devs use it as instructed.

Is it not common for projects to insist on submodules for dependencies they want to heavily modify instead of just forking the dependency into it's own repo, doing development for the forked dep there, and then just tracking the fork with the submodule? If not, why aren't they using a subtree merge instead?

> Know what would make it easier? Either having submodules working in all cases, or not having it at all.

You have three separate approaches that solve different sides of the same problem: build tool dep management, submodules, and subtrees. Instead of trying to solve the entire problem with one approach, why not just support separate solutions that are tailored to the needs people have? Each has tradeoffs and you shouldn't use one when you would use the other.

> That's not the point. If you have 10sec and you are doing a cherry pick what is ours/theirs?

> No manual available.

Ours is our branch (i.e. the branch you are currently on and merging into), Theirs is their branch (i.e. the branch you are trying to merge). The mental model is that you are merging in someone else's changes into your code, i.e. you merge theirs into ours where theirs and ours have a common ancestor.

> In practice people don't read manual to do X, they have preconceptions/ mental models how Git works and consult manual when things go pear shaped.

Exactly and that's fine. But if you don't know what you are doing (ex: if you haven't done it before or it's been a long time), instead of just bumbling ahead, try taking a minute to check the manual and verify that your assumptions are right.

It's like trying to go somewhere, if you go to that place regularly, you can probably navigate blind but if you haven't been there before or you don't know the area, you should probably look at the map first and then ask for directions if you can't figure out where you are or where to go next.

> I don't think you'll find two people doing non-Git programming that care about that factum.

Oh sure but the point is that complaints about subtree are not complaints about git. They are complaints about what is basically an unofficial hobby/side project of one of the developers and more importantly complaints about a piece of code that isn't necessarily guaranteed to be held to the same standard as code that is actually part of the git project.

[Ygg2]

> If you want to reduce knowing "proper use of tools" ad absurdum,

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.

> Sure and do you know how you get that to happen? You have them RTFM or at minimum skim it so they can understand the tool and construct their mental model in alignment with the tool when they are learning how to use it the first time.

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.

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.

E.g. imagine, for instance, that rather than making your screwdriver easier to grip (your screwdriver is just a shank and a blade), you make a manual for the screwdriver that says, "Hold screwdriver with a wrench for better leverage and/or grip".

> Is it not common for projects to insist on submodules for dependencies they want to heavily modify instead of just forking the dependency into it's own repo, doing development for the forked dep there, and then just tracking the fork with the submodule?

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.

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.

> Oh sure but the point is that complaints about subtree are not complaints about git. > If not, why aren't they using a subtree merge instead?

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?

Also, you can't recommend Git subtree merge and then insist subtree is not a complaint about Git. One or the other.

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.

[CuriousCosmic]

> 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.