5 ms·

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

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 3y ago
> 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 https://web.stanford.edu/class/cs81n/command.txt
- CuriousCosmic 3y ago
  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 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 3y ago
    > 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.

Ygg2 3y ago

> 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 https://web.stanford.edu/class/cs81n/command.txt

CuriousCosmic 3y ago
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 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 3y ago
  > 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.