It's quite frustrating seeing people complain about Git usability like it's some broadly accepted and objectively bad thing. As frivolous as anecdotes are, I took to Git very smoothly and I found it to operate in a very obvious and explicit fashion, particularly once I'd shifted my mental model from what I was using at the time (primarily SVN.)
Git is a very powerful, flexible, reliable and efficient tool. I'd be over the moon if someone wrote an init system holding similar values.
Couldn't agree more here. I picked up git at the same time I was starting out as a professional programmer, and never had any major problems with it at all. In fact I remember it being a breath of fresh air from my previous version control experience, which was banging around with TortoiseSVN on Windows.
I still remember the first time I used "git cherry-pick," I just guessed what it needed from my (then pretty limited) git experience, and it just worked seamlessly. The few little command-line quirks in git (like "checkout" being used to create new branches) are barely worth mentioning.
>Couldn't agree more here. I picked up git at the same time I was starting out as a professional programmer, and never had any major problems with it at all.
With all due respect, if you have zero experience with any other CLI solution, are you sure you can evaluate the qualities of git's interface? Nobody said git isn't capable.
Why not? First-time experience with VCS and git compared to first-time experience with git but multi-year experience with others VCS are both valid experiences that has to be considered.
Nobody is saying Git is unusable, or that it doesn't work, or that it isn't powerful.
We're saying the alternatives are easier to use. You freely admit you haven't used any of the alternatives - you haven't even used SVN from a command line, so you have literally nothing to compare to when using git commands.
Well, I am not saying that nor admitting to not having used anything else. AndrewBissell above did state that though.
My only point being, that while git is not perfect compared to others, even if you don't have experience with an alternative CLI, your experience with just that one CLI can be valuable.
Apologies, I didn't notice the different username. However I disagree - when the whole point is relative ease of use, having experience in just one is meaningless.
Yeah, on one hand, relative ease of use is important, especially if you're trying to write a tool to replace others. And I'm not saying that is not important. Just that it's important to consider both, not only one.
Compare it to when trying to make a website easier to use. Ok, fine, compare it to other websites too, but your first-timers that have no experience with anything else are important too.
Do you have a source for this widespread acceptance? I mean I get that version control in general can be hard for new developers to wrap their heads around but I never really had trouble picking up git personally, and the interns at my workplace haven't had any significant trouble either besides needing some coaching in how rebase works.
This comment (from a Hg developer on Lobste.rs [1]) is a good start:
> Furthermore, the proliferation of git wrappers says something. Mercurial has a lot of users too (Facebook), and guess what, they don’t write wrappers for it. They do write aliases and extensions, using hg’s established customisation mechanisms, but they don’t feel like the entire UI is so terrible that it has to be completely replaced by a different UI
Then let's consider this snippet, from the people that literally wrote the book on Git, in the Chapter "Git Internals" [2]:
> You may have skipped to this chapter from a previous chapter, or you may have gotten here after reading the rest of the book — in either case, this is where you’ll go over the inner workings and implementation of Git. I found that learning this information was fundamentally important to understanding how useful and powerful Git is, but others have argued to me that it can be confusing and unnecessarily complex for beginners.
If you don't know the internals, you don't really know git. I use git for client work on at least a weekly basis - not necessarily daily. I know enough to use it, and enough to know when I need to check the manual or search for something. I don't know the internals, and it's wrong that we 'need' need to.
Careful with equating "Facebook is a wildly market-successful product" with "Every engineering practice at Facebook is industry-applicable and should be emulated".
I didn't, the Hg dev simply used Facebook as a very large, well known software shop that uses Mercurial. We could swap out "Facebook" for "Mozilla" or "Nginx Inc." or a number of open source (either community or corporate backed) projects.
We could do the same thing with Git though, so clearly source control scheme is not strongly correlated with actual success of the project -- which makes sense.
The point was that there are a lot of git "wrappers" created to solve the problem of Git's usability. The same doesn't happen with Mercurial, and it isn't just because of a lack of use, as demonstrated by X, Y, Z prominent/large software companies/projects using it.
The UI has some warts, and a few design choices were made that some people find questionable. You can get used to them (which is probably why most people don't even notice it as a problem), but they're there.
Git is a very powerful, flexible, reliable and efficient tool. I'd be over the moon if someone wrote an init system holding similar values.