I have _no_ experience using patches (in git or otherwise) to manage
change control, ie. git-am, git-format-patch, etc., as of yet...
That being said, FWIW, here is a suggestion based on the following
assumptions:
a. It sounds like Pd and Pd-extended only get merged once-in-a-while
(infrequently).
b. Pd is the main version in use, and Pd-extended is a future version
or a not-yet-widely-used version.
c. Pd-extended is based on Pd, but since the inception of Pd-extended
both Pd and Pd-extended have advanced (diverged).
Assuming that is the case, this is similar to what our shop does. We
have a production system X12 and a new system X13 that is based on X12.
Periodically, bugfixes and enhancements from X12 need to be merged
into X13. Here's how we do it:
1. Identify the range of commits in X12 that are not yet in X13 (new
X12 commits since the last X12-X13 merge):
$ git log
sha1-of-last-X12-commit-alreadyMERGED-into-X13..sha1-of-newest-X12-commit-you-want-MERGED-into-X13
--format="%h%d %s"
>/somepath/whereIkeepstuff/X12-X13-MRG.01-REBASE-TO-DO.lst
2. Identify any commits in the X12 commits that you do not want merged
into X13.
3. Create a throw-away-integration-branch which is a copy of X12:
$ git checkout X12
$ git branch X12-Squash
4. Create a throw-away-integration-branch which is a copy of X13:
$ git checkout X13
$ git checkout X13-Merge-X12
5. Squash the X12 merge series into a single commit:
$ git checkout X12-Squash
$ git reset --hard sha1-of-newest-X12-commit-you-want-MERGED-into-X13
(in case its not the head commit of the branch)
$ git rebase -i sha1-of-last-X12-commit-alreadyMERGED-into-X13
(interactive rebase to squash the X12 "new commits" series)
#comment out any commits that you don't want in X13, if applicable.
put an "s" next to all the other commits to squash them.
6. Cherry pick the X12 squashed commit onto X13:
$ git checkout X13-Merge-X12
$ git cherry-pick --edit X12-Squash
resolve any conflicts
review what got ...