Mailing-List: contact commits-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Apache Wiki <wikidiffs@apache.org>
To: Apache Wiki <wikidiffs@apache.org>
Date: Tue, 08 May 2012 08:58:46 -0000
Message-ID: <20120508085846.21398.275@eos.apache.org>
Subject: 
 =?utf-8?q?=5BCouchdb_Wiki=5D_Update_of_=22Merge=5FProcedure=22_by_RobertN?=
 =?utf-8?q?ewson?=
Auto-Submitted: auto-generated

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Couchdb Wiki" for c=
hange notification.

The "Merge_Procedure" page has been changed by RobertNewson:
http://wiki.apache.org/couchdb/Merge_Procedure?action=3Ddiff&rev1=3D8&rev2=
=3D9

Comment:
some details on git handling

  If the ticket was COUCHDB-1234, and the ticket title was My Cool Feature,=
 your branch should be called `1234-cool`.
  =

  =3D=3D Git Best Practice =3D=3D
+ =

+ Developers are free to use a feature branch in any way they see fit durin=
g development. Prior to submitting a merge request to dev@, though, the bra=
nch should be prepared according to the following rules, as the commits on =
the feature branch will be a permanent part of the couchdb project's histor=
y.
+ =

+ A feature branch should consist of the smallest number of meaningful comm=
its as possible. For bug fixes and small features, this is likely to be a s=
ingle commit. For larger changes, multiple commits might be necessary. The =
guiding principle for deciding how many commits is coherence. A commit shou=
ld be readable and, ideally, implement one distinct idea. A feature that re=
quires multiple enhancements to achieve its goal should be presented as mul=
tiple commits. It is *not* necessary for the system to pass the test suite =
for any subset of these commits, only their combination.
+ =

  =

  '''@@ BOB, PLEASE LET ME KNOW IF YOU WANT A DIAGRAM MAKING FOR THIS SECTI=
ON.'''
  =

@@ -155, +160 @@

  =

  Follow these instructions to merge a feature in to one release branch.
  =

- '''@@ BOB, PLEASE CREATE IN A LIST OF INSTRUCTIONS, INCLUDING COPY AND PA=
STE GIT COMMANDS, HERE.'''
+ Feature branches are merged to release branches using 'git merge --no-ff =
<FEATURE BRANCH>'. This guarantees a merge commit, which are the only kinds=
 of commit that will appear on release branches. If the merge results in co=
nflicts, the release manager rejects the merge commit with an reply to the =
dev@ thread. If the merge is successful, the release manager should run 'ma=
ke distcheck' and push the merge upstream if the tests pass. =

  =

  =3D=3D Bugfix =3D=3D
  =

  Follow these instructions to merge a bugfix in to multiple release branch=
es.
  =

- '''@@ BOB, PLEASE CREATE A LIST OF INSTRUCTIONS, INCLUDING COPY AND PASTE=
 GIT COMMANDS, HERE.'''
+ For each release branch, 'git checkout <RELEASE BRANCH>' and 'git merge -=
-no-ff <BUGFIX BRANCH>'. If any of the merges fail, the merge request is re=
jected.
  =

  =3D=3D Security =3D=3D
  =

@@ -169, +174 @@

  =

  (Security fixes can be merged in to supported release branches just like =
bugfixes.)
  =

- '''@@ BOB, PLEASE CREATE A LIST OF INSTRUCTIONS, INCLUDING COPY AND PASTE=
 GIT COMMANDS, HERE.'''
-=20