I'm that psycopath :D
> I don't care, and I'm okay not caring. Not learning git might even give me extra time to learn about these magical computer algorithms I've heard so much about.
I'm fine with this actually. If you don't care, and don't want to. That's actually totally fine. I personally will look at you a bit strange. But when it comes down to it. You should only care about what you want to. But please, for my continued (admittedly borderline) sanity. Don't try to convince others that it's too hard to learn, and/or that they shouldn't try. I want to work with people who are curious, people who want to learn how cool things work. But there's a trend in software engineering, that parts of it are too hard, and that it's a waste of time to learn them. That's a scary thought to me; imagine the next generation of software devs, all convinced that they can't understand something, or that it would be a waste of their time to try?
Git is worth learning but it's about 10x harder to learn than it would have been had its designer known anything about human interface principles. And its manual is useless because that same designer wrote the manual too.
Git would be completely unlearnable without Google and Stack Overflow, but since those things exist, it's worth learning.
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.
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..
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.)
So like most other developers, I go about my day totally not understanding git at all and when something weird happens, I talk to that co-worker know understands get (there's always at least one such psychopath on each dev team in existence) and ask him to fix it. He invariably talks about how easy and elegant git is and then finally gets around to giving me a couple commands with non-sensical names and options that fix the problem.
I don't care, and I'm okay not caring. Not learning git might even give me extra time to learn about these magical computer algorithms I've heard so much about.