A Github pull request actually facilitate most of the requirements that you have mentioned. Even if you do not use the Github's merge capability.
Creating a pull request on Github will update the corresponding JIRA with the following sample information ====================================== GitHub user adityakishore opened a pull request: https://github.com/apache/incubator-drill/pull/36 DRILL-452 <https://issues.apache.org/jira/browse/DRILL-452>: Conversion functions for external data types https://reviews.apache.org/r/19723/ You can merge this pull request into a Git repository by running: ======> $ git pull https://github.com/adityakishore/incubator-drill DRILL-452 <https://issues.apache.org/jira/browse/DRILL-452>-Conversion-functions-for-external-data-types Alternatively you can review and apply these changes as the patch at: ======> https://github.com/apache/incubator-drill/pull/36.patch ====================================== So you have link to the patch in Git's "format-patch" format and the exact command to merge the pull request to the your local repository. That leaves two important responsibilities with the contributor. 1. Squash and push multiple commits pertaining to the single issue as one single commit with message in the prescribed format. 2. Keep it rebased to the head of the master branch so that a clean merge is possible. On Sat, Mar 29, 2014 at 3:05 PM, Jacques Nadeau <[email protected]> wrote: > I want to make a couple requests for people generating patches. First, I'm > finding pull-requests less efficient than patch files. This is because I > can't use GitHub's merge capabilities. Given everything that is going on > right now, I would find it helpful if we stick with patch files. > > My second request would be for everyone to work on using the same tools and > format to generate patch files and commits. This would be my preferred > process. The more people stick to this, the faster we'll be able to review > and merge outstanding patches. > > - A patch you post should be based on a single commit. > - If you are basing it on multiple commits, please do a branch > rebase > -i squash before submitting the patch. > - A patch should have a commit message of the format: "DRILL-XXX: > message here." > - Prepare your patch using git format-patch > > If you follow these steps, we can import your patches directly as commits, > keeping the commit log accurate and avoiding a bunch of small but extra > work. > > I've made small updates to the wiki around these items. If someone wanted > to expound there on this, that would be great. > > thanks, > Jacques >
