

The many faces of git rebase - ranit8
http://epx.com.br/artigos/gitfaces.php

======
dasil003
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.

~~~
pagekalisedown
You're description is correct, but it's also worth mentioning that the commit
dates don't change when "replaying" them.

In other words, the dates of commits won't be chronological after a rebase.

~~~
js2
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.

------
viraptor
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.

~~~
sho_hn
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.

1 = <http://lwn.net/Articles/487131/>

~~~
read_wharf
"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."

A better git than git?

git done right?

~~~
sho_hn
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.

------
ef4
"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.

~~~
gruseom
_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.

