5 ms·
The post considers rebasing the fork. It seems easier to do only merges. You can merge specific upstream commits, or the entire upstream branch. That way you on
by hiddew 2y ago
The post considers rebasing the fork. It seems easier to do only merges. You can merge specific upstream commits, or the entire upstream branch. That way you only need to merge in the changes, and not resolve the same conflicts for each downstream commit, every time the upstream is changed.
- rom1v 2y agoMaintaining a fork by merging upstream into downstream branches would be a mess: upstream and downstream code would be totally entangled, there would no clean way to edit/remove/reorder downstream commits. You can't easily know what you actually changed (not the full diff, but each "atomic" clean change). The way the author suggests is way cleaner IMO.
- kijin 2y agoIt depends on whether the downstream only ever consumes upstream changes, or also often contributes changes to upstream. Rebasing in both directions can result in a messy history, too, especially if upstream isn't very careful in how it accepts pull requests.
- dezgeg 2y agoAgreed, and in the wild I've indeed seen rebasing used significantly more often than merges for this purpose.
- hiddew 2y ago> there would no clean way to edit/remove/reorder downstream commits Yes, but I consider commits immutable so reordering or editing commits is not a thing that would happen. New commits are appended (either upstream or downstream), and any conflicting changes then of course have to be merged from upstream into downstream.
- keybored 2y agoMerging seems easier? With merging you can get a definite answer about which commits are where. With rebase you’re dealing with changes/patches so the answer is less clear. But it might be cleaner (for some definition of clean) to have a for which is just N commits on top of the upstream. Which is then rebased periodically.
- argulane 2y agoIt's bit hidden but once you enable `git rerere`, it will remember your fixed up rebase conflicts. https://git-scm.com/book/en/v2/Git-Tools-Rerere https://git-scm.com/book/en/v2/Git-Tools-Rerere
- xrisk 2y agoWow this is super neat. I wonder why it isn’t enabled by default.
- keybored 2y agoI think both are done for long-term forks. Since both are done we can surmise that both are practical. I suspect that rebase-forks are more common historically. Because the only thing I’ve heard of when it comes to managing changes on top of a version control system (which could be centralized) are “patch queues” or stacks. And those tend to be rebase systems with a different system. But I have no practical experience with long-lived forks.