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.
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.
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?
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.
> 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.
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.
> 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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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?
> 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)
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!
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.
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.
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:”
I always recommend learning Git by starting at chapter 10 (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.
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.
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.
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...
There are other version control systems, but git is by far and away the majority player.
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).
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.
I think mercurial's user interface has its advantages, but when they were facing off each other, git was far faster and quickly added more advanced capabilities. Power users preferred the speed, and they were the ones generally deciding which version control systems to use.
But that does not mean that git's user interface is perfect. I think there are many things that could be done to make it much easier to understand and use by non power users.
I think perhaps all that's needed is a GUI front end that ignores the structure of Git and just gives non-power users what they want.
Like one button. Backup, delete repo, re-pull and re-add my changes. No explanation of what's doing under the hood. Simplify branches for simple repos. Power users can do their thing seperate.
And improve GitHub. A WYSIWYG to edit .md files for instance.
I think it's not impossible to get Git and GitHub good.
>conquered the development world these past few years. That doesn't happen as a result of having a bad user experience
might does not make right. I can think of a few technologies that are overwhelmingly popular but are, objectively speaking, at best mediocre or in some cases downright awful.
Now I think overall git is a positive and it's a hard problem, but some aspects of it, like its user interface are pretty bad.
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.
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.
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.
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:))
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
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.
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.
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?
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)
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.
>> 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 :)
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.
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.
I considered using 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?
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/ and cartoons like 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-s...
But it'd be great if the git developers worked to make it easier to understand & use by the non-power-users.
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?
Depends on what's the bar for "power users" I suppose.
git is easy for the daily use case where nothing special needs to be done and nothing goes wrong. But that's the vast majority of the time, so mostly it's fine.
It is when anything out of the ordinary flow needs to be done that it becomes impenetrable and often leads to data loss (or at least, an irrecoverable state which requires restoring from backup).
I've been using source control over 30 years now, with the vast majority of those years being on distributed source control systems (starting with Sun's teamware in the mid-90s). git is the one and only where I have had to adopt the practice of making a tarball of the current working dir before any nontrivial operation. And I end up having to use that backup every so often as git gets into some irrecoverable state of confusion.
Some of the comments in this and other git threads suggest (and I'll believe it) that if I were to dedicate substantial time to become an expert in the implementation detail and inner working of git, it might be possible to avoid these irrecoverable states. Ok.
That right there is an indication of a massive user interface failure.
I'm not proud to admit (but I was interested to read that I'm not the only one) that I've gotten into the habit of making a tarball of my working directory and .git directory before large rebase operations between multiple feature branches, because like you I've lost work because git got into awkward states I couldn't get it out of without losing work.
A full system backup of my laptops is taken roughly every three hours so it's quite hard for me to lose more work than that. However recovering from a failed rebase without losing changes can also consume a sizable amount of time, which explains why I'm still careful and take precautions anyway.
There’s basically never an irrecoverable state in git, and it’s rare that you can’t recover “lost” data from the reflog. Yes it does require expertise to recover from a cockup, but you will never gain the expertise if you treat it as impossible.
Note that you don’t have to avoid getting in a mess: it’s normal, when you are trying to do something unusual or advanced (or impossible in other version control systems) to make a mistake and accidentally blow your foot off, but git gives you the tools to glue your foot back on good as new.
> There’s basically never an irrecoverable state in git
That is technically correct but irrelevant. If a user doesn't know how to easily recover, then there's a problem.
There should probably be a "git undo" command that always undoes whatever was done last. There's usually a way to undo a command (e.g., using the reflog), but the problem is that you have to know the correct incantation for every circumstance:
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.
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.
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.
> 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.
86 comments
[ 4.6 ms ] story [ 160 ms ] threadI 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_...
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.
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?
"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.
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.
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.
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.
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.
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.
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.
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.
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?
Mercurial is proof that one can have a good scs with a usable CLI.
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)
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.
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:”
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.
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.
Git was the parasite carried along by the GitHub host.
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...
There are other version control systems, but git is by far and away the majority player.
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.
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.
Linux backed, followed by GitHub sold the deal.
The incumbents were possibly better but were too forked to individually beat that team. It became a standard like English as someone else pointed out.
I think mercurial's user interface has its advantages, but when they were facing off each other, git was far faster and quickly added more advanced capabilities. Power users preferred the speed, and they were the ones generally deciding which version control systems to use.
But that does not mean that git's user interface is perfect. I think there are many things that could be done to make it much easier to understand and use by non power users.
I think perhaps all that's needed is a GUI front end that ignores the structure of Git and just gives non-power users what they want.
Like one button. Backup, delete repo, re-pull and re-add my changes. No explanation of what's doing under the hood. Simplify branches for simple repos. Power users can do their thing seperate.
And improve GitHub. A WYSIWYG to edit .md files for instance.
I think it's not impossible to get Git and GitHub good.
might does not make right. I can think of a few technologies that are overwhelmingly popular but are, objectively speaking, at best mediocre or in some cases downright awful.
Now I think overall git is a positive and it's a hard problem, but some aspects of it, like its user interface are pretty bad.
The problem I have with Git conquering the dev world is that it was built with large, over-the-internet projects in mind.
That same design hampers other projects, but who really wants to learn multiple VCS?
Git doesn’t do well with blobs and binaries (it’s convenient to have in VCS).
Git also isn’t so great with classic software structures either, where different teams work on different modules to build up into a whole.
There are third party tools to paper over this difference, but the right tool for the right project applies.
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.
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.
Surgeon: I'm never sure, I just hack at it until someone who knows how these things work tells me to stop.
The negativity is a shame, I wish it weren't part and parcel of participating in the greater developer community.
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.
The average person has no idea how to write a good interface. That's not a very fair demand.
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.
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.
Just a reminder that you're currently on hacker news and not Twitter :)
- Preaching on how to "win allies" with positivity that he doesn't use 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
- Bragging about being blocked by people on Twitter 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
- Speaking in the third person https://twitter.com/hhariri/status/1314590552344719360
- More venting and antagonism https://twitter.com/hhariri/status/1314591215166291968
- Antagonistic rhetoric https://twitter.com/hhariri/status/1314523004655874048
- Continuing to preach (this has some interesting, negatively slanted replies) 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.
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/ and cartoons like 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-s...
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?
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?
Depends on what's the bar for "power users" I suppose.
git is easy for the daily use case where nothing special needs to be done and nothing goes wrong. But that's the vast majority of the time, so mostly it's fine.
It is when anything out of the ordinary flow needs to be done that it becomes impenetrable and often leads to data loss (or at least, an irrecoverable state which requires restoring from backup).
I've been using source control over 30 years now, with the vast majority of those years being on distributed source control systems (starting with Sun's teamware in the mid-90s). git is the one and only where I have had to adopt the practice of making a tarball of the current working dir before any nontrivial operation. And I end up having to use that backup every so often as git gets into some irrecoverable state of confusion.
Some of the comments in this and other git threads suggest (and I'll believe it) that if I were to dedicate substantial time to become an expert in the implementation detail and inner working of git, it might be possible to avoid these irrecoverable states. Ok.
That right there is an indication of a massive user interface failure.
A full system backup of my laptops is taken roughly every three hours so it's quite hard for me to lose more work than that. However recovering from a failed rebase without losing changes can also consume a sizable amount of time, which explains why I'm still careful and take precautions anyway.
Note that you don’t have to avoid getting in a mess: it’s normal, when you are trying to do something unusual or advanced (or impossible in other version control systems) to make a mistake and accidentally blow your foot off, but git gives you the tools to glue your foot back on good as new.
That is technically correct but irrelevant. If a user doesn't know how to easily recover, then there's a problem.
There should probably be a "git undo" command that always undoes whatever was done last. There's usually a way to undo a command (e.g., using the reflog), but the problem is that you have to know the correct incantation for every circumstance:
https://github.blog/2015-06-08-how-to-undo-almost-anything-w...
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.
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_develo...
[2] Which, of course, means the tools' designers choose.
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