Mostly copied from a conversation on sr.ht-discuss 0.
Currently, patchsets sent to lists are assumed to apply directly to trunk, and builds will attempt to do so.
This doesn't really work when you have patchsets that depend on other patchsets, e.g. if you're working on a large, complex feature that requires multiple patchsets each containing multiple commits.
GitHub fails miserably at this, forcing contributors to make multiple pull-requests out of the same branch (which makes review difficult as commits of the earlier PR's show up in the later PR's as well), or give up and make one massive monster PR.
Phabricator handles this well by allowing each Revision (patchset) to specify which ones it depends upon.
It would be great to have a way to mark a patchset as depending on another one, and builds would apply all of the prerequisite patchsets before applying the current one for testing.
Fortunately, @emersion pointed out on IRC that Git already has a built-in feature called the "Base Tree Information" 1 whereby you send along with a given patch the public ancestor commit hash, plus the "patch id's" of all the dependencies. Patch-ID's are simply a hashed form of the patch contents.
It would be cool if lists and builds could make use of this to implement dependencies between patches.