Late reply to this, but I favor the git branch approach as you suggest. It is already a dependency, so why not use it for its intended purpose?
The great thing about a branch is that it is easy to use the version the patch is for, and update as desired. The tools to manage the use cases around a patch are already built into git. Remember, git was originally created to solve the problem of concurrently managing many large patch sets from distributed sources. Isn't that the problem here? > On Jun 15, 2016, at 1:24 AM, Kamil Cholewiński <[email protected]> wrote: > >> On Wed, 15 Jun 2016, David Phillips <[email protected]> wrote: >> Some people thought it was a good idea to use 6.1 to denote git head before >> 6.1 actually came out. This worked fine until they stopped maintaining >> their patches to apply against git head. >> >> Something should be done about the patches that no longer apply cleanly, >> however. > > Keep the "supported" patches as commits on separate branches in the > official git repo? > > - Pretty obvious which commit is the patch derived from, +1 > - Quite easy to rebase a patch to latest master, +1 > - Are git branches considered suckless though? :) > > K. >
