Back to the tutorial:
> you can only really use Git if you understand how Git works. Merely memorizing which commands you should run at what times will work in the short run, but it’s only a matter of time before you get stuck or, worse, break something.
> Half of the existing resources on Git, unfortunately, take just that approach: they walk you through which commands to run when, and expect that you should do fine if you just mimic those commands. The other half does go through all the concepts, but from what I have seen, they explain Git in a manner that assumes you already understand how Git works.
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. If you want to accomplish non-trivial things in any field, you have to be prepared to deal with some level of complexity. /rant
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.
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.
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/
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.
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.
(I've used git extensively for years, just playing devil's advocate)
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...
¹ Git can handle dozens of millions, as shown by the Linux kernel
My aliases do not work cleanly, so I don't want to advertise them. Still, a git wrapper which removes the index would be an improvement.
By the way, can we still call it "porcelain" or is that outdated?
How is that easier than the index and how do you undo changes?
Conceptually programmers having to mentally convert every line is poor ergonomics and will reduce speed and increase errors. Going to labels instead of numbers is an improvement even if shallow and able to improved upon further.
It should be noted that Git was not unique in its design. There were many source-control systems that had the same model that pre-dated Git, it's just that Git was fast and significantly easier to use than the other tools. The previous tools would not have been usable for developing Linux, and so Git was obviously necessary.
[1]: https://pijul.org/
I have heard people complain about the staging concept (personally I find it useful, because you can do 'git add -p' which allows you to craft intermediate commits or to-be-squashed fixup commits after you've finished some development), so it's removal in this tool is unsurprising. And it is nice to auto-stash on branch change (though personally I think that they should've made stashing a much better-supported concept in their Git wrapper -- I've never really liked how stashing was implemented in Git).
I do really like that they appear to have worked hard to remove all of the super-scary warnings that Git likes to spit out. As someone who has taught high-school students how to use Git (among other things), I've learned that the easiest way to scare away people from your project is to have bright-red warnings in response to a user doing something. Most students describe it as though the computer is effectively screaming at them. Some tools over-compensate for this is and spew emoji in response to user input, so I'm happy this tool has struck the right balance.