Autogenerated HTML docs for v2.35.1-193-g45fe28

1 files changed, 41 insertions, 1 deletions

diff --git a/SubmittingPatches.html b/SubmittingPatches.html
index 6059fa646..1abae96bc 100644
--- a/SubmittingPatches.html
+++ b/SubmittingPatches.html
@@ -849,6 +849,41 @@ run <code>git diff --check</code> on your changes before you commit.</p></div>
 </div>

 <div class="sect2">

 <h3 id="describe-changes">Describe your changes well.</h3>

+<div class="paragraph"><p>The log message that explains your changes is just as important as the

+changes themselves.  Your code may be clearly written with in-code

+comment to sufficiently explain how it works with the surrounding

+code, but those who need to fix or enhance your code in the future

+will need to know <em>why</em> your code does what it does, for a few

+reasons:</p></div>

+<div class="olist arabic"><ol class="arabic">

+<li>

+<p>

+Your code may be doing something differently from what you wanted it

+  to do.  Writing down what you actually wanted to achieve will help

+  them fix your code and make it do what it should have been doing

+  (also, you often discover your own bugs yourself, while writing the

+  log message to summarize the thought behind it).

+</p>

+</li>

+<li>

+<p>

+Your code may be doing things that were only necessary for your

+  immediate needs (e.g. "do X to directories" without implementing or

+  even designing what is to be done on files).  Writing down why you

+  excluded what the code does not do will help guide future developers.

+  Writing down "we do X to directories, because directories have

+  characteristic Y" would help them infer "oh, files also have the same

+  characteristic Y, so perhaps doing X to them would also make sense?".

+  Saying "we don&#8217;t do the same X to files, because &#8230;" will help them

+  decide if the reasoning is sound (in which case they do not waste

+  time extending your code to cover files), or reason differently (in

+  which case, they can explain why they extend your code to cover

+  files, too).

+</p>

+</li>

+</ol></div>

+<div class="paragraph"><p>The goal of your log message is to convey the <em>why</em> behind your

+change to help future developers.</p></div>

 <div class="paragraph"><p>The first line of the commit message should be a short description (50

 characters is the soft limit, see DISCUSSION in <a href="git-commit.html">git-commit(1)</a>),

 and should skip the full stop.  It is also conventional in most cases to

@@ -895,6 +930,11 @@ alternate solutions considered but discarded, if any.
 </p>

 </li>

 </ol></div>

+<div class="paragraph" id="present-tense"><p>The problem statement that describes the status quo is written in the

+present tense.  Write "The code does X when it is given input Y",

+instead of "The code used to do Y when given input X".  You do not

+have to say "Currently"---the status quo in the problem statement is

+about the code <em>without</em> your change, by project convention.</p></div>

 <div class="paragraph" id="imperative-mood"><p>Describe your changes in imperative mood, e.g. "make xyzzy do frotz"

 instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy

 to do frotz", as if you are giving orders to the codebase to change

@@ -1399,7 +1439,7 @@ this problem around.</p></div>
 <div id="footer">

 <div id="footer-text">

 Last updated

- 2022-01-24 10:08:26 PST

+ 2022-02-16 17:29:13 PST

 </div>

 </div>

 </body>