That's a shame it takes them weeks to read three quite comprehensible man
pages to think up two different ways of changing commit history.
How did we actually get to the point where it takes weeks of training to use
git, when I remember learning how to use it in a day or two, ten years ago
(when it was much less usable and documented), and for a (far from trivial)
use case of being a helper tool for off-line work with Subversion?
the desire would be to have a system which let you get started relatively quickly, and learn it more in depth as you have need to.
git really doesn't work this way because unless you manage your branching and merging in a sympathetic way (to both git and your peers), you can get very thoroughly punished.
> Probably because you have 10 years of experience?
I was learning git a decade ago, and all it took was at most two days of
reading. And yes, this includes the idea on how to rewrite commit history
(actually another one, very low-level; I don't expect anybody to ever think of
this way for the task).
I didn't have StackOverflow or plethora of tutorials on web that are present
today.
> Git is a mess
I keep hearing that, but once upon a time (seven? years ago) I tried learning
Mercurial, this paragon of usability, and I couldn't figure out one of the
simpler things: how to setup a repository to merge changes from two other
repositories without specifying full paths.
Given that, either I'm very smart, because I picked up git so quickly, but
so-praised Mercurial "is a mess", or I'm very stupid, because I couldn't
figure so simple Mercurial function, but then what does it say about people
who can't read the fsckin' git docs?
