Dangit, Git? | Hacker News Reader

Dangit, Git?

dangitgit.com

85 pointstodsacerdoti75 comments

Hi there! I am the person who made ohshitgit.com as well as dangitgit.com!

I resisted having a swear-free version for a long time! but, I heard from many folks that the swear-y url was blocked by their networks at work or school, and they wanted to be able to view & share the content too. I had also heard from a high school comp sci teacher that they wanted to share the OSG tips & knowledge with their students, but couldn’t because of the swears.

So, I decided to create the swear-free version to be more inclusive and allow more people to access the help they needed to get out of their git messes.

Cheers, Katie

Thanks for creating this new version—and thanks so much for creating OSG in the first place! I’ve been using it as an educational resource since I found out about it.

Both versions are useful. One makes me happier than the other. Yes, it's the other one.

But now you have options, whenever you don't wanna be quite so happy. Nice.

Thanks, will be much more comfortable passing this one to my juniors!

Good job. Git reflog in particular will save many a developer their lost work

Hi there! In English, we would normally say "many developers." Hope that helps!!

Both are valid. https://www.britannica.com/dictionary/eb/qa/the-difference-b...

I'm sorry, but now it's too American...

That’s great! Thanks for creating a second version!

I like this one: https://news.ycombinator.com/item?id=31874308 ( https://ohshitgit.com/ ) better... Great stuff!

BUT hopefully the author is reading this: PLEASE PLEASE remove the part about `sudo rm -r fucking-git-repo-dir` or at least if it's satire tell people not to really do this. It should be:

    cd ..
    tar -cvzf fucking-git-repo.tar.gz fucking-git-repo-dir
    echo "Please for the love of god help me I've fucked up and <describe problem>" | mail -s "NEED HEPL! git disaster" git-expert@xyzcompany.com -A fucking-git-repo.tar.gz
    git clone https://some.github.url/fucking-git-repo-dir.git fucking-git-repo-dir2
    cd fucking-git-repo-dir2

As long as you don't delete or muck with the `.git/` folder or files that aren't not be checked in, you have pretty fair odds that the mess can be untangled by someone either more knowledgeable about git or less pissed off.

> But seriously though, on what planet does checkout -- make sense as the best way to undo a file?

In recent versions of git you can use git restore, which besides having a better name and not being overloaded with other checkout functionality, has a better interface IMO.

> Git is hard: messing up is easy, and figuring out how to fix your mistakes is impossible.

Hyperbolic.

Fixing mistakes is easy if you understand the underlying data structure. Once you can conceptual map the structure into the intended form, you figure out what operations (verbs) you need. Then it’s a matter of mapping the operations into concrete command lines.

"Rocket science is easy once you understand the underlying principles of rocket science"

It amazes me the amount of engineers who can use a tool every day yet remain not the least bit curious to its basic internal operation.

Perhaps it is that they actually are curious, but the amount of knowledge to be had is quite substantial.

I don't think that's the case with git though? It's fairly simple actually. The biggest (only?) challenge is to not view it as a tool to do versioning of your code, but rather a tool to work on data structures that effectively do versioning of your code. It seemed fairly straight-forward to me once I did that mental shift.

Everyone says that, but I don’t find it to be true. For context, we run a Gitea fork at work, and I often have to read the source code inherited from upstream Gitea.

There are a ton of things that can happen during a merge, for example. Does anyone know what a smudge filter actually is? Why are there branches, and also tracking branches? There are refs, heads, objects, and blobs, and not all of those have the same operations (list, show) defined on them. There are changesets but also snapshots. Why do some commands have a --porcelain flag and others don’t? Did you know Git has garbage collection? You can’t rename a file in Git. What’s the difference between branches and tags? These are all things that are really discovered only through relentless trial and error.

I never dug into git tooling, I'm a mere git user - yet I knew most (not all) of these. Some of those actually make intuitive sense. And some of those don't really matter in regular usage, since it's not the actual on-disk data structure you need to be concerned about when working with git, but only parts of it that actually create the useful abstraction.

Everyone seems to be learning git by staging and committing some code, then making pushes and pulls, with all the rest added on top of that. Basically, learning the UI first and only then figuring out what that UI actually does. I'd rather advice to start by learning what refs are and how commits actually look like on a imagined repository graph, since that (along with the working tree) is what you're actually manipulating most of the time - all the rest flows quite naturally from that. Merges and rebases are quite simple from that point of view, and the way heads, branches and tags work make perfect sense then. Objects and blobs can mostly be perceived as implementation details, but once you realize that there are no actual changesets in git at all, they quickly stop being obscure as well (and then the fact there's no such thing as file rename becomes obvious too). And when it comes to garbage collection, git lets you know that by itself on a big enough repo ;)

When you start learning the UI already equipped with that knowledge, it simply makes much more sense.

Git's biggest sin is not having a clear separation between the abstraction it presents to the user and what's essentially its internal implementation. It's like an UI made for people who not only work with git, but also on git. The result is poor UX, which is why you need to learn what git does first before learning its UI. But poor UX doesn't mean it's rocket science - it only means that you'll have a better time learning from an external resource.

Clean and smudge filters seem interesting, I wasn't aware of them, thanks for mentioning that!

> You can’t rename a file in Git.

  $ git-mv <old_name> <new_name>

That will produce an add plus a deletion. Whether or not this is considered a rename is up to git-diff, via the -M flag which specifies a “similarity index”. Side note, this doesn’t work with LFS-tracked files. But, with regular files you can say, e.g. you want the similarity index to be 50%, and then any files that were deleted that match 50% of their contents with another add will be displayed as a rename. So it’s really just a view thing. In the underlying storage, there is no such thing as a rename.

See? That's what I was talking about. Learning the UI before learning what it actually does :)

This only leads to confusion once you use 'git mv' and edit the file significantly enough in the same commit. "Why doesn't git show that it's a rename? I explicitly told it so! Did I do something wrong?"

The problem is, very few Git learning resources start off by introducing what refs are, objects, etc. and those that do are usually wrong in some way. There are really not enough learning resources to learn Git this way.

your heart is in the right place but for many engineers there are ~20 tools that we use daily and we pick tools in most cases specifically based on "do they work" and "do I need PhD to get them to work" if I need to know how the tool works that that tool has already failed miserably!

Are you amazed that the people who use the software you build use it without understanding the underlying data model? Probably not, because you understand that the reason you make software for them is so they can use it, instead of manually doing all the underlying steps your program does for them.

Just because a tool is intended for engineers doesn’t mean it isn’t “hard” if it requires way more learning than any other tool in that engineer’s tool chain. Git is hard, even if you happen to have mastered it by now.

> It amazes me the amount of engineers who can use a tool every day yet remain not the least bit curious to its basic internal operation.

And how many of them use word processors and/or spreadsheets and don't bother learning about the internal structures of file formats?

* https://en.wikipedia.org/wiki/Microsoft_Office_XML_formats

Have you ever examined the bitstream of gzip or the structure of tar, even if you downloaded source file in them? Do you know the structure of RPM and/or Deb packages (depending on your favourite distro)? Do you know the voltage pattern of the Ethernet signals that go down the cable (or waveform of the Wifi / LTE radio signal)?

There are only so many hours in the day, and not everyone wants to (or has the time) to go deep into every rabbit hole.

Consider that there’s a simple heuristic to prioritize where you drill down. That heuristic is pain.

One of my current projects at $DAYJOB is teaching literal rocket scientists how to use git effectively.

This deserves its own hackernews thread :)

So that’s exactly my problem and I’ve yet to come across a guide that explains the underlying concept well. Any recommendations? I often feel like I’m uttering spells without understanding it when I use git. I hate working like that. Thanks in advance!

I've recommended it here previously, and I'll do it again, because it's so fantastic: Missing Semester's lecture on Git https://www.youtube.com/watch?v=2sjqTHE0zok

The Git book does a perfectly good job of this: https://git-scm.com/book/en/v2

I always recommended reading chapters 1-3 and skimming chapter 7 to people who are just getting started with Git.

Git for ages 4 and up. https://www.youtube.com/watch?v=1ffBJ4sVUb4

I asked myself what goes inside a commit, how git structures [e.g. connects different commits] together, why can't I tamper a commit, why are git histories tamper proof; I asked questions about what happens to the structures when I performed daily operations [fetch, merge, checkout, push -f etc.]. When I wasn't understanding merge conflicts I taught myself what git tries to do and contemplated over why you need three-way merge [e.g. instead of two way].

Some of this I was able to figure out about thinking through the problem, considering alternatives and some had to be done through reading.

My approach to learning is not so much "bottom up" [e.g. I can't just read a book from chapter 1, or some website that claims to explain everything].

Have a ready toolkit of general-purpose state-dumping "spells" ready at hand, to apply as soon as your tree starts to misbehave. Starter set:

  $ git-status
  $ git-log --graph --oneline --all [--reflog]
  $ git-branch -avv
  $ git-config --list

> Once you can conceptual map the structure into the intended form

This is the problem. A tool that hides its internal structure but requires you to rebuild it in your head is poorly designed, full stop. The reason git is difficult to deal with is that it is a low level abstraction over the underlying data structure, but simultaneously hides that complexity until suddenly you need to be aware of all of it.

> Fixing mistakes is easy if you understand the underlying data structure. Once you can conceptual map the structure into the intended form, you figure out what operations (verbs) you need.

Cue the old joke:

> git gets easier once you get the basic idea that branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space.

* https://twitter.com/agnoster/status/44636629423497217

Previous discussion: https://news.ycombinator.com/item?id=31874308

I remember the day I discovered `git reflog.` Truly a lifesaver for a rebase heavy workflow.

> Only amend commits that only exist in your local copy or you're gonna have a bad time.

Would you consider linking more information or adding an explanation of "a bad time"? I think it's really confusing for newcomers to understand the implications of "public commits", or even what "public" means.

The essential question is whether any collaborator might have already based their own work on a commit you've made available to them earlier, by a 'git push'. If so, your pushed work cannot be modified (carrying a new hash) without invalidating theirs (depending upon old hash).

Sites like this are great but make me wonder if I'm the only one who prefers using high level ide menu options instead.

The problem with high level IDE menus is that they are a leaky abstraction. And when something goes wrong at a lower level you are stuck only knowing how the abstraction works and need to figure out the how the actual tool works at the point of maximum stress, in situation complicated by something already having gone wrong.

This seems like a good place to mention that I had a co-worker who thought that git only allows 50-character commit messages. Why? Because the IDE was programmed to guide the user to the 50/72 rule[1] and would put up a warning when the first line went over 50 characters. It never occurred to my co-worker that he could simply hit the return key and create a multi-line commit message.

So not only are they leaky abstractions, when they do hide abstractions they can conceal important information.

1. https://tbaggery.com/2008/04/19/a-note-about-git-commit-mess...

“Git is hard: messing up is easy, and figuring out how to fix your mistakes is impossible.”

No, no and no. If you do know what you do, then you don’t. There are tons of explanation on git, just RTFM.

lets bowdlerize everything!

oh wait fuck that let’s not.

I find adults who are uncomfortable around profanity extremely unsettling. Emotions can be extreme (like destroying hours of work because of a git mess-up) language should be able to reflect that.

Obviously there are degrees to this. If an coworker started throwing around profanity and yelling because they got uncomfortable in a meeting, I'd question their professionalism.

Yeah but something like "this shit is fucking hard" wouldn't cross any lines with any reasonable audience.

Probably not, but there's certainly some situations involving coworkers where I'd hesitate to say that, depending on the audience.

I personally would rather not hear that. But you are free to be you.

the more we use extreme words, the less they mean. Overuse devalues the expressed emotions and then we have to create even more extreme words to describe the same emotion as few years/decades ago. I'm okay using swear words, but I'm using them less and less the older I get. Also, I respect less and less people who are enable to express complex ideas or feelings with precise words and reduce them to "shit" and "fuck". In such situations, swear words are doing more to conceal rather than express and it is really hard to relate to what the other person is saying.

How you handle profanity should literary be a measure of maturity.

I don't usually like to work with people that are too nice. Its a marker of dishonesty.

"dangit" is double entendre, for fuck's sake. And now it's a good mnemonic for remembering this reference sheet.

Haha YES thank you for noticing! I feel like I don’t get enough credit for finding a cleaver as fuck swear-free url

I understand. That site is a valuable resource, though, and I’d hate it if people don’t open it because of the swear words. This is technical documentation and online tutorials, not stand-up comedy. (Although I’d love it if Jon LaJoie wrote a song on git.)

You are uncomfortable with people who are uncomfortable with profanity?

The technical term is "metafragility".

Profanity is simply unnecessary in all but an extreme minority of cases. I judge the people who use profanity liberally to be simply unregulated as to how they dish out their emotions. Either that, or they don’t spend enough time around kids. In the remote environment, you never know who will hear what you say.

It's not a self regulation issue if they just don't consider profanity a big deal. Maybe a lack of creativity in vocabulary but that's a different issue.

Profanity is kind of a big deal by definition though. What else makes a word profane other than the fact that it’s a bigger deal to say it than the other words?

I agree that it's not strictly necessary. I've read a book that didn't use the word "is", and the book Gadsby is written without using the letter "e".

So it not being necessary is not evidence that part of a language shouldn't be used, or that it isn't easier to communicate with that part of language.

Sometimes curse words help express emotions.

Fuck 'em.

Swearing too much comes across as trying to seem cool or tough, and it usually has the opposite effect.

In most environments I encounter, swearing doesn't come across at all, because it's a a natural part of vocabulary that doesn't stand out other than to emphasize frustration occasionally (or also, excitement; what I'm saying is that it's really fucking useful).

If someone where to become annoyed or freaked out because I used the word fuck, or shit in conversation (not in the context of insulting another person; that's a whole different discussion), I would find it very uncomfortable to be around them because I'd be second-guessing my vocabulary constantly. I can be eloquent if I want, but sometimes a "fuck" is justified.

If they are swearing regularly then they either are having trouble regulating their emotions, or may not have a verbal alternative to release before a physical escalation.

Both are perfectly reasonable to feel uncomfortable around.

Is this the SFW version with no profanity in the URL? I actually applaud that idea—I felt a bit uncomfortable with the former URL.

ohshitgit has a little banner at the top: "Hi there! You can get this same content without swears at dangitgit.com"

I think it's a normal reaction actually.

I feel a bit of the same thing and my idea is that it might be related to an uncomfortable feeling of not being sure about the nuance or value of a word. 'Shit' is a known word in terms of meaning but what value it carries in any given context is a bit fuzzy, it can be received very differently.

Just avoid rebase and --amend and you will be fine.

Your commit log won't be perfect, but also you won't waste your time fixing conflicts and other issues...

You're just delaying the conflict resolution to when you actually want to merge the branch back in...

You're delaying it to a one-time pain rather than for every commit in your rebase. I've stopped rebasing altogether and it's much more manageable.

Problem is there are open source projects where PRs with multiple commits are not allowed. Not much choice but to rebase in that case. I struggled with it a lot at first but haven't had any issues more recently. But personally I'd rather not use it, and don't on other repos I work on. Btw I'd say if you've never had issues with git it's because you've never been forced to do a shallow clone (due to networking issues) or run out of disk space while using it. Had to blow away and reclone repos many times in both cases, but only after hours struggling with cryptic and unpredictable error messages.

That's really interesting, if PR's aren't allowed to have multiple commits then why not just enforce squash-and-merge for all PR's? Then it doesn't matter what you do on your local branch, because when the PR is merged it's squashed into a single commit.

Exactly what I argued, but it wasn't my call to make...

Reply on news.ycombinator.com