Hacker News Reader

Comment by pdimitar | Hacker News Reader

I'm very happy to fundamentally misunderstand GIT's internals because I want to do a finite (and small) set of operations with it, not HOW it operates under the covers.

Conflating the two, like you do, is elitism.

"If you just stopped and read to understand...", a-ha, sure, I'll do that for every one of the no less than 500 tools I've used over the course of my career and will never get anything done on time.

There's no time. We got real work to do and no we can't switch to a company that gives us this time. There's a big world outside the Silicon Valley.

GIT is a huge UX failure and seeing people pretend otherwise makes me question my -- or their -- sanity.

View on HN

You won't have to put your entire life on break in order to understand the fundamentals of git and why it works the way it works. Going through https://jwiegley.github.io/git-from-the-bottom-up/ and really understanding the material will take you a couple of hours at max, but will save you a lot of time in the future.

Wanting to understand things before using them is hardly elitism, not sure why you would think that.

Just like you probably don't want to fix bugs without understand the cause, it's hard to use a tool correctly unless you know how the tool works.

Git is one (egregious) example though; Do I need to understand the fundamentals of every tool that I use/interact with every day? That's just not feasible. If not, where do you draw the line? To many, git is a means to an end, in the same way that $(insert_internal_tool_here) is. Nobody expects you to know the details of a B-tree and an R-tree to use MySql, so why is it ok to expect people understand the implementation details of git to use centralized version control?

Except not knowing about btrees for MySQL will likely mean you don't understand how to write good indices.

I like your analogy because it outlines the flaw of GIT: we have to "fix bugs" in its UX so we can get our job done with it. :\

Also yeah, I agree learning GIT is not a huge sacrifice but with time I built a huge internal resistance against it so... dunno. ¯\_(ツ)_/¯

Maybe I'll get to it one day, in the meantime I am OK relearning cherry-pick and a few others every time I need them. I don't know, it just doesn't make sense to me. Guess to this day I don't see why it had to be a graph DB.

This article contains some very dangerous advice. In particular it says that the difference between reset--hard and checkout is merely down to the working tree changes not being preserved. What it does not mention is that reset will obliterate commit history subsequent to the requested revision 5f1bc85.

From the source:

Here’s me being straight up loco and resetting the head of my working tree to a particular commit:

  $ git reset --hard 5f1bc85

The –hard option says to erase all changes currently in my working tree, whether they’ve been registered for a checkin or not (more will be said about this command later). A safer way to do the same thing is by using checkout:

  $ git checkout 5f1bc85

The difference here is that changed files in my working tree are preserved.

> reset will obliterate commit history subsequent to the requested revision 5f1bc85.

It's not obliterated. It is still in the reflog, and in the history of any other branches or tags then have those commits in their history.

You have to try quite hard or wait 2 months to obliterate something that was committed or stashed into a repo.

You can even recover changes that were only staged.

Compare this to most other programs (word processors, GIMP, etc) which will happily genuinely obliterate if you undo multiple times and then do anything other than immediately redo.

This language is, IMO, damaging to the professionalism and image of software engineering. IIRC, I am echoing content from "Clean Coder", but in "professional" careers, it is expected that the practitioner is competent and stays up-to-date on the latest tools and techniques in their field.

When I see a doctor, I expect them to be familiar with the latest medical research. I expect they will treat my illnesses with modern medicines and employ the right tools, correctly, and understand how they work at a sufficient level of depth to do the job correctly. For example, I used to make electrical medical staplers; surgeons need not care about how RTOSes work, but they need to know how to interact with the software enough to do their job. Similarly, I'm not saying we all ought to be able to build Git from scratch. I'm saying we ought to master it to the extent necessary. If your use case is committing alone on a single branch, learn "git commit". But for most devs, understanding the tree structure that Git uses to store data and what basic operations are doing "under the covers" builds a mental model that makes Git easy.

We have to have the time to learn the tools that help us do our jobs well. You can neglect that duty to do "real work", as much as a doctor can neglect learning how to use a scalpel so they can "get on with the surgery".

> it is expected that the practitioner is competent and stays up-to-date on the latest tools and techniques in their field.

Even when the tools themselves suck?

The thing about our profession is that anyone can build better tools. Just like Linus took a week or two to sketch Git with some C code and a bunch of shell scripts (seriously, that was what happened - but he had the BitKeeper design in mind and how to improve on it). There is not regulation that says that in order to build a tool for millions of people to use you need to have a certification or anything.

Actually, I believe a deliberate goal was to write something distinctly different from how BitKeeper operated.

Yes, but without being informed by the BitKeeper's design and shortcomings he would never design Git so quickly

We all know the ideal theory, man.

Citing it as if it's something that's even needed to be said is kind of ironic on a forum with mostly programmers in it who, I am pretty sure, by and large possess a fair amount of critical thinking and quick analysis skills.

A ton of people have to make do with partial schedules. And I mean a ton, likely no less than 85% of all programmers everywhere.

You might want to make a good deep analysis on whether you're not coming from a position of severe privilege and a very positive filter bubble.

I agree with you, but I also have the thought of "well, git is one of the _top_ tools of the 500 I use," so I think I'm a bit more inclined to fill in a few more gaps as I encounter them. Ultimately though if you have the right balance of knowledge about the tool, you can always stop learning more about it until you learn otherwise…

Also true, and I agree. As mentioned in a sibling comment, with time I kind of started loathing the idea of learning GIT's internals so here we are. We'll see, these things tend to fall away with time.

Reply on news.ycombinator.com