4 ms·
Maybe create a `new-master` branch with the offending commits rebased out; then automation to cherry-pick new commits between `master` to `new-master`. Or chan
by tln 8y ago
Maybe create a `new-master` branch with the offending commits rebased out; then automation to cherry-pick new commits between `master` to `new-master`.
Or change all CI / dev docs to use `--depth`, and save more than 350MB per checkout in the process.
- WorldMaker 8y agoThe rebasing approach is effectively what solutions like BFG and git filter-branch automate. It's dangerous to do whole branch rebases, especially with 350 developers that you can't tell to stop working while you do it, that way lies a merge hell that can take years to dig out of. But if you are going to rebase an entire branch like that, BFG and git filter-branch are faster and easier than a manual rebase. `--depth` is a useful tool. There are still some issues with things like log/blame/annotate in working with more shallow clones. It's hopeful that the work on the commit-graph cache will help make this a lot better.
- tln 8y agoSure, so BFG/filter-branch/rebase on a NEW branch, that can't affect existing developers, then automate cherry-picking `master` <=> `new-master`, get all developers to switch at their own pace... Good point on log/blame/annotate.
- WorldMaker 8y ago"automate cherry-picking" is where I feel the migraine starts in git. I've seen three-way merge hell and it starts with something like that.