Hacker News Reader

> pointers to commits

Or to use the name git gives to that concept, "refs." Thus reflog :)

Also, one thing that I've found hasn't occurred to most people using git, is that all the branch/tag/etc refs of your fetched remotes, are also refs, able to be referenced anywhere you can name a ref.

For example, if you ever want to say "I don't care what's on this branch, don't fast-forward or merge or rebase, just overwrite my local branch with what's on the remote!" then that'd be:

    git checkout foo
    git reset --hard origin/foo

Ah yes, the fact that git brings the remote stuff locally when you `git pull` and all the `origin/<whatever>` are just branch names is something that I realised only too late.

As for the refs, yes, good point ;)

When you do 'git fetch'. The 'pull' is just an alias for fetch + merge (or rebase, depending on local settings).

> Or to use the name git gives to that concept, "refs." Thus reflog :)

A command name that I read as re-flog for the longest time :D. I really wondered about the strange, strange name for quite a while before I bothered to look up what it does and found out that I should read it as ref-log and that it is, indeed, a very useful thing.

The humans will be flogged and reflogged until they understand the distributed version control

I had the same experience for the longest time until one day I'd have to "re-flog" my local git because I reset some commits that I shouldn't have. Turns out that flogging isn't a real thing in git let alone re-flogging the commits again.

Wow I've been using git for years and for some reason that never clicked for me. Thanks for pointing that out.

Also being a de-refr probably helps.

> HEAD is pointing to the commit you're currently looking at

HEAD pointer is pointing to the branch pointer (e.g. my-branch) which is pointing to the commit. (Except in a detached HEAD state.)

> Every time that you make a commit on `my-branch`, then both the `HEAD` and `my-branch` move to point to the new commit.

HEAD pointer keeps pointing at the my-branch pointer, and only the my-branch pointer moves to point to the new commit. But of course, when you now follow HEAD to my-branch to the commit, now you end up to the new commit.

> "detached HEAD" means that the the `HEAD` (the commit you're looking at) is not pointed at by a branch.

"Detached HEAD" means that HEAD is pointing directly to a commit, instead of pointing to a branch pointer.

You can have a detached head state, where both HEAD and the branch pointer point to the latest commit. If you use `git log --decorate`, for the latest commit it will show (HEAD, my-branch) instead of the normal (HEAD -> my-branch).

> "Detached HEAD" means that HEAD is pointing directly to a commit, instead of pointing to a branch pointer.

Ah, thanks for pointing it out, always good to learn the finer distinctions

> HEAD pointer is pointing to the branch pointer (e.g. my-branch) which is pointing to the commit. (Except in a detached HEAD state.)

Yes! Here[1] is a nice picture about from Git Reset Demystified article. You can also see is in the following `git branch -a` output,

    * main
      remotes/origin/HEAD -> origin/main
      remotes/origin/main

[1] https://git-scm.com/book/en/v2/Git-Tools-Reset-Demystified

I love this explanation. One unfortunately confusing extra piece that some people might occasionally run into is that there are two types of tag. Most tags are what you describe: pointers (git ref) to a commit (git object) and nothing more. These are usually referred to as lightweight tags.

There are also annotated tags that can contain a message, have a timestamp, and sha, etc. These are proper git objects that behave a lot like commit objects, except they're still typically only referring to another git object (commit).

I thought I understood tags...

But now what's a "proper git object"? Is there an improper git object? Is there a proper git non-object?

"proper git object" = anything that has its own unique hash.

Underneath the SCM plumbing, the "true core" of git is a content-addressable object store. (See https://git-scm.com/book/en/v2/Git-Internals-Git-Objects)

When you `git fetch`, git is asking the remote to walk a tree of objects — starting at the commit object that the ref points to — and deliver them to you, to unpack into your own object store.

Git could in theory do a lot with just objects — with the whole "data state" of the repo (config, reflog, etc) just being objects, and then one toplevel journal file to track the hash of the newest versions of these state objects. (Sort of like how many DBMSes keep much of the config inside the database.)

But git mostly isn't designed to do this. Instead, git's higher SCM layers manage their state directly, outside of the object store, as files in well-known locations under .git/. This means that this higher-level state isn't part of the object-store synchronization step, and there must instead be a domain-specific synchronization step for each kind of SCM state metadata where applicable.

Tags are an interesting exception, though, in that while the default "lightweight" tags are "high-level SCM metadata" of the kind that isn't held in the object store; "annotated" tags become objects held in the object store.

(To be honest, I'm not sure what the benefit is of having "lightweight" tags that live outside the object store. To me, it looks like tags could just always be objects, and "lightweight" vs "annotated" should just determine the required fields of the data in the object. Maybe it's a legacy thing? Maybe third-party tooling parses lightweight tags out of the .git/ directory directly, and can't "see" annotated tags?)

Lightweight tags are simply references to commits that lie in refs/tags instead of refs/heads. Annotated tags are references to tag objects rather than commit objects. In both cases, the purpose of the reference is to give the object (tag or commit) a name.

I think no one uses lightweight tags anymore, except if you push by mistake a commit to refs/tags/something.

> Last but not least, when everything goes wrong, the single command that can take you out of any weird situation is `git reflog` which shows you all the commits that HEAD has pointed to.

And if you're feeling extra-paranoid like me, a `git rev-parse HEAD` and copying that string down somewhere safe before embarking on a tricky process with lots of merge-conflicts or other shuffling.

It's nice to have confidence that I've accurately identified which state is the last-known-good one--not one a few steps too far into the chaos-zone--and that I can usually get back to if everything goes to hell. (Barring unwise use of stuff like `git gc` or `git filter-branch`.)

Or putting a temporary tag on the current HEAD, so there's something I can return to later.

Really great point and also really illustrates the tree structure underneath the hood for git and how it rules everything.

The joke that isn't a joke is that you really need a CS degree to use git. It's not wrong.

The git default arguments makes for a very inconsistent experience, agreed.

And then `git checkout .` vs `git reset --hard/soft` vs `git cleanup` are all super similar but very different.

Still love it more than perforce/svn (I did like mercurial a little better back in the day but I doubt that might still be the case).

----- `git reflog` is king and shows you the truth.

Yeah anyone I run into that 'doesn't get git' and only has like the four commands they ever run... I point them at https://git-scm.com/book/en/v2/Git-Internals-Git-Objects

Once you internalize that git unlocks.

I use Stable Diffusion (A1111 webui) and sometimes run into config issues, sometimes untracked by git. Nothing more catastrophic than doing `git clean -dfx` by habit from tinkering with Debian packages and knowing that command actually resets everything that `git reset --hard` doesn't...

And then accidentally wiping out all of your checkpoints and generated images :')

Hardlink your checkpoints elsewhere, this way you don't have to keep them around elsewhere. Alternatively, make your models directory a symlink. (I don't think you can symlink the models themselves, I think that'll break it)

You can still use git and have it be useful even if you don't fully inderstand it, so I disagree with the CS degree notion.

Until you get “got”.

I think that this video should be considered mandatory viewing if you're a developer using Git — the whole lecture starts from the basic data structures involved and builds from there, as opposed to the way that it seems many people approach Git: "What command do I run?"

https://www.youtube.com/watch?v=2sjqTHE0zok

That's great evidence that git's UI is such a leaky abstraction that it's actually terrible.

Git's UI is not meant as an abstraction at all. It is a set of tools to work on the underlying model. And the underlying model is actually quite elegant and understandable. I'd take that anytime over a leaky abstraction like subversion.

Buh, buh, but Linus wrote it. There's got to be a pony in there somewhere. /s

I believe that detached HEAD means that there is not a current branch, that is no branch will be updated the next time you commit.

You can get to detached HEAD even if the commit is pointed to by a branch

AND we should have pseudo-pointers to the current directory layout and the files already “add”ed (a.k.a. cached/indexed/staged). Git’s UI should allow us to do “diff” or any other command on these. I tried to get the git maintainers to name these (DIR and NEXT?) and make them work with the big commands, but they didn’t see the simplicity of it all. So instead of “git diff DIR NEXT” we get “git diff” and instead of “git diff NEXT HEAD” we get “diff —cached HEAD” which are much less understandable.

>the single command that can take you out of any weird situation is `git reflog` which shows you all the commits that HEAD has pointed to.

Can you elaborate on why that's helpful? I rarely get into a weird state with git but when I do it's almost always faster/easier to just delete the repository, re-clone, and re-apply my changes manually.

When you accidentally delete a local branch or mess up a rebase you can use the reflog to retrieve your lost commits

If you accidentally symlink the wrong file, would you find it easier to delete the whole directory and restore from backup, or just learn how to change a symlink?

Git is many orders of magnitude more difficult than symlinks.

It isn't really. Spend a day learning it and you'll be like a superhero for your team.

I just delete the symlink and create a new one.

And, likewise, just delete the reference and create a new one.

A recent scenario had to do with me rebasing something to squash out some intermediate commits, and then I opened a PR, only to realise that some of the things I squashed I actually needed them.

With reflog I was able to go back before my rebase and redo it again, more carefully this time. (Unfortunately I couldn't just cherry-pick the thing I wanted)

In general it saves you from having to do what you described with delete/re-clone/re-apply things.

Whenever you get into an undesirable state, you usually want to undo whatever you just did. Sometimes it's very easy, e.g. if you created an object, to undo that you just delete the object. Sometimes git explicitly tells you what to do, e.g. if you are in the middle of a merge and you want to cancel it, it tells you to run `git merge --abort`. Sometimes it's not quite as easy, but still straightforward to google what to do, e.g. if you merged or committed to a branch, you just have to look up (or remember) the command to manually set what commit a branch points to.

However, in my experience the most difficult "weird state" to get out of is when you do something that removes/rewrites history. For example: deleting branches, rebasing, squashing, or accidentally getting rid of a reference while attempting to solve some other problem. The root issue is that you want to find a commit that seems like it no longer exists. If you rebase, the branch now points to a new commit that has ansestors you don't want, but the old commit is gone. The "secret" is that all commits that ever existed still exist, you just can't find them in `git log` because the pointers to them are gone. `git reflog` helps solve this by giving you a list of all commits that HEAD has ever pointed to.

  git checkout cool-branch  # HEAD points to commit abc123
  git rebase main           # HEAD and cool-branch point to commit def456, but you realize you don't want that rebase
  git reflog                # reflog tells you that the commit you were just on is abc123
  git reset --hard abc123   # HEAD and cool-branch now point to abc123. You've Ctrl+Z'd the rebase

> Sometimes it's very easy

LOL, that hasn’t typically been my experience, but I appreciate the positive attitude.

This is very helpful, thank you.

I just copy paste this and put it in my "break glass in case of emergency" folder. I have many snippets there. This is a good one. I usually refer to the log but reflog is really the "undo" for anything.

One thing that has really helped me understand git better is DAG (https://en.wikipedia.org/wiki/Directed_acyclic_graph). Whenever I do `git add <file/folder>`, it is somewhat easier to imagine how new blobs are created and how they are linked.

For beginners it is a fun exercise to understand why empty folders can't be added to git.

Not that there is any reason why git has to forbid the existence of empty tree objects.

(Fun fact, all such empty trees would be deduplicated to a single object).

Yep, HEAD isn't the head of any branch of the DAG, it's the CURRENT pointer to a commit. Why it's named HEAD shall forever remain a mystery.

Quite a lot of git is conceptually simple, but the UI has quite a few confusing names & options.