accumulo-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject svn commit: r1491677 - /accumulo/site/branches/git/content/git.mdtext
Date Tue, 11 Jun 2013 02:31:41 GMT
Author: elserj
Date: Tue Jun 11 02:31:41 2013
New Revision: 1491677

ACCUMULO-1498 Fix some major-release bugs. Lift more things from the Kakfa wiki. Outline patch
and pull-requests for contributors and devs. Clean up the multi-line code blocks that weren't
being properly formatted :(


Modified: accumulo/site/branches/git/content/git.mdtext
--- accumulo/site/branches/git/content/git.mdtext (original)
+++ accumulo/site/branches/git/content/git.mdtext Tue Jun 11 02:31:41 2013
@@ -117,8 +117,7 @@ Jira issue ACCUMULO-12345 that affects 1
 1. Ensure you configured Git with your information
-    `git config --global 'My Name'`
-    `git config --global ''`
+    `git config --global 'My Name' && git config --global ''`
 2. Clone the Accumulo repository:
@@ -149,15 +148,21 @@ to the ACCUMULO-12345 Jira issue.
     `git format-patch 1.5.1-SNAPSHOT --stdout > ACCUMULO-12345.patch`
-In a nutshell, contributors should make their changes against the version in
-which the fix is intended, `git-rebase`'ing their changes against the upstream
-branch so as to keep their changes co-located and free of unnecessary merges.
-The final contribution can be in the form of a git formatted patch (see the
-Kafka workflow linked above), a request to pull changes from a remote+ref, or a
-pull-request from [Apache Accumulo
-on Github]( Pull-requests from Github should
-automatically be sent to [](
+An alternative to creating a patch is submitting a request to pull your
+changes from some repository, e.g. Github. Please include the repository and
+branch name merge in the notice to the Jira issue, e.g.
+    repo=git://<username>/accumulo.git branch=ACCUMULO-12345
+A second alternative is to use Github's "Pull Requests" feature against the [Apache Accumulo
+account]( Notifications of new pull-requests
+from Github should automatically be sent to
+Ignoring specifics, contributors should be sure to make their changes against
+the earlier version in which the fix is intended, `git-rebase`'ing their changes
+against the upstream branch so as to keep their changes co-located and free of
+unnecessary merges.
 ## Developers
@@ -176,8 +181,8 @@ API-compatible improvements and backport
    consider where his/her changes should be applied.
 2. Better ties a branch containing commits for a minor release to Jira issues
    fixed in said minor release.
-3. Others that I'm not thinking of? I think more exist in gigantic 'GIT' thread
-   on dev@a.a.o.
+3. _Others that I'm not thinking of? I think more exist in gigantic 'GIT' thread
+   on dev@a.a.o._
 If said short-lived branch doesn't yet exist, the developer should create said
 branch off of the last minor release in the targeted major version.
@@ -189,6 +194,59 @@ name. It has been suggested to name the 
 releases are named. In other words, the branch just created would be named
 `1.4.4-snapshot` or similar.
+### Reviewing contributor changes
+**Patches** -- Developers should use the following steps to apply patches from contributors:
+1. Checkout the branch which the patch is submitted for:
+    `git checkout 1.5.1-SNAPSHOT`
+2. Verify the changes introduced by the patch:
+    `git apply --stat ACCUMULO-12345.patch`
+3. Verify that the patach applies cleanly:
+    `git apply --check ACCUMULO-12345.patch`
+4. If all is well, apply the patch:
+    `git am --signoff < ACCUMULO-12345.patch`
+5. When finished, push the changes:
+    `git push origin 1.5.1-SNAPSHOT`
+6. Merge where appropriate:
+    `git checkout master && git merge 1.5.1-SNAPSHOT`
+**Pull-Requests** -- If the contributor submits a repository and branch to pull from, the
steps are
+even easier:
+1. Add their repository as a remote to your repository
+    `git remote add some_name ${repository}`
+2. Fetch the refs from the given repository
+    `git fetch ${repository}`
+3. Merge in the given branch to your local branch
+    `git merge some_name/${branch}`
+4. Delete the remote:
+    `git remote remove some_name`
+If the branch doesn't fast-forward merge, you likely want to inform the
+contributor to update their branch to avoid the conflict resolution and merge
+commit. See the [Git
+for more information on merging.
 ### Feature Branches
 Ease in creating and using feature branches is a desirable merit which Git
@@ -242,7 +300,7 @@ The steps to create a new major release 
 named something like `x.y.0-RC-N`.
 3. Test and Vote
 4. Create a tag with the correct final name: `x.y.0`
-5. Push a delete of the remote branch `x.y.z'-SNAPSHOT` (_this should be fine
+5. Push a delete of the remote branch `x.y.0-SNAPSHOT` (_this should be fine
    with ASF policy since the history is still intact_)
 # The infrastructure

View raw message