Hacker News Reader

Over the last decade, I think I've only used `reflog` twice. The only case I remember clearly was to help a co-worker that had created a local mess, starting with a `git pull` (meaning a merge) on the wrong branch then piling onto that.

If you use Git in a terminal, a much simpler alternative to the reflog is having the commit hash in the prompt. Then comparing/reverting to a previous state just requires scrolling the terminal to find the commit id. It's much easier to read than the reflog. With the help of the shell prompt, the terminal can help with the questions "what did I do to get there and how to get out?".

I also think that Git has become much more error-proof. It's been a long time since I've seen anyone lost in their own repository like I'd seen years ago. There are better GUIs. In the command line, modern Git often displays hints, has warnings for some dangerous commands, and sometimes explains how to rollback.

For me, it‘s usually not about somehow „breaking“ my repository so that it‘s in a „weird“ state, but about messed up rebases, filter-branches (or modern equivalents), and other branch manipulations that leave my branches in a now unwanted state.

When working on big projects with many people, multiple release branches, and constant updates to those release branches, there‘s bound to be situations where you try to juggle multiple local branches for the same change(-set) to massage conflicting changes into place, only to after a while go „no, that went bad, let‘s start over“.

Having the commit ID displayed by the prompt is a good idea, and it solves the problem in a similar way. However, I prefer my prompt to be on one line, and it‘s already pretty long. Plus, I often do lots of stuff between git commands, so I‘d have to „hunt“ for the prompts. I need git reflog on average probably about once a month, and just typing „git reflog“ and seeing what git operations I‘ve performed is perfect for me.

I'd also recommend turning off reflog expiration with:

  gc.reflogexpire=never
  gc.reflogexpireunreachable=never

Defaults for each option of anyone is curious:

> gc.reflogexpire

90 days

> gc.reflogexpireunreachable

30 days

I didn‘t know about that. Good idea, thanks.

Even though I find reflog very useful, I don't think it should be the first thing.

What I think that should be one of the first things and most people don't know is written in "What is Git?" chapter from Pro Git: https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3...

> `git reflog`, which the article prominently mentions, really should be the VERY FIRST thing to teach everyone who is learning git.

Top that up with `log` showing all branches at all times (except if you ask otherwise) and you end up pretty much where mercurial is. Detached heads is such nonsense. Git missing phases and obsolescence (to denote if and how history eventually got rewritten) is another.

Oh, I actually make heavy uses of detached heads. The projects I work on frequently require you to look at a „snapshot“ of how the code was at a certain time when diagnosing issues, and it‘s good to be able to „look without touch“, i.e. being able to check out a specific state without it cluttering up my branches (though honestly, they‘re pretty cluttered already).

Yup, navigating history and checking-out commits at will is VCS ground-level. It's mind-blowing that git managed to make it unnecessarily complex by distinguishing "commits" from "commits with a label on them" (aka. branches), and putting in-your-face warnings when generating new commits in the former case (whereas the DAG itself doesn't care).

I agree!

I'm creating local tmp1 tmp2 branches before I'm doing anything sketchy. Branches will keep the commit visible and I can always return to the previous state if necessary. Tags would be more appropriate, I guess, I just got used to branches more.

You can see „git reflog“ as a sort of automatic tmp-branch creation at every step. Of course your way works as well, and I tend to do the same when I know it‘s getting hairy, but it‘s nice to just be able to do git stuff knowing you can always go back without much precaution.

The only thing I need to remind me to be careful about is, as said, uncommitted changes. With some luck, Time Machine can help for that, but to be safe I practically always stash away changes instead of somehow undoing them.

I prefer to use git from GUI and those usually do not support reflog. I'm aware of it, but that's my tool of the last resort, if I did something very wrong.

I'd replace that with giving someone a link to Git Fix Um[1]

[1]: https://sukima.github.io/GitFixUm/