Merge branch 'maint'

1 files changed, 28 insertions, 0 deletions

diff --git a/HACKING b/HACKING
index a4c918a73..ad0ae4956 100644
--- 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