Working with Contributors modified by Dave Brondsema

Dave Brondsema — Fri, 13 Sep 2013 15:45:28 -0000

Working with Contributors

Pull Requests

When a contributor forks Allura, commits to their fork, and then sends you a pull request (whether formal or not), you will probably want to work with their commits in your local work tree. To do this, the easy path is to add a temporary remote. For example, let's say Jamey Owens has forked allura and has some commits on his dev. From your local repo you would

git remote add jo git://git.code.sf.net/u/jowens81/alluraj

jo is the name of the remote, and the path to fetch is from the clone command on Jamey's fork page.

git fetch jo

Now you can look at Jamey's code by examining jo/dev. Check it out directly to a detached head, or make a local branch:

git checkout -b jo/dev jo/dev
# or perhaps for John Hoffmann if he intended to work on sandbox
git checkout -b jwh/jo/dev jo/dev

That command checks out a local branch refs/heads/jo/dev tracking the remote branch refs/remotes/jo/dev. Because we have constraints on origin for what branches you can push, delete, or rebase, you'll want to either name the branch as in the alternative above, or else push to a workable name at origin, e.g., for Dave Brondsema:

git push origin jo/dev:db/jo/dev

When the code passes review and testing, you merge to dev as usual and then delete the remote:

git remote rm jo

Patches by Mail

Commits exported via git format-patch can be sent through email. Save the patches to a file or files and apply them with

git am the-patch-file

This is the preferred way to get patches by email as they contain full commits with authorship, sign-off, and commit messages retained. Patches generated with git diff contain none of this and won't make a commit object when applied with git apply.

Recent changes to Working with Contributors

Working with Contributors modified by Dave Brondsema

Working with Contributors

Pull Requests

Patches by Mail