Hacker News Reader

In my own experience, https://www.sbf5.com/~cduan/technical/git/ makes all the difference in this world. The main complaint still remains: the CLI UX (yes, CLI has a user experience!) is really bewildeirng because switches change commands in really, really significant ways, so much so they ought to be different commands. And operations have totally different ways to express "work with repo only" "work with index" "work with working tree". And then git reset does not touch your working files but git reset --hard ruins your day unless you build a safety net: https://gist.github.com/chx/85db0ebed1e02ab14b1a65b6024dea29

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.

I could never understand the complaint that Git is "hard to use". Having used a plethora of version control systems over many years, I never found Git to significantly more or less complicated than any other system. Version management includes many use cases, some of which are inherently complex. Therefore any version control tool must be able to perform both simple and complex tasks, and the latter ones will obviously require a more complicated syntax and conceptual model.

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

>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...

I'm now roughly one year into my experiment to not use the index. I made some aliases to do that. My conclusion is: The index is unnecessary complexity. Amend to commits instead.

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?

"The index is unnecessary complexity. Amend to commits instead."

How is that easier than the index and how do you undo changes?

Conceptual problems themselves may be shallow, deep, or both. Wrapping machine code with assembly makes it easier to use but doesn't fix nasty issues with lack of memory boundaries.

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.

Well I'm definitely not a git expert ( i guess I should just invest more time into it). But was wondering the other day. Isn't GIT "as good" as its(source control) going to get ? Giving the problem its trying to solve:source control,distributed teams/repo's, branching etc... I mean what comes after GIT ?

There are some projects that aim to improve the merging model of Git, such as pijul[1]. Git uses "three-way merge" and it is fairly well-known that the repository state you end up with for non-fast-forward merges (merges that need merge commits) is not necessarily well-understood in all cases. Pijul uses a more efficient algorithm that has well-understood merge characteristics, and is designed around patches not repository states (which means that conceptually patches are the core -- rather than in Git where patches appear to be core but are actually all generated on-the-fly).

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/

git was easier to use :) - thanks will check it out

I took a quick look at the list of commands and they looked so similar to the primary git commands I use that it seemed like a waste. Better to just learn how to use git.