Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Everyone's got an opinion on "rebase", and IMO you can safely ignore those that conflate:

* the rebase command, as a means of adjusting commits

* the practice of squashing all commits into a single commit (typically, but not always, via rebase)

* the "rewriting of history", whether on public or private branches

* rebasing on merge vs. creating a merge commit

This article starts by saying they "like rebasing" only to then say

>Git rebase allows me to squash my disordered commits into a neat little one

Rebase allows this practice but you could just as easily `git reset @~` a few times and then `git add .; git commit -m "My big commit"`. Alternatively the author could just `git add .; git commit --amend --no-edit` throughout the task and end up with the same result. To be fair to the author, they later add that they don't always squash to a single commit, but here I'm talking about "rebasing" vs. commit practices. Rebase is just a tool which allows various practices and it's tiresome seeing the same arguments against this nebulous "rebase", when the arguments are actually directed at practices.



I really appreciate the distinction you're making here. That is, rebase itself is not necessarily either the hero or bane of the process. There are several ways to the "squash my disordered commits" problem, which you've described nicely.

I personally use rebase similar to the author, to squash all my noise down to my final intention. But this could be achieved in other ways, just the same.


I'd make fun of you so hard if I saw you doing that. You'd lose all your comments and have to retype them manually.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: