14 ms·

Git is not a success story, but a failure as a system with a bad user experience

47 points by ardit33 6y ago

bJGVygG7MQVF8c 6y ago
On Twitter, we cool kids call tripe like this cope
neckardt 6y ago
It's not fair to complain about how hard a tool is to use without comparing it to the alternatives. If git is a failure as claimed then the alternatives should be better, no? We have a list of known version control software [0], how many of these are better than git and how many are worse? I've heard Mercurial and Fossil are pretty good but I still haven't been pressured to give them a try. However, most of that list is filled with software people hated enough to ditch for git. I think it's very likely that git is solving a problem hard enough that it can't be simplified much further. If it can be simplified, I would expect to hear a growing minority of users pushing for people to switch to the next system. [0]: https://en.wikipedia.org/wiki/Comparison_of_version-control_software https://en.wikipedia.org/wiki/Comparison_of_version-control_...
- guitarbill 6y ago
  Mercurial sounds great, and ostensibly has less foot cannons... unless you use Mercurial Queues. I've learned to live with git, just like I have with English. It isn't perfect, but a lingua franca is useful, and it isn't so bad. If git is the worst part of your CI/CD workflow, that's a pretty good problem to have.
  - bsder 6y ago
    And "Mercurial Queues" primarily exists because of people incessantly bitching about the lack of "git rebase" in Mercurial. So, what does that say about the original feature from git that implementing it created a ton of footguns into a revision control system that didn't have them before?
    - nemetroid 6y ago
      The original feature doesn’t have footguns, so what does it say? I’m genuinely curious.
    - atq2119 6y ago
      Considering that rebasing is a crucial feature of version control, it seems to say that there is inherent complexity in distributed version control. By virtue of being honest about the problem space and giving central importance to the inherent concepts, Git is probably the best existing solution, even if it's not necessarily the best possible solution.
      - bsder 6y ago
        > Considering that rebasing is a crucial feature of version control "Rebasing" is NOT a crucial feature. "Commit history" being immutable is an equally valid axiom. "Rebase" is an architectural feature of git that matches the organization structure of the Linux kernel (individual maintainers squash the detail of the commits as it passes up through developer->Maintainer A->Uber Maintainer B->Super Uber Maintainer C->Linus) by virtue of Conway's Law. I would posit that most development teams would be much better served never squashing commit messages. Too many groups incur the complexity of rebase without having any reason for doing so.
        guitarbill 6y ago
        MQ is not just rebase. for example, it's a common way to integrate with code review tools. you might want to put out several commits as one CR (to make reviewing easier). then you want to fix up some feedback, i.e. rewrite history (note this also doesn't necessarily mean squashing when merging into the main branch). i think it's fair to say the committed history shouldn't change (even just on the main branch), and most (?) git servers support this. but ignoring the need for this/ignoring the distributed nature of version control will lead to hacks like MQ. rebase is flexible and allows this.
        atq2119 6y ago
        > individual maintainers squash the detail of the commits as it passes up through developer->Maintainer A->Uber Maintainer B->Super Uber Maintainer C->Linus This is not how Linux kernel development works. Instead, once a series of patches has been reviewed and accepted by the first maintainer, there will be no more rebasing -- the commits will eventually flow into Linus' copy via pull requests that are reflected in the DAG as merge commit. The point here is that the kernel actually does code review, and commits often go through several versions before being accepted. That's where `git rebase` comes in, because as a developer, you need it during this revision process as you amend and fixup the individual commits of the patch series that you're working on. Of course, if you don't do proper code reviews on your projects, and/or you're sloppy with how changes make it into the code base, then you may get away without using `git rebase`. That may be acceptable for smaller projects, or perhaps for larger projects that are easier to test; and larger commercial projects may be able to afford the cost of papering over the inefficiencies that come with a sloppy review and development process. But it's just not feasible for something like the Linux kernel, and so `git rebase` really is essential.
  - altfredd 6y ago
    In my experience, descriptions of the so-called "foot cannons" within Git are exaggerated by people, who don't understand Git and didn't use it much. It is virtually impossible to lose data, committed to Git. Between reflog, lazy garbage collection and ability to grep history for strings there is literally no way to corner yourself. I have never lost anything after years of using Git. Meanwhile, I have lost data at least once with most conventional filesystems and storage mediums: f2fs, ext4, ntfs, hard drives, SSDs, CDs, VHS tapes... Incidentally, when I tried to use Mercurial once (because the job demanded it) and immediately went for Mercurial Queues, the bug in implementation of Queues caused me to actually lose some data (an insignificant amount, but still!). Unstable internal storage format + implementing history editing via third-party tool = bad news.
- eindiran 6y ago
  Notably Mercurial and Fossil are also distributed; they differ a bit in how complex they are, what they allow you to do, which tools are bundled in, etc, but ultimately any of the DVCSes is going to be lightyears ahead of the pre-Git (pre-Mercurial? I'm not sure which came first) client-server VCSes. Regarding your point about git being unable to be further simplified, I think Mercurial demonstrates that that isn't true; it sacrifices some coverage of the edge cases to get a significantly simpler interface.
  - jjav 6y ago
    > lightyears ahead of the pre-Git (pre-Mercurial? I'm not sure which came first) client-server VCSes git and mercurial both came out at the same time, April 2005. But neither was the first distributed scs by a very long shot. There was of course bitkeeper (which motivated git) and Sun's teamware was there all of the 90s. Surely several others.
    - fanf2 6y ago
      There was GNU arch / tla https://en.wikipedia.org/wiki/GNU_arch https://en.wikipedia.org/wiki/GNU_arch and monotone https://en.wikipedia.org/wiki/Monotone_(software) https://en.wikipedia.org/wiki/Monotone_(software)
- jen20 6y ago
  BitKeeper solves the same problems as Git with a _far_ more sane user interface. My personal opinion is that it's best in class. The thing Git has going for it (over BitKeeper or really anything else) is GitHub. If we had something like BitHub that were widely used instead, I don't think I would bother with Git for anything except contributions to projects using it, despite being a fairly advanced Git user through necessity.
  - yencabulator 6y ago
    The thing Git has going over BitKeeper is that people are allowed to use Git. Larry revoked the license of some key developers, and if he hadn't done that, Git wouldn't probably even exist.
megous 6y ago
As someone who moved from CVS, to SVN, to tla/GNU Arch, to git (shortly after initial release). I haven't found any reason to move on from git ever since. Each step was a major change in features and ease of use. It's hard to see it as a failed system, with "bad" user experience. And the whole premise is nonsense. I certainly haven't spent more time on learning git than doing the work in the last 15 years or so of using it.
- wildleaf 6y ago
  I agree, my current company is stuck on cvs. I've been using git for years until now and it feels like I've had my legs chopped off.
- anotherevan 6y ago
  As someone who moved from CVS, to SVN, to Mercurial (with side-trips to SCCS, VSS, Bzr and Git along the way), I haven't found any reason to move from Mercurial ever since.
  - megous 6y ago
    The thing is that if you commit to some well supported DVCS, UI differences between them are not that earth shattering, compared to VCS that need a server.
    - anotherevan 6y ago
      Well, I disagree. I find Mercurial much easier to grok and use than Git, and I learned Git first.
      - megous 6y ago
        The basic UI looks pretty much the same as the git one I'm used to.
        anotherevan 6y ago
wobblyasp 6y ago
Code management, code versioning and code fixing are all hard problems. You can't in all cases put a simple tool/thing in front of it and fix it. Sometimes hard things are just that, hard. Also; git isn't meant for your "average" use case. People sometimes attempt to get content writers or other non-technical skills into git. It never works. There are far better tools purpose built for those use cases. Developers want tools that work, git works. Why would we try to make it better?
- jjav 6y ago
  > Sometimes hard things are just that, hard. Mercurial is proof that one can have a good scs with a usable CLI.
- marty-oehme 6y ago
  > People sometimes attempt to get content writers or other non-technical skills into git. It never works. There are far better tools purpose built for those use cases. Do you have an example of a tool like this? When writing for academia, as long as I produce content on my own everything is fine. But finding a good way for collaboration with versioning has been really hard for me so far. (without resorting to google docs)
archgoon 6y ago
May I be cursed with failures as bad as git.
- raegis 6y ago
  Right. It's amazing that Linus Torvalds created TWO separate things which changed the world. I'm still working on my first, and I fear I won't finish before retirement!
saagarjha 6y ago
Git the plumbing is a huge success story. Merkle trees, distributed development, lightweight branching, format so simple you could literally write tooling for it as a bunch of shell scripts–it's really great. Git the porcelain is terrible, and while I wouldn't call it a failure its user experience is a detriment, not an asset, to its overall niceness.
- leephillips 6y ago
  I love git. I use it for everything; I think of it as an extension to my filesystem, and, with fugitive, an extension to Vim. It gives me the superpower of time travel. I’m not even close to being an expert on it, but what I can glean from its design seems beautiful.
- ssivark 6y ago
  Git’s UI/porcelain definitely isn’t winning any awards. That said, why infantilize users so much that it’s considered abhorrent to understand the tool one depends on? The plumbing is so elegant/simple, after all! The utter passive cluelessness and disconnect-with-reality promoted & celebrated by “intuitive” interfaces reminds me of Mary Antoinette... “Tool not working... not intuitive enough :shrug:”
- mekoka 6y ago
  I always recommend learning Git by starting at chapter 10 (https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Po...) of the Git book. Granted the content is a bit technical and the advice generally directed at developers, but I found that once the plumbing is understood, the world of Git makes a lot more sense. The porcelain can still be quite ugly at times though.
  - samatman 6y ago
    This is actually the central complaint of the tweet which kicked off this thread: git requires a complete mental model of the underlying internals and primitives, to compensate for the numerous unintuitive and complex operations which make up the 'porcelain'. I'm someone who thinks this is backward: the problem is that git's internals aren't doing what I want them to do. I'm not 100% convinced that I know what I want them to do, but I'm about 80% sold that I want a repo to be a collection of patches, with the larger structures, e.g. branches or histories, to be ways of organizing the application of those patches, and telling a story to other developers about why they exist. So I'm eagerly awaiting the next generation of pijul, to get the chance to see if that's right.
jasoneckert 6y ago
Git is not a success story? I wonder if the author of this tweet is aware that Git has almost entirely conquered the development world these past few years. That doesn't happen as a result of having a bad user experience. Git is a powerful tool that does an excellent job of versioning and collaboration, and I can't imagine wanting it to be any more user friendly than what it currently is.
- bsder 6y ago
  I disagree. Git didn't win--GitHub won. Git was the parasite carried along by the GitHub host.
  - dwheeler 6y ago
    No, git essentially won. GitHub is the single most common site for OSS projects, but there are many others, and they generally use git as well. GitLab obviously supports git. SourceForge supports git. Savannah supports git. Bitbucket supports git. Microsoft internally uses git, and that happened before they bought GitHub: https://techcrunch.com/2017/05/24/microsoft-now-uses-git-and-gvfs-to-develop-windows/ https://techcrunch.com/2017/05/24/microsoft-now-uses-git-and... There are other version control systems, but git is by far and away the majority player.
    - bsder 6y ago
      Methinks you need a history lesson. Bitbucket was originally Mercurial-only. Savannah was SVN-only forever. SourceForge (geez--people still mention them after they turned into a dumpster fire of malware?) was CVS then SVN and only much later Git (long after SourceForge was relevant anymore). I presume GitLab was Git from the start. > Microsoft internally uses git Long after there was any relevance to the choice.
      - dwheeler 6y ago
        Methinks not. I was around for all that history, and that is exactly my point. Savannah, bitbucket, and SourceForge all added support for git later because they had to. They added support for git because git won, not because it failed. Also, please look at the article I cited about Microsoft. That was not just a simple swap. Microsoft could not use git as-is because of the way they use Version Control in general. Instead of sticking to their existing system, they implemented additional functionality for git so that git would work in their environment. That is a vote of confidence for git, because they believed it was better to add functionality to git.
bradhe 6y ago
The argument is that you have to know how the tool itself works in order to use it. This is, eventually, true with _every_ tool. Consider Postgres: It's really pretty easy to get up and running and for simple things works great. Once you start taxing the system you have to know how it's configured, what settings you have optionality over, and obviously how the subsystems work and behave based on those settings. This is just true with any dependency you take on: Any problem the dependency has is, eventually, your problem too. Git is a dependency of your software development process.
aaron695 6y ago
When XKCD makes a joke of it and a lot of people get it. It says a lot. https://xkcd.com/1597/ https://xkcd.com/1597/ I think perhaps a good front end for Git might help a lot though. But if Git as it stands is the best we can do as a planet for version control then that's a broken system.
oneplane 6y ago
Everything else has to be pretty 'perfect' for git to be the 'problem' of your toolset...
CapriciousCptl 6y ago
How to get retweets: “Popular and productive tool X has a rough spot around Y and is therefore a failure.” Nothing’s perfect, get over it, help out or make something better.
thrill 6y ago
Patient: Doctor, how do you know how deeply to cut? Surgeon: I'm never sure, I just hack at it until someone who knows how these things work tells me to stop.
TameAntelope 6y ago
Is this really how I'm supposed to operate in the world of technology and computer science? The negativity is a shame, I wish it weren't part and parcel of participating in the greater developer community.
denkmoon 6y ago
Mercurial presents a far more pleasant user experience. I've been very sad to see hg fade away in favour of git. Having taught graduates how to work with both tools, I found hg easier to explain (maybe because I prefer it though) and better retention/less questions in the future.
adembudak 6y ago
I love git mostly because its predictability, if you get along with it, you don't need to deep into the docs anymore, your guess probably end up with the right choice (most of the time:))
kyleee 6y ago
I've noticed it's somewhat en vogue in certain dev communities to bash git. I think since it started out as a CLI tool and some parts of git are complicated that it's easy to get cheap internet points by complaining about it
usr1106 6y ago
He should not complain, but write a better user interface. The underlying functionality and performance of the implementation is excellent. The user experience is poor, it took me several years to get really fluent. There are still things I know I don't know and some occasional surprises. The repos are such a success story that they won't go away for years. But if someone came up with a more consistent user interface that would not harm. It's a huge job though, if you want to cover the full functionality. And if you don't do that you will create a new inconsistency, because power users will sooner or later need to fall back to the current user interface.
- Dylan16807 6y ago
  > He should not complain, but write a better user interface. The average person has no idea how to write a good interface. That's not a very fair demand.
  - usr1106 6y ago
    The problem is that it requires an exceptional SW designer to design a good interface for git. The internal model of git is exceptionally well designed and maintained by much better than average hackers. They master the crude UI concepts we have today and obviously they don't care. It's free and open software. So everyone working on it does what they like. Obviously no one has volunteered to write a great and consistent front-end. At least not successful enough that users would know and use it. But shouting that no one volunteers as the orginal twitter poster does makes just no sense.
- ulisesrmzroche 6y ago
  Valid criticism does not require a solution to be given.
tartoran 6y ago
Id take GIT anytime over the stupid TFS i have to deal with on a daily basis. It’s forced embedding in VS adds to the frustration even more.
MattGaiser 6y ago
Is there any frustrating UI issue with Git that a tool like GitKraken does not solve for those who have command line trouble or prefer to easily visualize things?
kodah 6y ago
Calling git a "failure" blanketly is dubious and I'd expect a "developer advocate" to know that. He actually goes on to say that he's "marketing his frustration" (https://twitter.com/hhariri/status/1314287590523236352 https://twitter.com/hhariri/status/1314287590523236352) It's also equally ironic that it's a "developer advocate" from JetBrains that's calling out an open source projects usability. A first step might be that he and JetBrains try contributing to git or trying to build new porcelain on top of git. That said, this is par for the course of the kind of user that resides on Twitter. Twitter is mostly used by toxic people who like to air their grievances before the world and then try to convince the rest of us it's healthy. We need to stop encouraging engineers to use Twitter to communicate, imo. It enables this armchair quarterback behavior while having zero investment in the production of the desired result.
- angrais 6y ago
  >> That said, this is par for the course of the kind of user that resides on Twitter. Twitter is mostly used by toxic people who like to air their grievances before the world and then try to convince the rest of us it's healthy. Just a reminder that you're currently on hacker news and not Twitter :)
  - kodah 6y ago
    Sure, I posted a reply to my thread that has some more constructive feedback and examples.
- kodah 6y ago
  This guy is all sorts of irony, I've assembled some tweets from the last four days: - Preaching on how to "win allies" with positivity that he doesn't use https://twitter.com/hhariri/status/1315540900244848640 https://twitter.com/hhariri/status/1315540900244848640 - Antagonistic posting, alluding to that he'd like to call out Linux developers for user experience too https://twitter.com/hhariri/status/1314858276866134016 https://twitter.com/hhariri/status/1314858276866134016 - Bragging about being blocked by people on Twitter https://twitter.com/hhariri/status/1314836556008566784 https://twitter.com/hhariri/status/1314836556008566784 - He admits he's a "lower than average developer" but feels qualified to judge the work of others harshly https://twitter.com/hhariri/status/1314536445781180416 https://twitter.com/hhariri/status/1314536445781180416 - Speaking in the third person https://twitter.com/hhariri/status/1314590552344719360 https://twitter.com/hhariri/status/1314590552344719360 - More venting and antagonism https://twitter.com/hhariri/status/1314591215166291968 https://twitter.com/hhariri/status/1314591215166291968 - Antagonistic rhetoric https://twitter.com/hhariri/status/1314523004655874048 https://twitter.com/hhariri/status/1314523004655874048 - Continuing to preach (this has some interesting, negatively slanted replies) https://twitter.com/hhariri/status/1314179665574211584 https://twitter.com/hhariri/status/1314179665574211584 If you're an engineer on Twitter do yourself a favor and read your tweets as someone who doesn't know you. Getting to know your virtual-self is very important, because people have a tendency to act different online than they do in person. My impression of this guy based on four days of tweets? I'd block him and never use a JetBrains product again just for the sheer loads of entitlement, antagonism, and preachy/venting behavior. I'm also confused how someone who calls themselves a "lower than average" developer can be a "developer advocate". How are you ever going to empathize with the people you serve and the things they care about if you can't relate to them? This post almost perfectly exemplifies that out-of-touch nature.
mlindner 6y ago
Author has either just started learning git or has never used any previous RCS (Revision Control System). Put them on SVN, CVS, god forbid, Microsoft Visual SourceSafe and see how long they last. Just because something has some minor issues and "I don't like it" doesn't make it a failure.
Arkdy 6y ago
I considered using https://pijul.org/ https://pijul.org/ as an alternative to git, but Github is already so handy, popular and integrated that it's hard to justify switching. Does anyone think that they will ever abstract the platform from the specific git vcs?
- nemetroid 6y ago
  Pijul in particular is so fundamentally different from Git that it wouldn’t make sense to try to abstract over both of them.
dwheeler 6y ago
Git is a success. Claiming otherwise is silly. Git's user interface (porcelain) is not a great thing. Not because it's a CLI, but because it's not great for non-power end users. Case in point: Lousy naming inconsistencies. Git supports a staging area, but sometimes calls it a staging area & other times calls it an index. "Index" is a terrible term, because the word has too many other meanings. It's time for them to use one term ("staging area"); the inconsistency makes things harder to explain & use. Git is excessively complicated for simple uses, and it's easy to go wrong. Otherwise there wouldn't be sites like https://ohshitgit.com/ https://ohshitgit.com/ and cartoons like https://xkcd.com/1597/ https://xkcd.com/1597/ Mercurial (hg) shows that it is possible to have a distributed version control system with a simpler and clearer UI. Git has many technical advantages, and I use it all the time. Its fast branching, smart merging, and so on are all awesome. And while some people argue about the staging area, many have found it useful. It's perfectly reasonable to say "I like the tool's capabilities, but its user interface is not so good and needs improvement". That said, git's UI HAS gotten better over time. For example, "git checkout" was overloaded with two different meanings, and more recent versions of git have given them different names (git switch and git restore): https://www.i-programmer.info/news/90-tools/13027-git-adds-switch-and-restore.html https://www.i-programmer.info/news/90-tools/13027-git-adds-s... But it'd be great if the git developers worked to make it easier to understand & use by the non-power-users.
- the8472 6y ago
  > But it'd be great if the git developers worked to make it easier to understand & use by the non-power-users. Isn't that already covered by the various 3rd-party UIs?
- nunez 6y ago
  I am okay with Git the CLI being for power users as long as awesome UX developers create excellent user interfaces around it. There are great Git GUIs out there for those that need them, and many of them handle the core workflow (clone, pull and rebase, checkout, commit, push) really well. In fact, once I learned how Git works under the hood, the commands made a lot more sense. Perhaps the problem of distributed version control is just inherently complex?
- 6y ago
pg_bot 6y ago
I've worked at a couple of places where I was the "git guy", aka the person who fixed your git repo when you borked it. I don't understand why so many people have difficulty with git. I get the API can be a bit wonky, but why aren't you just aliasing commands to get around the bits you have difficulty remembering? You can tailor any UNIX tool to your own needs instead of relying on what was written by the original authors. Since version control is a tool you will most likely be using for your entire career save yourself the heartache and read some tutorials. If you learn what your tools are capable of you will be a much better developer in the long run.
- vidanay 6y ago
  Because those people don't read or study in order to lean something new. They just expect "magic".
  - loopz 6y ago
    You can't expect everyone to find those tutorials and videos within a full week. It's hit and miss, and the value is nonobvious at start. So if you want better results, share that will help the most. Not everyone will study asm and kernel calls either.
aeturnum 6y ago
Foucault talked about the idea of "governmentality."[1] This has gone many places, but one of the terms applications is to talk about learning to see like a state. To stop seeing humans or experience and start seeing the world as raw resources, defensible borders, potential treaty partners, etc. I think git creates a kind of "gitmentality" - where people start to think about code development in the structures and metaphors that git uses internally. I have always found git easy to use and easy to navigate, but I don't believe that the "git way" of representing changes or branching development are natural or obvious. The git way of talking about code is rigorous and reliable, but I don't think the structures it uses are grounded in previous human experience. Even though one can look back to previous structures (family trees, textual criticism) and see the techniques that git draws on, it generally avoids evoking cultural associations with those older systems (probably because doing so risks misunderstanding about the particulars of git). In general, it seems to me that when git encounters a situation that might be confusing, the tool chooses[2] to reveal more internal details instead of using a high level organizing concept. One could imagine a DSCM where the details of commit hashes and merge commits are hidden under guiding metaphors explained by the tools, but creating such a system is clearly a huge challenge! I can imagine it could be done, but I certainly don't know how to do it. Many of the things git does do not have culturally common antecedents. [1] https://en.wikipedia.org/wiki/Governmentality#Further_developments_of_the_concept https://en.wikipedia.org/wiki/Governmentality#Further_develo... [2] Which, of course, means the tools' designers choose.
- pmeunier 6y ago
  > The git way of talking about code is rigorous and reliable That's not quite true, for example the mere existence of "git rerere" means that conflicts are not really represented internally. Also, merges like 3-way merge (the default in Git) are not associative [1], meaning that you might get different results if you pull two consecutive commits A and B from a remote, or if you just pull B. [1] https://tahoe-lafs.org/%7Ezooko/badmerge/simple.html https://tahoe-lafs.org/%7Ezooko/badmerge/simple.html
ncmncm 6y ago
Still, pretty good as failures go. I wouldn't leave a failure like Git off my CV.
nineplay 6y ago
I think the biggest problem with 'git' is how hard it is to undo any mistakes. I'm freshly astonished every I mistakenly commit something and then have to carefully run 'git reset ~HEAD' some exact number of times to get back to a clean state. Thank goodness for my pricey IDE and it's history caching or I'd never manage. The reason I stick to 'commit', 'push' and 'merge' as my git flow is that I've gotten pretty good at undoing the messes I've made with them. I'm such a coward that my merge command is `git merge <branch> master --no-ff --no-commit`
- JesseObrien 6y ago
  Sounds like you need to use the reflog more often. git reflog keeps track of all changed references (branch tips, etc) being changed in your repository. You can effectively check back out into any state you want, whenever you want.
- plorkyeran 6y ago
  The thing I love most about git is how easy it is to undo any mistake short of deleting the repository.
- fanf2 6y ago
  I am amused that you complain about the difficulty of fixing mistakes. It is legitimately hard, but in other version control systems that emphasise immutable history, it’s impossible!
DenisM 6y ago
Anything Git does that Mercurial doesn’t? I wonder if I’m missing out sticking to hg.
eyelidlessness 6y ago
The comments here are deeply frustrating. Like, obviously no one considers git a failure overall. Obviously not even the tweet linked suggested that. So all the glib responses about that are unhelpful. But the ones that acknowledge the tweet’s (correct) point and say the failing is in the person who said it not having workarounds... that’s their point! It’s such a bad experience that you need to work around it!! Git is such a wonderful tool, I wouldn’t ever discourage anyone from using it. But its rough edges are such a source of pain that I discourage people from using it directly, even if they’re experienced devs. I personally encourage using a GUI over a bunch of CLI aliases, because the vast majority of normal git usage is so mundane it’s easy to make clicky, but even that mundane usage is complex enough that abstracting it at the shell is more likely to cause mishaps. Folks! That’s bad UI! It’s not a condemnation of the tool! It’s just a recognition that the tool’s primitives are too low level for normal, even technically minded normal, brains to interact with productively.
mro_name 6y ago
> that I need to understand how Git works under the covers to truly get advantage of it and not screw up my work. Happened to me with both knife and fire. Miserable failures with terrible UIs.

47 points by ardit33 6y ago

On Twitter, we cool kids call tripe like this cope

It's not fair to complain about how hard a tool is to use without comparing it to the alternatives. If git is a failure as claimed then the alternatives should be better, no? We have a list of known version control software [0], how many of these are better than git and how many are worse? I've heard Mercurial and Fossil are pretty good but I still haven't been pressured to give them a try. However, most of that list is filled with software people hated enough to ditch for git. I think it's very likely that git is solving a problem hard enough that it can't be simplified much further. If it can be simplified, I would expect to hear a growing minority of users pushing for people to switch to the next system. [0]: https://en.wikipedia.org/wiki/Comparison_of_version-control_software https://en.wikipedia.org/wiki/Comparison_of_version-control_...

guitarbill 6y ago
Mercurial sounds great, and ostensibly has less foot cannons... unless you use Mercurial Queues. I've learned to live with git, just like I have with English. It isn't perfect, but a lingua franca is useful, and it isn't so bad. If git is the worst part of your CI/CD workflow, that's a pretty good problem to have.
- bsder 6y ago
  And "Mercurial Queues" primarily exists because of people incessantly bitching about the lack of "git rebase" in Mercurial. So, what does that say about the original feature from git that implementing it created a ton of footguns into a revision control system that didn't have them before?
  - nemetroid 6y ago
    The original feature doesn’t have footguns, so what does it say? I’m genuinely curious.
  - atq2119 6y ago
    Considering that rebasing is a crucial feature of version control, it seems to say that there is inherent complexity in distributed version control. By virtue of being honest about the problem space and giving central importance to the inherent concepts, Git is probably the best existing solution, even if it's not necessarily the best possible solution.
    - bsder 6y ago
      > Considering that rebasing is a crucial feature of version control "Rebasing" is NOT a crucial feature. "Commit history" being immutable is an equally valid axiom. "Rebase" is an architectural feature of git that matches the organization structure of the Linux kernel (individual maintainers squash the detail of the commits as it passes up through developer->Maintainer A->Uber Maintainer B->Super Uber Maintainer C->Linus) by virtue of Conway's Law. I would posit that most development teams would be much better served never squashing commit messages. Too many groups incur the complexity of rebase without having any reason for doing so.
      - guitarbill 6y ago
        MQ is not just rebase. for example, it's a common way to integrate with code review tools. you might want to put out several commits as one CR (to make reviewing easier). then you want to fix up some feedback, i.e. rewrite history (note this also doesn't necessarily mean squashing when merging into the main branch). i think it's fair to say the committed history shouldn't change (even just on the main branch), and most (?) git servers support this. but ignoring the need for this/ignoring the distributed nature of version control will lead to hacks like MQ. rebase is flexible and allows this.
      - atq2119 6y ago
        > individual maintainers squash the detail of the commits as it passes up through developer->Maintainer A->Uber Maintainer B->Super Uber Maintainer C->Linus This is not how Linux kernel development works. Instead, once a series of patches has been reviewed and accepted by the first maintainer, there will be no more rebasing -- the commits will eventually flow into Linus' copy via pull requests that are reflected in the DAG as merge commit. The point here is that the kernel actually does code review, and commits often go through several versions before being accepted. That's where `git rebase` comes in, because as a developer, you need it during this revision process as you amend and fixup the individual commits of the patch series that you're working on. Of course, if you don't do proper code reviews on your projects, and/or you're sloppy with how changes make it into the code base, then you may get away without using `git rebase`. That may be acceptable for smaller projects, or perhaps for larger projects that are easier to test; and larger commercial projects may be able to afford the cost of papering over the inefficiencies that come with a sloppy review and development process. But it's just not feasible for something like the Linux kernel, and so `git rebase` really is essential.
- altfredd 6y ago
  In my experience, descriptions of the so-called "foot cannons" within Git are exaggerated by people, who don't understand Git and didn't use it much. It is virtually impossible to lose data, committed to Git. Between reflog, lazy garbage collection and ability to grep history for strings there is literally no way to corner yourself. I have never lost anything after years of using Git. Meanwhile, I have lost data at least once with most conventional filesystems and storage mediums: f2fs, ext4, ntfs, hard drives, SSDs, CDs, VHS tapes... Incidentally, when I tried to use Mercurial once (because the job demanded it) and immediately went for Mercurial Queues, the bug in implementation of Queues caused me to actually lose some data (an insignificant amount, but still!). Unstable internal storage format + implementing history editing via third-party tool = bad news.
eindiran 6y ago
Notably Mercurial and Fossil are also distributed; they differ a bit in how complex they are, what they allow you to do, which tools are bundled in, etc, but ultimately any of the DVCSes is going to be lightyears ahead of the pre-Git (pre-Mercurial? I'm not sure which came first) client-server VCSes. Regarding your point about git being unable to be further simplified, I think Mercurial demonstrates that that isn't true; it sacrifices some coverage of the edge cases to get a significantly simpler interface.
- jjav 6y ago
  > lightyears ahead of the pre-Git (pre-Mercurial? I'm not sure which came first) client-server VCSes git and mercurial both came out at the same time, April 2005. But neither was the first distributed scs by a very long shot. There was of course bitkeeper (which motivated git) and Sun's teamware was there all of the 90s. Surely several others.
  - fanf2 6y ago
    There was GNU arch / tla https://en.wikipedia.org/wiki/GNU_arch https://en.wikipedia.org/wiki/GNU_arch and monotone https://en.wikipedia.org/wiki/Monotone_(software) https://en.wikipedia.org/wiki/Monotone_(software)
jen20 6y ago
BitKeeper solves the same problems as Git with a _far_ more sane user interface. My personal opinion is that it's best in class. The thing Git has going for it (over BitKeeper or really anything else) is GitHub. If we had something like BitHub that were widely used instead, I don't think I would bother with Git for anything except contributions to projects using it, despite being a fairly advanced Git user through necessity.
- yencabulator 6y ago
  The thing Git has going over BitKeeper is that people are allowed to use Git. Larry revoked the license of some key developers, and if he hadn't done that, Git wouldn't probably even exist.

megous 6y ago

As someone who moved from CVS, to SVN, to tla/GNU Arch, to git (shortly after initial release). I haven't found any reason to move on from git ever since. Each step was a major change in features and ease of use. It's hard to see it as a failed system, with "bad" user experience. And the whole premise is nonsense. I certainly haven't spent more time on learning git than doing the work in the last 15 years or so of using it.

wildleaf 6y ago
I agree, my current company is stuck on cvs. I've been using git for years until now and it feels like I've had my legs chopped off.
anotherevan 6y ago
As someone who moved from CVS, to SVN, to Mercurial (with side-trips to SCCS, VSS, Bzr and Git along the way), I haven't found any reason to move from Mercurial ever since.
- megous 6y ago
  The thing is that if you commit to some well supported DVCS, UI differences between them are not that earth shattering, compared to VCS that need a server.
  - anotherevan 6y ago
    Well, I disagree. I find Mercurial much easier to grok and use than Git, and I learned Git first.
    - megous 6y ago
      The basic UI looks pretty much the same as the git one I'm used to.
      - anotherevan 6y ago

wobblyasp 6y ago

Code management, code versioning and code fixing are all hard problems. You can't in all cases put a simple tool/thing in front of it and fix it. Sometimes hard things are just that, hard. Also; git isn't meant for your "average" use case. People sometimes attempt to get content writers or other non-technical skills into git. It never works. There are far better tools purpose built for those use cases. Developers want tools that work, git works. Why would we try to make it better?

jjav 6y ago
> Sometimes hard things are just that, hard. Mercurial is proof that one can have a good scs with a usable CLI.
marty-oehme 6y ago
> People sometimes attempt to get content writers or other non-technical skills into git. It never works. There are far better tools purpose built for those use cases. Do you have an example of a tool like this? When writing for academia, as long as I produce content on my own everything is fine. But finding a good way for collaboration with versioning has been really hard for me so far. (without resorting to google docs)

archgoon 6y ago

May I be cursed with failures as bad as git.

raegis 6y ago
Right. It's amazing that Linus Torvalds created TWO separate things which changed the world. I'm still working on my first, and I fear I won't finish before retirement!

saagarjha 6y ago

Git the plumbing is a huge success story. Merkle trees, distributed development, lightweight branching, format so simple you could literally write tooling for it as a bunch of shell scripts–it's really great. Git the porcelain is terrible, and while I wouldn't call it a failure its user experience is a detriment, not an asset, to its overall niceness.

leephillips 6y ago
I love git. I use it for everything; I think of it as an extension to my filesystem, and, with fugitive, an extension to Vim. It gives me the superpower of time travel. I’m not even close to being an expert on it, but what I can glean from its design seems beautiful.
ssivark 6y ago
Git’s UI/porcelain definitely isn’t winning any awards. That said, why infantilize users so much that it’s considered abhorrent to understand the tool one depends on? The plumbing is so elegant/simple, after all! The utter passive cluelessness and disconnect-with-reality promoted & celebrated by “intuitive” interfaces reminds me of Mary Antoinette... “Tool not working... not intuitive enough :shrug:”
mekoka 6y ago
I always recommend learning Git by starting at chapter 10 (https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Po...) of the Git book. Granted the content is a bit technical and the advice generally directed at developers, but I found that once the plumbing is understood, the world of Git makes a lot more sense. The porcelain can still be quite ugly at times though.
- samatman 6y ago
  This is actually the central complaint of the tweet which kicked off this thread: git requires a complete mental model of the underlying internals and primitives, to compensate for the numerous unintuitive and complex operations which make up the 'porcelain'. I'm someone who thinks this is backward: the problem is that git's internals aren't doing what I want them to do. I'm not 100% convinced that I know what I want them to do, but I'm about 80% sold that I want a repo to be a collection of patches, with the larger structures, e.g. branches or histories, to be ways of organizing the application of those patches, and telling a story to other developers about why they exist. So I'm eagerly awaiting the next generation of pijul, to get the chance to see if that's right.

jasoneckert 6y ago

Git is not a success story? I wonder if the author of this tweet is aware that Git has almost entirely conquered the development world these past few years. That doesn't happen as a result of having a bad user experience. Git is a powerful tool that does an excellent job of versioning and collaboration, and I can't imagine wanting it to be any more user friendly than what it currently is.

bsder 6y ago
I disagree. Git didn't win--GitHub won. Git was the parasite carried along by the GitHub host.
- dwheeler 6y ago
  No, git essentially won. GitHub is the single most common site for OSS projects, but there are many others, and they generally use git as well. GitLab obviously supports git. SourceForge supports git. Savannah supports git. Bitbucket supports git. Microsoft internally uses git, and that happened before they bought GitHub: https://techcrunch.com/2017/05/24/microsoft-now-uses-git-and-gvfs-to-develop-windows/ https://techcrunch.com/2017/05/24/microsoft-now-uses-git-and... There are other version control systems, but git is by far and away the majority player.
  - bsder 6y ago
    Methinks you need a history lesson. Bitbucket was originally Mercurial-only. Savannah was SVN-only forever. SourceForge (geez--people still mention them after they turned into a dumpster fire of malware?) was CVS then SVN and only much later Git (long after SourceForge was relevant anymore). I presume GitLab was Git from the start. > Microsoft internally uses git Long after there was any relevance to the choice.
    - dwheeler 6y ago
      Methinks not. I was around for all that history, and that is exactly my point. Savannah, bitbucket, and SourceForge all added support for git later because they had to. They added support for git because git won, not because it failed. Also, please look at the article I cited about Microsoft. That was not just a simple swap. Microsoft could not use git as-is because of the way they use Version Control in general. Instead of sticking to their existing system, they implemented additional functionality for git so that git would work in their environment. That is a vote of confidence for git, because they believed it was better to add functionality to git.

bradhe 6y ago

The argument is that you have to know how the tool itself works in order to use it. This is, eventually, true with _every_ tool. Consider Postgres: It's really pretty easy to get up and running and for simple things works great. Once you start taxing the system you have to know how it's configured, what settings you have optionality over, and obviously how the subsystems work and behave based on those settings. This is just true with any dependency you take on: Any problem the dependency has is, eventually, your problem too. Git is a dependency of your software development process.

aaron695 6y ago

When XKCD makes a joke of it and a lot of people get it. It says a lot. https://xkcd.com/1597/ https://xkcd.com/1597/ I think perhaps a good front end for Git might help a lot though. But if Git as it stands is the best we can do as a planet for version control then that's a broken system.

oneplane 6y ago

Everything else has to be pretty 'perfect' for git to be the 'problem' of your toolset...

CapriciousCptl 6y ago

How to get retweets: “Popular and productive tool X has a rough spot around Y and is therefore a failure.” Nothing’s perfect, get over it, help out or make something better.

thrill 6y ago

Patient: Doctor, how do you know how deeply to cut? Surgeon: I'm never sure, I just hack at it until someone who knows how these things work tells me to stop.

TameAntelope 6y ago

Is this really how I'm supposed to operate in the world of technology and computer science? The negativity is a shame, I wish it weren't part and parcel of participating in the greater developer community.

denkmoon 6y ago

Mercurial presents a far more pleasant user experience. I've been very sad to see hg fade away in favour of git. Having taught graduates how to work with both tools, I found hg easier to explain (maybe because I prefer it though) and better retention/less questions in the future.

adembudak 6y ago

I love git mostly because its predictability, if you get along with it, you don't need to deep into the docs anymore, your guess probably end up with the right choice (most of the time:))

kyleee 6y ago

I've noticed it's somewhat en vogue in certain dev communities to bash git. I think since it started out as a CLI tool and some parts of git are complicated that it's easy to get cheap internet points by complaining about it

usr1106 6y ago

He should not complain, but write a better user interface. The underlying functionality and performance of the implementation is excellent. The user experience is poor, it took me several years to get really fluent. There are still things I know I don't know and some occasional surprises. The repos are such a success story that they won't go away for years. But if someone came up with a more consistent user interface that would not harm. It's a huge job though, if you want to cover the full functionality. And if you don't do that you will create a new inconsistency, because power users will sooner or later need to fall back to the current user interface.

Dylan16807 6y ago
> He should not complain, but write a better user interface. The average person has no idea how to write a good interface. That's not a very fair demand.
- usr1106 6y ago
  The problem is that it requires an exceptional SW designer to design a good interface for git. The internal model of git is exceptionally well designed and maintained by much better than average hackers. They master the crude UI concepts we have today and obviously they don't care. It's free and open software. So everyone working on it does what they like. Obviously no one has volunteered to write a great and consistent front-end. At least not successful enough that users would know and use it. But shouting that no one volunteers as the orginal twitter poster does makes just no sense.
ulisesrmzroche 6y ago
Valid criticism does not require a solution to be given.

tartoran 6y ago

Id take GIT anytime over the stupid TFS i have to deal with on a daily basis. It’s forced embedding in VS adds to the frustration even more.

MattGaiser 6y ago

Is there any frustrating UI issue with Git that a tool like GitKraken does not solve for those who have command line trouble or prefer to easily visualize things?

kodah 6y ago

Calling git a "failure" blanketly is dubious and I'd expect a "developer advocate" to know that. He actually goes on to say that he's "marketing his frustration" (https://twitter.com/hhariri/status/1314287590523236352 https://twitter.com/hhariri/status/1314287590523236352) It's also equally ironic that it's a "developer advocate" from JetBrains that's calling out an open source projects usability. A first step might be that he and JetBrains try contributing to git or trying to build new porcelain on top of git. That said, this is par for the course of the kind of user that resides on Twitter. Twitter is mostly used by toxic people who like to air their grievances before the world and then try to convince the rest of us it's healthy. We need to stop encouraging engineers to use Twitter to communicate, imo. It enables this armchair quarterback behavior while having zero investment in the production of the desired result.

angrais 6y ago
>> That said, this is par for the course of the kind of user that resides on Twitter. Twitter is mostly used by toxic people who like to air their grievances before the world and then try to convince the rest of us it's healthy. Just a reminder that you're currently on hacker news and not Twitter :)
- kodah 6y ago
  Sure, I posted a reply to my thread that has some more constructive feedback and examples.
kodah 6y ago
This guy is all sorts of irony, I've assembled some tweets from the last four days: - Preaching on how to "win allies" with positivity that he doesn't use https://twitter.com/hhariri/status/1315540900244848640 https://twitter.com/hhariri/status/1315540900244848640 - Antagonistic posting, alluding to that he'd like to call out Linux developers for user experience too https://twitter.com/hhariri/status/1314858276866134016 https://twitter.com/hhariri/status/1314858276866134016 - Bragging about being blocked by people on Twitter https://twitter.com/hhariri/status/1314836556008566784 https://twitter.com/hhariri/status/1314836556008566784 - He admits he's a "lower than average developer" but feels qualified to judge the work of others harshly https://twitter.com/hhariri/status/1314536445781180416 https://twitter.com/hhariri/status/1314536445781180416 - Speaking in the third person https://twitter.com/hhariri/status/1314590552344719360 https://twitter.com/hhariri/status/1314590552344719360 - More venting and antagonism https://twitter.com/hhariri/status/1314591215166291968 https://twitter.com/hhariri/status/1314591215166291968 - Antagonistic rhetoric https://twitter.com/hhariri/status/1314523004655874048 https://twitter.com/hhariri/status/1314523004655874048 - Continuing to preach (this has some interesting, negatively slanted replies) https://twitter.com/hhariri/status/1314179665574211584 https://twitter.com/hhariri/status/1314179665574211584 If you're an engineer on Twitter do yourself a favor and read your tweets as someone who doesn't know you. Getting to know your virtual-self is very important, because people have a tendency to act different online than they do in person. My impression of this guy based on four days of tweets? I'd block him and never use a JetBrains product again just for the sheer loads of entitlement, antagonism, and preachy/venting behavior. I'm also confused how someone who calls themselves a "lower than average" developer can be a "developer advocate". How are you ever going to empathize with the people you serve and the things they care about if you can't relate to them? This post almost perfectly exemplifies that out-of-touch nature.

mlindner 6y ago

Author has either just started learning git or has never used any previous RCS (Revision Control System). Put them on SVN, CVS, god forbid, Microsoft Visual SourceSafe and see how long they last. Just because something has some minor issues and "I don't like it" doesn't make it a failure.

Arkdy 6y ago

I considered using https://pijul.org/ https://pijul.org/ as an alternative to git, but Github is already so handy, popular and integrated that it's hard to justify switching. Does anyone think that they will ever abstract the platform from the specific git vcs?

nemetroid 6y ago
Pijul in particular is so fundamentally different from Git that it wouldn’t make sense to try to abstract over both of them.

dwheeler 6y ago

Git is a success. Claiming otherwise is silly. Git's user interface (porcelain) is not a great thing. Not because it's a CLI, but because it's not great for non-power end users. Case in point: Lousy naming inconsistencies. Git supports a staging area, but sometimes calls it a staging area & other times calls it an index. "Index" is a terrible term, because the word has too many other meanings. It's time for them to use one term ("staging area"); the inconsistency makes things harder to explain & use. Git is excessively complicated for simple uses, and it's easy to go wrong. Otherwise there wouldn't be sites like https://ohshitgit.com/ https://ohshitgit.com/ and cartoons like https://xkcd.com/1597/ https://xkcd.com/1597/ Mercurial (hg) shows that it is possible to have a distributed version control system with a simpler and clearer UI. Git has many technical advantages, and I use it all the time. Its fast branching, smart merging, and so on are all awesome. And while some people argue about the staging area, many have found it useful. It's perfectly reasonable to say "I like the tool's capabilities, but its user interface is not so good and needs improvement". That said, git's UI HAS gotten better over time. For example, "git checkout" was overloaded with two different meanings, and more recent versions of git have given them different names (git switch and git restore): https://www.i-programmer.info/news/90-tools/13027-git-adds-switch-and-restore.html https://www.i-programmer.info/news/90-tools/13027-git-adds-s... But it'd be great if the git developers worked to make it easier to understand & use by the non-power-users.

the8472 6y ago
> But it'd be great if the git developers worked to make it easier to understand & use by the non-power-users. Isn't that already covered by the various 3rd-party UIs?
nunez 6y ago
I am okay with Git the CLI being for power users as long as awesome UX developers create excellent user interfaces around it. There are great Git GUIs out there for those that need them, and many of them handle the core workflow (clone, pull and rebase, checkout, commit, push) really well. In fact, once I learned how Git works under the hood, the commands made a lot more sense. Perhaps the problem of distributed version control is just inherently complex?
6y ago

pg_bot 6y ago

I've worked at a couple of places where I was the "git guy", aka the person who fixed your git repo when you borked it. I don't understand why so many people have difficulty with git. I get the API can be a bit wonky, but why aren't you just aliasing commands to get around the bits you have difficulty remembering? You can tailor any UNIX tool to your own needs instead of relying on what was written by the original authors. Since version control is a tool you will most likely be using for your entire career save yourself the heartache and read some tutorials. If you learn what your tools are capable of you will be a much better developer in the long run.

vidanay 6y ago
Because those people don't read or study in order to lean something new. They just expect "magic".
- loopz 6y ago
  You can't expect everyone to find those tutorials and videos within a full week. It's hit and miss, and the value is nonobvious at start. So if you want better results, share that will help the most. Not everyone will study asm and kernel calls either.

aeturnum 6y ago

Foucault talked about the idea of "governmentality."[1] This has gone many places, but one of the terms applications is to talk about learning to see like a state. To stop seeing humans or experience and start seeing the world as raw resources, defensible borders, potential treaty partners, etc. I think git creates a kind of "gitmentality" - where people start to think about code development in the structures and metaphors that git uses internally. I have always found git easy to use and easy to navigate, but I don't believe that the "git way" of representing changes or branching development are natural or obvious. The git way of talking about code is rigorous and reliable, but I don't think the structures it uses are grounded in previous human experience. Even though one can look back to previous structures (family trees, textual criticism) and see the techniques that git draws on, it generally avoids evoking cultural associations with those older systems (probably because doing so risks misunderstanding about the particulars of git). In general, it seems to me that when git encounters a situation that might be confusing, the tool chooses[2] to reveal more internal details instead of using a high level organizing concept. One could imagine a DSCM where the details of commit hashes and merge commits are hidden under guiding metaphors explained by the tools, but creating such a system is clearly a huge challenge! I can imagine it could be done, but I certainly don't know how to do it. Many of the things git does do not have culturally common antecedents. [1] https://en.wikipedia.org/wiki/Governmentality#Further_developments_of_the_concept https://en.wikipedia.org/wiki/Governmentality#Further_develo... [2] Which, of course, means the tools' designers choose.

pmeunier 6y ago
> The git way of talking about code is rigorous and reliable That's not quite true, for example the mere existence of "git rerere" means that conflicts are not really represented internally. Also, merges like 3-way merge (the default in Git) are not associative [1], meaning that you might get different results if you pull two consecutive commits A and B from a remote, or if you just pull B. [1] https://tahoe-lafs.org/%7Ezooko/badmerge/simple.html https://tahoe-lafs.org/%7Ezooko/badmerge/simple.html

ncmncm 6y ago

Still, pretty good as failures go. I wouldn't leave a failure like Git off my CV.

nineplay 6y ago

I think the biggest problem with 'git' is how hard it is to undo any mistakes. I'm freshly astonished every I mistakenly commit something and then have to carefully run 'git reset ~HEAD' some exact number of times to get back to a clean state. Thank goodness for my pricey IDE and it's history caching or I'd never manage. The reason I stick to 'commit', 'push' and 'merge' as my git flow is that I've gotten pretty good at undoing the messes I've made with them. I'm such a coward that my merge command is `git merge <branch> master --no-ff --no-commit`

JesseObrien 6y ago
Sounds like you need to use the reflog more often. git reflog keeps track of all changed references (branch tips, etc) being changed in your repository. You can effectively check back out into any state you want, whenever you want.
plorkyeran 6y ago
The thing I love most about git is how easy it is to undo any mistake short of deleting the repository.
fanf2 6y ago
I am amused that you complain about the difficulty of fixing mistakes. It is legitimately hard, but in other version control systems that emphasise immutable history, it’s impossible!

DenisM 6y ago

Anything Git does that Mercurial doesn’t? I wonder if I’m missing out sticking to hg.

eyelidlessness 6y ago

The comments here are deeply frustrating. Like, obviously no one considers git a failure overall. Obviously not even the tweet linked suggested that. So all the glib responses about that are unhelpful. But the ones that acknowledge the tweet’s (correct) point and say the failing is in the person who said it not having workarounds... that’s their point! It’s such a bad experience that you need to work around it!! Git is such a wonderful tool, I wouldn’t ever discourage anyone from using it. But its rough edges are such a source of pain that I discourage people from using it directly, even if they’re experienced devs. I personally encourage using a GUI over a bunch of CLI aliases, because the vast majority of normal git usage is so mundane it’s easy to make clicky, but even that mundane usage is complex enough that abstracting it at the shell is more likely to cause mishaps. Folks! That’s bad UI! It’s not a condemnation of the tool! It’s just a recognition that the tool’s primitives are too low level for normal, even technically minded normal, brains to interact with productively.

mro_name 6y ago

> that I need to understand how Git works under the covers to truly get advantage of it and not screw up my work. Happened to me with both knife and fire. Miserable failures with terrible UIs.