Hacker News Reader

Comment by snuxoll | Hacker News Reader

Because when I am developing in my local repo I have a stream of commits that go “adding xyz because abc is being a pain”. They’re informational for me as I progress through iterating on a feature, but when I’m ready to merge I really don’t want that mess polluting the global commit history. I may also be working on multiple things in parallel and want to isolate them from each other, both to keep a cleaner history but also for code review purposes.

There’s plenty of reason to use rebase, but if you’re fine letting the occasional mess slip into the history then it’s fine to NOT use it as well.

The one universal case though. Rebase before you submit a patchset for review. I don’t want to fight through merge conflicts to review a change, make sure it’s applied to the current HEAD before you send it.

View on HN

Rebasing to squash commits or even split commits up before/during making a PR makes sense to me and I do it all the time just to clean up my mess. The order of development and the state of the repo over time isn't faked, this is just labelling and granularity.

What doesn't make sense to me is rebasing instead of merging. If master has a lot of changes and you want to pick those up, you can merge in which case history reflects reality - each commit has an actual state of the repo that you had on your machine.

Or you can rebase, in which case all of the commits on your branch now contain code that no-one ever had on their machine, not tested, never run, maybe it doesn't compile, maybe it's nonsense.

Both result in the same diff from master so are equivalent for submitting a patchset.

It's really hard for me to see the value of trashing your history like that. People like linear history but history actually is not linear sometimes.

Lots of criss-cross merges make it really difficult to follow history, making it less useful.

Note that merge vs rebase a false dichotomy. After rebasing you still have to merge your branch anyway, either fast-forward or with an explicit merge commit.

In the end, it's about commutating your changes effectively. The less noise there is, the better you can communicate. That takes effort from both sides, but many persons put all the burden on the receiving side.

> After rebasing you still have to merge your branch anyway, either fast-forward or with an explicit merge commit

You can push directly to the target branch.

git push origin my-branch:master

If your branch is a direct continuation of master -- which is often the desired result of rebasing -- then no merge and no force-push are necessary.

(I'm not saying this is a good workflow, btw.)

Which is the equivalent of a fast-forward merge. Same result, different mechanism.

Reply on news.ycombinator.com