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 && 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
