Patch oriented workflow

[ddimtirov]

PAtches are lowest common denominator when collaborating on codebases. While modern repository managers provide a nice workflow with Pull Requests, a number of use-cases are still better addressed by patches.

I would like that we have an option that we can request that Git Proxy would send a patch of the approved changes to a designated external address.

The way I propose to implement it is that a company can setup an internal mirror of an upstream codebase, and use GitProxy to manage contributions to it. When a contribution is approved, instead of applying the commit, GitProxy would sign the patch and email it to all contributors + fixed mailing list for audit purposes (possibly informed by the CODEOWNERS file).

As user experience I see it as an option where on approval one can select whether they want to perform the push, forward the patch, or do a push+patch. Permissions can be used to make one of the options unavailable, in which case the choice can be hidden.

Alternatives:

• We could auto-merge the contribution in addition to sending the patch - this would be problematic and lead to merge conflicts in the cases where the patch is modified as result of upstream code review. By releasing the patches, we simplify the process and keep the internal mirror a plain copy of upstream.
• We could have used pull requests (or equivalent) with custom automation and manual processes - being custom-built for OSS review, we hope that GitProxy would allow more tailored workflow and better user experience. It would also be nice to have consistency between projects that we can contribute-to directly, and the patch workflow.

[grovesy]

Sounds good - I actually don't think this would be super hard to achieve.

Git-proxy under the covers pull's the upstream, commits the pak files, then used a git diff. There is a PR coming which implement some emailing workflow, we could extend these two do the above.

Would be interested how you would see this in the configuration for a repository - i.e. would you enable this at a 'repo' level or a git-proxy installation level.,