[EarthLaunch]

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.

[CuriousCosmic]

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]

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.

[slowmovintarget]

I don't think that's true, especially for complex command-line tools.

Reading the manual, especially when it's well written, can help you understand why design decisions were made with the tool. We're not talking about a simple tool without safeguards. We're talking about a complex tool with a lot of interacting pieces.

You do read the manual on that airliner as a pilot because it's your job to know the systems of the airliner. You do read the manual on the sonar system in the submarine, because it's your job as a sonar operator to know the system.

I dislike the shiny-plastic-button mindset that seems to infect everything these days. Professional tools tend to be more flexible and more complex than consumer tools, because professionals often need to do more, and get more out of those tools. Git is not Dropbox or WinZip. It has a far more complex function. If you have to read the manual to get full use from a tool, that's not losing, that's learning. It's part of the job.

And yes, I have read the Git manual.

[Ygg2]

> I don't think that's true, especially for complex command-line tools.

That's the issue. The interface a person sees, should be minimal when possible. Git can't claim it's not needlessly complex when tools like Mercurial and Sapling exist.

> You do read the manual on that airliner as a pilot because it's your job to know the systems of the airliner.

Man, if you are comparing Git to an airliner, you do realize people allowed to touch a real aeroplane consoles need months if not years of exams and hundreds of hours of practice in simulators? Are you saying Git should require the same? Because then the analogy doesn't work.

Any CLI that would require months of reading the manual and practising in Git sandbox would be deemed too complex for all but the most masochist of devs.

Git doesn't have to be that complex, but its fundamental file based "abstraction" combined with keeping it exposed to end users leads to problems.

As someone said, Git isn't a Version control system, but a Version control toolkit, that you shape into a system. And everyone has a subtly different way of thinking how it should work, so you end up with some very bizarre workflows.

> I dislike the shiny-plastic-button mindset that seems to infect everything these days. Professional tools tend to be more flexible and more complex than consumer tools, because professionals often need to do more, and get more out of those tools.

And I dislike the RTFM mentality that is pervasive in the OSS sphere, but here we are. I don't want to think about what exactly the Git is doing, and "Why is Submodule eating my directories?". I want to write code.

Look, it's fine to RTFM when it's you and your buddies are writing a kernel in 1980. Not when it gets used by millions of developers.

[MaxBarraclough]

> If you need to resort to RTFM to use the tool, you've already lost.

Git is a power tool aimed at professional-level software developers. If they tried to make it idiot-proof, it would probably stop being useful. It would at the very least bring considerable restrictions.

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

[CRConrad]

> How many developers have actually read any of the git instructional material?

At least one.

[Dylan16807]

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

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

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]

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