4 ms·

I saw this was downvoted and tried to help by upvoting, but it is worth talking about what “history” means though. Squash commits rewrite the source branch hist

by dahart 4y ago

I saw this was downvoted and tried to help by upvoting, but it is worth talking about what “history” means though. Squash commits rewrite the source branch history, but they don’t rewrite the destination branch history. I would argue the team-wide destination branch history is what should be called “history”, and the only thing that matters. But Fossil’s distinction is more rigid and it considers anything ever committed to be history. Squashing a local branch does, in a way, rewrite local commit history. But this shouldn’t be called “rewriting history” in my book. Rebasing the main branch really is fully rewriting history (and this isn’t a squash commit). Squashing a feature branch that multiple people touch is somewhere in between. It’s a little rewriting. It’s often desirable. Should squashing small feature branch PRs be called “rewriting history” in the sense that Fossil claims that it’s intended to misrepresent the project? I don’t really think so, but since “rewriting history” wasn’t clearly defined, it’s open for debate.

cortesoft 4y ago
You don't even need to rewrite the source branch history. You can leave the source branch as is, and create a single commit on the main branch that is the squashed content of the source branch. It isn't considered a merge in the normal way by git, which can cause issues, but there is no lost history and GitHub and gitlab are able to keep track of the source of the squash commit.
- dahart 4y ago
  Yeah true! It still goes to clarifying what people mean by the words “history” and “rewrite”, etc. The primary public history of a feature branch might only be preserved in the merge commit, so in some sense the preserved history is different than the branch history. It’s somewhat fair to call that rewritten. I prefer to focus on the fact the git never promised a “history” at all. Git doesn’t offer to capture what happened accurately, it only promised to keep the content of your changes and its relationship to the preceding state of the content. It only promised a sequence of dependent commits, and it allows reordering commits by design.

by dahart 4y ago

cortesoft 4y ago

You don't even need to rewrite the source branch history. You can leave the source branch as is, and create a single commit on the main branch that is the squashed content of the source branch. It isn't considered a merge in the normal way by git, which can cause issues, but there is no lost history and GitHub and gitlab are able to keep track of the source of the squash commit.

dahart 4y ago
Yeah true! It still goes to clarifying what people mean by the words “history” and “rewrite”, etc. The primary public history of a feature branch might only be preserved in the merge commit, so in some sense the preserved history is different than the branch history. It’s somewhat fair to call that rewritten. I prefer to focus on the fact the git never promised a “history” at all. Git doesn’t offer to capture what happened accurately, it only promised to keep the content of your changes and its relationship to the preceding state of the content. It only promised a sequence of dependent commits, and it allows reordering commits by design.