Hacker News Reader

Comment by poorman | Hacker News Reader

Can someone explain the benefit of this? vs. "squash and merge"?

I personally think that commit history should be kept as long as it makes sense. But in some cases, you don't want to keep some of the commit messages if they don't add anything to development flow.

For example,

- Force SSL flag when connecting to server

- Use new syntax for SSL flag

- Wrap flag implementation to its own method

- Add forgotten tests

This branch's main goal was to use ssl flag on external requests but ended up having several commits that does not really matter to other developers. Then you want to squash this branch into a commit and merge.

Rebase and merge example,

- Improve sorting by adding cache

- Implement a separate config class to fetch caching times.

- Modify search implementation to use cache config class

These are rather important commits by themselves and better keep them separated in your history.

> These are rather important commits by themselves and better keep them separated in your history.

Which you could already do with a regular merge. Just because the commits are fine as part of a branch doesn't mean you want to keep them as part of mainline.

> Just because the commits are fine as part of a branch doesn't mean you want to keep them as part of mainline.

Can you elaborate on this? I would be happy to learn more about it.

Parent is missing the point that you were making, which is the benefit of not squashing vs. squashing.

What masklinn means is that when you just merge a PR, the history is retained as-is (same as with rebase). But instead of the history being flat, it's bumpy.

> Parent is missing the point that you were making, which is the benefit of not squashing vs. squashing.

I'm not missing any point, I'm saying you already get that benefit with the original merge strategy.

If you want to keep the individual commits rather than squash the into a single commit. This is useful if the author of the PR actually wrote good commits that you don't want to make into a single commit. I'm also thinking of the case where a squash could turn a series of commits into a single commit with a massive amount of changes that is harder to grok when going back historically.

So it's like the old "merge", but doesn't create another commit when you close the PR?

Yes -- a merge merges one branch into another, and creates a merge commit while doing so.

A rebase rewrites history, as if the PR had been written on master directly. There is no merge commit and no evidence of a previous branch. Some people prefer rebasing over merging because it gives you a linear commit history.

This is not correct. What you're describing is two different styles of merging: fast-forward and no fast-forward, as indicated by the `--no-ff` and `--ff-only` flags provided to `git-merge`

`git-rebase` will rewrite the history of the current branch. In this case, github will rewrite the history of the branch that you would like to merge such that the base commit (hence the name "rebase") or the commit that was branched off of is the latest commit on the default branch (usually master)

Then when you merge it, you'll get a merge commit or not depending on whether or not you do a fast-forward merge

Reply on news.ycombinator.com