Hacker News Reader

Comment by guard-of-terra | Hacker News Reader

Two fun things about git: It is deterministic, and it doesn't delete anything (readily).

This means you can't really have a catastrophe.

Just git reflog your way out.

This is the right answer. I think for whatever reason, software programmers are afraid to learn how git works. They'll spend countless hours learning how their other tools work - but not the one that keeps and protects changes to their work. It's maddening. The worst part is - it's really not that difficult to go into the .git directory and look at how the files are structured and learn it. Once you do, a lot of using git becomes second nature.

This is the video that I keep recommending to new people who want to know how it works on a technical level. I've always had amazing/euphoric feedback to that recommendation.

https://www.youtube.com/watch?v=ZDR433b0HJY

Cool. For me it is this video. https://www.youtube.com/watch?v=MYP56QJpDr4

I notice they are from the same publisher.

That's a bit of an overstatement. You can't have a catastrophe with stuff already committed (but it's very easy to delete in-progress work).

Only if you never commit and then do checkout -f / reset --hard. Why would you be doing that?

Otherwise it's still in reflog. Anything you ever commited is just there.

Unreachable references will be pruned after 30 days (by default) if/when git-gc gets run (which will occasionally happen automatically by default). Not saying it's a problem, just note that they're not actually there forever.

For reflog it's 90 days. (So anything referenced by the reflog will be retained for that long.)

AFAICT, for unreachable entries (e.g. as generated by `git commit --amend`) the default is 30 days as defined by `gc.reflogExpireUnreachable`.

No, because those commits are still reachable from the reflog.

If you are committing so rarely that you can have a CATASTROPHE with your in-progress work, maybe you should try breaking the work in smaller parts and committing more often

Unfortunately git's staging area concept encourages you to do exactly the opposite of this.

I almost only use it to cherry-pick and then immediately commit?

Right, all the good use cases involve not actually using it - if you're immediately committing then it would be better if it just became a commit.

I meant: I cherrypick from my changes and commit bugfixes and drive-by update of comments separately.

My bad. I shouldn't have used the word cherrypick there.

well unless you haven't pushed in a while and you rm -rf your home directory. Of course that has never happened to me.

On a completely unrelated topic, extundelete is a great piece of software.

I've had occasional data-loss from git.

The problem is when you realise someone badly rebased, or forced a push, a while ago and now you have to try to find where the stuff was lost.

the reflog is GCed, IIRC. So if you wait long enough, and commit long enough, that history will be gone.

The reflog GC is time-based -- it defaults to retaining entries 90 days.

Reply on news.ycombinator.com