Hacker News Reader

Comment by tomp | Hacker News Reader

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).

View on HN

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.

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.

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.

Reply on news.ycombinator.com