> I think the people not satisfied with git are told that is a result of them not understanding it.
People are told this because it's generally true. Of course, it's not the case for everyone, but I find that most criticisms of the tool focus heavily on remembering how to use it.
(The author does mention some missing features, which is valid, but git can't be everything for everyone. In those cases, perhaps it's not the appropriate tool.)
> I need to always deeply understand the difference between reset, revert, [...]
> You need to remember that push and pull [...]
> When it comes to merging, you need to think through the logic [...]
Yes, you need to understand, remember, and think. Git (and other similar tools) solve a complex problem and doing so in a simple way would likely restrict teams into a small set of possible workflows.
I find that using git is quite simple once the project team has established the processes where the tool is used, and understands git's role in those processes. In my experience, most day-to-day tasks involve using the same small handful of git subcommands, and issues that arise are quite easily fixable.
> People are told this because it's generally true. Of course, it's not the case for everyone, but I find that most criticisms of the tool focus heavily on remembering how to use it.
Another way to look at this is that Git is a bad UX for what the correct and convenient tool for development is.
Is like when people wanna do JOINs but what you have is documents and map-reduce. Sure, you can bend towards it, but then the tool is ill-suited.
Sure, if a few people have trouble because they didn't pay attention or don't get it that's fine. But if most users of the tool struggle to remember how to use it and using it right requires significant thought, it's a bad tool (or at least, a bad UI).
I don't know, the person writing this article seems to understand git and doesn't like it (and yeah, I agree with him, and I'm good with git too, but think it's unnecessarily complicated - Perforce does everything Git does, and it's way easier to use, although it is a paid product).
git is fundamentally a sort of database. If people think about it as having a not-dissimilar level of complexity, use cases, and users to Postgres, the complexity shouldn't be too surprising.
Like anything used by a lot of people to solve real problems, it has warts and duct tape, but, honestly, git feels like the least troublesome part of my daily workflow.
Yeah, but if every project, no matter how small, required you to spin up and maintain a full Postgres install, surely you'd start thinking, there has to be something easier than this...
The problem with Git is the same kind of problem Excel has: everyone can (correctly) claim to only use 20% of its features, thus everyone can say "Git is too complex!". But the problem is that everyone uses a different 20% of Git; Git is the union of the solutions to lots of different problems.
They don't actually sound like someone doing any real work.
> Why do I need to download 500 files in a project if I'm only going to edit 3 of them
Either their project structure sucks and they combine a lot of unrelated items together, or this guy is just an manager/architect who isn't making any significant changes but wants to poke in the codebase.
Why do you need to download the entire project? So you can build/compile/launch it and view/test your changes. Are we just talking about a README.md file here?
The author is in devops[1], which intuitively seems like the sort of job that would have that 'not making any significant changes, just working on single files' type of flow that isn't the same flow as a standard dev approach (where it's common to work across an entire repo). So it's understandable from that perspective that they might come to that conclusion.
Put another way, in a software product, you bring down those 500 files because you want to locally make sure that your changes to the 3 files you care about are compatible with the 500 files you don't. In a dev-ops repo, perhaps they are dealing with a situation where small amount of files they deal with have less impact on the whole.
I'm in DevOps and this desire to view an entire repository through the small lens of a few files concerns me, specifically for the reasons you call out.
> In a dev-ops repo, perhaps they are dealing with a situation where small amount of files they deal with have less impact on the whole.
Do they not test against the real thing and assume their test cases hit every corner case?
Edit: Also as a DevOps person it is your responsibility to make sure things work well. If this is onerous for you and you're not doing anything to make it better and instead are trying to shy away from the reality of working with the reposit, you're doing your job wrong.
I was making some large assumptions and reading through the lines that they have repos that track many products where particular folders / files have zero overlap with the whole. Or perhaps they have situations where they're working on configurations that can only be tested by deploying them and not by local tests. There's lots of reasonable reasons for only needing to be concerned with a portion of a repo. I'm giving the author the benefit of the doubt as the expert in their own job that they are in one of those reasonable situations.
> Alright, I want to move unstaged edits to a new branch. If the branch doesn't exist, I want to use checkout, but if it does exist I need to stash, checkout and then stash pop
Use `git switch` instead. `git checkout` is known to be overloaded to do too many things.
If it's a new branch, `git switch --create <branch>`
If it's an existing branch and the changes would conflict, `git switch --merge <branch>`
I really hate git a lot and wish I didn't have to use it. I find that it gets in the way and adds complication without providing compensatory benefits. I consider it a step backwards in version control.
I've often wondered why I seem to be in the minority on this opinion. Most devs seem to be OK with it, and many love it. I have no idea why.
The only thing I can think of is that git operates in a very specific way and either your brain is in sync with that way or it isn't.
One thing I disagree with in the article:
> More specifically, it doesn't work offline
It absolutely does. Maybe the author is confusing git with one of the bit-based services like github?
> It absolutely does. Maybe the author is confusing git with one of the bit-based services like github?
That was the most confusing paragraph. It says that “pull request” merges aren’t part of Git or something. Of course the merge itself is part of Git. I certainly would have heard something by now if people were getting different merge results when using GitHub compared to git(1).
Also
> Most of that distributed history gets thrown away when I do a squash.
Step (1) use squash; step (2) complain that squash throws the history away.
I’m not sure it’s possible to do so without a huge regression in usability. Multiple people working concurrently on a codebase is a fundamentally decentralized activity. One of the big problems with the cvs/svn concurrency model is that you have to resolve conflicts (which corrupts your work in progress) before you can commit your edits, whereas with git the workflow is commit first then resolve conflicts. git gives you a lot more safety than svn, and more flexibility and tooling for managing work in progress.
Heh. I suspect that it might seem fine at first. Then some time passes and people end up wanting more fine-grained control over their local changes that upstream hasn’t accepted yet. Then they either start organizing branches on the upstream into their own namespaces (best case) or they start using (local) patch management systems on top of the centralized VCS (a worse case).
HN's flamewar detector penalizes stories with a high comment to upvote ratio, and they also penalize flagged stories too of course. It's one of the reasons why I browse /active quite a bit instead of just the front page.
I've given up on git a long time ago. At every place I worked there was a different set of rules and software to interface it. And at every place, there were git gurus, who are needed because every repo has places with labels like "this branch is cursed and bugged, ask xy before using". Not a week goes by without a git emergency. It's laughable that something like that is trusted with code.
I've also used svn for a long time, and I remember it fondly. With git, you use git. With svn, you can actually code. Since it's become non-optional to use git, I just use commits and logs. I don't even bother with branches anymore, they bug out too often. I've become so jaded about tools, and git is a major reason for it.
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.
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)
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.
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.
> 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.
> 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.
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.
> 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
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:
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).
> 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.
> 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.
> 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.
> 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.
> 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.
You've constructed a mythical Git user that perfectly knows to handle Git.
When someone points out how a Git user struggles with X, you say - well, true Git users read X in the manual. When no one reads the manual in practice.
The same goes for Real Men know to program in C without UB. Then you show all the CVEs from it. So they retort, well, Real Men don't write UB.
Same fallacy different target.
> 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.
It's about better human accessibility. Just because programmers love horrible tools, doesn't make them good. Vim included.
> Again, so what? Use the tool that fits the purpose.
Again, I'd love to, but I have to use it because Git is all source repositories, today support. Since peer pressuring humanity is impossible, only avenues are:
A) change Git
B) wait for something better to be discovered
> 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.
We replaced the intended usage with local NPM package. It made everything better.
So even for its intended usage it was better served by NPM package.
The second repository is still on submodules, and it will remain that way for the foreseeable future.
> You realize git doesn't install those tools by default right? You have to manually build them and install them separately.
You realize that Git doesn't work just on Linux? On Mac it comes with brew and on Windows it comes with installation.
Also, if git-subtree doesn't come by "default" then it can't be a replacement by submodules. You can't say I'm not affiliated by Stephen, but I will take all credits for Stephen's work.
> Subtree merge is unrelated to git-subtree.
I'm talking about merging git subtree to upstream (i.e. what the article was talking about).
> 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.
Anyone trying to mandate reading software manual or documentation (outside government regulation) has already lost. No one sane has that much spare time.
> 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.
> 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?
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.
I have never been at a place with cursed branches and I have no idea how that can possibly happen in git. Sorry but your colleagues were just totally incompetent.
People say that, but my experience has been like that over a decade at many different places. Just a month ago my git.exe crashed (!) during a commit. It just doesn't work as a tool at all. I always copy my entire work folder before a commit because there's a realistic chance that git messes it up. Every commit is pain and Russian roulette
...and the author has lost me (I did read the entire post though).
> If GitHub is down today I can't deploy anyway so I might as well embrace the server requirement as a perk.
Just because you can't deploy doesn't mean others can't as well. (Also, GitHub != Git. Period.)
Heck, the entire idea of DVCS is that you should be able to continue to work even after the servers are down. If you can't, then it's not Git problem.
It seems that the author didn't even understand the concepts and ideas, or the rationals behind DVCS, let alone Git. As a someone who had lived through the period when SVN was the only game in town (and not wanting to return to those dark days), seeing the author pining for the "good 'ol days" of SVN-like, centralized VCS is just silly.
Yeah, the thing about us programmers is that we can build whatever stuff which is incompatible with the fundamental tool (centralized things vs. git(1)) on top of the tool and then complain that the tool has become useless. So it’s true that if you insist on having so much centralization that you become impotent once GitHub goes down, then yeah decentralization isn’t work for you—because you went out of your way to make it useless.
Most of this is not hate on Git, but hate on the frankly garbage GitHub integration model that is merge based.
Other git tools like Gerrit that focus on rebases and chaining of commits are far superior in terms of getting code through review in a clean and efficient manner.
Yeah, the problem is git is too low level for almost everything a dev does during the day. It really needs a tool on top of it that makes the simple tasks easy (and it must be possible, because Perforce is waay easier to use than git and works like a charm, at least in my opinion).
... but, at the same time, git is great for automation because the build-tool devs have some much control, so keep it as a foundation.
There's so much wrong with this that it's hard to see if there's anything at all right with it.
> More specifically, it doesn't work offline.
??? Of fucking course it does! You mean Git Hub doesn't work offline, don't you?
> It relies on merge controls that aren't even a part of git with Pull Requests.
No, git doesn't "rely on merge controls that aren't even a part of git". Other things do. Things people nowadays confuse with git. People like, apparently, the author of TFA. (And no, the "F" doesn't stand for "fine" in this case.)
> Dump the decentralized model.
You can do that yourself: Just don't use it.
> Move a lot of the work server-side and on-demand.
Sure, just ssh into the server and run your search there. What's your problem?
> Pull Request as a first-class citizen.
A: Huh? But that's part of a decentralized workflow, and didn't you just say to "Dump the decentralized model"? Make up your mind.
> Why did SVN get dumped then? One word: branches.
Yeah, that is a bit ironic... Seeing as how git's killer feature was branches, and for the last ten years (or how long has it been; at least five?) everyone has been pooh-poohing them and going on about their "linear commit history", as if that were somehow so fucking important.
> I also think programmers love decentralized designs because it encourages the (somewhat) false hope of portability. Yes I am entirely reliant on GitHub actions, Pull Requests, GitHub access control
Who told you to make yourself dependant on all that shit? I sure didn't, and I'm pretty sure git didn't either. Sounds -- again -- like your problem is with GitHub, not with git.
> I could move the actual repo itself to a different provider.
Your problem is probably that you think you need a "provider" in the first place. Just put a fucking ordinary git repo somewhere, and use that.
I know this isn’t truly the point of the article, but I’d encourage anyone/everyone to give https://fork.dev a try. Unlimited free trial but well worth it to support the great devs. It solves basically all of the ergonomic gripes I have with the `git` CLI.
I love Fork and use it a lot, though I’d say for any Git GUI you should still build a solid understanding of the fundamentals to use it effectively.
I’m not implying this was the point you’re making at all, but imo a Git GUI should be for aiding visualisation and to avoid needing to type the (sometimes unintuitive) commands rather than to avoid learning Git itself. I think this is what causes many people to get stuck.
People are told this because it's generally true. Of course, it's not the case for everyone, but I find that most criticisms of the tool focus heavily on remembering how to use it.
(The author does mention some missing features, which is valid, but git can't be everything for everyone. In those cases, perhaps it's not the appropriate tool.)
> I need to always deeply understand the difference between reset, revert, [...]
> You need to remember that push and pull [...]
> When it comes to merging, you need to think through the logic [...]
Yes, you need to understand, remember, and think. Git (and other similar tools) solve a complex problem and doing so in a simple way would likely restrict teams into a small set of possible workflows.
I find that using git is quite simple once the project team has established the processes where the tool is used, and understands git's role in those processes. In my experience, most day-to-day tasks involve using the same small handful of git subcommands, and issues that arise are quite easily fixable.