Hacker News Reader

Comment by capableweb | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com