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