The many faces of git rebase
epx.com.br
epx.com.br
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.
In other words, the dates of commits won't be chronological after a rebase.
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.
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.
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.
A better git than git?
git done right?
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.
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.