Hacker News Reader

Comment by mpdehaan2 | Hacker News Reader

Rebase is awesome. Here's an example.

http://michaeldehaan.net/post/116465000577/understanding-whe...

No it's not, it rewrites and destroys history. The problem it solves is "keeping the history clean", when actually it's not what you want. You don't see your history, you see logs and diffs. So you want to keep your logs and diffs clean. There should be an other solution to this other than simply removing/merging commits and eventually removing information with it.

We had the same discussion in my office. If I am developing a feature (in a separate branch) - why shouldn't I rebase to make a single commit out of this feature ?

Is this really interesting for you that it took me 10 commits to do sO ? Even if one of the commits was just a "I have to switch an fix a bug and want to commit before switching to another branch" - commit ?

I think there is nothing wrong with rebasing and to merge commits before pusing them.

I don't think it's wrong when using git. However I think it shouldn't be designed like this though. Git rebase should add metadata not remove them. Essentially you rebase because you want to hide certain details because they are not important. Rebase could do one or more actual merges instead and mark certain commits not important so they wouldn't show up in logs by default.

AFAIK rebase is the only operation that happily destroys your history without any --force or --hard option. It always disturbed me.

There is a legitimate usage of rebase though: you really want something removed from history. Like you accidentally committed a secret, inappropriate message or you just want to fix a typo in the last commit.

The way I understand it, I should only rebase (for squashing, not in the case of a spilled secret or inappropriate message) if I haven't pushed it to a shared remote branch. Is that correct?

That's how I am using rebase all the time. I'd say yes - that's the most common use for it and I think it works fine for this.

if you read my post, "history" on local branches is irrelevant. They do not exist and "destroy" here is totally fine. It's not like it's meant to be a grand book detailing all the work done by you, in every point in time, as a database record. What you want here instead is just a clean patch coming off your topic branch -- which this does perfectly.

This is SUPREMELY valuable for OSS patch workflow and I absolutely love git for having it.

Some of the arguments against merging made in this article seem a little strange, for example saying "If folks on topic branches rebase, there will not be any conflicts on merge" after previously stating "It’s also a great idea to rebase periodically - several times a day", as there would also be no merge conflicts if the branch was merged in periodically as well. If merge commits are so abhorrent, just alias git log to git log --no-merges

Rebase is not just a history win, but also a patch review win.

Reply on news.ycombinator.com