4 ms·

You could also just filter down to merge commits when you look at history. I think if gitlab and github supported this, many people would change their minds ab

You could also just filter down to merge commits when you look at history. I think if gitlab and github supported this, many people would change their minds about squashing or rebasing. I don't have a problem with squashing per se, especially when it's a private branch for a single developer. The problem is when you have multiple developers working on a feature branch together, or when you have to merge in a branch with a fix or feature that has not yet been merged up higher. My bottom line is I want as few merge conflicts as possible, and I want to see the real author and a relevant commit message if I'm digging into changes to figure out what went wrong with something.

int_19h 4y ago
Squashing or rebasing a shared branch would break it for basically everybody else, so who even does that? Realistically, squash & rebase is used only to clean up history in those private branches before it gets in the main repo. Fossil doesn't support it on the basis that those local commits are valuable to other developers who work on the code, and I disagree with this as a general claim.
- dec0dedab0de 4y ago
  Squashing or rebasing a shared branch would break it for basically everybody else, so who even does that? It tends to be developers that are used to the opensource workflow of forking before submitting a patch or pull request. Who are now on a team where everyone's working on branches in the same repo. I understand wanting to combine a bunch of commits that say "trying it like this, trying it like that". but I find it's better to have the noise than lose something important, or cause a messy conflict later on. I also don't like multiple changes in a single commit. I hate when I look into the commit history of a file and it's "added feature X" which touches 15 different files making changes to multiple code blocks in each. If I want that, I'll look at the merge commits.
  - int_19h 4y ago
    Open source or not, you still have your local fork of the repo, and that's where the squash ought to be happening.

int_19h 4y ago

Squashing or rebasing a shared branch would break it for basically everybody else, so who even does that? Realistically, squash & rebase is used only to clean up history in those private branches before it gets in the main repo. Fossil doesn't support it on the basis that those local commits are valuable to other developers who work on the code, and I disagree with this as a general claim.

dec0dedab0de 4y ago
Squashing or rebasing a shared branch would break it for basically everybody else, so who even does that? It tends to be developers that are used to the opensource workflow of forking before submitting a patch or pull request. Who are now on a team where everyone's working on branches in the same repo. I understand wanting to combine a bunch of commits that say "trying it like this, trying it like that". but I find it's better to have the noise than lose something important, or cause a messy conflict later on. I also don't like multiple changes in a single commit. I hate when I look into the commit history of a file and it's "added feature X" which touches 15 different files making changes to multiple code blocks in each. If I want that, I'll look at the merge commits.
- int_19h 4y ago
  Open source or not, you still have your local fork of the repo, and that's where the squash ought to be happening.