Comment by mikemcquaid
2 days ago
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).
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.
Ha, how many years spent reading it as re-flog and not ref-log. Flog the git!
> (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?
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`.
Unsure, no longer there. I think maybe just “contact support”.
> 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...