I see it like learning a build system: ultimately a pointless piece of trivia that isn't very interesting or worthwhile. This is in contrast to math or CS, which is generalizable and timeless.
But you're right, we should all understand this stuff. And if it wasn't for that one magic coworker (you're really taking one for the team), I probably would.
Git is a little bit different. It is a really good implementation of the 'history is immutable' philosophy of programming.
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..
> Git is a little bit different. It is a really good implementation of the 'history is immutable' philosophy of programming.
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.
Rebase does not mutate. It creates new commits and updates the rebased branch to point at them. The original commits still exist (even if no other branch points at them).
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?
> Is it possible to get a true chronological log from them?
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).
As far as I know, commits that were once ancestors of a branch can sometimes no longer be ancestors of that branch. If that's not a mutation, then the word is not as useful as I thought.
Branches are just pointers into a graph of commits. The graph cannot be mutated (it can be pruned by garbage collection but that does never happen related to an oh shit event, it takes weeks even in a heavily modified repo). The pointers can be modified to point anywhere else in the graph, which makes things look mutated without being mutated. Using reflog you can get your back to where your pointers pointed to at any earlier point of time.
I'd say it's a pretty standard use of the word. Branches are analogous to pointers. If a program changes where the pointer points, it has not mutated any values, besides the pointer itself.
But you're right, we should all understand this stuff. And if it wasn't for that one magic coworker (you're really taking one for the team), I probably would.