One can imagine applying a series of patches as a rebase operation of a “virtual” branch, with the resulting ephemeral branch being thrown away after the build.

One can imagine applying a series of patches as a rebase operation of a “virtual” branch, with the resulting ephemeral branch being thrown away after the build. So the only real difference is that one stores the changes to be rebased as part of the main repo vs the repo of a forked dependency. As a result of that one loses the existing tooling aimed at merge/rebase management (git rerere, git rebase -i) Thus - if the part of the code base being patched is relatively unchanging, this is a nice shortcut. But if it is part of actively changed code, explicitly managing what is essentially a fork in disguise may be more convenient.