

Rebase Is Safe - garybernhardt
http://blog.extracheese.org/2010/12/rebase-is-safe.html

======
dfox
I simply don't see how this effort to use rebase instead of every merge helps
anything. While there are valid uses for rebase I simply don't buy this
"cleaner" (and incorrect) history argument.

~~~
gruseom
Git has changed how I work with and even think about a codebase, and rebase is
a big part of that. Because of git's speed, the warm fuzzy security provided
by its hashing mechanism, and a few other things, a new dimension (time) has
opened up for organizing my ideas and experiments. Before git, committing to
source control was like laying down layers in concrete. That meant going back
and fixing anything was a concrete-smashing construction project, and that led
to a mental model in which version history was just a documentary record: if
things were originally done in order X,Y,Z, to turn that into X',Y',Z' would
be to falsify history. With git I have a different mental model: the temporal
dimension is no longer just a factual history (though it still is that at a
large scale). It's now a medium for organizing and reorganizing things
logically. It's like having a new scratch buffer in your brain.

Such a new medium is a rarity in programming and can take a long time before
it finds its proper place. It seems flawed because it deviates from the
"normal" way. But this new tool has led to breakthroughs in how my designs
evolve, and I wouldn't give it up willingly. That's despite the fact that some
of the criticisms of rebase are real: e.g. you can break previous commits
without knowing it. The value of the feature far outweighs these costs, at
least for the projects I've used it on. You know how Lisp programmers go on
about how malleable Lisp programs are, like you're molding in clay rather than
pouring concrete? It's analogous to that.

Edit: another analogy is interactivity. Rebase gives you a feedback loop into
the evolution of your code the way that REPLs give you a feedback loop into
its execution. Qualitatively new feedback loops are extraordinarily valuable.

------
p_nathan
Safe is not a good word for rebase.

It's a tool, and a fairly sharp double-edged one at that.

Use with care.

------
EGreg
tell me again why we NEED rebase?

~~~
zrail
I commit a lot. A lot a lot. Sometimes those commits don't actually work for
some reason. For example, when I leave for the day and I'm in the middle of a
task, I like to leave a failing test so I have something to pick up on
immediately when I get in for work in the morning. I fairly often commit this
state.

When it comes time for me to publish my changes, I very much do _not_ want
those unpublishable intermediary states going out into the world. Rebase lets
me break apart and combine them into rational, test-passing changes that have
cogent, readable commit messages instead of "blah", "blah again", "what the
hell i forgot to frob the flubulizer!?", etc.

In sum, yes it's a heavy-handed tool. Yes you're "destroying" history, but
often that history is extremely ephemeral and mundane and not germane to the
actual meaning or effect of the change.

~~~
EGreg
When you publish something to the world, don't you want to take a minute to
make sure it's good? You do this when pushing to production, right?

Well, then why not take the same care and simply create a new branch with only
the "clean" commits, and then push that branch?

I don't see a need for rebase. Don't rewrite your existing history, make a new
branch to push to others! Like "tags" in svn.

~~~
zrail
It's not like there are clean independent commits just floating around in
there with the junk. It's the amalgamation of the junk that produces the clean
commits, thus the need for rebase. As someone else in this thread talked
about, being able to tweak my commit history has changed the way I've
approached coding. I commit often because I know I'll be able to go back and
rewrite history before other people have a chance to look at it.

~~~
EGreg
I'm just asking, why can't you make a new branch and merge-commit every 3rd
commit to it, with a better message? It would preserve the philosophical
"involatility" of history.

~~~
zrail
Ok, so the philosophical "involatility" is preserved, sure, but that's rather
a large amount of work to do to preserve unworkable deadends and silly commit
messages and broken builds and the like.

Also, it introduces a huge non-linear mess into the commit history that can be
hard to untangle. Just looking at topic branches in a normal tree with gitk
can be hard. Can you imagine looking at topic branches and these junk branches
at the same time?

