4 ms·

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 d

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.

masklinn 10y ago
> 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.
- whizzkid 10y ago
  > 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.
  - scrollaway 10y ago
    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.
    - masklinn 10y ago
      > 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.

masklinn 10y ago

> 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.

whizzkid 10y ago
> 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.
- scrollaway 10y ago
  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.
  - masklinn 10y ago
    > 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.