I prefer to think of rebase as accomplishing one simply-described task:
Taking a series of commits from anywhere in the repo and replaying it starting from any point in the repo, possibly with modifications.
All the use cases described in the article and crazy CLI options fall out of this simple description. I realize there's quite a bit you need to grok before this becomes obvious, but nevertheless I think it's a good mantra to have as you are learning git and run into problems.
Eventually your mental model shifts from "what does this command option do?" to "what final state of the repository do I want?", and from there it's just a matter of practice.
Every commit has both an author/author-date and a committer/committer-date. The former are retained during a rebase, the latter are reset. However, you can use --ignore-date to reset the author-date, or --committer-date-is-author-date to retain the original committer-date.
In any case, when using git log, you can override its default of listing commits in reverse chronological order with --topo-order or --date-order.
There are actually two dates associated with each commit. I cat recall the names for them off he top of my head but they're basically created_at and modified_at, and the modified_at ones will be chronological after a rebase.
About that git "eating" commits - they're always recoverable from reflog: see `git log -g`. (where always == until you gc, or delete old clone, or ...)
Otherwise git's interface sucks and is inconsistent, but we're probably past the point of no return. There's always Easy Git and similar projects which aim to make it a bit better if someone wants to use them.
Up-voted for the salient observation that we're past the point of no return.
This occured to me as well recently, when there was a lot of web traffic about the git devs polling their audience about a minor behavioral change to git push[1]. What I realized then: git's interface is now more or less frozen, too much depends on it never changing significantly, that big 2.0 that'll fix everything will never come. At this point, we're stuck with all of git's quirks, until something new comes along that's significantly better in enough fundamental ways to displace it.
Frustrating in a way, but that's how it goes in the real world. Good thing the core is beautiful.
"At this point, we're stuck with all of git's quirks, until something new comes along that's significantly better in enough fundamental ways to displace it."
No, that won't be enough. You need something that's better than git in the same way git is better than SVN: A paradigm shift. Merely being nicer or easier at doing the same thing is rarely enough, you need to do something broadly useful the entrenched tool just cannot do.
"CAUTION: several people I know, including guys very proficient in Git, have complained about "git ate two days worth of my work!". It is easy to make errors in rebasing and reset --hard, and you may end up losing commits."
Like everything else in git, the solution to this problem is just to make more branches.
If you're about to do something like a rebase, just fork off a new branch first. It makes it trivially easy to get back where you started if something goes wrong. That's the whole point of version control, after all.
several people I know, including guys very proficient in Git, have complained about "git ate two days worth of my work!" It is easy to make errors in rebasing and reset --hard, and you may end up losing commits.
Something seems wrong there. How do you lose commits? They're all in the reflog. The only way I can see git "eating" work is if the work hadn't been committed in the first place and they overwrote it - in which case it's not so much "git ate my work" as "I deleted it".
It's true that it's easy to make errors with rebase and reset, but it's just as easy to correct them. That's the beauty of it: commits are so malleable that they become part of interactive hacking. One gains a new axis along which to store information and move it around and rework it (comparable to a bunch of new registers magically appearing in a machine). For me the most interesting consequences don't have to do with version control so much as with how I craft programs in general. Biggest win since the REPL.
Taking a series of commits from anywhere in the repo and replaying it starting from any point in the repo, possibly with modifications.
All the use cases described in the article and crazy CLI options fall out of this simple description. I realize there's quite a bit you need to grok before this becomes obvious, but nevertheless I think it's a good mantra to have as you are learning git and run into problems.
Eventually your mental model shifts from "what does this command option do?" to "what final state of the repository do I want?", and from there it's just a matter of practice.