I used CVS and ClearCase before moving into Git, and it took me some time to adjust to the fact that the cost of branching in Git is much much less than ClearCase. And getting into the “distributed” mindset didn’t happen overnight.
I used CVS and ClearCase before moving into Git, and it took me some time to adjust to the fact that the cost of branching in Git is much much less than ClearCase. And getting into the “distributed” mindset didn’t happen overnight.
I’ve seen this sort of opinion surface often,but it never comes with specific examples. This takes away from the credibility of any of these claims.
Can you provide a single example that you feel illustrates the roughest aspect of Git’s user experience?
Yeah sure.
git pushsays “did you meangit push -u branchname origin”. Yes obviously I meant that. I always mean that.I’d been copying and pasting that for about 5 years before I discovered there’s a feature (auto branch setup or something) which means it will automatically do that. But it’s not mentioned in the error message! Why?
Git has a load of
--fixed-behaviourflags like that that are just not on by default and never mentioned.The terminology is very poorly chosen in a lot of cases. “The index”? Wtf is that? “Staging area” is at least slightly better but would “draft commit” have been too much to ask? Ours/theirs is also a stonkingly bad choice of words. How does Git know which code is mine? It doesn’t. Hell it isn’t even consistent about which way around they are.
Someone has force pushed a branch and I want to update my local ref (without typing the whole branch name again).
git pullgives a wall of text without the answer, which is…git reset --hard @{u}. Catchy!Or maybe I’ve got a branch that is tracking my fork but I want to pull from upstream. Can I do
git pull upstream? Nope. I have to repeat the branch namegit pull upstream branch-i-am-on. (Please don’t say "but git doesn’t know which branch you want to pull.)Then there’s the error messages… Make a branch called
foo/bar. Now try to check out a remote branchfoo. See that nice explanation about how git branches are actually files and directories, not just strings? Nope? Huh.This is just a few I can remember off the top of my head but it’s the tip of the iceberg.
The completely useless error messages kill me. And the commands that don’t do what they say… WTF is the point in “clean” and “force” if they don’t clean or force? And then there’s the inconsistency in command arguments. With one you have to use force, even though it doesn’t actually force, and the other you have to use “hard”. Hard? I mean I guess hard makes sense once you realize that force doesn’t actually mean force. Now I’m just waiting to run across the switch “–seriouslyguysimeanitthistime”.
OMG, I can’t up vote this thread enough… git is such a purposefully exclusionary step in software development that I can’t believe it is the preferred solution. It is very powerful, but it is painfully obvious that no one has ever gone back and said, “but what if anyone else who wants to use this is not a Linux cli guru and already has an expert understanding of git commands?”. Why is it that learning to check in code is significantly harder than learning the actual IDEs that the devel uses to develop the code?
This x100. I mean I think I know the answer - Git was written by a C kernel guy, and the devs that it attracted are C guys. The kind of people who think user friendliness is a weakness. Guess how you contribute a patch to Git? Well step 1 is reading a 10 page essay… Needless to say that isn’t going to attract many people that care about beginners.
yea this all generally tracks.
The kind of “polish” I’m talking about is the sort that a good UI/UX/GUI dev would do by tracking common user behaviours and needs or having testing users run the app through its paces. All of these confusing instances where better terminology, commands and error messages would come up through a process like that.
Now, one could say that this is a dev tool which shouldn’t need to go through that process. That developers should be expected to understand the tool’s inner workings and conceptual model well enough to not need any of that. But that gets back to my initial point. Git is so popular and basically ubiquitous now that that policy makes little sense. Many devs who use or are expected to use git are not capable of getting to terms with git’s internals to the point of never having difficulty with the UI, either because of a lack of time, capacity or skill. Moreover, the time required to get familiar with git enough to never find the UI frustrating should not be underestimated … it’s not just conceptual but technical and specific to git’s implementation details to the point of just knowing how the UI/CLI has been implemented.
If you want to trash such developers … go ahead … but they’re still developer’s doing work and it’s to the industry’s benefit to have a standardised and powerful VCS … which means that at some point it’s worth thinking about meeting developers where they are.
Beyond all of that … one could also say “fuck that” and talk about how being popular and “the standard” requires being better. Git’s centrality to the dev workflow as at text-editor levels. But while text editors have a portable format (IE “plain text” and character encodings) and so enjoy pretty healthy competition (vim, emacs, sublime, VSCode, Jetbrains … etc) … VCSs, AFAICT, don’t have the same portability and neither the competition. I’m actually curious now … are there drop in replacements for git that provide complete compatibility but are completely different implementations?.
It’s interesting, IMO, to think about why/how this has come to be, but in the end, it means that there’s a lot on git’s shoulders here. Even a little bit of an improvement can go a long way, and so being critical (rather than cultishly defensive), I’d argue, is the correct aspect here on utilitarian grounds.
As for why git is in its current situation (without having really thought about it before) … I’d actually speculate that there’s something insidious here regarding it’s imperfect/confusing UI. Namely that it has a monopolising force. Once it’s gained critical mass, and once there are enough devs out there who have deep and experienced understanding of the tool, and enough internet content capturing that expertise, then moving off to another tool which doesn’t have the same established expertise is prohibitively difficult. Comparing here VCS to text editing and programming languages may be part of it, where the basic difficulty of doing VCS (at least in so far as the complexity is exposed to the user) is likely somewhere between that of a text-editor and a programming language. In a similar vein, the solution space for VCSs is probably relatively small while text-editors and languages enjoy a good deal of design variety. And so, there’s little interest or inventive or even capacity to come up with interesting alternatives for what is a relatively difficult/complex kind of tool, which gives any established VCS a good amount of competitive protection and inertia.
Keep in mind though, I’m not talking about the UI here, but the core functionality. That many GUIs exist shows that the UI is a relatively open design space. But that git itself has hardly explored that space on their own is my critique (where comparing to text editors like vim/nvim and emacs and the built-in features they have might be informative here).
I mean sure. I personally haven’t researched and become an expert on this … it is an early-user’s misconceptions thread after all. And a dev can justifiably reflect on all of their tooling and consider their general usability against their popularity.
However, by the same token, your lack of any counter examples isn’t exactly highly credible either.
Nonetheless:
deleted by creator
You didn’t provided a single concrete example of something you actually feel could be improved.
The most concrete complain you could come up was struggling with remembering commands, again without providing any concrete example or specific.
Why is it so hard for critics to actually point out a specific example of something they feel could be improved? It’s always “I’ve heard someone say that x”.
Because this is a casual discussion and that’d be more effort than I’m willing to put in. Also, your premise is false: it can both be
trivialNON-trivial to implement something better and relatively obvious that a better implementation could exist.Also, if you’ve encountered these sorts of discussions before, I’d dare say it’s because people often avoid flame wars and you give off flame war energy.
I’ve mentioned two pretty concrete examples: be like mercurial and have a built in GUI. The basic commands being janky is also pretty concrete given the recent additions that have been made to correct that. But I don’t trust that you want a discussion because you’re being pretty demanding and aggressive here. Sea lioning would be somewhat apt … there is such a thing as meeting people where they are … do you have an example of something people often criticise about git that you don’t think can be improved or not easily? “Why is it so hard for replies to actually have a discussion rather than be demanding, argumentative and aggressive”
I didn’t asked you to write a research paper. You accused Git of suffering from usability issues and I asked you to provide concrete examples.
And apparently that’s an impossible task for you.
If you cannot come up with a single example and instead write a wall of text on you cannot put the effort to even provide a single opinion… What does this say about your claims?