4 ms·
Every complaint I've read about rebase is this same one, over and over, and I think it's based on a false premise. > Rebasing destroys your history, and theref
by threedaymonk 13y ago
Every complaint I've read about rebase is this same one, over and over, and I think it's based on a false premise.
> Rebasing destroys your history, and therefore destroys the point of using a VCS.
The answer, of course, is don't do that. Don't rebase public branches, and that includes master and whatever else you're deploying from.
In any case, you can't rebase master unless you're willing to force push, and if that hasn't tipped you off to the fact that you've gone off piste, what will?
> If you've got an entire history that's been heavily-rebased and your problem is "This bug started happening on Tuesday last week", you have a big problem: You can't just track back through your simple, linear branch until you get to last Tuesday's commits.
This hypothetical scenario of last Tuesday's bug therefore makes no sense. You can do exactly that, because you don't rebase history: you rebase work in progress onto the canonical record.
In summary, rewriting history would be bad, but that's not what rebase is used for.
- cleaver 13y agoAlas, "Stay away from rebase" will get more clicks than "Git-rebase caused me some problems and I should be more careful". I've found rebase essential in maintaining nice clean feature branches. Occasionally I run into issues, but I make sure I can back out of any changes even if it means copying the whole damn repo to somewhere else on disk.
- threedaymonk 13y agogit reflog will save you from any amount of rebase-induced chaos. Pick the last good point, reset --hard, and carry on.
- sanderjd 13y agoAny time you rebase you rewrite history, not only when you rebase public branches. It is significantly worse to re-write the history of public branches as you've pointed out. Your work in progress also has a history that you re-write when you rebase.