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
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.