Live data from Hacker News

Oh shit, git (2016)

ohshitgit.com

11–20 of 280 posts

Re: Oh shit, git (2016)

#11
post #5

Git is not hard. It's very simple. But people learn it the wrong way. You have to learn it from the DAG up. If you cannot grasp how the DAG works you'll forever be reading and writing articles like this one which do not help you to learn. This is a horrible article. You should not bookmark it or use it. If you're not a programmer, you shouldn't use git. If you are a programmer, do yourself a favour and spend a day go…

Don't gatekeep. Git isn't just for programmers.. it's for people that are learning.. people using it in non programming capacities and tons more. Telling people to "git gud" is not helpful. Not everyone knows, or indeed cares to know what a Directed Acyclic Graph is, and sites like this help people's anxiety who are just learning, or who have already screwed up and just want a solution.

Re: Oh shit, git (2016)

#12
post #5

Git is not hard. It's very simple. But people learn it the wrong way. You have to learn it from the DAG up. If you cannot grasp how the DAG works you'll forever be reading and writing articles like this one which do not help you to learn. This is a horrible article. You should not bookmark it or use it. If you're not a programmer, you shouldn't use git. If you are a programmer, do yourself a favour and spend a day go…

What's a DAG?

Directed Acyclic Graph.

Graph = graph, a structure composed of a set of objects (nodes or vertices) with links between them (edges).

Directed = the edges have an orientation / a direction.

Acyclic = there's no cycle, you can't come back to a node (in a directed graph you have to follow edge direction).

In Git, the commit objects are nodes, the "parent" link(s) is a directed edge, and because commit objects are immutable you can't create a commit which refers to one of its "descendants" and thus the graph is acyclic.

Re: Oh shit, git (2016)

#13
post #5

Git is not hard. It's very simple. But people learn it the wrong way. You have to learn it from the DAG up. If you cannot grasp how the DAG works you'll forever be reading and writing articles like this one which do not help you to learn. This is a horrible article. You should not bookmark it or use it. If you're not a programmer, you shouldn't use git. If you are a programmer, do yourself a favour and spend a day go…

I think you are right about the DAG. Once I understood what the high-level data structure of git is, many branch related commands immediately made sense and it was suddenly very easy to use. Many of my colleagues haven't taken the time to learn that and continuously struggle with basic commands.

Re: Oh shit, git (2016)

#14
post #5

Git is not hard. It's very simple. But people learn it the wrong way. You have to learn it from the DAG up. If you cannot grasp how the DAG works you'll forever be reading and writing articles like this one which do not help you to learn. This is a horrible article. You should not bookmark it or use it. If you're not a programmer, you shouldn't use git. If you are a programmer, do yourself a favour and spend a day go…

I agree that the DAG and Git storage model are at least not particularly complicated. The problem is that the Git user interface (the CLI, plus various concepts that are used in other interfaces as well, like refspecs, that are not fundamental to Git) is not very simple, and the correspondence between the DAG and mutations you may wish to perform, and Git commands, is often fairly obtuse and opaque.

Re: Oh shit, git (2016)

#15
post #5

Git is not hard. It's very simple. But people learn it the wrong way. You have to learn it from the DAG up. If you cannot grasp how the DAG works you'll forever be reading and writing articles like this one which do not help you to learn. This is a horrible article. You should not bookmark it or use it. If you're not a programmer, you shouldn't use git. If you are a programmer, do yourself a favour and spend a day go…

I care about the internals of git about as much as I care about the internals of my filesystem.

It's probably helpful to know some basics, but do I need to know intimate details of my filesystem to use cp, mv, shell redirection? No. For most basic actions it Just Works™.

The problems in git are purely user-interface based. Other distributed systems have proven you can make a dcvs with a reasonably friendly UI.

Re: Oh shit, git (2016)

#17
post #5

Git is not hard. It's very simple. But people learn it the wrong way. You have to learn it from the DAG up. If you cannot grasp how the DAG works you'll forever be reading and writing articles like this one which do not help you to learn. This is a horrible article. You should not bookmark it or use it. If you're not a programmer, you shouldn't use git. If you are a programmer, do yourself a favour and spend a day go…

Write yourself a git is a wonderful site to read through, even if you don't end up doing the implementation. It really helped my git usage!

But git isn't just for programmers, and cheat sheets can be good for people who just want to dip their toes in.

Re: Oh shit, git (2016)

#18
Honest to god, I don't know how people who find `git` hard to use manage to write code. Everyone on the Internet acts like the concepts are impossible to grasp and it's like really easy to grok.

Honestly, it faded into the background of code from the beginning. I mean, I know "Forward-port local commits to the updated upstream head" means nothing to anyone not already familiar with `git rebase` but a practical mastery of the tool is very easy to achieve.

I honestly think this is a pedagogical lack. We tell everyone it's this complex thing and that they should be scared of rebase and the reflog and they believe it. Maybe if we didn't, it'd be easier.

Re: Oh shit, git (2016)

#19
post #6

> I committed and immediately realized I need to make one small change! I think it might be nice to add a disclaimer saying that this is not advisable if you've already pushed the code. Suck it up and make a new commit–don't rewrite public Git history.

I find it okay to rewrite public history in short lived feature branches. It’s typically your branch after all. So it would change your advice to: Don’t rewrite public Git history unless you can assume it’s read only. Patches for Linux get rewritten all the time till they are finally merged.

That's not public git history though, those are just patches on mailing lists. Even before it goes into maintainer's lists, in my experience it's extremely rare that a maintainer will force push to their own public -next branch.

Re: Oh shit, git (2016)

#20
Reading this article, I realize that I'm old now. I still remember wrestling with cvs, svn. Merge, branch were slow and even more challenging. It was much easier to mess up and so difficult to rewind.

When I first learned git, I thought it's pretty neat. It solves merge, branch, rewind problems. Git is one of the things in life that doesn't work like the way we think. But it turns out to be a better way.

Post reply on HN