Add a section 0 explaining which commit to base patches on. Rewrite a
couple of paragraphs about signing off patches to reflect Junio's
updated preferences.
From: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
Documentation/SubmittingPatches | 52 ++++++++++++++++++++++++++++++--------
1 files changed, 41 insertions(+), 11 deletions(-)
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index abc65de..a90155c 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -53,6 +53,37 @@ But the patch submission requirements are a lot more relaxed
here on the technical/contents front, because the core GIT is
thousand times smaller ;-). So here is only the relevant bits.
+(0) Decide what to base your work on.
+
+The general principle is always to base your work on the oldest branch
+that your change is relevant to.
+
+ - A fix for a bug that has been with git from older releases should be
+ included in both the upcoming feature release and the current
+ maintenance release. Try to base your work on the 'maint' branch. A
+ work to kill a bug that is in 'master' but not in 'maint' should be
+ based on 'master'.
+
+ - A fix for a bug that is not yet in 'master' is the best bug to kill.
+ If you can find the topic that introduces the regression, base your
+ work on the tip of the topic. "log --first-parent master..pu" would be
+ a good way to find the tips of topic branches.
+
+ - A new feature should be based on the 'master' branch in general.
+
+ - If your new feature depends on some other topics that are not in
+ 'master' yet, and if it relies only on one topic, base your work on the
+ tip of that topic. If it depends on too many topics that are not in
+ 'master', you can privately start working on 'next' or even 'pu' and
+ send out your patches for discussion, but it is possible that your
+ maintainer may ask you to wait and rebase your ...
