Problem
I noticed that:
- several PRs in the past were squashed into a single commit upon merge (history erased).
- several other PRs have their commits rebased into iterorganization/SimDB (non-identical duplicated history).
- others are indeed merged as merge commits (history retained).
This is messy. Could we stick to one method?
Also, can we not rewrite history if not explicitly intended?
Solution
Based on some minor discussion in SimDB-Dashboard where some of us find it sad to see history erased or altered, GitHub leaves us only the "merge commits" option as viable.
- This allows clones of the repo to remain proper clones with identical history.
- It also shows contributions more directly, keeps
blame intact, and avoids commits with huge diffs.
Because I'm so opinionated, and because I want to preserve the history of some major developments that are very soon to merge (#70, #83), I went ahead and disabled the PR options squash and rebase in the settings of this repo. Please forgive me 🥺 Comments welcome! 😄
More infos
The lack of fast-forward support is well documented at least since 2020 and although the GitHub REST API apparently supports fast-forward since 2014, it seems unlikely GitHub is going to add it to their UI. Frustrating but true.
Cleaning branches
Mind you, I think we should not confuse these PR merge options with a method to keep the repo's history clean. This I would prefer to delegate to the authors of the PRs.
Branches are cheap and are allowed to live shortly, so use it to:
- rebase your work onto a recent
develop to update branches, and
- squash your own commits to reduce clutter, and
- resolve merge conflicts before the actual merge-commit issued by GitHub
(doing the above, this merge should now have been a fast-forward, but GitHub refuses)
List of squashed commits
Some of these are massive.
$ git log --oneline develop |grep '(\#[0-9]\+)'
Produces:
Problem
I noticed that:
This is messy. Could we stick to one method?
Also, can we not rewrite history if not explicitly intended?
Solution
Based on some minor discussion in SimDB-Dashboard where some of us find it sad to see history erased or altered, GitHub leaves us only the "merge commits" option as viable.
blameintact, and avoids commits with huge diffs.Because I'm so opinionated, and because I want to preserve the history of some major developments that are very soon to merge (#70, #83), I went ahead and disabled the PR options squash and rebase in the settings of this repo. Please forgive me 🥺 Comments welcome! 😄
More infos
The lack of fast-forward support is well documented at least since 2020 and although the GitHub REST API apparently supports fast-forward since 2014, it seems unlikely GitHub is going to add it to their UI. Frustrating but true.
Cleaning branches
Mind you, I think we should not confuse these PR merge options with a method to keep the repo's history clean. This I would prefer to delegate to the authors of the PRs.
Branches are cheap and are allowed to live shortly, so use it to:
developto update branches, and(doing the above, this merge should now have been a fast-forward, but GitHub refuses)
List of squashed commits
Some of these are massive.
Produces: