svn commit: r1491677 - /accumulo/site/branches/git/content/git.mdtext

[el...@apache.org]

Author: elserj
Date: Tue Jun 11 02:31:41 2013
New Revision: 1491677

URL: http://svn.apache.org/r1491677
Log:
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

Modified: accumulo/site/branches/git/content/git.mdtext
URL: http://svn.apache.org/viewvc/accumulo/site/branches/git/content/git.mdtext?rev=1491677&r1=1491676&r2=1491677&view=diff
==============================================================================
--- 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 user.name 'My Name'`
-    `git config --global user.email 'myname@mydomain.com'`
+    `git config --global user.name 'My Name' && git config --global user.email 'myname@mydomain.com'`
 
 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](https://github.com/apache/accumulo). Pull-requests from Github should
-automatically be sent to [dev@accumulo.apache.org](mailto:dev@accumulo.apache.org).
+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://github.com/<username>/accumulo.git branch=ACCUMULO-12345
+
+A second alternative is to use Github's "Pull Requests" feature against the [Apache Accumulo
+account](https://github.com/apache/accumulo). Notifications of new pull-requests
+from Github should automatically be sent to
+[dev@accumulo.apache.org](mailto:dev@accumulo.apache.org).
+
+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
+manual](http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging)
+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