>I could never understand the complaint that Git is "hard to use".

It uses horribly unintuitive metaphors and has weird cryptic methods for doing common, simple tasks that practically require the use of google unless you've memorized the UI.

There's a reason that there is a plethora of wrappers around the system (most of them not very good, unfortunately :().

>In any case, we are supposed to be professionals. Complaining that Git is hard to use is a bit like a machinist complaining that a CNC machine is hard to use.

Gatekeeping is the real reason why git's shoddy UI is tolerated (possibly even celebrated). Knowing and memorizing its quirks is seen as the mark of a "true" professional software developer.

>If you want to accomplish non-trivial things in any field, you have to be prepared to deal with some level of complexity. /rant

I don't agree. 99% of git usage on a project involves a series of repetitive commands following one of about < 8 different workflows per project. I'd rather actually use a high level tool that allows you to build and use these workflows on a project by project basis, but sadly I've never really seen a good tool to do this.

Such a tool would also open up git to non-programmers, allowing easier collaboration. I'd love to see managers tweak configuration properties via git, designers push assets, copywriters push copy and translators push content. I wouldn't have to be the go-between on all of this stuff.

The language is part of the reason its so confusing. Why is called a commit? Makes no sense and is confusing. The commands should be obvious by looking at it. Why does someone make a pull request? It seems backwards as people push to a repository.

And then there is all the flags. Why in 2018 are we not writing full words?

Linus is a genius, but he makes things that works for him and without much consideration for others. This is just human nature I think.

The way I see it the Git nomenclature makes much sense.

You "push" to a repository, if it is yours, but you cannot just push to the repositories of others. You make a "pull request" for others to fetch changes from you.

Commit is a "commit" because you "commit a change" as in make something new which differs from the previous state.

"Rebase" just puts your commits on top of the other branch, using the other branch as a "base". (It helps to think of the graph structure)

"Branch" is a branch because what you have is a kind of tree of commits, often more or less a straight line if you've done it right (IMO), and when you make something to work with you deviate from this other history of commits by branching off from it.

I mean it is rather standard terminology, and most importantly, it makes sense. Don't get me started with e.g. Clearcase which frankly makes no sense and should be killed with atomic weapons from low Earth orbit (or any orbit as long as it does the job), just to be sure.

As for hard to use, I never understood this either... I usually use a handful of commands and get things done just fine. If I ever feel like absolutely having to use some kind exotic merge with --onto and looking up octopus merges and whatnot I am probably doing something wrong.

There are plenty of good Git resources available, for example https://git-scm.com/

My perspective is this. I am a quite experiance CNC operator and have used this particular model for over a decade. I don’t have a problem with it, even though I admit it took a bit of getting used to originally and I still agree that the controls aren’t intuitive, but that doesn’t matter to me cause I know them by heart... but now I’m running a shop with 5 other CNC operators who constantly break the machine and shut down work for trivial completely non problems like John used Peters Machine and now Peter is back so John is back on his own machine, suddenly none is able to turn on their machines so they’ve all started cutting out parts by hand. So I’m spending tons of time dealing with complete bullshit things that would not otherwise have been a problem had it not been for this particular brand of CNC. It doesn’t matter how well I personally know the machine, because the problem is that I’m now wasting my time trying to prevent them from wasting theirs. This is not a problem of inexperienced operators, it’s a problem with a machine that only works with the aid of a super-user, and which doesn’t easily show the path of how people should develop super-user abilities without breaking stuff and working really hard to understand what they broke and why before they can move on to fix it.

Thank god I’ve never had to deal with a CNC machine like that. But git is that machine.

Secretly I think this is the true reason for gits popularity. It’s like vim, a wonderful tool once you get past the first hill, but I would never force a whole team to use vim, I know it would be a disaster productivity wise. But because of gits popularity it is indeed forced on almost every developer.

> But git is that machine. Secretly I think this is the true reason for its popularity.

I think it became popular because it was written to solve the needs of the largest collaborative project in the history of mankind (Linux). It was objectively better for that job than any other tool that was available at the time (and thus for many such collaborative projects), and that's where the popularity came from.

Now, does it have warts? Yes. I don't agree that it requires very detailed knowledge to use effectively (if I was able to figure it out as a high-school student, I'm certain that it's not beyond the majority of developers). I think it's just that many developers don't feel the need to learn how to use their tools effectively, and if a tool isn't as-easy-as-possible for simple tasks (which I will admit is the case for Git -- the index concept appears to really throw people off) then it is seen as being "too hard".

In your scenario, using a CNC machine is a key part of their jobs as CNC operators -- so I would expect that learning how to use the CNC machine they use for their job would be an important part of working there. Similarly, developers who use git daily (and is a central part of their work) really should put the time into learning how to use it effectively (it wouldn't take more than a weekend with the right resources). I don't think it's reasonable to say that a developer whose job it is to use git should not have any burden to learn how to use their tools, and that it's the tools fault for being hard to use.

I don't disagree that the on-boarding with git and some of the UX (such as stashing) is quite bad. But it's nowhere near as hard as people make out, and at the end of the day if you want to use something you should learn how to use it -- just because you can get it to somewhat work after 10 minutes of bashing at your keyboard doesn't mean you shouldn't spend the few extra hours to actually understand what you're doing. git is a transferable skill, and the time taken to learn how to use it pays off very quickly.

Git, the version control system, is pretty simple. Git, the command line tool that helps manage repositories, is not.

Which is why I like gutless. Same VCS, sane interfaces, less state to juggle.

Linus' power had lasted that much.

Not everyone here is a 'professional' software developer. Git does have a steep learning curve.

(I've used git extensively for years, just playing devil's advocate)

To reinforce your point - I have worked with people in the past, mostly older, that struggled a lot with Git when all they were trying to do was something simple like commit some static files generated from third-party software to my project. These people only needed the bare minimum (stage, commit, push) of Git yet found themselves baffled and fighting with the tool because of all the possibilities and things it could do that they didn’t really need.

There's a fair amount of tools capable of manipulating a Git repo, not all of which are `/usr/bin/git`. "Everybody must use this complex CLI power tool, therefore people struggle" is simply untrue here, in the premise.

Try managing a massive set of inter-dependent repositories too big for a mono-repo with git, then you will know "hard to use". Your only real choice in this case is submodules, and those bring in an additional layer of pain.

There's also "repo" from Google. And many other tools.

Git is not a panacea for bad design. If you have interdependent repositories (I read that the same as a cyclical dependency, A needs B needs A), then you should fix that first. I mean, if you have the described setup, you will have other problems too...

No, you also have the choice of using separate repositories, and just connecting them with dependency lists. I never understood the obsession with putting hundreds of millions of lines of code¹ in a single repo. Whatever happened to decoupling?

¹ Git can handle dozens of millions, as shown by the Linux kernel

Well even the entire windows sits in a single git repo https://blogs.msdn.microsoft.com/bharry/2017/05/24/the-large...