I beg to differ. Mercurial is all about immutable history. Git is explicitly designed to mutate history (that's what rebase does) in the demented (IMHO) pursuit of a linear change log.
Git commits are never mutated. They are referred to by a hash of their content after all.
What's the UI for getting at those old commits? Is it possible to get a true chronological log from them? Do they stay around forever or do they get garbage collected eventually?
git log --all --graph --oneline --reflog
git config --global alias.lg "log --date=format-local:'%Y-%m-%d %H:%M:%S' --pretty=format:'%cd %<(20,trunc)%an %C(auto)%h%Creset%C(auto)%d%Creset %s'"
git lg --all --graph --reflog
The output of git log with --graph is not chronological, because it does a topological traversal of the commit graph.
> Do they stay around forever or do they get garbage collected eventually?
They get garbage collected eventually. As a rule you should not assume dangling commits are safe. If you need to keep one, assign a trivial branch name to it.
The same as any other commit. You can check them out by referring to their hash, by referring to any tags that point to them, or any branch that points at them.
The other reply gives options assuming the commits have been orphaned (no tags or branches point at them).
(Obviously the branch/pointer itself is mutable.)
Learning the implementation details and reading the mystifying documentation to learn what something is called can be a bit wasteful but understanding the git model is very worthwhile. It is interesting to see how it handles the pragmatic issues of fixing the situation up when the history becomes snarled.
Learning git will make some not insignificant number of people better at concurrent programming. Most build systems don't do that..