Here's the problem and how we currently manage this at work.We have a buildout recipe that fetch multiple git repositories. Sometimes, it is necessary to patch a module from a repository that we don't own (public repository). At my previous position in a different company, we used to fork all the public repository and push patches in different branches. This work well but in some cases, it's much harder to maintain and sometimes, patches are really specific to a particular client so it becomes hard to understand which branches are relevant and forking 50+ repositories isn't particularly easy to manage if you have to give permission to push to developers. At the same time, we managed patch files that could be applied directly without forking any repository.At my current job, I decided to limit myself to patch files because it simplify the process. Technically applying a patch and merging a branch is pretty much the same thing.Patch are stored on a per client repository and applied in the build process. Since with fetch multiple repositories, some patch are to be applied on projectA and some other on projectB ... Right now, I'm writing every single patch that needs to be applied in the build config file but I was wondering if there was a way to make it less coupled witht the configuration.Like instead of applying a patch, I'd apply a patch set that would be more close to a merge that can apply multiple commit. But the patch set should be able to apply patches in multiple directories/repositories. Patch are usually made for the particular repository using git format patch.
Patch management in a multi repository environment
git;build system;patch
For the similar scenario we used a Quilt tool - patch set management utility: https://wiki.debian.org/UsingQuiltBasically you have a patches directory in the root of your project which contains several independent patches, managed by the quilt. Patch dir could look like this:patches/100_asserts.diffpatches/101_terminate_call.diffpatches/102_status_code477.diffpatches/107_parser.diffpatches/110_ssldefault.diffPatches are applied sequentially (quilt push), can be unapplied (quilt pop),  updated (quilt refresh) and so on. It makes sense to separate patches to files according to their logic. In the situation with more repositories you can create a new wrapping git repo with dependencies as git submodules.patches/  <-- patches repo01, repo02repo01/   <-- git submodulerepo02/   <-- git submoduleIn this example, the patches directory is managed by git.In the single repository use-case we used to fork the repository, add the patches dir and maintain the patches in the same repository. Updating is also doable by: pop-ing all patches by quilt pop -a, git pull, quilt push patch one by one, resolve conflict if needed, usually quilt refresh does the job.There are also tools that directly integrates with git: http://repo.or.cz/guilt.githttps://github.com/jeffpc/guilt