Page tree
Skip to end of metadata
Go to start of metadata

The ASF INFRA team maintains a mirror of our git repository over on GitHub. That mirror is strictly one-way: changes from the Apache git get copied over, but not the other way around. Further, the mirror on GitHub is read-only for everyone. Which means we can neither accept nor close pull requests filled there via the GitHub web UI. However, we want to allow for contributions via GitHub Pull Requests. Here's how:

Add the ASF git repository

See this guide.

Merge changes

The next step is to merge all changes on the Pull Request as a single commit. There are two methods here: (A) pull the branch from the GitHub Pull Request and squash commits, or (B) get the .diff from GitHub and manually create a commit from this information. Each option has its pros and cons. With method A, git does some of the tedious work of preserving commit messages; but in some cases the squash may not apply cleanly, and the merger will have to carefully resolve conflicts. With method B, the .diff will apply cleanly (given that the branch is up-to-date, i.e. the GitHub GUI states that the "This pull request can be automatically merged by project collaborators"); but the merger will have to carefully copy over commit messages and edit author information.

Check the commit message

See this guide for what to look for.

Resolving issue vs Closing issue

The last step of merging a pull request is resolving the associated issue. Committer should resolve it, provide the current release number (the latest unreleased version) in "Fix version" field and provide a link to the pull request in the comment.

Issue should be closed only if no productive steps were taken for it, i.e. it is "won't fix" or "duplicate" or "contained by". If some work was done but it doesn't have pull request associated with it, the issue should be resolved by the person who did the work.

Method A

PowerShell setup instructions contain functions which wrap the following actions and make committer's life easier.

A-1. Create a branch on your local git repository

You want to make sure that that branch is current with the the master branch on Apache git:

This assumes that you called the remote git repository at the ASF "apache". You can name the branch however you want, but it is customary to name them either after the pull request number or the JIRA id, e.g. REEF-24.

A-2. Pull the contribution into that branch

This is as simple as

However, the GitHub web ui makes it somewhat hard to get these two strings. The email from GitHub that informs us of Pull Requests makes this really obvious, though. Consider this quote from pull request #10:

You can merge this Pull Request by running

  git pull juwang-logfactory

This copies the changes from the given remote branch into the one we just created locally.

A-3. Check the pull request

  1. Make sure the code compiles and all tests pass.
    1. If the pull request changes any POM.xml file: Please either clean your local maven repository before testing OR wait for the build servers to confirm that the project builds. This is to avoid situations in which an artifact was renamed or removed but is still in your local maven repository.
    2. Test java code

    3. Test .Net code

  2. If the code touches code that you suspect might break on YARN or Mesos, please test on those environments. If you don't have access to a test environment, ask on the mailing list for help.

  3. Make sure the code adheres to our coding guidelines.

  4. Make sure that the additions don't create errors in a Apache RAT check via mvn apache-rat:check

A-4. Rebase the branch onto current apache master

In the rebase process, make sure that the contribution is squashed to a single commit. From the list of commits, "pick" the commit in the first line (the oldest), and "squash" the commits in the remaining lines:

Chapter 3 and Chapter 7 of the Git Book contains lots of information on what this means.

Please make sure that the commit message contains the information given in "Commit Message" above. The latest commit can be changed at any time with the command:

A-5. Push the code into apache's git

This is a good time to reflect back on this change and whether it is likely to break the build. If you are certain that it won't, go ahead and do:

This pushes the current branch into the master branch hosted on Apache's git repository. From there, it will be mirrored onto GitHub. And by virtue of the comment added above to the commit message, GitHub will now close the Pull Request.

Method B

B-1. Update local master

In this method, you will work directly on your local master branch. Make sure you have the latest changes on your local master branch, by running:

B-2. Download the .diff and apply it

You can download the .diff file by appending .diff to the GitHub Pull Request url. This file will contain the exact changes that are shown in "Files changed" in the GitHub GUI. For example, for the .diff file is Using this url, run apply: 

B-3. Commit and edit author information

Commit all files, making sure to include all modified and new files. In the commit message, make sure to include all information given in "Commit Message" above. After committing you must also change the author information to reflect the original author (and not yourself):

B-4. Push the code into apache's git

Now push your single commit to apache git:

This pushes the current branch into the master branch hosted on Apache's git repository. From there, it will be mirrored onto GitHub. And by virtue of the comment added above to the commit message, GitHub will now close the Pull Request.

  • No labels