Using rebase and reflog really taught me a lot about git, because it "rewrites" history and exposes you to some nuance. Like: basically nothing in git is ever gone if it was at one point committed to the repository, that includes branches you delete and never pushed, it also includes commits that are removed with git reset --hard. Once I learned about how to find references, refer to them, and manipulate them, everything else made a lot more sense.
Ask HN: What made you finally grok Git?
81–90 of 94 posts
Re: Ask HN: What made you finally grok Git?
#82Implementing it. Once I read somewhere it is just a key - object, append only, DB then it seemed easy to implement the core of it, so I did. It's simpler that it sounds.
Re: Ask HN: What made you finally grok Git?
#83Re: Ask HN: What made you finally grok Git?
#84Teaching Git to others (e.g. company-internal workshops). You learn so much from teaching, and also from questions others ask, helping you discover your unknown knows and unknown unknowns.
Re: Ask HN: What made you finally grok Git?
#85Maybe the one thing that made it click for me was realizing that a branch is merely a label to a git commit hash. There can be local and remote ones and the local is aware of the remote (e.g. git pull). Checking out a branch makes it current, with filesystem matching the branch head's git fileset state. New commits get added and the branch label moved to the new head.
That and a git tree view GUI or "git log --oneline --graph" and "git reflog" to undo stuff. Also, you're better off committing temp stuff on the current local branch with message "WIP" than using "git stash".
Re: Ask HN: What made you finally grok Git?
#86Maybe the one thing that made it click for me was realizing that a branch is merely a label to a git commit hash. There can be local and remote ones and the local is aware of the remote (e.g. git pull). Checking out a branch makes it current, with filesystem matching the branch head's git fileset state. New commits get added and the branch label moved to the new head. That and a git tree view GUI or "git log --onelin…
How I really learned git well though was looking in the .git/ directory. "ls .git/refs/heads" shows a bunch of files with names of local branches.
And "cat .git/refs/heads/my-local-branch" shows a git commit hash. You can learn a lot about git this way, and it's first-hand knowledge that's easier to recall than reading about it somewhere.
Re: Ask HN: What made you finally grok Git?
#87Earlier quoted context omitted.
Kinda. I wouldn't be able to tell you too much about the internals of VSCode. The 'trouble' with git is, though, that what happens when you run the wrong command can vary from "easy to fix" all the way to "you just lost your work, you shouldn't have run that command". Which means you need to either be very careful anytime you run git, or you need to learn more about git to avoid the footgun aspects of it.
It's kinda sad though because off the top of my head i suspect it's really difficult to actually lose your work. Ie between the fact that the content store stores.. well, all content, until it's GC'd, and the obvious reflog, you can almost always get back your data. The downside to this though is the type of novice most likely to make a mistake in "losing" their data will also not know how to recover their data.
> it's really difficult to actually lose your work
If it's been checked into a commit, sure.
But if you discard changes which haven't been checked in, then the work is lost.
Re: Ask HN: What made you finally grok Git?
#88Git from the bottom up. A very clear and simple guide to the internals. https://jwiegley.github.io/git-from-the-bottom-up/
Same for me.
I avoided getting into Git for years (long ago when it was new, before GitHub) and found the man pages unhelpful.
Git From The Bottom Up totally turned it around for me.
Ever since then I've been comfortable using Git in all sorts of advanced ways, such as constructing repos from old software backups, editing decades of history to separate out publishable parts from proprietary or inappropriate parts while keeping the history, fixing broken repo issues, as well as regular daily use the way most people use it.
Re: Ask HN: What made you finally grok Git?
#89Earlier quoted context omitted.
I just ran into this problem last night... if you shouldn't rebase after pushing to remote, how do you update a PR days after you originally created it to be on top of the latest origin/master and be able to resolve merge conflicts locally?
You can merge with master instead of rebasing, the downside is you'll end up with a lot of merge commits in a long living branch. I just rebase and force push. I really don't get all the people that say avoid doing that. If you're the only one working on that branch, there's no risk. If you're working with other people on the branch, and no one has unpushed changes, it's also fine. Everyone will just need to reset to…
> If people do have unpushed changes and you force push, then they need to spend some time untangling it.
This is where `git pull --rebase` could save you all some time. You can even modify your git configs if this happens enough.
Re: Ask HN: What made you finally grok Git?
#90The Git Parable (https://tom.preston-werner.com/2009/05/19/the-git-parable.ht...) cliched it for me.