5 ms·

No True Git fallacy. If you don't enjoy Git, it wasn't Git as it's meant to be! There's always something 'wrong' with Git because it's incredibly complex. Mo

No True Git fallacy. If you don't enjoy Git, it wasn't Git as it's meant to be! There's always something 'wrong' with Git because it's incredibly complex. Most developer flows don't require that complexity, but have to pay for it anyway. That's the article. When I have significant changes, I copy the directory before messing with Git beyond regular commands, because it's so easy to nuke code with it. Someone could tell me I'm doing it wrong, but an LLM could generate that comment at this point, so don't bother.

stewx 2y ago
Counterpoint: sometimes teams actually do use a tool poorly, and it ruins the experience for people and makes them think something is wrong with the tool itself. You're allowed to not like Git, but the complaint "branches are buggy" suggests that there are problems with the team's workflow.
- jeltz 2y ago
  Yeah, this is a very unique complaint which makes me think OP is the one doing something seriously wrong.
CuriousCosmic 2y ago
Okay serious question though. How many developers have actually read any of the git instructional material? Like beyond just peaking at the reference/man pages. Git's docs have quite well written guides and introductory material but how many developers have ever even read those docs, even in part? I can't think of a single other tool or library I use on a regular basis that has documentation but it's considered standard practice to just ignore all those docs and "wing it" based on colloquial knowledge and random copypasted snippets from stack overflow. Everywhere else in the tech space RTFM is standard practice but as soon as you say that with git, it's interpreted as if it was said with complete and utter condescension. (aside: you can still dislike git and there are perfectly valid reasons to but so often I see people argue that git is bad without ever having experience following the instructions printed on the tin)
- Ygg2 2y ago
  If you need to resort to RTFM to use the tool, you've already lost. You don't yell at person for getting shocked and cut because the saw is just a motor with blade attached, and you need to start blade by shorting circuiting it with a graphite pen. It means your interface (place where app and user interact) is hopelessly bad.
  - CuriousCosmic 2y ago
    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 2y 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
Dylan16807 2y ago
> No True Git fallacy. If you don't enjoy Git, it wasn't Git as it's meant to be! That is not what is happening here. Simply being better than SVN is not very hard, and most git workflows accomplish that. > When I have significant changes, I copy the directory before messing with Git beyond regular commands, because it's so easy to nuke code with it. Someone could tell me I'm doing it wrong, but an LLM could generate that comment at this point, so don't bother. If you're committing first, I doubt it's actually nuked. If you're skipping committing before doing strange things, then stop doing that. That's not some kind of condescending and useless "do it better", it's like telling you to flip the breaker before you start rewiring your house.
CRConrad 2y ago
> There's always something 'wrong' with Git because it's incredibly complex. Most developer flows don't require that complexity, but have to pay for it anyway. That's the article. Nope, that's not it. Sure, git is too complex for any single user or team to effectively use all of its features. That's a consequence of the famous "Everyone only uses 10 (5, 20, whatever) percent of its features -- but it's a different 10 (...) percent for everyone!" dictum. But this article was a self-contradictory mishmash that showed only that the author doesn't really have any idea what he's talking about. Case in point: > Dump the decentralized model. > Pull Request as a first-class citizen. What would you need pull requests for without a decentralized model?

stewx 2y ago

Counterpoint: sometimes teams actually do use a tool poorly, and it ruins the experience for people and makes them think something is wrong with the tool itself. You're allowed to not like Git, but the complaint "branches are buggy" suggests that there are problems with the team's workflow.

jeltz 2y ago
Yeah, this is a very unique complaint which makes me think OP is the one doing something seriously wrong.

CuriousCosmic 2y ago

Okay serious question though. How many developers have actually read any of the git instructional material? Like beyond just peaking at the reference/man pages. Git's docs have quite well written guides and introductory material but how many developers have ever even read those docs, even in part? I can't think of a single other tool or library I use on a regular basis that has documentation but it's considered standard practice to just ignore all those docs and "wing it" based on colloquial knowledge and random copypasted snippets from stack overflow. Everywhere else in the tech space RTFM is standard practice but as soon as you say that with git, it's interpreted as if it was said with complete and utter condescension. (aside: you can still dislike git and there are perfectly valid reasons to but so often I see people argue that git is bad without ever having experience following the instructions printed on the tin)

Ygg2 2y ago
If you need to resort to RTFM to use the tool, you've already lost. You don't yell at person for getting shocked and cut because the saw is just a motor with blade attached, and you need to start blade by shorting circuiting it with a graphite pen. It means your interface (place where app and user interact) is hopelessly bad.
- CuriousCosmic 2y ago
  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 2y 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

Dylan16807 2y ago

> No True Git fallacy. If you don't enjoy Git, it wasn't Git as it's meant to be! That is not what is happening here. Simply being better than SVN is not very hard, and most git workflows accomplish that. > When I have significant changes, I copy the directory before messing with Git beyond regular commands, because it's so easy to nuke code with it. Someone could tell me I'm doing it wrong, but an LLM could generate that comment at this point, so don't bother. If you're committing first, I doubt it's actually nuked. If you're skipping committing before doing strange things, then stop doing that. That's not some kind of condescending and useless "do it better", it's like telling you to flip the breaker before you start rewiring your house.

CRConrad 2y ago

> There's always something 'wrong' with Git because it's incredibly complex. Most developer flows don't require that complexity, but have to pay for it anyway. That's the article. Nope, that's not it. Sure, git is too complex for any single user or team to effectively use all of its features. That's a consequence of the famous "Everyone only uses 10 (5, 20, whatever) percent of its features -- but it's a different 10 (...) percent for everyone!" dictum. But this article was a self-contradictory mishmash that showed only that the author doesn't really have any idea what he's talking about. Case in point: > Dump the decentralized model. > Pull Request as a first-class citizen. What would you need pull requests for without a decentralized model?