[rom1v]

Maintaining 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.

[hiddew]

> 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]

Merging 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.

[kijin]

It 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]

Agreed, and in the wild I've indeed seen rebasing used significantly more often than merges for this purpose.