[mikemcquaid]

I’ve used Git for 20 years now and wrote a book about it.

The biggest mistake most sources make when teaching about history rewriting is omitting these two lessons first:

- it’s easy to lose uncommitted data in Git and hard to lose committed data

- given this, learn how to use ‘git reflog’ to see what you’ve done and how to undo/redo it (as this post recommends but, even then, a little too late)

If you just get in the habit of constant committing and checking reflog: you’ll never lose data.

(Related lesson from my 10 years employed by GitHub: they almost never do the git gc you’d expect to remove commits so once you push a commit: it’s likely there forever and identifiable by that same hash from anywhere in the fork network. This can be bad/scary so be aware).

[dist-epoch]

> it’s likely there forever and identifiable by that same hash from anywhere in the fork network

in case you are not aware of it already:

https://www.aikido.dev/blog/the-fork-awakens-why-githubs-inv...

[speq]

The most important thing to happen to git in its entire history is jj as a better porcelain to git, so that you don't need to read entire books to get it right.

[douglee650]

Ha, how many years spent reading it as re-flog and not ref-log. Flog the git!

[codethief]

> (Related lesson from my 10 years employed by GitHub: they almost never do the git gc you’d expect to remove commits so once you push a commit: it’s likely there forever and identifiable by that same hash from anywhere in the fork network. This can be bad/scary so be aware).

Oh wow. Is there a way to trigger GC manually?

[OneDeuxTriSeiGo]

For github itself the answer is "contact them if you think you pushed a secret".

For git. You can run `git maintenance run` or the legacy command `git gc`.

[mikemcquaid]

Unsure, no longer there. I think maybe just “contact support”.