Add example git work flow; discuss merge --log in HACKING.

* HACKING: Update.
Suggestion by Stefano Lattarini.

Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>

diff --git a/ChangeLog b/ChangeLog
index 0ea44a4..4f96039 100644 (file)
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,9 @@
 2010-07-31  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>
 
+       Add example git work flow; discuss merge --log in HACKING.
+       * HACKING: Update.
+       Suggestion by Stefano Lattarini.
+
        Add more hints for debugging make rules.
        * doc/automake.texi (Debugging Make Rules): Show command to find
        out expanded values of variables; point to makefile debugger.

diff --git a/HACKING b/HACKING
index 8facbeb..f25a0e0 100644 (file)
--- a/HACKING
+++ b/HACKING
@@ -113,6 +113,30 @@
   suitable testing.  It is advisable to merge only after a set of related
   commits have been applied.
 
+* Example work flow for patches to maint:
+
+  # 1. Checkout the "maint" branch:
+  git checkout maint
+
+  # 2. Apply the patch(es) with "git am" (or create them with $EDITOR):
+  git am -3 0*.patch
+  # 2a. Run required tests, if any ...
+
+  # 3. Merge maint into branch-1.11:
+  git checkout branch-1.11
+  git merge maint
+  # 3a. Run required tests, if any ...
+
+  # 4. Redo steps 3 and 3a for master:
+  git checkout master
+  git merge maint
+  # testing ...
+
+  # 5. Push the maint and master branches:
+  git push --dry-run origin maint branch-1.11 master
+  # if all seems ok, then actually push:
+  git push origin maint branch-1.11 master
+
 * For bug fixes of long-standing bugs, it may be useful to commit them to
   a new branch based off of the commit that introduced the bug, and merge
   this bugfix branch into active branches that descend from the buggy commit.
@@ -123,6 +147,10 @@
   common ground for feature merging and testing, should they not be ready
   for master yet.
 
+* For merges from branches other than maint, prefer 'git merge --log' over
+  plain 'git merge', so that a later 'git log' gives an indication of which
+  actual patches were merged even when they don't appear early in the list.
+
 * master and release branches should not be rewound, i.e., should always
   fast-forward, except maybe for privacy issues.  The maint branch should not
   be rewound except maybe after retiring a release branch or a new stable