svn commit: r921813 - in /websites/staging/accumulo/trunk/content: ./ git.html

[bu...@apache.org]

Author: buildbot
Date: Thu Sep 11 00:41:19 2014
New Revision: 921813

Log:
Staging update by buildbot for accumulo

Modified:
    websites/staging/accumulo/trunk/content/   (props changed)
    websites/staging/accumulo/trunk/content/git.html

Propchange: websites/staging/accumulo/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Thu Sep 11 00:41:19 2014
@@ -1 +1 @@
-1624173
+1624175

Modified: websites/staging/accumulo/trunk/content/git.html
==============================================================================
--- websites/staging/accumulo/trunk/content/git.html (original)
+++ websites/staging/accumulo/trunk/content/git.html Thu Sep 11 00:41:19 2014
@@ -195,12 +195,7 @@ Latest 1.5 release: <strong>1.5.1</stron
     <p><a href="http://git-scm.com">Git</a> is an open source, distributed version control system
 which has become very popular in large, complicated software projects due to
 its efficient handling of multiple, simultaneously and independently developed
-branches of source code.</p>
-<h1 id="the-plan">The plan</h1>
-<p>There are multiple steps that are required of us to fully transition from
-active development against Subversion to Git. Each of these requires consensus
-(lazy or not) from the team along with documentation that developers, both
-existing and current, can reference to understand how and what to do.</p>
+branches of source code.\</p>
 <h2 id="workflow-background">Workflow Background</h2>
 <p>Likely the most contested subject matter regarding switching an active team
 from one SCM tool to another is a shift in the development paradigm.</p>
@@ -383,7 +378,8 @@ Committers should verify that the contri
 Contribution under the <a href="http://www.apache.org/licenses/LICENSE-2.0.txt">Apache License</a>.
 When pulling the code, committers should also verify that the commits pulled match the 
 list of commits sent to the Accumulo dev list in the pull request.</p>
-<p><strong>Patches</strong> -- Developers should use the following steps to apply patches from
+<h4 id="patches">Patches</h4>
+<p>Developers should use the following steps to apply patches from
 contributors:</p>
 <ol>
 <li>
@@ -411,7 +407,8 @@ contributors:</p>
 <p><code>git checkout master &amp;&amp; git merge 1.5.1-SNAPSHOT</code></p>
 </li>
 </ol>
-<p><strong>Pull-Requests</strong> -- If the contributor submits a repository and branch to pull
+<h4 id="pull-requests">Pull-Requests</h4>
+<p>If the contributor submits a repository and branch to pull
 from, the steps are even easier:</p>
 <ol>
 <li>
@@ -435,7 +432,10 @@ from, the steps are even easier:</p>
 contributor to update their branch to avoid the conflict resolution and merge
 commit. See the <a href="http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging">Git
 manual</a>
-for more information on merging.</p>
+for more information on merging. When merging a pull-request, it's best to <strong>not</strong>
+include a signoff on the commit(s) as it changes the final commit ID in the
+Accumulo repository. This also has the negative of not automatically closing
+the Pull-Request when the changes are made public.</p>
 <h3 id="feature-branches">Feature Branches</h3>
 <p>Ease in creating and using feature branches is a desirable merit which Git
 provides with little work. Feature branches are a great way in which developers