Why Don't I Like Git More?
matduggan.com
matduggan.com
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.
or because tool is unnecessary complicated?
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.
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.
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.
"So pick a better tool"
We do (mercurial). Sadly `git` won.
If you're working on any kind of team doing work in parallel.. Just dont bother with SVN.
Got can get into strange states sometimes but I've never not been able to fix it. I don't personally find the same difficulties as the author though.
> 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?
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.
> 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.
That's not developers responsibility, we can write tests only for our known knowns and known unknowns.
This thread was more around the author who doesn't seem to understand that taking the full source(at least once) is a vital part.
Then just create a few aliases for yourself and forget the rest.
People think that git is complex. It is.
The task it's accomplishing is insanely complicated.
Easily accessing, rearranging, and merging the changes between those versions gets complicated, but git isn't actually very good at those parts!
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'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?
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.
Not only that, but then followed it up with:
> Pull Request as a first-class citizen.
What on Earth for?!? If you only have a centralized repository, what else is there to pull from?
Luckily I can still find yesterday's article about credit cards rewards at the top. I think there's a perverse incentive around flagging.
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.
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.
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)
It means your interface (place where app and user interact) is hopelessly bad.
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 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
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.
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.
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.
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.
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.
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.
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.
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.
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.
At least one.
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.
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?
In practice you just want server with local commits.
...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.
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.
https://www.reddit.com/r/git/comments/pa656j/wrappers_on_top...
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.
> 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.
B: "git request-pull": https://git-scm.com/docs/git-request-pull
> 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.
Sheesh.
> I've been working with git now full-time for around a decade now.
Duplicated "now". Boom, roasted.
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.