[snprbob86]

I don't understand why anyone considers rebase to be scary. It's really quite simple:

Primarily, rebase is a tool for modifying patches. Patches are as much about communication as they are about modifying code.

You edit your emails before you send them, so why not your patches? You proof read your edited emails before you send them, so why wouldn't you test rebased patches?

There are plenty of reasons to use rebase and as many advanced use cases as there are git enthusiasts. However, it's not "rewriting history" because you've always got reflog and cryptographically secure version hashes. It's not any more scary to rebase than it is to "undo" and subsequently "redo" in your text editor. The only caveat is that you shouldn't rebase code on branches that you've shared publicly for the exact same reasons that you shouldn't publish version 3.2.1 and then re-publish it with a bug fix without calling it version 3.2.2.

[alinajaf]

> The only caveat is that you shouldn't rebase code on branches that you've shared publicly for the exact same reasons that you shouldn't publish version 3.2.1 and then re-publish it with a bug fix without calling it version 3.2.2.

<rant>

When one is on a development team that doesn't really understand how rebase (or git for that matter) works and are suitably trigger happy with `git pull --rebase`, this itty bitty caveat makes origin a minefield when working with branches.

In that situation, one would honestly wish one were using svn instead. Then at least one could use git-svn locally and treat trunk as origin/master, which is what ones team really wants.

</rant>

[snprbob86]

This is where smaller code projects with clearer dependencies come in to play. You can designate maintainers, integrators, reviewers, etc on a per-project/per-boundary basis. This means that failure to understand rebase has severely localized effects. As a bonus, you'll get better factored code backed by developers with an enhanced sense of ownership.

[alinajaf]

Or you know, you could just spend a few hours learning about how a tool you're probably going to be using for over a decade works.

[aaronblohowiak]

>it's not "rewriting history" because you've always got reflog and cryptographically secure version hashes

To avoid having to go to the reflog, you can follow this simple procedure: branch before rebase. Then when you're comfortable, just change the branch to point at the new ref. This is the rename(2) approach to rebasing :D

[snprbob86]

> To avoid having to go to the reflog

Why should I avoid having to go to the reflog?

I've met a few folks that, upon learning about reflog, think that every time they run `git reflog` they are admitting that they made a mistake or have otherwise failed to accomplish some task with Git. It's not a failure to need reflog; even if it was, you shouldn't have such an aversion to failure. I frequently run reflog to re-orient myself just like I do with `git log` or `git status`.

[aaronblohowiak]

Interesting point, I will try to take this attitude and approach and see how I like it.