Hacker News Reader

Comment by rootlocus | Hacker News Reader

> Learn just enough git to create a repo, create branches, push and merge, and all that. Anything more complex? Google it when you need to like the rest of us.

Bad advice. Learning git internals is surprisingly easy and has a lot of ROI. This tiny book has everything you need https://github.com/pluralsight/git-internals-pdf

View on HN

What's the ROI? I tend to agree with the author on this subject here. In my case I care for just enough git to get by so I can focus on the projects I'm using git to facilitate.

Learning "recipes" on the internet and copy pasting commands is a sure way to mess something up and could bring a lot of frustration. You only need to spend a few hours to understand how git works underneath to avoid any of that.

You should not have to learn the internals of any decent source control system to use it in a way that does not lead to a mess. An overview of usage principles and examples should be enough and should provide enough insight to search for more information if needed.

User level documentation should be sufficient for user actions. If someone wants to learn internals, great; but this should be an option, not a requirement.

Lots of "should"s, but we're talking about advice on using git, not "any decent source control system". This is a problem I see with people not understanding git. They treat it like they think it should be treated. Like it or not, that's not going to work for git.

You don't give python advice to a C++ developer, regardless of how much you'd like C++ to be like python.

This logic also works on computers. Or, well, anything. You'd be surprised at just how useful people can find things while still making a mess of them.

So, yes, if you have the time, learn the internals. But no, that is not in any way a prerequisite. Nor should it be.

> You'd be surprised at just how useful people can find things while still making a mess of them.

You mean like this? http://www.thisiscolossal.com/2017/12/tatsuo-horiuchi-excel-...

I wouldn't have thought of that, but yes. :)

Most of my inspiration nowadays comes from my kids.

It's very easy to end up with messy/unusable history or even lose work when you have multiple people working on related parts of a project with outdated branches and limited git knowledge.

I have been bitten by coworkers submitting preposterous pull requests because of a lack of understanding of what you can do with git and how it works that could have been avoided by taking the time to really grok git.

For years I took your position, particularly since previous VCSen such as Subversion “just worked” and generally faded into the background. However after recently taking the time to learn Git internals, and after pulling out much hair as the guy tasked with figuring out wtf Git had done with the project’s history, or why it was necessary to clone a new tree and manually copy edits over from a seemingly totally broken original tree, I now see that you just can’t use Git without a deep understanding of what it is up to and why. Not that I agree this is the right state to be in as an industry: revision control can be, and was, an almost invisible useful service, but Git just isn’t that.

Just use fossil.

Reply on news.ycombinator.com