That way seems reasonable and should work. The only negative, and I use the term loosely, is the continuous addition of remotes as new contributors provide submissions (certainly a nice problem to have!). There are a few other ways you can tackle this to combat adding a remote for each user that may come along, and I'll list two I've encountered as a quick reference:
* Grabbing a patch file: You are able to append .patch onto any pull request URL to get a patch file that you can apply in the fashion to which you are accustomed. [1] * Getting PRs directly from Github via [2] or [3] I primarily use the method of [2] myself. There are some caveats about how this functions in general listed in the comments, but for the case of working with NiFi and treating github as another remote, has been a pretty streamlined process for me. [3] is mechanically quite similar to [2], but does a full path to the PR in the remote. [1] https://github.com/blog/967-github-secrets#diff-patch [2] https://gist.github.com/piscisaureus/3342247 [3] https://help.github.com/articles/checking-out-pull-requests-locally/#modifying-an-inactive-pull-request-locally On Mon, Oct 12, 2015 at 10:36 AM, dan bress <[email protected]> wrote: > Whoops, step 5 should be > 5) mvn clean install -Pcontrib-check > > On Mon, Oct 12, 2015 at 10:00 AM dan bress <[email protected]> wrote: > > > Apache NiFi Committers, > > I am working on fulfilling a pull request(NIFI-774), and wanted to > make > > sure I am doing it right. > > > > These are the steps that I plan on following > > > > 1) git remote add yu https://github.com/yu-iskw/nifi.git > > 2) git pull yu > > 3) git checkout master > > 4) git merge --no-ff yu/NIFI-774 > > 5) clean install install -Pcontrib-check > > 6) double check code and inspect release > > 7) git push origin > > > > How does that sound to you guys? > > > > Thanks, > > Dan > > >
