From 66082eb3a3eea78ca1dd45a61b5ff48a8fe3b081 Mon Sep 17 00:00:00 2001
From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Sat, 1 Mar 2025 12:38:53 +0100
Subject: [PATCH 1/6] update-docs: extract the list of Git project-specific
 manual pages

There are a couple of "manual pages" that are really not interesting to
regular Git users because they affect how to work _with the Git
project_, not how to work _with Git_.

It is somewhat unfortunate (and a clear lack of separation of concerns)
that these are included in what Git's home page calls the "Git
reference".

Note that this has not been the case for a long time! Only with
ea0e16d02 (docs: include SubmittingPatches, 2018-04-16) it changed,
adding a single Git project-specific file to the site.

Since that dam was broken, 44bf76690 (index.rake: build
MyFirstContribution tutorial, 2019-08-14) and later db4e92007 (docs:
render 'MyFirstObjectWalk', 2020-06-07) introduced _further_ pages that
have nothing to do, really, with how to use Git.

In preparation for labeling these pages clearly as specific to the Git
project, let's extract the list of these _special_ pages to a central
location where it can be reused in the Hugo part of the site generation.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 data/docs_extra.yml   |  6 ++++++
 script/update-docs.rb | 22 ++++++++++++++++++----
 2 files changed, 24 insertions(+), 4 deletions(-)
 create mode 100644 data/docs_extra.yml

diff --git a/data/docs_extra.yml b/data/docs_extra.yml
new file mode 100644
index 0000000000..57b9e79378
--- /dev/null
+++ b/data/docs_extra.yml
@@ -0,0 +1,6 @@
+---
+git_project_specific:
+  - MyFirstContribution
+  - MyFirstObjectWalk
+  - SubmittingPatches
+---
diff --git a/script/update-docs.rb b/script/update-docs.rb
index a3b169713c..264d07bd12 100644
--- a/script/update-docs.rb
+++ b/script/update-docs.rb
@@ -13,6 +13,7 @@
 SITE_ROOT = File.join(File.expand_path(File.dirname(__FILE__)), '../')
 DOCS_INDEX_FILE = "#{SITE_ROOT}external/docs/content/docs/_index.html"
 DATA_FILE = "#{SITE_ROOT}external/docs/data/docs.yml"
+DOCS_EXTRA_FILE = "#{SITE_ROOT}data/docs_extra.yml"
 
 def read_data
   if File.exist?(DATA_FILE)
@@ -29,6 +30,20 @@ def read_data
   data
 end
 
+def read_docs_extra
+  if File.exist?(DOCS_EXTRA_FILE)
+    # `permitted_classes` required to allow running with Ruby v3.1
+    docs_extra = YAML.load_file(DOCS_EXTRA_FILE)
+  else
+    docs_extra = {}
+  end
+
+  docs_extra["git_project_specific"] = [] unless docs_extra["git_project_specific"]
+
+  docs_extra
+end
+
+
 def make_asciidoc(content)
   Asciidoctor::Document.new(content,
                             attributes: {
@@ -286,6 +301,7 @@ def index_doc(filter_tags, doc_list, get_content)
   rebuild = ENV.fetch("REBUILD_DOC", nil)
   rerun = ENV["RERUN"] || rebuild || false
 
+  docs_extra = read_docs_extra
   data = read_data
 
   tags = filter_tags.call(rebuild).sort_by { |tag| Version.version_to_num(tag.first[1..]) }
@@ -307,9 +323,6 @@ def index_doc(filter_tags, doc_list, get_content)
     doc_files = tag_files.select do |ent|
       ent.first =~
         /^Documentation\/(
-          SubmittingPatches |
-          MyFirstContribution.txt |
-          MyFirstObjectWalk.txt |
           (
             git.* |
             everyday |
@@ -323,7 +336,8 @@ def index_doc(filter_tags, doc_list, get_content)
             pull.* |
             scalar |
             technical\/.*
-        )\.txt)$/x
+        )\.txt)$/x or
+        docs_extra["git_project_specific"].include?(ent.first.sub(/^Documentation\/(.*?)(\.txt|\.adoc)?$/, '\1'))
     end
 
     puts "Found #{doc_files.size} entries"

From 868e7526af11fa8b43b9f3599f296c07c99ae2f9 Mon Sep 17 00:00:00 2001
From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Sat, 1 Mar 2025 13:17:58 +0100
Subject: [PATCH 2/6] community: offer anchors for all headers

This makes it more convenient to link to, say, the part talking about
contributing to Git.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 content/community/_index.html | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/content/community/_index.html b/content/community/_index.html
index a7ae06dbf2..14c12979df 100644
--- a/content/community/_index.html
+++ b/content/community/_index.html
@@ -8,7 +8,7 @@
 <div id="main">
   <h1> Community</h1>
 
-  <h2> Mailing List</h2>
+  <h2 id="git-mailing-list"><a class="anchor" href="#git-mailing-list"></a> Mailing List</h2>
 
   <p>
     General questions or comments for the Git community can be sent to the mailing list by using the email address <a href="mailto:git@vger.kernel.org">git@vger.kernel.org</a>.
@@ -34,7 +34,7 @@ <h2> Mailing List</h2>
     If you're a downstream packager of Git, consider joining the <a href="https://groups.google.com/forum/?fromgroups#!forum/git-packagers">Git packagers mailing list</a> for low-volume announcements from the developers, as well as other discussion related to packaging &amp; porting Git.
   </p>
 
-  <h2> Bug Reporting </h2>
+  <h2 id="reporting-bugs"><a class="anchor" href="#reporting-bugs"></a> Bug Reporting </h2>
 
   <p>
     Bugs in git can be reported directly to the mailing list (see above for
@@ -68,14 +68,14 @@ <h2> Bug Reporting </h2>
       guide</a> helpful for producing useful bug reports.
   </p>
 
-  <h2> Reporting Security Issues </h2>
+  <h2 id="git-security"><a class="anchor" href="#git-security"></a> Reporting Security Issues </h2>
 
   <p>
     Issues which are security relevant should be disclosed privately to
     the <a href="mailto:git-security@googlegroups.com">Git Security</a> mailing list.
   </p>
 
-  <h2> IRC Channel </h2>
+  <h2 id="irc"><a class="anchor" href="#irc"></a> IRC Channel </h2>
 
   <p>
     If the manpages and this book aren’t enough and you need in-person help, you can try the <span class="highlight fixed">#git</span> channel on the <a href="https://libera.chat/guides/connect">Libera Chat</a> IRC server (<strong>irc.libera.chat</strong>). These channels are regularly filled with hundreds of people who are all very knowledgeable about Git and are often willing to help.
@@ -86,19 +86,19 @@ <h2> IRC Channel </h2>
     If you need specific help about one of the for-profit Git hosting sites, you might try their own IRC channels (such as <span class="highlight fixed">#github</span> or <span class="highlight fixed">#gitlab</span>) on the same IRC server.
   </p>
 
-  <h2> Discord Server </h2>
+  <h2 id="discord"><a class="anchor" href="#discord"></a> Discord Server </h2>
 
   <p>
     The <a href="https://discord.gg/GRFVkzgxRd">Git Community Discord Server</a> also has many knowledgeable and helpful people. Additionally, it provides a space to be able to voice chat about patches, designs, or anything else Git related.
   </p>
 
-  <h2> Newsletter </h2>
+  <h2 id="git-rev-news"><a class="anchor" href="#git-rev-news"></a> Newsletter </h2>
 
   <p>
     There is a monthly community newsletter called <a href="https://git.github.io/rev_news/rev_news/">"Git Rev News"</a>, with <a href="https://git.github.io/rev_news/archive/">its archive</a> and <a href="https://git.github.io/rev_news/">its latest edition</a>. Information on how to subscribe can be found on the <a href="https://git.github.io/rev_news/rev_news/">dedicated webpage</a>.
   </p>
 
-  <h2> Contributing to Git </h2>
+  <h2 id="contributing"><a class="anchor" href="#contributing"></a> Contributing to Git </h2>
 
   <p>
     The <a href="https://github.com/git/git/tree/master/Documentation">Documentation directory</a> in the Git source code has several files of interest to developers who are looking to help contribute. After reading the <a href="https://github.com/git/git/blob/master/Documentation/CodingGuidelines">coding guidelines</a> and <a href="https://github.com/git/git/blob/master/CODE_OF_CONDUCT.md">code of conduct</a>, you can learn <a href="{{< relurl "docs/SubmittingPatches" >}}">how to submit patches</a>. If you are just starting out, you can read the <a href="{{< relurl "docs/MyFirstContribution" >}}">My First Contribution tutorial</a>. For those looking to get more deeply involved, there is a <a href="https://github.com/git/git/blob/master/Documentation/howto/maintain-git.txt">howto for Git maintainers</a>.

From dca936dcdf1a5b6a47cfcaa948ab87b0e8f4248f Mon Sep 17 00:00:00 2001
From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Sat, 1 Mar 2025 12:56:00 +0100
Subject: [PATCH 3/6] docs: mark Git project-specific pages clearly

This adds a callout at the top of the pages that are irrelevant to all
Git users except the ones who wish to contribute to the Git project
itself. There are only very few of them, anyway (about to be a few
more), but it is a good idea to ensure that readers are not confused
into believing that they have to follow the Git project's coding
guidelines if they want to use Git.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 layouts/_default/baseof.html | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/layouts/_default/baseof.html b/layouts/_default/baseof.html
index 300f8881f3..1ddbd1fbe1 100644
--- a/layouts/_default/baseof.html
+++ b/layouts/_default/baseof.html
@@ -117,6 +117,12 @@ <h1>{{ .Params.book.section.cs_number }} {{ .Params.book.chapter.title }} - {{ .
           <!-- older manual page versions are less interesting and need to be excluded from the search -->
           {{ $include_in_search := (or (not (isset .Params "docname")) (isset .Params "latest-changes") (isset .Params "lang")) }}
           <div id="main"{{ if $include_in_search }} data-pagefind-filter="category:reference" data-pagefind-meta="category:Reference" data-pagefind-weight="0.05" data-pagefind-body{{ end }}>
+	    {{ if (and (isset .Params "docname") (in .Site.Data.docs_extra.git_project_specific .Params.docname)) }}
+	    <div class="callout">
+	    <h2>This information is specific to the Git project</h2>
+	    <p>Please note that this information is only relevant to you if you plan on <a href="{{ relURL "community#contributing" }}">contributing to the Git project itself</a>. It is in no shape or form required reading for regular Git users.</p>
+	    </div>
+	    {{ end }}
             {{ .Content }}
             {{ $match := findRESubmatch "(?s)>NAME</h2>.*?<p[^>]*>(git-)?([^ ]+)" .Content 1 }}
             {{ if (eq ($match | len) 1) }}

From 1deace4d416b790a67f74b04fde846b734db5b80 Mon Sep 17 00:00:00 2001
From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Sat, 1 Mar 2025 12:49:25 +0100
Subject: [PATCH 4/6] docs: include more Git project-specific pages

Now that they are clearly labeled as such, let's augment the list of
"manual pages" that concern themselves with information only relevant
for contributors to the Git project itself.

This closes https://github.com/git/git-scm.com/issues/1938,
https://github.com/git/git-scm.com/issues/1939 and
https://github.com/git/git-scm.com/issues/1961.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 content/community/_index.html | 2 +-
 data/docs_extra.yml           | 3 +++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/content/community/_index.html b/content/community/_index.html
index 14c12979df..1d752ee8ed 100644
--- a/content/community/_index.html
+++ b/content/community/_index.html
@@ -101,7 +101,7 @@ <h2 id="git-rev-news"><a class="anchor" href="#git-rev-news"></a> Newsletter </h
   <h2 id="contributing"><a class="anchor" href="#contributing"></a> Contributing to Git </h2>
 
   <p>
-    The <a href="https://github.com/git/git/tree/master/Documentation">Documentation directory</a> in the Git source code has several files of interest to developers who are looking to help contribute. After reading the <a href="https://github.com/git/git/blob/master/Documentation/CodingGuidelines">coding guidelines</a> and <a href="https://github.com/git/git/blob/master/CODE_OF_CONDUCT.md">code of conduct</a>, you can learn <a href="{{< relurl "docs/SubmittingPatches" >}}">how to submit patches</a>. If you are just starting out, you can read the <a href="{{< relurl "docs/MyFirstContribution" >}}">My First Contribution tutorial</a>. For those looking to get more deeply involved, there is a <a href="https://github.com/git/git/blob/master/Documentation/howto/maintain-git.txt">howto for Git maintainers</a>.
+    The <a href="https://github.com/git/git/tree/master/Documentation">Documentation directory</a> in the Git source code has several files of interest to developers who are looking to help contribute. After reading the <a href="{{ relURL "docs/CodingGuidelines" }}">coding guidelines</a> and <a href="https://github.com/git/git/blob/master/CODE_OF_CONDUCT.md">code of conduct</a>, you can learn <a href="{{< relurl "docs/SubmittingPatches" >}}">how to submit patches</a>. If you are just starting out, you can read the <a href="{{< relurl "docs/MyFirstContribution" >}}">My First Contribution tutorial</a>. For those looking to get more deeply involved, there is a <a href="https://github.com/git/git/blob/master/Documentation/howto/maintain-git.txt">howto for Git maintainers</a>.
   </p>
 
   <p>
diff --git a/data/docs_extra.yml b/data/docs_extra.yml
index 57b9e79378..9c80fa561d 100644
--- a/data/docs_extra.yml
+++ b/data/docs_extra.yml
@@ -1,6 +1,9 @@
 ---
 git_project_specific:
+  - BreakingChanges
+  - CodingGuidelines
   - MyFirstContribution
   - MyFirstObjectWalk
+  - ReviewingGuidelines
   - SubmittingPatches
 ---

From c691f0d25f4e9f3a2ddc34e3c5b64ca70ea8e8e2 Mon Sep 17 00:00:00 2001
From: dscho <dscho@noreply.github.com>
Date: Sat, 1 Mar 2025 17:46:37 +0000
Subject: [PATCH 5/6] Update manual pages (manually forced rebuild)

Updated via the `update-git-version-and-manual-pages.yml` GitHub workflow.
---
 .../0317be45e7d36ce28b9d4ac17272a2d4ca57d620  |  754 +++++++++
 .../13e8ae1a74ea153fbfe36c0a08113b8f89595b00  |  589 +++++++
 .../201fe4605e6de6698b4916de3fa8b194a71c5f64  |  610 +++++++
 .../251eb6d9ec08d864904404e8cc131eca8ec72284  |  179 ++
 .../2e9671e52ffadcf2df658fe919633f6aba936a06  |  917 ++++++++++
 .../32781022f7f5c49bc62c2cc3ab09bee44cc04945  |  758 +++++++++
 .../32f7e6163d58c1215034f5d599a90e3e9fcf84b4  |  735 ++++++++
 .../384992bd708c35d0869455bfb756632a1ced33f2  |  645 +++++++
 .../384de0c2eb9bf8e5b95cd22ef5740abd694022d6  |  162 ++
 .../39bbf29f884e401a43d2af98c30539f335176513  |  584 +++++++
 .../55011116bc4302d7dde275723d3fb60e9bf39d8e  |  549 ++++++
 .../660e60c007657c8aeaaf25cc41138f04b83f15ff  |  162 ++
 .../696065291c8dcb7cbec1a8dc47a55864ddd0d808  |  584 +++++++
 .../69f4ac48c946a35bba57c7c8797511ee65231d47  |  727 ++++++++
 .../71b2434bb15acfa6720c087f54107b20b61a1b0c  |  727 ++++++++
 .../77f797459e96e94e3a6014d10c0c1bda00c8768d  |  640 +++++++
 .../7983213f3ace118da2fd286c613aba364e124b89  |  544 ++++++
 .../8496395b740ea161bc89ea066db49eb95e228c26  |  650 ++++++++
 .../8567155f3e546b061f4a64aee252b80ab3e27e2a  |  722 ++++++++
 .../975b191d029bc4676e7ea0c0223f018da61f129c  |  758 +++++++++
 .../9776886cc5f18c5859d4e3af0bc22df96113a881  |  613 +++++++
 .../9c32b5e746e13047c56b6acd89d1308b139d8cd1  |  947 +++++++++++
 .../a3aac268363085b0e36d5392bafb6bc7c2e17d1a  |  557 +++++++
 .../b8a56b0af0407301072e4e43a966b7a784900549  |  135 ++
 .../c1f2cd288d496192b1029e59ff7a92359e1b1198  |  695 ++++++++
 .../c6e5fb1cba5ded1146eafe7b92bfcd9d2a4ee162  |  863 ++++++++++
 .../ce20a0533295750b94bd23a9cb5c67430f8503ba  |  372 +++++
 .../d2d2e94cbec5178624611283429cb5f21861ff74  |  155 ++
 .../d3b4cbca6a79491fc719c451995a3667cc68b397  |  512 ++++++
 .../d49c40b5a0969c8f9c2b9ff6cc204e92af030f8e  |  758 +++++++++
 .../d7fc919fc1b767d7ef6d2ca2c8f2b227c63d6df0  |  758 +++++++++
 .../dcf07e945fc4ac4874475bace3a886d8ddc2064b  |  742 +++++++++
 .../ed8d63cdf8567e70f4d62c88daca3133a9142b79  |  174 ++
 .../f2b007745ffc33a055f437faa3f0ba54ceab087e  |  639 +++++++
 .../f485f9b050c77bb17365499faca70a6e985afbf9  |  750 +++++++++
 .../f8255c58b0b03311a6d37ae461d44e7522c08491  |  592 +++++++
 .../ff290873af26a1047e859571a8e319da8570a23c  |  535 ++++++
 .../ff51a5c73ef7c16162ab8672c3649e5fd1f93607  |  827 +++++++++
 .../ff58baf57350f365f22ec5f7ce1e0cf50351359b  |  639 +++++++
 .../docs/content/docs/BreakingChanges.html    |  279 ++++
 .../content/docs/BreakingChanges/2.46.0.html  |  234 +++
 .../content/docs/BreakingChanges/2.47.0.html  |  257 +++
 .../content/docs/BreakingChanges/2.48.0.html  |  279 ++++
 .../docs/content/docs/CodingGuidelines.html   | 1479 +++++++++++++++++
 .../content/docs/CodingGuidelines/2.0.5.html  |  586 +++++++
 .../content/docs/CodingGuidelines/2.1.4.html  |  813 +++++++++
 .../content/docs/CodingGuidelines/2.11.4.html |  922 ++++++++++
 .../content/docs/CodingGuidelines/2.13.7.html |  924 ++++++++++
 .../content/docs/CodingGuidelines/2.17.0.html |  941 +++++++++++
 .../content/docs/CodingGuidelines/2.19.2.html |  934 +++++++++++
 .../content/docs/CodingGuidelines/2.20.0.html |  965 +++++++++++
 .../content/docs/CodingGuidelines/2.22.0.html |  958 +++++++++++
 .../content/docs/CodingGuidelines/2.22.1.html | 1013 +++++++++++
 .../content/docs/CodingGuidelines/2.25.0.html | 1008 +++++++++++
 .../content/docs/CodingGuidelines/2.27.0.html | 1014 +++++++++++
 .../content/docs/CodingGuidelines/2.28.0.html | 1031 ++++++++++++
 .../content/docs/CodingGuidelines/2.3.10.html |  853 ++++++++++
 .../content/docs/CodingGuidelines/2.32.0.html | 1025 ++++++++++++
 .../content/docs/CodingGuidelines/2.33.0.html | 1128 +++++++++++++
 .../content/docs/CodingGuidelines/2.35.0.html | 1157 +++++++++++++
 .../content/docs/CodingGuidelines/2.36.0.html | 1170 +++++++++++++
 .../content/docs/CodingGuidelines/2.37.0.html | 1159 +++++++++++++
 .../content/docs/CodingGuidelines/2.38.0.html | 1153 +++++++++++++
 .../content/docs/CodingGuidelines/2.38.2.html | 1176 +++++++++++++
 .../content/docs/CodingGuidelines/2.39.0.html | 1196 +++++++++++++
 .../content/docs/CodingGuidelines/2.4.12.html |  869 ++++++++++
 .../content/docs/CodingGuidelines/2.41.0.html | 1193 +++++++++++++
 .../content/docs/CodingGuidelines/2.42.0.html | 1195 +++++++++++++
 .../content/docs/CodingGuidelines/2.42.1.html | 1198 +++++++++++++
 .../content/docs/CodingGuidelines/2.43.0.html | 1195 +++++++++++++
 .../content/docs/CodingGuidelines/2.43.1.html | 1204 ++++++++++++++
 .../content/docs/CodingGuidelines/2.45.0.html | 1300 +++++++++++++++
 .../content/docs/CodingGuidelines/2.46.1.html | 1352 +++++++++++++++
 .../content/docs/CodingGuidelines/2.47.0.html | 1438 ++++++++++++++++
 .../content/docs/CodingGuidelines/2.48.0.html | 1479 +++++++++++++++++
 .../content/docs/CodingGuidelines/2.8.6.html  |  872 ++++++++++
 .../content/docs/CodingGuidelines/2.9.5.html  |  884 ++++++++++
 .../content/docs/ReviewingGuidelines.html     |  249 +++
 .../docs/ReviewingGuidelines/2.38.0.html      |  253 +++
 .../docs/ReviewingGuidelines/2.43.0.html      |  246 +++
 .../docs/ReviewingGuidelines/2.47.0.html      |  252 +++
 external/docs/data/docs.yml                   |  569 +++++++
 82 files changed, 62661 insertions(+)
 create mode 100644 external/docs/asciidoc/0317be45e7d36ce28b9d4ac17272a2d4ca57d620
 create mode 100644 external/docs/asciidoc/13e8ae1a74ea153fbfe36c0a08113b8f89595b00
 create mode 100644 external/docs/asciidoc/201fe4605e6de6698b4916de3fa8b194a71c5f64
 create mode 100644 external/docs/asciidoc/251eb6d9ec08d864904404e8cc131eca8ec72284
 create mode 100644 external/docs/asciidoc/2e9671e52ffadcf2df658fe919633f6aba936a06
 create mode 100644 external/docs/asciidoc/32781022f7f5c49bc62c2cc3ab09bee44cc04945
 create mode 100644 external/docs/asciidoc/32f7e6163d58c1215034f5d599a90e3e9fcf84b4
 create mode 100644 external/docs/asciidoc/384992bd708c35d0869455bfb756632a1ced33f2
 create mode 100644 external/docs/asciidoc/384de0c2eb9bf8e5b95cd22ef5740abd694022d6
 create mode 100644 external/docs/asciidoc/39bbf29f884e401a43d2af98c30539f335176513
 create mode 100644 external/docs/asciidoc/55011116bc4302d7dde275723d3fb60e9bf39d8e
 create mode 100644 external/docs/asciidoc/660e60c007657c8aeaaf25cc41138f04b83f15ff
 create mode 100644 external/docs/asciidoc/696065291c8dcb7cbec1a8dc47a55864ddd0d808
 create mode 100644 external/docs/asciidoc/69f4ac48c946a35bba57c7c8797511ee65231d47
 create mode 100644 external/docs/asciidoc/71b2434bb15acfa6720c087f54107b20b61a1b0c
 create mode 100644 external/docs/asciidoc/77f797459e96e94e3a6014d10c0c1bda00c8768d
 create mode 100644 external/docs/asciidoc/7983213f3ace118da2fd286c613aba364e124b89
 create mode 100644 external/docs/asciidoc/8496395b740ea161bc89ea066db49eb95e228c26
 create mode 100644 external/docs/asciidoc/8567155f3e546b061f4a64aee252b80ab3e27e2a
 create mode 100644 external/docs/asciidoc/975b191d029bc4676e7ea0c0223f018da61f129c
 create mode 100644 external/docs/asciidoc/9776886cc5f18c5859d4e3af0bc22df96113a881
 create mode 100644 external/docs/asciidoc/9c32b5e746e13047c56b6acd89d1308b139d8cd1
 create mode 100644 external/docs/asciidoc/a3aac268363085b0e36d5392bafb6bc7c2e17d1a
 create mode 100644 external/docs/asciidoc/b8a56b0af0407301072e4e43a966b7a784900549
 create mode 100644 external/docs/asciidoc/c1f2cd288d496192b1029e59ff7a92359e1b1198
 create mode 100644 external/docs/asciidoc/c6e5fb1cba5ded1146eafe7b92bfcd9d2a4ee162
 create mode 100644 external/docs/asciidoc/ce20a0533295750b94bd23a9cb5c67430f8503ba
 create mode 100644 external/docs/asciidoc/d2d2e94cbec5178624611283429cb5f21861ff74
 create mode 100644 external/docs/asciidoc/d3b4cbca6a79491fc719c451995a3667cc68b397
 create mode 100644 external/docs/asciidoc/d49c40b5a0969c8f9c2b9ff6cc204e92af030f8e
 create mode 100644 external/docs/asciidoc/d7fc919fc1b767d7ef6d2ca2c8f2b227c63d6df0
 create mode 100644 external/docs/asciidoc/dcf07e945fc4ac4874475bace3a886d8ddc2064b
 create mode 100644 external/docs/asciidoc/ed8d63cdf8567e70f4d62c88daca3133a9142b79
 create mode 100644 external/docs/asciidoc/f2b007745ffc33a055f437faa3f0ba54ceab087e
 create mode 100644 external/docs/asciidoc/f485f9b050c77bb17365499faca70a6e985afbf9
 create mode 100644 external/docs/asciidoc/f8255c58b0b03311a6d37ae461d44e7522c08491
 create mode 100644 external/docs/asciidoc/ff290873af26a1047e859571a8e319da8570a23c
 create mode 100644 external/docs/asciidoc/ff51a5c73ef7c16162ab8672c3649e5fd1f93607
 create mode 100644 external/docs/asciidoc/ff58baf57350f365f22ec5f7ce1e0cf50351359b
 create mode 100644 external/docs/content/docs/BreakingChanges.html
 create mode 100644 external/docs/content/docs/BreakingChanges/2.46.0.html
 create mode 100644 external/docs/content/docs/BreakingChanges/2.47.0.html
 create mode 100644 external/docs/content/docs/BreakingChanges/2.48.0.html
 create mode 100644 external/docs/content/docs/CodingGuidelines.html
 create mode 100644 external/docs/content/docs/CodingGuidelines/2.0.5.html
 create mode 100644 external/docs/content/docs/CodingGuidelines/2.1.4.html
 create mode 100644 external/docs/content/docs/CodingGuidelines/2.11.4.html
 create mode 100644 external/docs/content/docs/CodingGuidelines/2.13.7.html
 create mode 100644 external/docs/content/docs/CodingGuidelines/2.17.0.html
 create mode 100644 external/docs/content/docs/CodingGuidelines/2.19.2.html
 create mode 100644 external/docs/content/docs/CodingGuidelines/2.20.0.html
 create mode 100644 external/docs/content/docs/CodingGuidelines/2.22.0.html
 create mode 100644 external/docs/content/docs/CodingGuidelines/2.22.1.html
 create mode 100644 external/docs/content/docs/CodingGuidelines/2.25.0.html
 create mode 100644 external/docs/content/docs/CodingGuidelines/2.27.0.html
 create mode 100644 external/docs/content/docs/CodingGuidelines/2.28.0.html
 create mode 100644 external/docs/content/docs/CodingGuidelines/2.3.10.html
 create mode 100644 external/docs/content/docs/CodingGuidelines/2.32.0.html
 create mode 100644 external/docs/content/docs/CodingGuidelines/2.33.0.html
 create mode 100644 external/docs/content/docs/CodingGuidelines/2.35.0.html
 create mode 100644 external/docs/content/docs/CodingGuidelines/2.36.0.html
 create mode 100644 external/docs/content/docs/CodingGuidelines/2.37.0.html
 create mode 100644 external/docs/content/docs/CodingGuidelines/2.38.0.html
 create mode 100644 external/docs/content/docs/CodingGuidelines/2.38.2.html
 create mode 100644 external/docs/content/docs/CodingGuidelines/2.39.0.html
 create mode 100644 external/docs/content/docs/CodingGuidelines/2.4.12.html
 create mode 100644 external/docs/content/docs/CodingGuidelines/2.41.0.html
 create mode 100644 external/docs/content/docs/CodingGuidelines/2.42.0.html
 create mode 100644 external/docs/content/docs/CodingGuidelines/2.42.1.html
 create mode 100644 external/docs/content/docs/CodingGuidelines/2.43.0.html
 create mode 100644 external/docs/content/docs/CodingGuidelines/2.43.1.html
 create mode 100644 external/docs/content/docs/CodingGuidelines/2.45.0.html
 create mode 100644 external/docs/content/docs/CodingGuidelines/2.46.1.html
 create mode 100644 external/docs/content/docs/CodingGuidelines/2.47.0.html
 create mode 100644 external/docs/content/docs/CodingGuidelines/2.48.0.html
 create mode 100644 external/docs/content/docs/CodingGuidelines/2.8.6.html
 create mode 100644 external/docs/content/docs/CodingGuidelines/2.9.5.html
 create mode 100644 external/docs/content/docs/ReviewingGuidelines.html
 create mode 100644 external/docs/content/docs/ReviewingGuidelines/2.38.0.html
 create mode 100644 external/docs/content/docs/ReviewingGuidelines/2.43.0.html
 create mode 100644 external/docs/content/docs/ReviewingGuidelines/2.47.0.html

diff --git a/external/docs/asciidoc/0317be45e7d36ce28b9d4ac17272a2d4ca57d620 b/external/docs/asciidoc/0317be45e7d36ce28b9d4ac17272a2d4ca57d620
new file mode 100644
index 0000000000..003393ed16
--- /dev/null
+++ b/external/docs/asciidoc/0317be45e7d36ce28b9d4ac17272a2d4ca57d620
@@ -0,0 +1,754 @@
+Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, a few rough rules are:
+
+ - Most importantly, we never say "It's in POSIX; we'll happily
+   ignore your needs should your system not conform to it."
+   We live in the real world.
+
+ - However, we often say "Let's stay away from that construct,
+   it's not even in POSIX".
+
+ - In spite of the above two rules, we sometimes say "Although
+   this is not in POSIX, it (is so convenient | makes the code
+   much more readable | has other good characteristics) and
+   practically all the platforms we care about support it, so
+   let's use it".
+
+   Again, we live in the real world, and it is sometimes a
+   judgement call, the decision based more on real world
+   constraints people face than what the paper standard says.
+
+ - Fixing style violations while working on a real change as a
+   preparatory clean-up step is good, but otherwise avoid useless code
+   churn for the sake of conforming to the style.
+
+   "Once it _is_ in the tree, it's not really worth the patch noise to
+   go and fix it up."
+   Cf. http://lkml.iu.edu/hypermail/linux/kernel/1001.3/01069.html
+
+ - Log messages to explain your changes are as important as the
+   changes themselves.  Clearly written code and in-code comments
+   explain how the code works and what is assumed from the surrounding
+   context.  The log messages explain what the changes wanted to
+   achieve and why the changes were necessary (more on this in the
+   accompanying SubmittingPatches document).
+
+Make your code readable and sensible, and don't try to be clever.
+
+As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the _local_
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn't match the overall style of existing code).
+
+But if you must have a list of rules, here are some language
+specific ones. Note that Documentation/ToolsForGit.txt document
+has a collection of tips to help you use some external tools
+to conform to these guidelines.
+
+For shell scripts specifically (not exhaustive):
+
+ - We use tabs for indentation.
+
+ - Case arms are indented at the same depth as case and esac lines,
+   like this:
+
+	case "$variable" in
+	pattern1)
+		do this
+		;;
+	pattern2)
+		do that
+		;;
+	esac
+
+ - Redirection operators should be written with space before, but no
+   space after them.  In other words, write 'echo test >"$file"'
+   instead of 'echo test> $file' or 'echo test > $file'.  Note that
+   even though it is not required by POSIX to double-quote the
+   redirection target in a variable (as shown above), our code does so
+   because some versions of bash issue a warning without the quotes.
+
+	(incorrect)
+	cat hello > world < universe
+	echo hello >$world
+
+	(correct)
+	cat hello >world <universe
+	echo hello >"$world"
+
+ - We prefer $( ... ) for command substitution; unlike ``, it
+   properly nests.  It should have been the way Bourne spelled
+   it from day one, but unfortunately isn't.
+
+ - If you want to find out if a command is available on the user's
+   $PATH, you should use 'type <command>', instead of 'which <command>'.
+   The output of 'which' is not machine parsable and its exit code
+   is not reliable across platforms.
+
+ - We use POSIX compliant parameter substitutions and avoid bashisms;
+   namely:
+
+   - We use ${parameter-word} and its [-=?+] siblings, and their
+     colon'ed "unset or null" form.
+
+   - We use ${parameter#word} and its [#%] siblings, and their
+     doubled "longest matching" form.
+
+   - No "Substring Expansion" ${parameter:offset:length}.
+
+   - No shell arrays.
+
+   - No pattern replacement ${parameter/pattern/string}.
+
+ - We use Arithmetic Expansion $(( ... )).
+
+ - We do not use Process Substitution <(list) or >(list).
+
+ - Do not write control structures on a single line with semicolon.
+   "then" should be on the next line for if statements, and "do"
+   should be on the next line for "while" and "for".
+
+	(incorrect)
+	if test -f hello; then
+		do this
+	fi
+
+	(correct)
+	if test -f hello
+	then
+		do this
+	fi
+
+ - If a command sequence joined with && or || or | spans multiple
+   lines, put each command on a separate line and put && and || and |
+   operators at the end of each line, rather than the start. This
+   means you don't need to use \ to join lines, since the above
+   operators imply the sequence isn't finished.
+
+	(incorrect)
+	grep blob verify_pack_result \
+	| awk -f print_1.awk \
+	| sort >actual &&
+	...
+
+	(correct)
+	grep blob verify_pack_result |
+	awk -f print_1.awk |
+	sort >actual &&
+	...
+
+ - We prefer "test" over "[ ... ]".
+
+ - We do not write the noiseword "function" in front of shell
+   functions.
+
+ - We prefer a space between the function name and the parentheses,
+   and no space inside the parentheses. The opening "{" should also
+   be on the same line.
+
+	(incorrect)
+	my_function(){
+		...
+
+	(correct)
+	my_function () {
+		...
+
+ - As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+   [::], [==], or [..]) for portability.
+
+   - We do not use \{m,n\};
+
+   - We do not use ? or + (which are \{0,1\} and \{1,\}
+     respectively in BRE) but that goes without saying as these
+     are ERE elements not BRE (note that \? and \+ are not even part
+     of BRE -- making them accessible from BRE is a GNU extension).
+
+ - Use Git's gettext wrappers in git-sh-i18n to make the user
+   interface translatable. See "Marking strings for translation" in
+   po/README.
+
+ - We do not write our "test" command with "-a" and "-o" and use "&&"
+   or "||" to concatenate multiple "test" commands instead, because
+   the use of "-a/-o" is often error-prone.  E.g.
+
+     test -n "$x" -a "$a" = "$b"
+
+   is buggy and breaks when $x is "=", but
+
+     test -n "$x" && test "$a" = "$b"
+
+   does not have such a problem.
+
+ - Even though "local" is not part of POSIX, we make heavy use of it
+   in our test suite.  We do not use it in scripted Porcelains, and
+   hopefully nobody starts using "local" before they are reimplemented
+   in C ;-)
+
+
+For C programs:
+
+ - We use tabs to indent, and interpret tabs as taking up to
+   8 spaces.
+
+ - We try to keep to at most 80 characters per line.
+
+ - As a Git developer we assume you have a reasonably modern compiler
+   and we recommend you to enable the DEVELOPER makefile knob to
+   ensure your patch is clear of all compiler warnings we care about,
+   by e.g. "echo DEVELOPER=1 >>config.mak".
+
+ - We try to support a wide range of C compilers to compile Git with,
+   including old ones.  As of Git v2.35.0 Git requires C99 (we check
+   "__STDC_VERSION__"). You should not use features from a newer C
+   standard, even if your compiler groks them.
+
+   New C99 features have been phased in gradually, if something's new
+   in C99 but not used yet don't assume that it's safe to use, some
+   compilers we target have only partial support for it. These are
+   considered safe to use:
+
+   . since around 2007 with 2b6854c863a, we have been using
+     initializer elements which are not computable at load time. E.g.:
+
+	const char *args[] = {"constant", variable, NULL};
+
+   . since early 2012 with e1327023ea, we have been using an enum
+     definition whose last element is followed by a comma.  This, like
+     an array initializer that ends with a trailing comma, can be used
+     to reduce the patch noise when adding a new identifier at the end.
+
+   . since mid 2017 with cbc0f81d, we have been using designated
+     initializers for struct (e.g. "struct t v = { .val = 'a' };").
+
+   . since mid 2017 with 512f41cf, we have been using designated
+     initializers for array (e.g. "int array[10] = { [5] = 2 }").
+
+   . since early 2021 with 765dc168882, we have been using variadic
+     macros, mostly for printf-like trace and debug macros.
+
+   . since late 2021 with 44ba10d6, we have had variables declared in
+     the for loop "for (int i = 0; i < 10; i++)".
+
+   New C99 features that we cannot use yet:
+
+   . %z and %zu as a printf() argument for a size_t (the %z being for
+     the POSIX-specific ssize_t). Instead you should use
+     printf("%"PRIuMAX, (uintmax_t)v).  These days the MSVC version we
+     rely on supports %z, but the C library used by MinGW does not.
+
+   . Shorthand like ".a.b = *c" in struct initializations is known to
+     trip up an older IBM XLC version, use ".a = { .b = *c }" instead.
+     See the 33665d98 (reftable: make assignments portable to AIX xlc
+     v12.01, 2022-03-28).
+
+ - Variables have to be declared at the beginning of the block, before
+   the first statement (i.e. -Wdeclaration-after-statement).
+
+ - NULL pointers shall be written as NULL, not as 0.
+
+ - When declaring pointers, the star sides with the variable
+   name, i.e. "char *string", not "char* string" or
+   "char * string".  This makes it easier to understand code
+   like "char *string, c;".
+
+ - Use whitespace around operators and keywords, but not inside
+   parentheses and not around functions. So:
+
+        while (condition)
+		func(bar + 1);
+
+   and not:
+
+        while( condition )
+		func (bar+1);
+
+ - Do not explicitly compare an integral value with constant 0 or '\0',
+   or a pointer value with constant NULL.  For instance, to validate that
+   counted array <ptr, cnt> is initialized but has no elements, write:
+
+	if (!ptr || cnt)
+		BUG("empty array expected");
+
+   and not:
+
+	if (ptr == NULL || cnt != 0);
+		BUG("empty array expected");
+
+ - We avoid using braces unnecessarily.  I.e.
+
+	if (bla) {
+		x = 1;
+	}
+
+   is frowned upon. But there are a few exceptions:
+
+	- When the statement extends over a few lines (e.g., a while loop
+	  with an embedded conditional, or a comment). E.g.:
+
+		while (foo) {
+			if (x)
+				one();
+			else
+				two();
+		}
+
+		if (foo) {
+			/*
+			 * This one requires some explanation,
+			 * so we're better off with braces to make
+			 * it obvious that the indentation is correct.
+			 */
+			doit();
+		}
+
+	- When there are multiple arms to a conditional and some of them
+	  require braces, enclose even a single line block in braces for
+	  consistency. E.g.:
+
+		if (foo) {
+			doit();
+		} else {
+			one();
+			two();
+			three();
+		}
+
+ - We try to avoid assignments in the condition of an "if" statement.
+
+ - Try to make your code understandable.  You may put comments
+   in, but comments invariably tend to stale out when the code
+   they were describing changes.  Often splitting a function
+   into two makes the intention of the code much clearer.
+
+ - Multi-line comments include their delimiters on separate lines from
+   the text.  E.g.
+
+	/*
+	 * A very long
+	 * multi-line comment.
+	 */
+
+   Note however that a comment that explains a translatable string to
+   translators uses a convention of starting with a magic token
+   "TRANSLATORS: ", e.g.
+
+	/*
+	 * TRANSLATORS: here is a comment that explains the string to
+	 * be translated, that follows immediately after it.
+	 */
+	_("Here is a translatable string explained by the above.");
+
+ - Double negation is often harder to understand than no negation
+   at all.
+
+ - There are two schools of thought when it comes to comparison,
+   especially inside a loop. Some people prefer to have the less stable
+   value on the left hand side and the more stable value on the right hand
+   side, e.g. if you have a loop that counts variable i down to the
+   lower bound,
+
+	while (i > lower_bound) {
+		do something;
+		i--;
+	}
+
+   Other people prefer to have the textual order of values match the
+   actual order of values in their comparison, so that they can
+   mentally draw a number line from left to right and place these
+   values in order, i.e.
+
+	while (lower_bound < i) {
+		do something;
+		i--;
+	}
+
+   Both are valid, and we use both.  However, the more "stable" the
+   stable side becomes, the more we tend to prefer the former
+   (comparison with a constant, "i > 0", is an extreme example).
+   Just do not mix styles in the same part of the code and mimic
+   existing styles in the neighbourhood.
+
+ - There are two schools of thought when it comes to splitting a long
+   logical line into multiple lines.  Some people push the second and
+   subsequent lines far enough to the right with tabs and align them:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+		span_more_than_a_single_line_of ||
+		the_source_text) {
+                ...
+
+   while other people prefer to align the second and the subsequent
+   lines with the column immediately inside the opening parenthesis,
+   with tabs and spaces, following our "tabstop is always a multiple
+   of 8" convention:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of ||
+	    the_source_text) {
+                ...
+
+   Both are valid, and we use both.  Again, just do not mix styles in
+   the same part of the code and mimic existing styles in the
+   neighbourhood.
+
+ - When splitting a long logical line, some people change line before
+   a binary operator, so that the result looks like a parse tree when
+   you turn your head 90-degrees counterclockwise:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to
+	    || span_more_than_a_single_line_of_the_source_text) {
+
+   while other people prefer to leave the operator at the end of the
+   line:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of_the_source_text) {
+
+   Both are valid, but we tend to use the latter more, unless the
+   expression gets fairly complex, in which case the former tends to
+   be easier to read.  Again, just do not mix styles in the same part
+   of the code and mimic existing styles in the neighbourhood.
+
+ - When splitting a long logical line, with everything else being
+   equal, it is preferable to split after the operator at higher
+   level in the parse tree.  That is, this is more preferable:
+
+	if (a_very_long_variable * that_is_used_in +
+	    a_very_long_expression) {
+		...
+
+   than
+
+	if (a_very_long_variable *
+	    that_is_used_in + a_very_long_expression) {
+		...
+
+ - Some clever tricks, like using the !! operator with arithmetic
+   constructs, can be extremely confusing to others.  Avoid them,
+   unless there is a compelling reason to use them.
+
+ - Use the API.  No, really.  We have a strbuf (variable length
+   string), several arrays with the ALLOC_GROW() macro, a
+   string_list for sorted string lists, a hash map (mapping struct
+   objects) named "struct decorate", amongst other things.
+
+ - When you come up with an API, document its functions and structures
+   in the header file that exposes the API to its callers. Use what is
+   in "strbuf.h" as a model for the appropriate tone and level of
+   detail.
+
+ - The first #include in C files, except in platform specific compat/
+   implementations and sha1dc/, must be either "git-compat-util.h" or
+   one of the approved headers that includes it first for you.  (The
+   approved headers currently include "cache.h", "builtin.h",
+   "t/helper/test-tool.h", "xdiff/xinclude.h", or
+   "reftable/system.h").  You do not have to include more than one of
+   these.
+
+ - A C file must directly include the header files that declare the
+   functions and the types it uses, except for the functions and types
+   that are made available to it by including one of the header files
+   it must include by the previous rule.
+
+ - If you are planning a new command, consider writing it in shell
+   or perl first, so that changes in semantics can be easily
+   changed and discussed.  Many Git commands started out like
+   that, and a few are still scripts.
+
+ - Avoid introducing a new dependency into Git. This means you
+   usually should stay away from scripting languages not already
+   used in the Git core command set (unless your command is clearly
+   separate from it, such as an importer to convert random-scm-X
+   repositories to Git).
+
+ - When we pass <string, length> pair to functions, we should try to
+   pass them in that order.
+
+ - Use Git's gettext wrappers to make the user interface
+   translatable. See "Marking strings for translation" in po/README.
+
+ - Variables and functions local to a given source file should be marked
+   with "static". Variables that are visible to other source files
+   must be declared with "extern" in header files. However, function
+   declarations should not use "extern", as that is already the default.
+
+ - You can launch gdb around your program using the shorthand GIT_DEBUGGER.
+   Run `GIT_DEBUGGER=1 ./bin-wrappers/git foo` to simply use gdb as is, or
+   run `GIT_DEBUGGER="<debugger> <debugger-args>" ./bin-wrappers/git foo` to
+   use your own debugger and arguments. Example: `GIT_DEBUGGER="ddd --gdb"
+   ./bin-wrappers/git log` (See `wrap-for-bin.sh`.)
+
+For Perl programs:
+
+ - Most of the C guidelines above apply.
+
+ - We try to support Perl 5.8 and later ("use Perl 5.008").
+
+ - use strict and use warnings are strongly preferred.
+
+ - Don't overuse statement modifiers unless using them makes the
+   result easier to follow.
+
+	... do something ...
+	do_this() unless (condition);
+        ... do something else ...
+
+   is more readable than:
+
+	... do something ...
+	unless (condition) {
+		do_this();
+	}
+        ... do something else ...
+
+   *only* when the condition is so rare that do_this() will be almost
+   always called.
+
+ - We try to avoid assignments inside "if ()" conditions.
+
+ - Learn and use Git.pm if you need that functionality.
+
+For Python scripts:
+
+ - We follow PEP-8 (http://www.python.org/dev/peps/pep-0008/).
+
+ - As a minimum, we aim to be compatible with Python 2.7.
+
+ - Where required libraries do not restrict us to Python 2, we try to
+   also be compatible with Python 3.1 and later.
+
+
+Program Output
+
+ We make a distinction between a Git command's primary output and
+ output which is merely chatty feedback (for instance, status
+ messages, running transcript, or progress display), as well as error
+ messages. Roughly speaking, a Git command's primary output is that
+ which one might want to capture to a file or send down a pipe; its
+ chatty output should not interfere with these use-cases.
+
+ As such, primary output should be sent to the standard output stream
+ (stdout), and chatty output should be sent to the standard error
+ stream (stderr). Examples of commands which produce primary output
+ include `git log`, `git show`, and `git branch --list` which generate
+ output on the stdout stream.
+
+ Not all Git commands have primary output; this is often true of
+ commands whose main function is to perform an action. Some action
+ commands are silent, whereas others are chatty. An example of a
+ chatty action commands is `git clone` with its "Cloning into
+ '<path>'..." and "Checking connectivity..." status messages which it
+ sends to the stderr stream.
+
+ Error messages from Git commands should always be sent to the stderr
+ stream.
+
+
+Error Messages
+
+ - Do not end error messages with a full stop.
+
+ - Do not capitalize the first word, only because it is the first word
+   in the message ("unable to open %s", not "Unable to open %s").  But
+   "SHA-3 not supported" is fine, because the reason the first word is
+   capitalized is not because it is at the beginning of the sentence,
+   but because the word would be spelled in capital letters even when
+   it appeared in the middle of the sentence.
+
+ - Say what the error is first ("cannot open %s", not "%s: cannot open")
+
+
+Externally Visible Names
+
+ - For configuration variable names, follow the existing convention:
+
+   . The section name indicates the affected subsystem.
+
+   . The subsection name, if any, indicates which of an unbounded set
+     of things to set the value for.
+
+   . The variable name describes the effect of tweaking this knob.
+
+   The section and variable names that consist of multiple words are
+   formed by concatenating the words without punctuations (e.g. `-`),
+   and are broken using bumpyCaps in documentation as a hint to the
+   reader.
+
+   When choosing the variable namespace, do not use variable name for
+   specifying possibly unbounded set of things, most notably anything
+   an end user can freely come up with (e.g. branch names).  Instead,
+   use subsection names or variable values, like the existing variable
+   branch.<name>.description does.
+
+
+Writing Documentation:
+
+ Most (if not all) of the documentation pages are written in the
+ AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+ processed into HTML and manpages (e.g. git.html and git.1 in the
+ same directory).
+
+ The documentation liberally mixes US and UK English (en_US/UK)
+ norms for spelling and grammar, which is somewhat unfortunate.
+ In an ideal world, it would have been better if it consistently
+ used only one and not the other, and we would have picked en_US
+ (if you wish to correct the English of some of the existing
+ documentation, please see the documentation-related advice in the
+ Documentation/SubmittingPatches file).
+
+ In order to ensure the documentation is inclusive, avoid assuming
+ that an unspecified example person is male or female, and think
+ twice before using "he", "him", "she", or "her".  Here are some
+ tips to avoid use of gendered pronouns:
+
+  - Prefer succinctness and matter-of-factly describing functionality
+    in the abstract.  E.g.
+
+     --short:: Emit output in the short-format.
+
+    and avoid something like these overly verbose alternatives:
+
+     --short:: Use this to emit output in the short-format.
+     --short:: You can use this to get output in the short-format.
+     --short:: A user who prefers shorter output could....
+     --short:: Should a person and/or program want shorter output, he
+               she/they/it can...
+
+    This practice often eliminates the need to involve human actors in
+    your description, but it is a good practice regardless of the
+    avoidance of gendered pronouns.
+
+  - When it becomes awkward to stick to this style, prefer "you" when
+    addressing the hypothetical user, and possibly "we" when
+    discussing how the program might react to the user.  E.g.
+
+      You can use this option instead of --xyz, but we might remove
+      support for it in future versions.
+
+    while keeping in mind that you can probably be less verbose, e.g.
+
+      Use this instead of --xyz. This option might be removed in future
+      versions.
+
+  - If you still need to refer to an example person that is
+    third-person singular, you may resort to "singular they" to avoid
+    "he/she/him/her", e.g.
+
+      A contributor asks their upstream to pull from them.
+
+    Note that this sounds ungrammatical and unnatural to those who
+    learned that "they" is only used for third-person plural, e.g.
+    those who learn English as a second language in some parts of the
+    world.
+
+ Every user-visible change should be reflected in the documentation.
+ The same general rule as for code applies -- imitate the existing
+ conventions.
+
+ A few commented examples follow to provide reference when writing or
+ modifying command usage strings and synopsis sections in the manual
+ pages:
+
+ Placeholders are spelled in lowercase and enclosed in angle brackets:
+   <file>
+   --sort=<key>
+   --abbrev[=<n>]
+
+ If a placeholder has multiple words, they are separated by dashes:
+   <new-branch-name>
+   --template=<template-directory>
+
+ Possibility of multiple occurrences is indicated by three dots:
+   <file>...
+   (One or more of <file>.)
+
+ Optional parts are enclosed in square brackets:
+   [<file>...]
+   (Zero or more of <file>.)
+
+   --exec-path[=<path>]
+   (Option with an optional argument.  Note that the "=" is inside the
+   brackets.)
+
+   [<patch>...]
+   (Zero or more of <patch>.  Note that the dots are inside, not
+   outside the brackets.)
+
+ Multiple alternatives are indicated with vertical bars:
+   [-q | --quiet]
+   [--utf8 | --no-utf8]
+
+ Use spacing around "|" token(s), but not immediately after opening or
+ before closing a [] or () pair:
+   Do: [-q | --quiet]
+   Don't: [-q|--quiet]
+
+ Don't use spacing around "|" tokens when they're used to seperate the
+ alternate arguments of an option:
+    Do: --track[=(direct|inherit)]
+    Don't: --track[=(direct | inherit)]
+
+ Parentheses are used for grouping:
+   [(<rev> | <range>)...]
+   (Any number of either <rev> or <range>.  Parens are needed to make
+   it clear that "..." pertains to both <rev> and <range>.)
+
+   [(-p <parent>)...]
+   (Any number of option -p, each with one <parent> argument.)
+
+   git remote set-head <name> (-a | -d | <branch>)
+   (One and only one of "-a", "-d" or "<branch>" _must_ (no square
+   brackets) be provided.)
+
+ And a somewhat more contrived example:
+   --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+   Here "=" is outside the brackets, because "--diff-filter=" is a
+   valid usage.  "*" has its own pair of brackets, because it can
+   (optionally) be specified only when one or more of the letters is
+   also provided.
+
+  A note on notation:
+   Use 'git' (all lowercase) when talking about commands i.e. something
+   the user would type into a shell and use 'Git' (uppercase first letter)
+   when talking about the version control system and its properties.
+
+ A few commented examples follow to provide reference when writing or
+ modifying paragraphs or option/command explanations that contain options
+ or commands:
+
+ Literal examples (e.g. use of command-line options, command names,
+ branch names, URLs, pathnames (files and directories), configuration and
+ environment variables) must be typeset in monospace (i.e. wrapped with
+ backticks):
+   `--pretty=oneline`
+   `git rev-list`
+   `remote.pushDefault`
+   `http://git.example.com`
+   `.git/config`
+   `GIT_DIR`
+   `HEAD`
+
+ An environment variable must be prefixed with "$" only when referring to its
+ value and not when referring to the variable itself, in this case there is
+ nothing to add except the backticks:
+   `GIT_DIR` is specified
+   `$GIT_DIR/hooks/pre-receive`
+
+ Word phrases enclosed in `backtick characters` are rendered literally
+ and will not be further expanded. The use of `backticks` to achieve the
+ previous rule means that literal examples should not use AsciiDoc
+ escapes.
+   Correct:
+      `--pretty=oneline`
+   Incorrect:
+      `\--pretty=oneline`
+
+ If some place in the documentation needs to typeset a command usage
+ example with inline substitutions, it is fine to use +monospaced and
+ inline substituted text+ instead of `monospaced literal text`, and with
+ the former, the part that should not get substituted must be
+ quoted/escaped.
diff --git a/external/docs/asciidoc/13e8ae1a74ea153fbfe36c0a08113b8f89595b00 b/external/docs/asciidoc/13e8ae1a74ea153fbfe36c0a08113b8f89595b00
new file mode 100644
index 0000000000..48aa4edfbd
--- /dev/null
+++ b/external/docs/asciidoc/13e8ae1a74ea153fbfe36c0a08113b8f89595b00
@@ -0,0 +1,589 @@
+Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, a few rough rules are:
+
+ - Most importantly, we never say "It's in POSIX; we'll happily
+   ignore your needs should your system not conform to it."
+   We live in the real world.
+
+ - However, we often say "Let's stay away from that construct,
+   it's not even in POSIX".
+
+ - In spite of the above two rules, we sometimes say "Although
+   this is not in POSIX, it (is so convenient | makes the code
+   much more readable | has other good characteristics) and
+   practically all the platforms we care about support it, so
+   let's use it".
+
+   Again, we live in the real world, and it is sometimes a
+   judgement call, the decision based more on real world
+   constraints people face than what the paper standard says.
+
+ - Fixing style violations while working on a real change as a
+   preparatory clean-up step is good, but otherwise avoid useless code
+   churn for the sake of conforming to the style.
+
+   "Once it _is_ in the tree, it's not really worth the patch noise to
+   go and fix it up."
+   Cf. http://lkml.iu.edu/hypermail/linux/kernel/1001.3/01069.html
+
+Make your code readable and sensible, and don't try to be clever.
+
+As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the _local_
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn't match the overall style of existing code).
+
+But if you must have a list of rules, here they are.
+
+For shell scripts specifically (not exhaustive):
+
+ - We use tabs for indentation.
+
+ - Case arms are indented at the same depth as case and esac lines,
+   like this:
+
+	case "$variable" in
+	pattern1)
+		do this
+		;;
+	pattern2)
+		do that
+		;;
+	esac
+
+ - Redirection operators should be written with space before, but no
+   space after them.  In other words, write 'echo test >"$file"'
+   instead of 'echo test> $file' or 'echo test > $file'.  Note that
+   even though it is not required by POSIX to double-quote the
+   redirection target in a variable (as shown above), our code does so
+   because some versions of bash issue a warning without the quotes.
+
+	(incorrect)
+	cat hello > world < universe
+	echo hello >$world
+
+	(correct)
+	cat hello >world <universe
+	echo hello >"$world"
+
+ - We prefer $( ... ) for command substitution; unlike ``, it
+   properly nests.  It should have been the way Bourne spelled
+   it from day one, but unfortunately isn't.
+
+ - If you want to find out if a command is available on the user's
+   $PATH, you should use 'type <command>', instead of 'which <command>'.
+   The output of 'which' is not machine parseable and its exit code
+   is not reliable across platforms.
+
+ - We use POSIX compliant parameter substitutions and avoid bashisms;
+   namely:
+
+   - We use ${parameter-word} and its [-=?+] siblings, and their
+     colon'ed "unset or null" form.
+
+   - We use ${parameter#word} and its [#%] siblings, and their
+     doubled "longest matching" form.
+
+   - No "Substring Expansion" ${parameter:offset:length}.
+
+   - No shell arrays.
+
+   - No strlen ${#parameter}.
+
+   - No pattern replacement ${parameter/pattern/string}.
+
+ - We use Arithmetic Expansion $(( ... )).
+
+ - Inside Arithmetic Expansion, spell shell variables with $ in front
+   of them, as some shells do not grok $((x)) while accepting $(($x))
+   just fine (e.g. dash older than 0.5.4).
+
+ - We do not use Process Substitution <(list) or >(list).
+
+ - Do not write control structures on a single line with semicolon.
+   "then" should be on the next line for if statements, and "do"
+   should be on the next line for "while" and "for".
+
+	(incorrect)
+	if test -f hello; then
+		do this
+	fi
+
+	(correct)
+	if test -f hello
+	then
+		do this
+	fi
+
+ - We prefer "test" over "[ ... ]".
+
+ - We do not write the noiseword "function" in front of shell
+   functions.
+
+ - We prefer a space between the function name and the parentheses,
+   and no space inside the parentheses. The opening "{" should also
+   be on the same line.
+
+	(incorrect)
+	my_function(){
+		...
+
+	(correct)
+	my_function () {
+		...
+
+ - As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+   [::], [==], or [..]) for portability.
+
+   - We do not use \{m,n\};
+
+   - We do not use -E;
+
+   - We do not use ? or + (which are \{0,1\} and \{1,\}
+     respectively in BRE) but that goes without saying as these
+     are ERE elements not BRE (note that \? and \+ are not even part
+     of BRE -- making them accessible from BRE is a GNU extension).
+
+ - Use Git's gettext wrappers in git-sh-i18n to make the user
+   interface translatable. See "Marking strings for translation" in
+   po/README.
+
+ - We do not write our "test" command with "-a" and "-o" and use "&&"
+   or "||" to concatenate multiple "test" commands instead, because
+   the use of "-a/-o" is often error-prone.  E.g.
+
+     test -n "$x" -a "$a" = "$b"
+
+   is buggy and breaks when $x is "=", but
+
+     test -n "$x" && test "$a" = "$b"
+
+   does not have such a problem.
+
+
+For C programs:
+
+ - We use tabs to indent, and interpret tabs as taking up to
+   8 spaces.
+
+ - We try to keep to at most 80 characters per line.
+
+ - As a Git developer we assume you have a reasonably modern compiler
+   and we recommend you to enable the DEVELOPER makefile knob to
+   ensure your patch is clear of all compiler warnings we care about,
+   by e.g. "echo DEVELOPER=1 >>config.mak".
+
+ - We try to support a wide range of C compilers to compile Git with,
+   including old ones. That means that you should not use C99
+   initializers, even if a lot of compilers grok it.
+
+ - Variables have to be declared at the beginning of the block.
+
+ - NULL pointers shall be written as NULL, not as 0.
+
+ - When declaring pointers, the star sides with the variable
+   name, i.e. "char *string", not "char* string" or
+   "char * string".  This makes it easier to understand code
+   like "char *string, c;".
+
+ - Use whitespace around operators and keywords, but not inside
+   parentheses and not around functions. So:
+
+        while (condition)
+		func(bar + 1);
+
+   and not:
+
+        while( condition )
+		func (bar+1);
+
+ - We avoid using braces unnecessarily.  I.e.
+
+	if (bla) {
+		x = 1;
+	}
+
+   is frowned upon. But there are a few exceptions:
+
+	- When the statement extends over a few lines (e.g., a while loop
+	  with an embedded conditional, or a comment). E.g.:
+
+		while (foo) {
+			if (x)
+				one();
+			else
+				two();
+		}
+
+		if (foo) {
+			/*
+			 * This one requires some explanation,
+			 * so we're better off with braces to make
+			 * it obvious that the indentation is correct.
+			 */
+			doit();
+		}
+
+	- When there are multiple arms to a conditional and some of them
+	  require braces, enclose even a single line block in braces for
+	  consistency. E.g.:
+
+		if (foo) {
+			doit();
+		} else {
+			one();
+			two();
+			three();
+		}
+
+ - We try to avoid assignments in the condition of an "if" statement.
+
+ - Try to make your code understandable.  You may put comments
+   in, but comments invariably tend to stale out when the code
+   they were describing changes.  Often splitting a function
+   into two makes the intention of the code much clearer.
+
+ - Multi-line comments include their delimiters on separate lines from
+   the text.  E.g.
+
+	/*
+	 * A very long
+	 * multi-line comment.
+	 */
+
+   Note however that a comment that explains a translatable string to
+   translators uses a convention of starting with a magic token
+   "TRANSLATORS: ", e.g.
+
+	/*
+	 * TRANSLATORS: here is a comment that explains the string to
+	 * be translated, that follows immediately after it.
+	 */
+	_("Here is a translatable string explained by the above.");
+
+ - Double negation is often harder to understand than no negation
+   at all.
+
+ - There are two schools of thought when it comes to comparison,
+   especially inside a loop. Some people prefer to have the less stable
+   value on the left hand side and the more stable value on the right hand
+   side, e.g. if you have a loop that counts variable i down to the
+   lower bound,
+
+	while (i > lower_bound) {
+		do something;
+		i--;
+	}
+
+   Other people prefer to have the textual order of values match the
+   actual order of values in their comparison, so that they can
+   mentally draw a number line from left to right and place these
+   values in order, i.e.
+
+	while (lower_bound < i) {
+		do something;
+		i--;
+	}
+
+   Both are valid, and we use both.  However, the more "stable" the
+   stable side becomes, the more we tend to prefer the former
+   (comparison with a constant, "i > 0", is an extreme example).
+   Just do not mix styles in the same part of the code and mimic
+   existing styles in the neighbourhood.
+
+ - There are two schools of thought when it comes to splitting a long
+   logical line into multiple lines.  Some people push the second and
+   subsequent lines far enough to the right with tabs and align them:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+		span_more_than_a_single_line_of ||
+		the_source_text) {
+                ...
+
+   while other people prefer to align the second and the subsequent
+   lines with the column immediately inside the opening parenthesis,
+   with tabs and spaces, following our "tabstop is always a multiple
+   of 8" convention:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of ||
+	    the_source_text) {
+                ...
+
+   Both are valid, and we use both.  Again, just do not mix styles in
+   the same part of the code and mimic existing styles in the
+   neighbourhood.
+
+ - When splitting a long logical line, some people change line before
+   a binary operator, so that the result looks like a parse tree when
+   you turn your head 90-degrees counterclockwise:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to
+	    || span_more_than_a_single_line_of_the_source_text) {
+
+   while other people prefer to leave the operator at the end of the
+   line:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of_the_source_text) {
+
+   Both are valid, but we tend to use the latter more, unless the
+   expression gets fairly complex, in which case the former tends to
+   be easier to read.  Again, just do not mix styles in the same part
+   of the code and mimic existing styles in the neighbourhood.
+
+ - When splitting a long logical line, with everything else being
+   equal, it is preferable to split after the operator at higher
+   level in the parse tree.  That is, this is more preferable:
+
+	if (a_very_long_variable * that_is_used_in +
+	    a_very_long_expression) {
+		...
+
+   than
+
+	if (a_very_long_variable *
+	    that_is_used_in + a_very_long_expression) {
+		...
+
+ - Some clever tricks, like using the !! operator with arithmetic
+   constructs, can be extremely confusing to others.  Avoid them,
+   unless there is a compelling reason to use them.
+
+ - Use the API.  No, really.  We have a strbuf (variable length
+   string), several arrays with the ALLOC_GROW() macro, a
+   string_list for sorted string lists, a hash map (mapping struct
+   objects) named "struct decorate", amongst other things.
+
+ - When you come up with an API, document it.
+
+ - The first #include in C files, except in platform specific compat/
+   implementations, must be either "git-compat-util.h", "cache.h" or
+   "builtin.h".  You do not have to include more than one of these.
+
+ - A C file must directly include the header files that declare the
+   functions and the types it uses, except for the functions and types
+   that are made available to it by including one of the header files
+   it must include by the previous rule.
+
+ - If you are planning a new command, consider writing it in shell
+   or perl first, so that changes in semantics can be easily
+   changed and discussed.  Many Git commands started out like
+   that, and a few are still scripts.
+
+ - Avoid introducing a new dependency into Git. This means you
+   usually should stay away from scripting languages not already
+   used in the Git core command set (unless your command is clearly
+   separate from it, such as an importer to convert random-scm-X
+   repositories to Git).
+
+ - When we pass <string, length> pair to functions, we should try to
+   pass them in that order.
+
+ - Use Git's gettext wrappers to make the user interface
+   translatable. See "Marking strings for translation" in po/README.
+
+ - Variables and functions local to a given source file should be marked
+   with "static". Variables that are visible to other source files
+   must be declared with "extern" in header files. However, function
+   declarations should not use "extern", as that is already the default.
+
+For Perl programs:
+
+ - Most of the C guidelines above apply.
+
+ - We try to support Perl 5.8 and later ("use Perl 5.008").
+
+ - use strict and use warnings are strongly preferred.
+
+ - Don't overuse statement modifiers unless using them makes the
+   result easier to follow.
+
+	... do something ...
+	do_this() unless (condition);
+        ... do something else ...
+
+   is more readable than:
+
+	... do something ...
+	unless (condition) {
+		do_this();
+	}
+        ... do something else ...
+
+   *only* when the condition is so rare that do_this() will be almost
+   always called.
+
+ - We try to avoid assignments inside "if ()" conditions.
+
+ - Learn and use Git.pm if you need that functionality.
+
+ - For Emacs, it's useful to put the following in
+   GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode:
+
+    ;; note the first part is useful for C editing, too
+    ((nil . ((indent-tabs-mode . t)
+                  (tab-width . 8)
+                  (fill-column . 80)))
+     (cperl-mode . ((cperl-indent-level . 8)
+                    (cperl-extra-newline-before-brace . nil)
+                    (cperl-merge-trailing-else . t))))
+
+For Python scripts:
+
+ - We follow PEP-8 (http://www.python.org/dev/peps/pep-0008/).
+
+ - As a minimum, we aim to be compatible with Python 2.6 and 2.7.
+
+ - Where required libraries do not restrict us to Python 2, we try to
+   also be compatible with Python 3.1 and later.
+
+ - When you must differentiate between Unicode literals and byte string
+   literals, it is OK to use the 'b' prefix.  Even though the Python
+   documentation for version 2.6 does not mention this prefix, it has
+   been supported since version 2.6.0.
+
+Error Messages
+
+ - Do not end error messages with a full stop.
+
+ - Do not capitalize ("unable to open %s", not "Unable to open %s")
+
+ - Say what the error is first ("cannot open %s", not "%s: cannot open")
+
+
+Externally Visible Names
+
+ - For configuration variable names, follow the existing convention:
+
+   . The section name indicates the affected subsystem.
+
+   . The subsection name, if any, indicates which of an unbounded set
+     of things to set the value for.
+
+   . The variable name describes the effect of tweaking this knob.
+
+   The section and variable names that consist of multiple words are
+   formed by concatenating the words without punctuations (e.g. `-`),
+   and are broken using bumpyCaps in documentation as a hint to the
+   reader.
+
+   When choosing the variable namespace, do not use variable name for
+   specifying possibly unbounded set of things, most notably anything
+   an end user can freely come up with (e.g. branch names).  Instead,
+   use subsection names or variable values, like the existing variable
+   branch.<name>.description does.
+
+
+Writing Documentation:
+
+ Most (if not all) of the documentation pages are written in the
+ AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+ processed into HTML and manpages (e.g. git.html and git.1 in the
+ same directory).
+
+ The documentation liberally mixes US and UK English (en_US/UK)
+ norms for spelling and grammar, which is somewhat unfortunate.
+ In an ideal world, it would have been better if it consistently
+ used only one and not the other, and we would have picked en_US
+ (if you wish to correct the English of some of the existing
+ documentation, please see the documentation-related advice in the
+ Documentation/SubmittingPatches file).
+
+ Every user-visible change should be reflected in the documentation.
+ The same general rule as for code applies -- imitate the existing
+ conventions.
+
+ A few commented examples follow to provide reference when writing or
+ modifying command usage strings and synopsis sections in the manual
+ pages:
+
+ Placeholders are spelled in lowercase and enclosed in angle brackets:
+   <file>
+   --sort=<key>
+   --abbrev[=<n>]
+
+ If a placeholder has multiple words, they are separated by dashes:
+   <new-branch-name>
+   --template=<template-directory>
+
+ Possibility of multiple occurrences is indicated by three dots:
+   <file>...
+   (One or more of <file>.)
+
+ Optional parts are enclosed in square brackets:
+   [<extra>]
+   (Zero or one <extra>.)
+
+   --exec-path[=<path>]
+   (Option with an optional argument.  Note that the "=" is inside the
+   brackets.)
+
+   [<patch>...]
+   (Zero or more of <patch>.  Note that the dots are inside, not
+   outside the brackets.)
+
+ Multiple alternatives are indicated with vertical bars:
+   [-q | --quiet]
+   [--utf8 | --no-utf8]
+
+ Parentheses are used for grouping:
+   [(<rev> | <range>)...]
+   (Any number of either <rev> or <range>.  Parens are needed to make
+   it clear that "..." pertains to both <rev> and <range>.)
+
+   [(-p <parent>)...]
+   (Any number of option -p, each with one <parent> argument.)
+
+   git remote set-head <name> (-a | -d | <branch>)
+   (One and only one of "-a", "-d" or "<branch>" _must_ (no square
+   brackets) be provided.)
+
+ And a somewhat more contrived example:
+   --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+   Here "=" is outside the brackets, because "--diff-filter=" is a
+   valid usage.  "*" has its own pair of brackets, because it can
+   (optionally) be specified only when one or more of the letters is
+   also provided.
+
+  A note on notation:
+   Use 'git' (all lowercase) when talking about commands i.e. something
+   the user would type into a shell and use 'Git' (uppercase first letter)
+   when talking about the version control system and its properties.
+
+ A few commented examples follow to provide reference when writing or
+ modifying paragraphs or option/command explanations that contain options
+ or commands:
+
+ Literal examples (e.g. use of command-line options, command names,
+ branch names, configuration and environment variables) must be
+ typeset in monospace (i.e. wrapped with backticks):
+   `--pretty=oneline`
+   `git rev-list`
+   `remote.pushDefault`
+   `GIT_DIR`
+   `HEAD`
+
+ An environment variable must be prefixed with "$" only when referring to its
+ value and not when referring to the variable itself, in this case there is
+ nothing to add except the backticks:
+   `GIT_DIR` is specified
+   `$GIT_DIR/hooks/pre-receive`
+
+ Word phrases enclosed in `backtick characters` are rendered literally
+ and will not be further expanded. The use of `backticks` to achieve the
+ previous rule means that literal examples should not use AsciiDoc
+ escapes.
+   Correct:
+      `--pretty=oneline`
+   Incorrect:
+      `\--pretty=oneline`
+
+ If some place in the documentation needs to typeset a command usage
+ example with inline substitutions, it is fine to use +monospaced and
+ inline substituted text+ instead of `monospaced literal text`, and with
+ the former, the part that should not get substituted must be
+ quoted/escaped.
diff --git a/external/docs/asciidoc/201fe4605e6de6698b4916de3fa8b194a71c5f64 b/external/docs/asciidoc/201fe4605e6de6698b4916de3fa8b194a71c5f64
new file mode 100644
index 0000000000..8579530710
--- /dev/null
+++ b/external/docs/asciidoc/201fe4605e6de6698b4916de3fa8b194a71c5f64
@@ -0,0 +1,610 @@
+Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, a few rough rules are:
+
+ - Most importantly, we never say "It's in POSIX; we'll happily
+   ignore your needs should your system not conform to it."
+   We live in the real world.
+
+ - However, we often say "Let's stay away from that construct,
+   it's not even in POSIX".
+
+ - In spite of the above two rules, we sometimes say "Although
+   this is not in POSIX, it (is so convenient | makes the code
+   much more readable | has other good characteristics) and
+   practically all the platforms we care about support it, so
+   let's use it".
+
+   Again, we live in the real world, and it is sometimes a
+   judgement call, the decision based more on real world
+   constraints people face than what the paper standard says.
+
+ - Fixing style violations while working on a real change as a
+   preparatory clean-up step is good, but otherwise avoid useless code
+   churn for the sake of conforming to the style.
+
+   "Once it _is_ in the tree, it's not really worth the patch noise to
+   go and fix it up."
+   Cf. http://lkml.iu.edu/hypermail/linux/kernel/1001.3/01069.html
+
+Make your code readable and sensible, and don't try to be clever.
+
+As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the _local_
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn't match the overall style of existing code).
+
+But if you must have a list of rules, here they are.
+
+For shell scripts specifically (not exhaustive):
+
+ - We use tabs for indentation.
+
+ - Case arms are indented at the same depth as case and esac lines,
+   like this:
+
+	case "$variable" in
+	pattern1)
+		do this
+		;;
+	pattern2)
+		do that
+		;;
+	esac
+
+ - Redirection operators should be written with space before, but no
+   space after them.  In other words, write 'echo test >"$file"'
+   instead of 'echo test> $file' or 'echo test > $file'.  Note that
+   even though it is not required by POSIX to double-quote the
+   redirection target in a variable (as shown above), our code does so
+   because some versions of bash issue a warning without the quotes.
+
+	(incorrect)
+	cat hello > world < universe
+	echo hello >$world
+
+	(correct)
+	cat hello >world <universe
+	echo hello >"$world"
+
+ - We prefer $( ... ) for command substitution; unlike ``, it
+   properly nests.  It should have been the way Bourne spelled
+   it from day one, but unfortunately isn't.
+
+ - If you want to find out if a command is available on the user's
+   $PATH, you should use 'type <command>', instead of 'which <command>'.
+   The output of 'which' is not machine parseable and its exit code
+   is not reliable across platforms.
+
+ - We use POSIX compliant parameter substitutions and avoid bashisms;
+   namely:
+
+   - We use ${parameter-word} and its [-=?+] siblings, and their
+     colon'ed "unset or null" form.
+
+   - We use ${parameter#word} and its [#%] siblings, and their
+     doubled "longest matching" form.
+
+   - No "Substring Expansion" ${parameter:offset:length}.
+
+   - No shell arrays.
+
+   - No strlen ${#parameter}.
+
+   - No pattern replacement ${parameter/pattern/string}.
+
+ - We use Arithmetic Expansion $(( ... )).
+
+ - Inside Arithmetic Expansion, spell shell variables with $ in front
+   of them, as some shells do not grok $((x)) while accepting $(($x))
+   just fine (e.g. dash older than 0.5.4).
+
+ - We do not use Process Substitution <(list) or >(list).
+
+ - Do not write control structures on a single line with semicolon.
+   "then" should be on the next line for if statements, and "do"
+   should be on the next line for "while" and "for".
+
+	(incorrect)
+	if test -f hello; then
+		do this
+	fi
+
+	(correct)
+	if test -f hello
+	then
+		do this
+	fi
+
+ - If a command sequence joined with && or || or | spans multiple
+   lines, put each command on a separate line and put && and || and |
+   operators at the end of each line, rather than the start. This
+   means you don't need to use \ to join lines, since the above
+   operators imply the sequence isn't finished.
+
+	(incorrect)
+	grep blob verify_pack_result \
+	| awk -f print_1.awk \
+	| sort >actual &&
+	...
+
+	(correct)
+	grep blob verify_pack_result |
+	awk -f print_1.awk |
+	sort >actual &&
+	...
+
+ - We prefer "test" over "[ ... ]".
+
+ - We do not write the noiseword "function" in front of shell
+   functions.
+
+ - We prefer a space between the function name and the parentheses,
+   and no space inside the parentheses. The opening "{" should also
+   be on the same line.
+
+	(incorrect)
+	my_function(){
+		...
+
+	(correct)
+	my_function () {
+		...
+
+ - As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+   [::], [==], or [..]) for portability.
+
+   - We do not use \{m,n\};
+
+   - We do not use -E;
+
+   - We do not use ? or + (which are \{0,1\} and \{1,\}
+     respectively in BRE) but that goes without saying as these
+     are ERE elements not BRE (note that \? and \+ are not even part
+     of BRE -- making them accessible from BRE is a GNU extension).
+
+ - Use Git's gettext wrappers in git-sh-i18n to make the user
+   interface translatable. See "Marking strings for translation" in
+   po/README.
+
+ - We do not write our "test" command with "-a" and "-o" and use "&&"
+   or "||" to concatenate multiple "test" commands instead, because
+   the use of "-a/-o" is often error-prone.  E.g.
+
+     test -n "$x" -a "$a" = "$b"
+
+   is buggy and breaks when $x is "=", but
+
+     test -n "$x" && test "$a" = "$b"
+
+   does not have such a problem.
+
+
+For C programs:
+
+ - We use tabs to indent, and interpret tabs as taking up to
+   8 spaces.
+
+ - We try to keep to at most 80 characters per line.
+
+ - As a Git developer we assume you have a reasonably modern compiler
+   and we recommend you to enable the DEVELOPER makefile knob to
+   ensure your patch is clear of all compiler warnings we care about,
+   by e.g. "echo DEVELOPER=1 >>config.mak".
+
+ - We try to support a wide range of C compilers to compile Git with,
+   including old ones. That means that you should not use C99
+   initializers, even if a lot of compilers grok it.
+
+ - Variables have to be declared at the beginning of the block.
+
+ - NULL pointers shall be written as NULL, not as 0.
+
+ - When declaring pointers, the star sides with the variable
+   name, i.e. "char *string", not "char* string" or
+   "char * string".  This makes it easier to understand code
+   like "char *string, c;".
+
+ - Use whitespace around operators and keywords, but not inside
+   parentheses and not around functions. So:
+
+        while (condition)
+		func(bar + 1);
+
+   and not:
+
+        while( condition )
+		func (bar+1);
+
+ - We avoid using braces unnecessarily.  I.e.
+
+	if (bla) {
+		x = 1;
+	}
+
+   is frowned upon. But there are a few exceptions:
+
+	- When the statement extends over a few lines (e.g., a while loop
+	  with an embedded conditional, or a comment). E.g.:
+
+		while (foo) {
+			if (x)
+				one();
+			else
+				two();
+		}
+
+		if (foo) {
+			/*
+			 * This one requires some explanation,
+			 * so we're better off with braces to make
+			 * it obvious that the indentation is correct.
+			 */
+			doit();
+		}
+
+	- When there are multiple arms to a conditional and some of them
+	  require braces, enclose even a single line block in braces for
+	  consistency. E.g.:
+
+		if (foo) {
+			doit();
+		} else {
+			one();
+			two();
+			three();
+		}
+
+ - We try to avoid assignments in the condition of an "if" statement.
+
+ - Try to make your code understandable.  You may put comments
+   in, but comments invariably tend to stale out when the code
+   they were describing changes.  Often splitting a function
+   into two makes the intention of the code much clearer.
+
+ - Multi-line comments include their delimiters on separate lines from
+   the text.  E.g.
+
+	/*
+	 * A very long
+	 * multi-line comment.
+	 */
+
+   Note however that a comment that explains a translatable string to
+   translators uses a convention of starting with a magic token
+   "TRANSLATORS: ", e.g.
+
+	/*
+	 * TRANSLATORS: here is a comment that explains the string to
+	 * be translated, that follows immediately after it.
+	 */
+	_("Here is a translatable string explained by the above.");
+
+ - Double negation is often harder to understand than no negation
+   at all.
+
+ - There are two schools of thought when it comes to comparison,
+   especially inside a loop. Some people prefer to have the less stable
+   value on the left hand side and the more stable value on the right hand
+   side, e.g. if you have a loop that counts variable i down to the
+   lower bound,
+
+	while (i > lower_bound) {
+		do something;
+		i--;
+	}
+
+   Other people prefer to have the textual order of values match the
+   actual order of values in their comparison, so that they can
+   mentally draw a number line from left to right and place these
+   values in order, i.e.
+
+	while (lower_bound < i) {
+		do something;
+		i--;
+	}
+
+   Both are valid, and we use both.  However, the more "stable" the
+   stable side becomes, the more we tend to prefer the former
+   (comparison with a constant, "i > 0", is an extreme example).
+   Just do not mix styles in the same part of the code and mimic
+   existing styles in the neighbourhood.
+
+ - There are two schools of thought when it comes to splitting a long
+   logical line into multiple lines.  Some people push the second and
+   subsequent lines far enough to the right with tabs and align them:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+		span_more_than_a_single_line_of ||
+		the_source_text) {
+                ...
+
+   while other people prefer to align the second and the subsequent
+   lines with the column immediately inside the opening parenthesis,
+   with tabs and spaces, following our "tabstop is always a multiple
+   of 8" convention:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of ||
+	    the_source_text) {
+                ...
+
+   Both are valid, and we use both.  Again, just do not mix styles in
+   the same part of the code and mimic existing styles in the
+   neighbourhood.
+
+ - When splitting a long logical line, some people change line before
+   a binary operator, so that the result looks like a parse tree when
+   you turn your head 90-degrees counterclockwise:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to
+	    || span_more_than_a_single_line_of_the_source_text) {
+
+   while other people prefer to leave the operator at the end of the
+   line:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of_the_source_text) {
+
+   Both are valid, but we tend to use the latter more, unless the
+   expression gets fairly complex, in which case the former tends to
+   be easier to read.  Again, just do not mix styles in the same part
+   of the code and mimic existing styles in the neighbourhood.
+
+ - When splitting a long logical line, with everything else being
+   equal, it is preferable to split after the operator at higher
+   level in the parse tree.  That is, this is more preferable:
+
+	if (a_very_long_variable * that_is_used_in +
+	    a_very_long_expression) {
+		...
+
+   than
+
+	if (a_very_long_variable *
+	    that_is_used_in + a_very_long_expression) {
+		...
+
+ - Some clever tricks, like using the !! operator with arithmetic
+   constructs, can be extremely confusing to others.  Avoid them,
+   unless there is a compelling reason to use them.
+
+ - Use the API.  No, really.  We have a strbuf (variable length
+   string), several arrays with the ALLOC_GROW() macro, a
+   string_list for sorted string lists, a hash map (mapping struct
+   objects) named "struct decorate", amongst other things.
+
+ - When you come up with an API, document its functions and structures
+   in the header file that exposes the API to its callers. Use what is
+   in "strbuf.h" as a model for the appropriate tone and level of
+   detail.
+
+ - The first #include in C files, except in platform specific compat/
+   implementations, must be either "git-compat-util.h", "cache.h" or
+   "builtin.h".  You do not have to include more than one of these.
+
+ - A C file must directly include the header files that declare the
+   functions and the types it uses, except for the functions and types
+   that are made available to it by including one of the header files
+   it must include by the previous rule.
+
+ - If you are planning a new command, consider writing it in shell
+   or perl first, so that changes in semantics can be easily
+   changed and discussed.  Many Git commands started out like
+   that, and a few are still scripts.
+
+ - Avoid introducing a new dependency into Git. This means you
+   usually should stay away from scripting languages not already
+   used in the Git core command set (unless your command is clearly
+   separate from it, such as an importer to convert random-scm-X
+   repositories to Git).
+
+ - When we pass <string, length> pair to functions, we should try to
+   pass them in that order.
+
+ - Use Git's gettext wrappers to make the user interface
+   translatable. See "Marking strings for translation" in po/README.
+
+ - Variables and functions local to a given source file should be marked
+   with "static". Variables that are visible to other source files
+   must be declared with "extern" in header files. However, function
+   declarations should not use "extern", as that is already the default.
+
+For Perl programs:
+
+ - Most of the C guidelines above apply.
+
+ - We try to support Perl 5.8 and later ("use Perl 5.008").
+
+ - use strict and use warnings are strongly preferred.
+
+ - Don't overuse statement modifiers unless using them makes the
+   result easier to follow.
+
+	... do something ...
+	do_this() unless (condition);
+        ... do something else ...
+
+   is more readable than:
+
+	... do something ...
+	unless (condition) {
+		do_this();
+	}
+        ... do something else ...
+
+   *only* when the condition is so rare that do_this() will be almost
+   always called.
+
+ - We try to avoid assignments inside "if ()" conditions.
+
+ - Learn and use Git.pm if you need that functionality.
+
+ - For Emacs, it's useful to put the following in
+   GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode:
+
+    ;; note the first part is useful for C editing, too
+    ((nil . ((indent-tabs-mode . t)
+                  (tab-width . 8)
+                  (fill-column . 80)))
+     (cperl-mode . ((cperl-indent-level . 8)
+                    (cperl-extra-newline-before-brace . nil)
+                    (cperl-merge-trailing-else . t))))
+
+For Python scripts:
+
+ - We follow PEP-8 (http://www.python.org/dev/peps/pep-0008/).
+
+ - As a minimum, we aim to be compatible with Python 2.6 and 2.7.
+
+ - Where required libraries do not restrict us to Python 2, we try to
+   also be compatible with Python 3.1 and later.
+
+ - When you must differentiate between Unicode literals and byte string
+   literals, it is OK to use the 'b' prefix.  Even though the Python
+   documentation for version 2.6 does not mention this prefix, it has
+   been supported since version 2.6.0.
+
+Error Messages
+
+ - Do not end error messages with a full stop.
+
+ - Do not capitalize ("unable to open %s", not "Unable to open %s")
+
+ - Say what the error is first ("cannot open %s", not "%s: cannot open")
+
+
+Externally Visible Names
+
+ - For configuration variable names, follow the existing convention:
+
+   . The section name indicates the affected subsystem.
+
+   . The subsection name, if any, indicates which of an unbounded set
+     of things to set the value for.
+
+   . The variable name describes the effect of tweaking this knob.
+
+   The section and variable names that consist of multiple words are
+   formed by concatenating the words without punctuations (e.g. `-`),
+   and are broken using bumpyCaps in documentation as a hint to the
+   reader.
+
+   When choosing the variable namespace, do not use variable name for
+   specifying possibly unbounded set of things, most notably anything
+   an end user can freely come up with (e.g. branch names).  Instead,
+   use subsection names or variable values, like the existing variable
+   branch.<name>.description does.
+
+
+Writing Documentation:
+
+ Most (if not all) of the documentation pages are written in the
+ AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+ processed into HTML and manpages (e.g. git.html and git.1 in the
+ same directory).
+
+ The documentation liberally mixes US and UK English (en_US/UK)
+ norms for spelling and grammar, which is somewhat unfortunate.
+ In an ideal world, it would have been better if it consistently
+ used only one and not the other, and we would have picked en_US
+ (if you wish to correct the English of some of the existing
+ documentation, please see the documentation-related advice in the
+ Documentation/SubmittingPatches file).
+
+ Every user-visible change should be reflected in the documentation.
+ The same general rule as for code applies -- imitate the existing
+ conventions.
+
+ A few commented examples follow to provide reference when writing or
+ modifying command usage strings and synopsis sections in the manual
+ pages:
+
+ Placeholders are spelled in lowercase and enclosed in angle brackets:
+   <file>
+   --sort=<key>
+   --abbrev[=<n>]
+
+ If a placeholder has multiple words, they are separated by dashes:
+   <new-branch-name>
+   --template=<template-directory>
+
+ Possibility of multiple occurrences is indicated by three dots:
+   <file>...
+   (One or more of <file>.)
+
+ Optional parts are enclosed in square brackets:
+   [<extra>]
+   (Zero or one <extra>.)
+
+   --exec-path[=<path>]
+   (Option with an optional argument.  Note that the "=" is inside the
+   brackets.)
+
+   [<patch>...]
+   (Zero or more of <patch>.  Note that the dots are inside, not
+   outside the brackets.)
+
+ Multiple alternatives are indicated with vertical bars:
+   [-q | --quiet]
+   [--utf8 | --no-utf8]
+
+ Parentheses are used for grouping:
+   [(<rev> | <range>)...]
+   (Any number of either <rev> or <range>.  Parens are needed to make
+   it clear that "..." pertains to both <rev> and <range>.)
+
+   [(-p <parent>)...]
+   (Any number of option -p, each with one <parent> argument.)
+
+   git remote set-head <name> (-a | -d | <branch>)
+   (One and only one of "-a", "-d" or "<branch>" _must_ (no square
+   brackets) be provided.)
+
+ And a somewhat more contrived example:
+   --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+   Here "=" is outside the brackets, because "--diff-filter=" is a
+   valid usage.  "*" has its own pair of brackets, because it can
+   (optionally) be specified only when one or more of the letters is
+   also provided.
+
+  A note on notation:
+   Use 'git' (all lowercase) when talking about commands i.e. something
+   the user would type into a shell and use 'Git' (uppercase first letter)
+   when talking about the version control system and its properties.
+
+ A few commented examples follow to provide reference when writing or
+ modifying paragraphs or option/command explanations that contain options
+ or commands:
+
+ Literal examples (e.g. use of command-line options, command names,
+ branch names, configuration and environment variables) must be
+ typeset in monospace (i.e. wrapped with backticks):
+   `--pretty=oneline`
+   `git rev-list`
+   `remote.pushDefault`
+   `GIT_DIR`
+   `HEAD`
+
+ An environment variable must be prefixed with "$" only when referring to its
+ value and not when referring to the variable itself, in this case there is
+ nothing to add except the backticks:
+   `GIT_DIR` is specified
+   `$GIT_DIR/hooks/pre-receive`
+
+ Word phrases enclosed in `backtick characters` are rendered literally
+ and will not be further expanded. The use of `backticks` to achieve the
+ previous rule means that literal examples should not use AsciiDoc
+ escapes.
+   Correct:
+      `--pretty=oneline`
+   Incorrect:
+      `\--pretty=oneline`
+
+ If some place in the documentation needs to typeset a command usage
+ example with inline substitutions, it is fine to use +monospaced and
+ inline substituted text+ instead of `monospaced literal text`, and with
+ the former, the part that should not get substituted must be
+ quoted/escaped.
diff --git a/external/docs/asciidoc/251eb6d9ec08d864904404e8cc131eca8ec72284 b/external/docs/asciidoc/251eb6d9ec08d864904404e8cc131eca8ec72284
new file mode 100644
index 0000000000..d42a418009
--- /dev/null
+++ b/external/docs/asciidoc/251eb6d9ec08d864904404e8cc131eca8ec72284
@@ -0,0 +1,179 @@
+Reviewing Patches in the Git Project
+====================================
+
+Introduction
+------------
+The Git development community is a widely distributed, diverse, ever-changing
+group of individuals. Asynchronous communication via the Git mailing list poses
+unique challenges when reviewing or discussing patches. This document contains
+some guiding principles and helpful tools you can use to make your reviews both
+more efficient for yourself and more effective for other contributors.
+
+Note that none of the recommendations here are binding or in any way a
+requirement of participation in the Git community. They are provided as a
+resource to supplement your skills as a contributor.
+
+Principles
+----------
+
+Selecting patch(es) to review
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+If you are looking for a patch series in need of review, start by checking
+the latest "What's cooking in git.git" email
+(https://lore.kernel.org/git/xmqqilm1yp3m.fsf@gitster.g/[example]). The "What's
+cooking" emails & replies can be found using the query `s:"What's cooking"` on
+the https://lore.kernel.org/git/[`lore.kernel.org` mailing list archive];
+alternatively, you can find the contents of the "What's cooking" email tracked
+in `whats-cooking.txt` on the `todo` branch of Git. Topics tagged with "Needs
+review" and those in the "[New Topics]" section are typically those that would
+benefit the most from additional review.
+
+Patches can also be searched manually in the mailing list archive using a query
+like `s:"PATCH" -s:"Re:"`. You can browse these results for topics relevant to
+your expertise or interest.
+
+If you've already contributed to Git, you may also be CC'd in another
+contributor's patch series. These are topics where the author feels that your
+attention is warranted. This may be because their patch changes something you
+wrote previously (making you a good judge of whether the new approach does or
+doesn't work), or because you have the expertise to provide an exceptionally
+helpful review. There is no requirement to review these patches but, in the
+spirit of open source collaboration, you should strongly consider doing so.
+
+Reviewing patches
+~~~~~~~~~~~~~~~~~
+While every contributor takes their own approach to reviewing patches, here are
+some general pieces of advice to make your reviews as clear and helpful as
+possible. The advice is broken into two rough categories: high-level reviewing
+guidance, and concrete tips for interacting with patches on the mailing list.
+
+==== High-level guidance
+- Remember to review the content of commit messages for correctness and clarity,
+  in addition to the code change in the patch's diff. The commit message of a
+  patch should accurately and fully explain the code change being made in the
+  diff.
+
+- Reviewing test coverage is an important - but easy to overlook - component of
+  reviews. A patch's changes may be covered by existing tests, or new tests may
+  be introduced to exercise new behavior. Checking out a patch or series locally
+  allows you to manually mutate lines of new & existing tests to verify expected
+  pass/fail behavior. You can use this information to verify proper coverage or
+  to suggest additional tests the author could add.
+
+- When providing a recommendation, be as clear as possible about whether you
+  consider it "blocking" (the code would be broken or otherwise made worse if an
+  issue isn't fixed) or "non-blocking" (the patch could be made better by taking
+  the recommendation, but acceptance of the series does not require it).
+  Non-blocking recommendations can be particularly ambiguous when they are
+  related to - but outside the scope of - a series ("nice-to-have"s), or when
+  they represent only stylistic differences between the author and reviewer.
+
+- When commenting on an issue, try to include suggestions for how the author
+  could fix it. This not only helps the author to understand and fix the issue,
+  it also deepens and improves your understanding of the topic.
+
+- Reviews do not need to exclusively point out problems.  Positive
+  reviews indicate that it is not only the original author of the
+  patches who care about the issue the patches address, and are
+  highly encouraged.
+
+- Do not hesitate to give positive reviews on a series from your
+  work colleague.  If your positive review is written well, it will
+  not make you look as if you two are representing corporate
+  interest on a series that is otherwise uninteresting to other
+  community members and shoving it down their throat.
+
+- Write a positive review in such a way that others can understand
+  why you support the goal, the approach, and the implementation the
+  patches took.  Make sure to demonstrate that you did thoroughly read
+  the series and understood problem area well enough to be able to
+  say that the patches are written well.  Feel free to "think out
+  loud" in your review: describe how you read & understood a complex section of
+  a patch, ask a question about something that confused you, point out something
+  you found exceptionally well-written, etc.
+
+- In particular, uplifting feedback goes a long way towards
+  encouraging contributors to participate more actively in the Git
+  community.
+
+==== Performing your review
+- Provide your review comments per-patch in a plaintext "Reply-All" email to the
+  relevant patch. Comments should be made inline, immediately below the relevant
+  section(s).
+
+- You may find that the limited context provided in the patch diff is sometimes
+  insufficient for a thorough review. In such cases, you can review patches in
+  your local tree by either applying patches with linkgit:git-am[1] or checking
+  out the associated branch from https://github.com/gitster/git once the series
+  is tracked there.
+
+- Large, complicated patch diffs are sometimes unavoidable, such as when they
+  refactor existing code. If you find such a patch difficult to parse, try
+  reviewing the diff produced with the `--color-moved` and/or
+  `--ignore-space-change` options.
+
+- If a patch is long, you are encouraged to delete parts of it that are
+  unrelated to your review from the email reply. Make sure to leave enough
+  context for readers to understand your comments!
+
+- If you cannot complete a full review of a series all at once, consider letting
+  the author know (on- or off-list) if/when you plan to review the rest of the
+  series.
+
+Completing a review
+~~~~~~~~~~~~~~~~~~~
+Once each patch of a series is reviewed, the author (and/or other contributors)
+may discuss the review(s). This may result in no changes being applied, or the
+author will send a new version of their patch(es).
+
+After a series is rerolled in response to your or others' review, make sure to
+re-review the updates. If you are happy with the state of the patch series,
+explicitly indicate your approval (typically with a reply to the latest
+version's cover letter). Optionally, you can let the author know that they can
+add a "Reviewed-by: <you>" trailer if they resubmit the reviewed patch verbatim
+in a later iteration of the series.
+
+Finally, subsequent "What's cooking" emails may explicitly ask whether a
+reviewed topic is ready for merging to the `next` branch (typically phrased
+"Will merge to \'next\'?"). You can help the maintainer and author by responding
+with a short description of the state of your (and others', if applicable)
+review, including the links to the relevant thread(s).
+
+Terminology
+-----------
+nit: ::
+	Denotes a small issue that should be fixed, such as a typographical error
+	or misalignment of conditions in an `if()` statement.
+
+aside: ::
+optional: ::
+non-blocking: ::
+	Indicates to the reader that the following comment should not block the
+	acceptance of the patch or series. These are typically recommendations
+	related to code organization & style, or musings about topics related to
+	the patch in question, but beyond its scope.
+
+s/<before>/<after>/::
+	Shorthand for "you wrote <before>, but I think you meant <after>," usually
+	for misspellings or other typographical errors. The syntax is a reference
+	to "substitute" command commonly found in Unix tools such as `ed`, `sed`,
+	`vim`, and `perl`.
+
+cover letter::
+	The "Patch 0" of a multi-patch series. This email describes the
+	high-level intent and structure of the patch series to readers on the
+	Git mailing list. It is also where the changelog notes and range-diff of
+	subsequent versions are provided by the author.
++
+On single-patch submissions, cover letter content is typically not sent as a
+separate email. Instead, it is inserted between the end of the patch's commit
+message (after the `---`) and the beginning of the diff.
+
+#leftoverbits::
+  Used by either an author or a reviewer to describe features or suggested
+  changes that are out-of-scope of a given patch or series, but are relevant
+  to the topic for the sake of discussion.
+
+See Also
+--------
+link:/docs/MyFirstContribution[MyFirstContribution]
diff --git a/external/docs/asciidoc/2e9671e52ffadcf2df658fe919633f6aba936a06 b/external/docs/asciidoc/2e9671e52ffadcf2df658fe919633f6aba936a06
new file mode 100644
index 0000000000..3263245b03
--- /dev/null
+++ b/external/docs/asciidoc/2e9671e52ffadcf2df658fe919633f6aba936a06
@@ -0,0 +1,917 @@
+Like other projects, we also have some guidelines for our code.  For
+Git in general, a few rough rules are:
+
+ - Most importantly, we never say "It's in POSIX; we'll happily
+   ignore your needs should your system not conform to it."
+   We live in the real world.
+
+ - However, we often say "Let's stay away from that construct,
+   it's not even in POSIX".
+
+ - In spite of the above two rules, we sometimes say "Although
+   this is not in POSIX, it (is so convenient | makes the code
+   much more readable | has other good characteristics) and
+   practically all the platforms we care about support it, so
+   let's use it".
+
+   Again, we live in the real world, and it is sometimes a
+   judgement call, the decision based more on real world
+   constraints people face than what the paper standard says.
+
+ - Fixing style violations while working on a real change as a
+   preparatory clean-up step is good, but otherwise avoid useless code
+   churn for the sake of conforming to the style.
+
+   "Once it _is_ in the tree, it's not really worth the patch noise to
+   go and fix it up."
+   Cf. https://lore.kernel.org/all/20100126160632.3bdbe172.akpm@linux-foundation.org/
+
+ - Log messages to explain your changes are as important as the
+   changes themselves.  Clearly written code and in-code comments
+   explain how the code works and what is assumed from the surrounding
+   context.  The log messages explain what the changes wanted to
+   achieve and why the changes were necessary (more on this in the
+   accompanying SubmittingPatches document).
+
+Make your code readable and sensible, and don't try to be clever.
+
+As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the _local_
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code are expected to match the style the surrounding code already
+uses (even if it doesn't match the overall style of existing code).
+
+But if you must have a list of rules, here are some language
+specific ones. Note that Documentation/ToolsForGit.txt document
+has a collection of tips to help you use some external tools
+to conform to these guidelines.
+
+For shell scripts specifically (not exhaustive):
+
+ - We use tabs for indentation.
+
+ - Case arms are indented at the same depth as case and esac lines,
+   like this:
+
+	case "$variable" in
+	pattern1)
+		do this
+		;;
+	pattern2)
+		do that
+		;;
+	esac
+
+ - Redirection operators should be written with space before, but no
+   space after them.  In other words, write 'echo test >"$file"'
+   instead of 'echo test> $file' or 'echo test > $file'.  Note that
+   even though it is not required by POSIX to double-quote the
+   redirection target in a variable (as shown above), our code does so
+   because some versions of bash issue a warning without the quotes.
+
+	(incorrect)
+	cat hello > world < universe
+	echo hello >$world
+
+	(correct)
+	cat hello >world <universe
+	echo hello >"$world"
+
+ - We prefer $( ... ) for command substitution; unlike ``, it
+   properly nests.  It should have been the way Bourne spelled
+   it from day one, but unfortunately isn't.
+
+ - If you want to find out if a command is available on the user's
+   $PATH, you should use 'type <command>', instead of 'which <command>'.
+   The output of 'which' is not machine parsable and its exit code
+   is not reliable across platforms.
+
+ - We use POSIX compliant parameter substitutions and avoid bashisms;
+   namely:
+
+   - We use ${parameter-word} and its [-=?+] siblings, and their
+     colon'ed "unset or null" form.
+
+   - We use ${parameter#word} and its [#%] siblings, and their
+     doubled "longest matching" form.
+
+   - No "Substring Expansion" ${parameter:offset:length}.
+
+   - No shell arrays.
+
+   - No pattern replacement ${parameter/pattern/string}.
+
+ - We use Arithmetic Expansion $(( ... )).
+
+ - We do not use Process Substitution <(list) or >(list).
+
+ - Do not write control structures on a single line with semicolon.
+   "then" should be on the next line for if statements, and "do"
+   should be on the next line for "while" and "for".
+
+	(incorrect)
+	if test -f hello; then
+		do this
+	fi
+
+	(correct)
+	if test -f hello
+	then
+		do this
+	fi
+
+ - If a command sequence joined with && or || or | spans multiple
+   lines, put each command on a separate line and put && and || and |
+   operators at the end of each line, rather than the start. This
+   means you don't need to use \ to join lines, since the above
+   operators imply the sequence isn't finished.
+
+	(incorrect)
+	grep blob verify_pack_result \
+	| awk -f print_1.awk \
+	| sort >actual &&
+	...
+
+	(correct)
+	grep blob verify_pack_result |
+	awk -f print_1.awk |
+	sort >actual &&
+	...
+
+ - We prefer "test" over "[ ... ]".
+
+ - We do not write the noiseword "function" in front of shell
+   functions.
+
+ - We prefer a space between the function name and the parentheses,
+   and no space inside the parentheses. The opening "{" should also
+   be on the same line.
+
+	(incorrect)
+	my_function(){
+		...
+
+	(correct)
+	my_function () {
+		...
+
+ - As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+   [::], [==], or [..]) for portability.
+
+   - We do not use \{m,n\};
+
+   - We do not use ? or + (which are \{0,1\} and \{1,\}
+     respectively in BRE) but that goes without saying as these
+     are ERE elements not BRE (note that \? and \+ are not even part
+     of BRE -- making them accessible from BRE is a GNU extension).
+
+ - Use Git's gettext wrappers in git-sh-i18n to make the user
+   interface translatable. See "Marking strings for translation" in
+   po/README.
+
+ - We do not write our "test" command with "-a" and "-o" and use "&&"
+   or "||" to concatenate multiple "test" commands instead, because
+   the use of "-a/-o" is often error-prone.  E.g.
+
+     test -n "$x" -a "$a" = "$b"
+
+   is buggy and breaks when $x is "=", but
+
+     test -n "$x" && test "$a" = "$b"
+
+   does not have such a problem.
+
+ - Even though "local" is not part of POSIX, we make heavy use of it
+   in our test suite.  We do not use it in scripted Porcelains, and
+   hopefully nobody starts using "local" before all shells that matter
+   support it (notably, ksh from AT&T Research does not support it yet).
+
+ - Some versions of shell do not understand "export variable=value",
+   so we write "variable=value" and then "export variable" on two
+   separate lines.
+
+ - Some versions of dash have broken variable assignment when prefixed
+   with "local", "export", and "readonly", in that the value to be
+   assigned goes through field splitting at $IFS unless quoted.
+
+	(incorrect)
+	local variable=$value
+	local variable=$(command args)
+
+	(correct)
+	local variable="$value"
+	local variable="$(command args)"
+
+ - The common construct
+
+	VAR=VAL command args
+
+   to temporarily set and export environment variable VAR only while
+   "command args" is running is handy, but this triggers an
+   unspecified behaviour according to POSIX when used for a command
+   that is not an external command (like shell functions).  Indeed,
+   dash 0.5.10.2-6 on Ubuntu 20.04, /bin/sh on FreeBSD 13, and AT&T
+   ksh all make a temporary assignment without exporting the variable,
+   in such a case.  As it does not work portably across shells, do not
+   use this syntax for shell functions.  A common workaround is to do
+   an explicit export in a subshell, like so:
+
+	(incorrect)
+	VAR=VAL func args
+
+	(correct)
+	(
+		VAR=VAL &&
+		export VAR &&
+		func args
+	)
+
+   but be careful that the effect "func" makes to the variables in the
+   current shell will be lost across the subshell boundary.
+
+ - Use octal escape sequences (e.g. "\302\242"), not hexadecimal (e.g.
+   "\xc2\xa2") in printf format strings, since hexadecimal escape
+   sequences are not portable.
+
+
+For C programs:
+
+ - We use tabs to indent, and interpret tabs as taking up to
+   8 spaces.
+
+ - Nested C preprocessor directives are indented after the hash by one
+   space per nesting level.
+
+	#if FOO
+	# include <foo.h>
+	# if BAR
+	#  include <bar.h>
+	# endif
+	#endif
+
+ - We try to keep to at most 80 characters per line.
+
+ - As a Git developer we assume you have a reasonably modern compiler
+   and we recommend you to enable the DEVELOPER makefile knob to
+   ensure your patch is clear of all compiler warnings we care about,
+   by e.g. "echo DEVELOPER=1 >>config.mak".
+
+ - When using DEVELOPER=1 mode, you may see warnings from the compiler
+   like "error: unused parameter 'foo' [-Werror=unused-parameter]",
+   which indicates that a function ignores its argument. If the unused
+   parameter can't be removed (e.g., because the function is used as a
+   callback and has to match a certain interface), you can annotate
+   the individual parameters with the UNUSED (or MAYBE_UNUSED)
+   keyword, like "int foo UNUSED".
+
+ - We try to support a wide range of C compilers to compile Git with,
+   including old ones.  As of Git v2.35.0 Git requires C99 (we check
+   "__STDC_VERSION__"). You should not use features from a newer C
+   standard, even if your compiler groks them.
+
+   New C99 features have been phased in gradually, if something's new
+   in C99 but not used yet don't assume that it's safe to use, some
+   compilers we target have only partial support for it. These are
+   considered safe to use:
+
+   . since around 2007 with 2b6854c863a, we have been using
+     initializer elements which are not computable at load time. E.g.:
+
+	const char *args[] = { "constant", variable, NULL };
+
+   . since early 2012 with e1327023ea, we have been using an enum
+     definition whose last element is followed by a comma.  This, like
+     an array initializer that ends with a trailing comma, can be used
+     to reduce the patch noise when adding a new identifier at the end.
+
+   . since mid 2017 with cbc0f81d, we have been using designated
+     initializers for struct (e.g. "struct t v = { .val = 'a' };").
+
+   . since mid 2017 with 512f41cf, we have been using designated
+     initializers for array (e.g. "int array[10] = { [5] = 2 }").
+
+   . since early 2021 with 765dc168882, we have been using variadic
+     macros, mostly for printf-like trace and debug macros.
+
+   . since late 2021 with 44ba10d6, we have had variables declared in
+     the for loop "for (int i = 0; i < 10; i++)".
+
+   New C99 features that we cannot use yet:
+
+   . %z and %zu as a printf() argument for a size_t (the %z being for
+     the POSIX-specific ssize_t). Instead you should use
+     printf("%"PRIuMAX, (uintmax_t)v).  These days the MSVC version we
+     rely on supports %z, but the C library used by MinGW does not.
+
+   . Shorthand like ".a.b = *c" in struct initializations is known to
+     trip up an older IBM XLC version, use ".a = { .b = *c }" instead.
+     See the 33665d98 (reftable: make assignments portable to AIX xlc
+     v12.01, 2022-03-28).
+
+ - Variables have to be declared at the beginning of the block, before
+   the first statement (i.e. -Wdeclaration-after-statement).  It is
+   encouraged to have a blank line between the end of the declarations
+   and the first statement in the block.
+
+ - NULL pointers shall be written as NULL, not as 0.
+
+ - When declaring pointers, the star sides with the variable
+   name, i.e. "char *string", not "char* string" or
+   "char * string".  This makes it easier to understand code
+   like "char *string, c;".
+
+ - Use whitespace around operators and keywords, but not inside
+   parentheses and not around functions. So:
+
+        while (condition)
+		func(bar + 1);
+
+   and not:
+
+        while( condition )
+		func (bar+1);
+
+ - A binary operator (other than ",") and ternary conditional "?:"
+   have a space on each side of the operator to separate it from its
+   operands.  E.g. "A + 1", not "A+1".
+
+ - A unary operator (other than "." and "->") have no space between it
+   and its operand.  E.g. "(char *)ptr", not "(char *) ptr".
+
+ - Do not explicitly compare an integral value with constant 0 or '\0',
+   or a pointer value with constant NULL.  For instance, to validate that
+   counted array <ptr, cnt> is initialized but has no elements, write:
+
+	if (!ptr || cnt)
+		BUG("empty array expected");
+
+   and not:
+
+	if (ptr == NULL || cnt != 0);
+		BUG("empty array expected");
+
+ - We avoid using braces unnecessarily.  I.e.
+
+	if (bla) {
+		x = 1;
+	}
+
+   is frowned upon. But there are a few exceptions:
+
+	- When the statement extends over a few lines (e.g., a while loop
+	  with an embedded conditional, or a comment). E.g.:
+
+		while (foo) {
+			if (x)
+				one();
+			else
+				two();
+		}
+
+		if (foo) {
+			/*
+			 * This one requires some explanation,
+			 * so we're better off with braces to make
+			 * it obvious that the indentation is correct.
+			 */
+			doit();
+		}
+
+	- When there are multiple arms to a conditional and some of them
+	  require braces, enclose even a single line block in braces for
+	  consistency. E.g.:
+
+		if (foo) {
+			doit();
+		} else {
+			one();
+			two();
+			three();
+		}
+
+ - We try to avoid assignments in the condition of an "if" statement.
+
+ - Try to make your code understandable.  You may put comments
+   in, but comments invariably tend to stale out when the code
+   they were describing changes.  Often splitting a function
+   into two makes the intention of the code much clearer.
+
+ - Multi-line comments include their delimiters on separate lines from
+   the text.  E.g.
+
+	/*
+	 * A very long
+	 * multi-line comment.
+	 */
+
+   Note however that a comment that explains a translatable string to
+   translators uses a convention of starting with a magic token
+   "TRANSLATORS: ", e.g.
+
+	/*
+	 * TRANSLATORS: here is a comment that explains the string to
+	 * be translated, that follows immediately after it.
+	 */
+	_("Here is a translatable string explained by the above.");
+
+ - Double negation is often harder to understand than no negation
+   at all.
+
+ - There are two schools of thought when it comes to comparison,
+   especially inside a loop. Some people prefer to have the less stable
+   value on the left hand side and the more stable value on the right hand
+   side, e.g. if you have a loop that counts variable i down to the
+   lower bound,
+
+	while (i > lower_bound) {
+		do something;
+		i--;
+	}
+
+   Other people prefer to have the textual order of values match the
+   actual order of values in their comparison, so that they can
+   mentally draw a number line from left to right and place these
+   values in order, i.e.
+
+	while (lower_bound < i) {
+		do something;
+		i--;
+	}
+
+   Both are valid, and we use both.  However, the more "stable" the
+   stable side becomes, the more we tend to prefer the former
+   (comparison with a constant, "i > 0", is an extreme example).
+   Just do not mix styles in the same part of the code and mimic
+   existing styles in the neighbourhood.
+
+ - There are two schools of thought when it comes to splitting a long
+   logical line into multiple lines.  Some people push the second and
+   subsequent lines far enough to the right with tabs and align them:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+		span_more_than_a_single_line_of ||
+		the_source_text) {
+                ...
+
+   while other people prefer to align the second and the subsequent
+   lines with the column immediately inside the opening parenthesis,
+   with tabs and spaces, following our "tabstop is always a multiple
+   of 8" convention:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of ||
+	    the_source_text) {
+                ...
+
+   Both are valid, and we use both.  Again, just do not mix styles in
+   the same part of the code and mimic existing styles in the
+   neighbourhood.
+
+ - When splitting a long logical line, some people change line before
+   a binary operator, so that the result looks like a parse tree when
+   you turn your head 90-degrees counterclockwise:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to
+	    || span_more_than_a_single_line_of_the_source_text) {
+
+   while other people prefer to leave the operator at the end of the
+   line:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of_the_source_text) {
+
+   Both are valid, but we tend to use the latter more, unless the
+   expression gets fairly complex, in which case the former tends to
+   be easier to read.  Again, just do not mix styles in the same part
+   of the code and mimic existing styles in the neighbourhood.
+
+ - When splitting a long logical line, with everything else being
+   equal, it is preferable to split after the operator at higher
+   level in the parse tree.  That is, this is more preferable:
+
+	if (a_very_long_variable * that_is_used_in +
+	    a_very_long_expression) {
+		...
+
+   than
+
+	if (a_very_long_variable *
+	    that_is_used_in + a_very_long_expression) {
+		...
+
+ - Some clever tricks, like using the !! operator with arithmetic
+   constructs, can be extremely confusing to others.  Avoid them,
+   unless there is a compelling reason to use them.
+
+ - Use the API.  No, really.  We have a strbuf (variable length
+   string), several arrays with the ALLOC_GROW() macro, a
+   string_list for sorted string lists, a hash map (mapping struct
+   objects) named "struct decorate", amongst other things.
+
+ - When you come up with an API, document its functions and structures
+   in the header file that exposes the API to its callers. Use what is
+   in "strbuf.h" as a model for the appropriate tone and level of
+   detail.
+
+ - The first #include in C files, except in platform specific compat/
+   implementations and sha1dc/, must be <git-compat-util.h>.  This
+   header file insulates other header files and source files from
+   platform differences, like which system header files must be
+   included in what order, and what C preprocessor feature macros must
+   be defined to trigger certain features we expect out of the system.
+   A collorary to this is that C files should not directly include
+   system header files themselves.
+
+   There are some exceptions, because certain group of files that
+   implement an API all have to include the same header file that
+   defines the API and it is convenient to include <git-compat-util.h>
+   there.  Namely:
+
+   - the implementation of the built-in commands in the "builtin/"
+     directory that include "builtin.h" for the cmd_foo() prototype
+     definition,
+
+   - the test helper programs in the "t/helper/" directory that include
+     "t/helper/test-tool.h" for the cmd__foo() prototype definition,
+
+   - the xdiff implementation in the "xdiff/" directory that includes
+     "xdiff/xinclude.h" for the xdiff machinery internals,
+
+   - the unit test programs in "t/unit-tests/" directory that include
+     "t/unit-tests/test-lib.h" that gives them the unit-tests
+     framework, and
+
+   - the source files that implement reftable in the "reftable/"
+     directory that include "reftable/system.h" for the reftable
+     internals,
+
+   are allowed to assume that they do not have to include
+   <git-compat-util.h> themselves, as it is included as the first
+   '#include' in these header files.  These headers must be the first
+   header file to be "#include"d in them, though.
+
+ - A C file must directly include the header files that declare the
+   functions and the types it uses, except for the functions and types
+   that are made available to it by including one of the header files
+   it must include by the previous rule.
+
+ - If you are planning a new command, consider writing it in shell
+   or perl first, so that changes in semantics can be easily
+   changed and discussed.  Many Git commands started out like
+   that, and a few are still scripts.
+
+ - Avoid introducing a new dependency into Git. This means you
+   usually should stay away from scripting languages not already
+   used in the Git core command set (unless your command is clearly
+   separate from it, such as an importer to convert random-scm-X
+   repositories to Git).
+
+ - When we pass <string, length> pair to functions, we should try to
+   pass them in that order.
+
+ - Use Git's gettext wrappers to make the user interface
+   translatable. See "Marking strings for translation" in po/README.
+
+ - Variables and functions local to a given source file should be marked
+   with "static". Variables that are visible to other source files
+   must be declared with "extern" in header files. However, function
+   declarations should not use "extern", as that is already the default.
+
+ - You can launch gdb around your program using the shorthand GIT_DEBUGGER.
+   Run `GIT_DEBUGGER=1 ./bin-wrappers/git foo` to simply use gdb as is, or
+   run `GIT_DEBUGGER="<debugger> <debugger-args>" ./bin-wrappers/git foo` to
+   use your own debugger and arguments. Example: `GIT_DEBUGGER="ddd --gdb"
+   ./bin-wrappers/git log` (See `wrap-for-bin.sh`.)
+
+ - The primary data structure that a subsystem 'S' deals with is called
+   `struct S`. Functions that operate on `struct S` are named
+   `S_<verb>()` and should generally receive a pointer to `struct S` as
+   first parameter. E.g.
+
+	struct strbuf;
+
+	void strbuf_add(struct strbuf *buf, ...);
+
+	void strbuf_reset(struct strbuf *buf);
+
+    is preferred over:
+
+	struct strbuf;
+
+	void add_string(struct strbuf *buf, ...);
+
+	void reset_strbuf(struct strbuf *buf);
+
+ - There are several common idiomatic names for functions performing
+   specific tasks on a structure `S`:
+
+    - `S_init()` initializes a structure without allocating the
+      structure itself.
+
+    - `S_release()` releases a structure's contents without freeing the
+      structure.
+
+    - `S_clear()` is equivalent to `S_release()` followed by `S_init()`
+      such that the structure is directly usable after clearing it. When
+      `S_clear()` is provided, `S_init()` shall not allocate resources
+      that need to be released again.
+
+    - `S_free()` releases a structure's contents and frees the
+      structure.
+
+For Perl programs:
+
+ - Most of the C guidelines above apply.
+
+ - We try to support Perl 5.8.1 and later ("use Perl 5.008001").
+
+ - use strict and use warnings are strongly preferred.
+
+ - Don't overuse statement modifiers unless using them makes the
+   result easier to follow.
+
+	... do something ...
+	do_this() unless (condition);
+        ... do something else ...
+
+   is more readable than:
+
+	... do something ...
+	unless (condition) {
+		do_this();
+	}
+        ... do something else ...
+
+   *only* when the condition is so rare that do_this() will be almost
+   always called.
+
+ - We try to avoid assignments inside "if ()" conditions.
+
+ - Learn and use Git.pm if you need that functionality.
+
+For Python scripts:
+
+ - We follow PEP-8 (https://peps.python.org/pep-0008/).
+
+ - As a minimum, we aim to be compatible with Python 2.7.
+
+ - Where required libraries do not restrict us to Python 2, we try to
+   also be compatible with Python 3.1 and later.
+
+
+Program Output
+
+ We make a distinction between a Git command's primary output and
+ output which is merely chatty feedback (for instance, status
+ messages, running transcript, or progress display), as well as error
+ messages. Roughly speaking, a Git command's primary output is that
+ which one might want to capture to a file or send down a pipe; its
+ chatty output should not interfere with these use-cases.
+
+ As such, primary output should be sent to the standard output stream
+ (stdout), and chatty output should be sent to the standard error
+ stream (stderr). Examples of commands which produce primary output
+ include `git log`, `git show`, and `git branch --list` which generate
+ output on the stdout stream.
+
+ Not all Git commands have primary output; this is often true of
+ commands whose main function is to perform an action. Some action
+ commands are silent, whereas others are chatty. An example of a
+ chatty action commands is `git clone` with its "Cloning into
+ '<path>'..." and "Checking connectivity..." status messages which it
+ sends to the stderr stream.
+
+ Error messages from Git commands should always be sent to the stderr
+ stream.
+
+
+Error Messages
+
+ - Do not end error messages with a full stop.
+
+ - Do not capitalize the first word, only because it is the first word
+   in the message ("unable to open %s", not "Unable to open %s").  But
+   "SHA-3 not supported" is fine, because the reason the first word is
+   capitalized is not because it is at the beginning of the sentence,
+   but because the word would be spelled in capital letters even when
+   it appeared in the middle of the sentence.
+
+ - Say what the error is first ("cannot open %s", not "%s: cannot open")
+
+
+Externally Visible Names
+
+ - For configuration variable names, follow the existing convention:
+
+   . The section name indicates the affected subsystem.
+
+   . The subsection name, if any, indicates which of an unbounded set
+     of things to set the value for.
+
+   . The variable name describes the effect of tweaking this knob.
+
+   The section and variable names that consist of multiple words are
+   formed by concatenating the words without punctuation marks (e.g. `-`),
+   and are broken using bumpyCaps in documentation as a hint to the
+   reader.
+
+   When choosing the variable namespace, do not use variable name for
+   specifying possibly unbounded set of things, most notably anything
+   an end user can freely come up with (e.g. branch names).  Instead,
+   use subsection names or variable values, like the existing variable
+   branch.<name>.description does.
+
+
+Writing Documentation:
+
+ Most (if not all) of the documentation pages are written in the
+ AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+ processed into HTML and manpages (e.g. git.html and git.1 in the
+ same directory).
+
+ The documentation liberally mixes US and UK English (en_US/UK)
+ norms for spelling and grammar, which is somewhat unfortunate.
+ In an ideal world, it would have been better if it consistently
+ used only one and not the other, and we would have picked en_US
+ (if you wish to correct the English of some of the existing
+ documentation, please see the documentation-related advice in the
+ Documentation/SubmittingPatches file).
+
+ In order to ensure the documentation is inclusive, avoid assuming
+ that an unspecified example person is male or female, and think
+ twice before using "he", "him", "she", or "her".  Here are some
+ tips to avoid use of gendered pronouns:
+
+  - Prefer succinctness and matter-of-factly describing functionality
+    in the abstract.  E.g.
+
+     `--short`:: Emit output in the short-format.
+
+    and avoid something like these overly verbose alternatives:
+
+     `--short`:: Use this to emit output in the short-format.
+     `--short`:: You can use this to get output in the short-format.
+     `--short`:: A user who prefers shorter output could....
+     `--short`:: Should a person and/or program want shorter output, he
+                 she/they/it can...
+
+    This practice often eliminates the need to involve human actors in
+    your description, but it is a good practice regardless of the
+    avoidance of gendered pronouns.
+
+  - When it becomes awkward to stick to this style, prefer "you" when
+    addressing the hypothetical user, and possibly "we" when
+    discussing how the program might react to the user.  E.g.
+
+      You can use this option instead of `--xyz`, but we might remove
+      support for it in future versions.
+
+    while keeping in mind that you can probably be less verbose, e.g.
+
+      Use this instead of `--xyz`. This option might be removed in future
+      versions.
+
+  - If you still need to refer to an example person that is
+    third-person singular, you may resort to "singular they" to avoid
+    "he/she/him/her", e.g.
+
+      A contributor asks their upstream to pull from them.
+
+    Note that this sounds ungrammatical and unnatural to those who
+    learned that "they" is only used for third-person plural, e.g.
+    those who learn English as a second language in some parts of the
+    world.
+
+ Every user-visible change should be reflected in the documentation.
+ The same general rule as for code applies -- imitate the existing
+ conventions.
+
+
+Markup:
+
+ Literal parts (e.g. use of command-line options, command names,
+ branch names, URLs, pathnames (files and directories), configuration and
+ environment variables) must be typeset as verbatim (i.e. wrapped with
+ backticks):
+   `--pretty=oneline`
+   `git rev-list`
+   `remote.pushDefault`
+   `http://git.example.com`
+   `.git/config`
+   `GIT_DIR`
+   `HEAD`
+   `umask`(2)
+
+ An environment variable must be prefixed with "$" only when referring to its
+ value and not when referring to the variable itself, in this case there is
+ nothing to add except the backticks:
+   `GIT_DIR` is specified
+   `$GIT_DIR/hooks/pre-receive`
+
+ Word phrases enclosed in `backtick characters` are rendered literally
+ and will not be further expanded. The use of `backticks` to achieve the
+ previous rule means that literal examples should not use AsciiDoc
+ escapes.
+   Correct:
+      `--pretty=oneline`
+   Incorrect:
+      `\--pretty=oneline`
+
+ Placeholders are spelled in lowercase and enclosed in
+ angle brackets surrounded by underscores:
+   _<file>_
+   _<commit>_
+
+ If a placeholder has multiple words, they are separated by dashes:
+   _<new-branch-name>_
+   _<template-directory>_
+
+ A placeholder is not enclosed in backticks, as it is not a literal.
+
+ When needed, use a distinctive identifier for placeholders, usually
+ made of a qualification and a type:
+   _<git-dir>_
+   _<key-id>_
+
+ When literal and placeholders are mixed, each markup is applied for
+ each sub-entity. If they are stuck, a special markup, called
+ unconstrained formatting is required.
+ Unconstrained formating for placeholders is __<like-this>__
+ Unconstrained formatting for literal formatting is ++like this++
+   `--jobs` _<n>_
+   ++--sort=++__<key>__
+   __<directory>__++/.git++
+   ++remote.++__<name>__++.mirror++
+
+ caveat: ++ unconstrained format is not verbatim and may expand
+ content. Use Asciidoc escapes inside them.
+
+Synopsis Syntax
+
+ Syntax grammar is formatted neither as literal nor as placeholder.
+
+ A few commented examples follow to provide reference when writing or
+ modifying command usage strings and synopsis sections in the manual
+ pages:
+
+ Possibility of multiple occurrences is indicated by three dots:
+   _<file>_...
+   (One or more of <file>.)
+
+ Optional parts are enclosed in square brackets:
+   [_<file>_...]
+   (Zero or more of <file>.)
+
+   ++--exec-path++[++=++__<path>__]
+   (Option with an optional argument.  Note that the "=" is inside the
+   brackets.)
+
+   [_<patch>_...]
+   (Zero or more of <patch>.  Note that the dots are inside, not
+   outside the brackets.)
+
+ Multiple alternatives are indicated with vertical bars:
+   [`-q` | `--quiet`]
+   [`--utf8` | `--no-utf8`]
+
+ Use spacing around "|" token(s), but not immediately after opening or
+ before closing a [] or () pair:
+   Do: [`-q` | `--quiet`]
+   Don't: [`-q`|`--quiet`]
+
+ Don't use spacing around "|" tokens when they're used to separate the
+ alternate arguments of an option:
+    Do: ++--track++[++=++(`direct`|`inherit`)]`
+    Don't: ++--track++[++=++(`direct` | `inherit`)]
+
+ Parentheses are used for grouping:
+   [(_<rev>_ | _<range>_)...]
+   (Any number of either <rev> or <range>.  Parens are needed to make
+   it clear that "..." pertains to both <rev> and <range>.)
+
+   [(`-p` _<parent>_)...]
+   (Any number of option -p, each with one <parent> argument.)
+
+   `git remote set-head` _<name>_ (`-a` | `-d` | _<branch>_)
+   (One and only one of "-a", "-d" or "<branch>" _must_ (no square
+   brackets) be provided.)
+
+ And a somewhat more contrived example:
+   `--diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]`
+   Here "=" is outside the brackets, because "--diff-filter=" is a
+   valid usage.  "*" has its own pair of brackets, because it can
+   (optionally) be specified only when one or more of the letters is
+   also provided.
+
+  A note on notation:
+   Use 'git' (all lowercase) when talking about commands i.e. something
+   the user would type into a shell and use 'Git' (uppercase first letter)
+   when talking about the version control system and its properties.
+
+ If some place in the documentation needs to typeset a command usage
+ example with inline substitutions, it is fine to use +monospaced and
+ inline substituted text+ instead of `monospaced literal text`, and with
+ the former, the part that should not get substituted must be
+ quoted/escaped.
diff --git a/external/docs/asciidoc/32781022f7f5c49bc62c2cc3ab09bee44cc04945 b/external/docs/asciidoc/32781022f7f5c49bc62c2cc3ab09bee44cc04945
new file mode 100644
index 0000000000..8d3a467c01
--- /dev/null
+++ b/external/docs/asciidoc/32781022f7f5c49bc62c2cc3ab09bee44cc04945
@@ -0,0 +1,758 @@
+Like other projects, we also have some guidelines for our code.  For
+Git in general, a few rough rules are:
+
+ - Most importantly, we never say "It's in POSIX; we'll happily
+   ignore your needs should your system not conform to it."
+   We live in the real world.
+
+ - However, we often say "Let's stay away from that construct,
+   it's not even in POSIX".
+
+ - In spite of the above two rules, we sometimes say "Although
+   this is not in POSIX, it (is so convenient | makes the code
+   much more readable | has other good characteristics) and
+   practically all the platforms we care about support it, so
+   let's use it".
+
+   Again, we live in the real world, and it is sometimes a
+   judgement call, the decision based more on real world
+   constraints people face than what the paper standard says.
+
+ - Fixing style violations while working on a real change as a
+   preparatory clean-up step is good, but otherwise avoid useless code
+   churn for the sake of conforming to the style.
+
+   "Once it _is_ in the tree, it's not really worth the patch noise to
+   go and fix it up."
+   Cf. https://lore.kernel.org/all/20100126160632.3bdbe172.akpm@linux-foundation.org/
+
+ - Log messages to explain your changes are as important as the
+   changes themselves.  Clearly written code and in-code comments
+   explain how the code works and what is assumed from the surrounding
+   context.  The log messages explain what the changes wanted to
+   achieve and why the changes were necessary (more on this in the
+   accompanying SubmittingPatches document).
+
+Make your code readable and sensible, and don't try to be clever.
+
+As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the _local_
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code are expected to match the style the surrounding code already
+uses (even if it doesn't match the overall style of existing code).
+
+But if you must have a list of rules, here are some language
+specific ones. Note that Documentation/ToolsForGit.txt document
+has a collection of tips to help you use some external tools
+to conform to these guidelines.
+
+For shell scripts specifically (not exhaustive):
+
+ - We use tabs for indentation.
+
+ - Case arms are indented at the same depth as case and esac lines,
+   like this:
+
+	case "$variable" in
+	pattern1)
+		do this
+		;;
+	pattern2)
+		do that
+		;;
+	esac
+
+ - Redirection operators should be written with space before, but no
+   space after them.  In other words, write 'echo test >"$file"'
+   instead of 'echo test> $file' or 'echo test > $file'.  Note that
+   even though it is not required by POSIX to double-quote the
+   redirection target in a variable (as shown above), our code does so
+   because some versions of bash issue a warning without the quotes.
+
+	(incorrect)
+	cat hello > world < universe
+	echo hello >$world
+
+	(correct)
+	cat hello >world <universe
+	echo hello >"$world"
+
+ - We prefer $( ... ) for command substitution; unlike ``, it
+   properly nests.  It should have been the way Bourne spelled
+   it from day one, but unfortunately isn't.
+
+ - If you want to find out if a command is available on the user's
+   $PATH, you should use 'type <command>', instead of 'which <command>'.
+   The output of 'which' is not machine parsable and its exit code
+   is not reliable across platforms.
+
+ - We use POSIX compliant parameter substitutions and avoid bashisms;
+   namely:
+
+   - We use ${parameter-word} and its [-=?+] siblings, and their
+     colon'ed "unset or null" form.
+
+   - We use ${parameter#word} and its [#%] siblings, and their
+     doubled "longest matching" form.
+
+   - No "Substring Expansion" ${parameter:offset:length}.
+
+   - No shell arrays.
+
+   - No pattern replacement ${parameter/pattern/string}.
+
+ - We use Arithmetic Expansion $(( ... )).
+
+ - We do not use Process Substitution <(list) or >(list).
+
+ - Do not write control structures on a single line with semicolon.
+   "then" should be on the next line for if statements, and "do"
+   should be on the next line for "while" and "for".
+
+	(incorrect)
+	if test -f hello; then
+		do this
+	fi
+
+	(correct)
+	if test -f hello
+	then
+		do this
+	fi
+
+ - If a command sequence joined with && or || or | spans multiple
+   lines, put each command on a separate line and put && and || and |
+   operators at the end of each line, rather than the start. This
+   means you don't need to use \ to join lines, since the above
+   operators imply the sequence isn't finished.
+
+	(incorrect)
+	grep blob verify_pack_result \
+	| awk -f print_1.awk \
+	| sort >actual &&
+	...
+
+	(correct)
+	grep blob verify_pack_result |
+	awk -f print_1.awk |
+	sort >actual &&
+	...
+
+ - We prefer "test" over "[ ... ]".
+
+ - We do not write the noiseword "function" in front of shell
+   functions.
+
+ - We prefer a space between the function name and the parentheses,
+   and no space inside the parentheses. The opening "{" should also
+   be on the same line.
+
+	(incorrect)
+	my_function(){
+		...
+
+	(correct)
+	my_function () {
+		...
+
+ - As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+   [::], [==], or [..]) for portability.
+
+   - We do not use \{m,n\};
+
+   - We do not use ? or + (which are \{0,1\} and \{1,\}
+     respectively in BRE) but that goes without saying as these
+     are ERE elements not BRE (note that \? and \+ are not even part
+     of BRE -- making them accessible from BRE is a GNU extension).
+
+ - Use Git's gettext wrappers in git-sh-i18n to make the user
+   interface translatable. See "Marking strings for translation" in
+   po/README.
+
+ - We do not write our "test" command with "-a" and "-o" and use "&&"
+   or "||" to concatenate multiple "test" commands instead, because
+   the use of "-a/-o" is often error-prone.  E.g.
+
+     test -n "$x" -a "$a" = "$b"
+
+   is buggy and breaks when $x is "=", but
+
+     test -n "$x" && test "$a" = "$b"
+
+   does not have such a problem.
+
+ - Even though "local" is not part of POSIX, we make heavy use of it
+   in our test suite.  We do not use it in scripted Porcelains, and
+   hopefully nobody starts using "local" before they are reimplemented
+   in C ;-)
+
+ - Use octal escape sequences (e.g. "\302\242"), not hexadecimal (e.g.
+   "\xc2\xa2") in printf format strings, since hexadecimal escape
+   sequences are not portable.
+
+
+For C programs:
+
+ - We use tabs to indent, and interpret tabs as taking up to
+   8 spaces.
+
+ - We try to keep to at most 80 characters per line.
+
+ - As a Git developer we assume you have a reasonably modern compiler
+   and we recommend you to enable the DEVELOPER makefile knob to
+   ensure your patch is clear of all compiler warnings we care about,
+   by e.g. "echo DEVELOPER=1 >>config.mak".
+
+ - We try to support a wide range of C compilers to compile Git with,
+   including old ones.  As of Git v2.35.0 Git requires C99 (we check
+   "__STDC_VERSION__"). You should not use features from a newer C
+   standard, even if your compiler groks them.
+
+   New C99 features have been phased in gradually, if something's new
+   in C99 but not used yet don't assume that it's safe to use, some
+   compilers we target have only partial support for it. These are
+   considered safe to use:
+
+   . since around 2007 with 2b6854c863a, we have been using
+     initializer elements which are not computable at load time. E.g.:
+
+	const char *args[] = {"constant", variable, NULL};
+
+   . since early 2012 with e1327023ea, we have been using an enum
+     definition whose last element is followed by a comma.  This, like
+     an array initializer that ends with a trailing comma, can be used
+     to reduce the patch noise when adding a new identifier at the end.
+
+   . since mid 2017 with cbc0f81d, we have been using designated
+     initializers for struct (e.g. "struct t v = { .val = 'a' };").
+
+   . since mid 2017 with 512f41cf, we have been using designated
+     initializers for array (e.g. "int array[10] = { [5] = 2 }").
+
+   . since early 2021 with 765dc168882, we have been using variadic
+     macros, mostly for printf-like trace and debug macros.
+
+   . since late 2021 with 44ba10d6, we have had variables declared in
+     the for loop "for (int i = 0; i < 10; i++)".
+
+   New C99 features that we cannot use yet:
+
+   . %z and %zu as a printf() argument for a size_t (the %z being for
+     the POSIX-specific ssize_t). Instead you should use
+     printf("%"PRIuMAX, (uintmax_t)v).  These days the MSVC version we
+     rely on supports %z, but the C library used by MinGW does not.
+
+   . Shorthand like ".a.b = *c" in struct initializations is known to
+     trip up an older IBM XLC version, use ".a = { .b = *c }" instead.
+     See the 33665d98 (reftable: make assignments portable to AIX xlc
+     v12.01, 2022-03-28).
+
+ - Variables have to be declared at the beginning of the block, before
+   the first statement (i.e. -Wdeclaration-after-statement).
+
+ - NULL pointers shall be written as NULL, not as 0.
+
+ - When declaring pointers, the star sides with the variable
+   name, i.e. "char *string", not "char* string" or
+   "char * string".  This makes it easier to understand code
+   like "char *string, c;".
+
+ - Use whitespace around operators and keywords, but not inside
+   parentheses and not around functions. So:
+
+        while (condition)
+		func(bar + 1);
+
+   and not:
+
+        while( condition )
+		func (bar+1);
+
+ - Do not explicitly compare an integral value with constant 0 or '\0',
+   or a pointer value with constant NULL.  For instance, to validate that
+   counted array <ptr, cnt> is initialized but has no elements, write:
+
+	if (!ptr || cnt)
+		BUG("empty array expected");
+
+   and not:
+
+	if (ptr == NULL || cnt != 0);
+		BUG("empty array expected");
+
+ - We avoid using braces unnecessarily.  I.e.
+
+	if (bla) {
+		x = 1;
+	}
+
+   is frowned upon. But there are a few exceptions:
+
+	- When the statement extends over a few lines (e.g., a while loop
+	  with an embedded conditional, or a comment). E.g.:
+
+		while (foo) {
+			if (x)
+				one();
+			else
+				two();
+		}
+
+		if (foo) {
+			/*
+			 * This one requires some explanation,
+			 * so we're better off with braces to make
+			 * it obvious that the indentation is correct.
+			 */
+			doit();
+		}
+
+	- When there are multiple arms to a conditional and some of them
+	  require braces, enclose even a single line block in braces for
+	  consistency. E.g.:
+
+		if (foo) {
+			doit();
+		} else {
+			one();
+			two();
+			three();
+		}
+
+ - We try to avoid assignments in the condition of an "if" statement.
+
+ - Try to make your code understandable.  You may put comments
+   in, but comments invariably tend to stale out when the code
+   they were describing changes.  Often splitting a function
+   into two makes the intention of the code much clearer.
+
+ - Multi-line comments include their delimiters on separate lines from
+   the text.  E.g.
+
+	/*
+	 * A very long
+	 * multi-line comment.
+	 */
+
+   Note however that a comment that explains a translatable string to
+   translators uses a convention of starting with a magic token
+   "TRANSLATORS: ", e.g.
+
+	/*
+	 * TRANSLATORS: here is a comment that explains the string to
+	 * be translated, that follows immediately after it.
+	 */
+	_("Here is a translatable string explained by the above.");
+
+ - Double negation is often harder to understand than no negation
+   at all.
+
+ - There are two schools of thought when it comes to comparison,
+   especially inside a loop. Some people prefer to have the less stable
+   value on the left hand side and the more stable value on the right hand
+   side, e.g. if you have a loop that counts variable i down to the
+   lower bound,
+
+	while (i > lower_bound) {
+		do something;
+		i--;
+	}
+
+   Other people prefer to have the textual order of values match the
+   actual order of values in their comparison, so that they can
+   mentally draw a number line from left to right and place these
+   values in order, i.e.
+
+	while (lower_bound < i) {
+		do something;
+		i--;
+	}
+
+   Both are valid, and we use both.  However, the more "stable" the
+   stable side becomes, the more we tend to prefer the former
+   (comparison with a constant, "i > 0", is an extreme example).
+   Just do not mix styles in the same part of the code and mimic
+   existing styles in the neighbourhood.
+
+ - There are two schools of thought when it comes to splitting a long
+   logical line into multiple lines.  Some people push the second and
+   subsequent lines far enough to the right with tabs and align them:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+		span_more_than_a_single_line_of ||
+		the_source_text) {
+                ...
+
+   while other people prefer to align the second and the subsequent
+   lines with the column immediately inside the opening parenthesis,
+   with tabs and spaces, following our "tabstop is always a multiple
+   of 8" convention:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of ||
+	    the_source_text) {
+                ...
+
+   Both are valid, and we use both.  Again, just do not mix styles in
+   the same part of the code and mimic existing styles in the
+   neighbourhood.
+
+ - When splitting a long logical line, some people change line before
+   a binary operator, so that the result looks like a parse tree when
+   you turn your head 90-degrees counterclockwise:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to
+	    || span_more_than_a_single_line_of_the_source_text) {
+
+   while other people prefer to leave the operator at the end of the
+   line:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of_the_source_text) {
+
+   Both are valid, but we tend to use the latter more, unless the
+   expression gets fairly complex, in which case the former tends to
+   be easier to read.  Again, just do not mix styles in the same part
+   of the code and mimic existing styles in the neighbourhood.
+
+ - When splitting a long logical line, with everything else being
+   equal, it is preferable to split after the operator at higher
+   level in the parse tree.  That is, this is more preferable:
+
+	if (a_very_long_variable * that_is_used_in +
+	    a_very_long_expression) {
+		...
+
+   than
+
+	if (a_very_long_variable *
+	    that_is_used_in + a_very_long_expression) {
+		...
+
+ - Some clever tricks, like using the !! operator with arithmetic
+   constructs, can be extremely confusing to others.  Avoid them,
+   unless there is a compelling reason to use them.
+
+ - Use the API.  No, really.  We have a strbuf (variable length
+   string), several arrays with the ALLOC_GROW() macro, a
+   string_list for sorted string lists, a hash map (mapping struct
+   objects) named "struct decorate", amongst other things.
+
+ - When you come up with an API, document its functions and structures
+   in the header file that exposes the API to its callers. Use what is
+   in "strbuf.h" as a model for the appropriate tone and level of
+   detail.
+
+ - The first #include in C files, except in platform specific compat/
+   implementations and sha1dc/, must be either "git-compat-util.h" or
+   one of the approved headers that includes it first for you.  (The
+   approved headers currently include "builtin.h",
+   "t/helper/test-tool.h", "xdiff/xinclude.h", or
+   "reftable/system.h").  You do not have to include more than one of
+   these.
+
+ - A C file must directly include the header files that declare the
+   functions and the types it uses, except for the functions and types
+   that are made available to it by including one of the header files
+   it must include by the previous rule.
+
+ - If you are planning a new command, consider writing it in shell
+   or perl first, so that changes in semantics can be easily
+   changed and discussed.  Many Git commands started out like
+   that, and a few are still scripts.
+
+ - Avoid introducing a new dependency into Git. This means you
+   usually should stay away from scripting languages not already
+   used in the Git core command set (unless your command is clearly
+   separate from it, such as an importer to convert random-scm-X
+   repositories to Git).
+
+ - When we pass <string, length> pair to functions, we should try to
+   pass them in that order.
+
+ - Use Git's gettext wrappers to make the user interface
+   translatable. See "Marking strings for translation" in po/README.
+
+ - Variables and functions local to a given source file should be marked
+   with "static". Variables that are visible to other source files
+   must be declared with "extern" in header files. However, function
+   declarations should not use "extern", as that is already the default.
+
+ - You can launch gdb around your program using the shorthand GIT_DEBUGGER.
+   Run `GIT_DEBUGGER=1 ./bin-wrappers/git foo` to simply use gdb as is, or
+   run `GIT_DEBUGGER="<debugger> <debugger-args>" ./bin-wrappers/git foo` to
+   use your own debugger and arguments. Example: `GIT_DEBUGGER="ddd --gdb"
+   ./bin-wrappers/git log` (See `wrap-for-bin.sh`.)
+
+For Perl programs:
+
+ - Most of the C guidelines above apply.
+
+ - We try to support Perl 5.8 and later ("use Perl 5.008").
+
+ - use strict and use warnings are strongly preferred.
+
+ - Don't overuse statement modifiers unless using them makes the
+   result easier to follow.
+
+	... do something ...
+	do_this() unless (condition);
+        ... do something else ...
+
+   is more readable than:
+
+	... do something ...
+	unless (condition) {
+		do_this();
+	}
+        ... do something else ...
+
+   *only* when the condition is so rare that do_this() will be almost
+   always called.
+
+ - We try to avoid assignments inside "if ()" conditions.
+
+ - Learn and use Git.pm if you need that functionality.
+
+For Python scripts:
+
+ - We follow PEP-8 (http://www.python.org/dev/peps/pep-0008/).
+
+ - As a minimum, we aim to be compatible with Python 2.7.
+
+ - Where required libraries do not restrict us to Python 2, we try to
+   also be compatible with Python 3.1 and later.
+
+
+Program Output
+
+ We make a distinction between a Git command's primary output and
+ output which is merely chatty feedback (for instance, status
+ messages, running transcript, or progress display), as well as error
+ messages. Roughly speaking, a Git command's primary output is that
+ which one might want to capture to a file or send down a pipe; its
+ chatty output should not interfere with these use-cases.
+
+ As such, primary output should be sent to the standard output stream
+ (stdout), and chatty output should be sent to the standard error
+ stream (stderr). Examples of commands which produce primary output
+ include `git log`, `git show`, and `git branch --list` which generate
+ output on the stdout stream.
+
+ Not all Git commands have primary output; this is often true of
+ commands whose main function is to perform an action. Some action
+ commands are silent, whereas others are chatty. An example of a
+ chatty action commands is `git clone` with its "Cloning into
+ '<path>'..." and "Checking connectivity..." status messages which it
+ sends to the stderr stream.
+
+ Error messages from Git commands should always be sent to the stderr
+ stream.
+
+
+Error Messages
+
+ - Do not end error messages with a full stop.
+
+ - Do not capitalize the first word, only because it is the first word
+   in the message ("unable to open %s", not "Unable to open %s").  But
+   "SHA-3 not supported" is fine, because the reason the first word is
+   capitalized is not because it is at the beginning of the sentence,
+   but because the word would be spelled in capital letters even when
+   it appeared in the middle of the sentence.
+
+ - Say what the error is first ("cannot open %s", not "%s: cannot open")
+
+
+Externally Visible Names
+
+ - For configuration variable names, follow the existing convention:
+
+   . The section name indicates the affected subsystem.
+
+   . The subsection name, if any, indicates which of an unbounded set
+     of things to set the value for.
+
+   . The variable name describes the effect of tweaking this knob.
+
+   The section and variable names that consist of multiple words are
+   formed by concatenating the words without punctuations (e.g. `-`),
+   and are broken using bumpyCaps in documentation as a hint to the
+   reader.
+
+   When choosing the variable namespace, do not use variable name for
+   specifying possibly unbounded set of things, most notably anything
+   an end user can freely come up with (e.g. branch names).  Instead,
+   use subsection names or variable values, like the existing variable
+   branch.<name>.description does.
+
+
+Writing Documentation:
+
+ Most (if not all) of the documentation pages are written in the
+ AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+ processed into HTML and manpages (e.g. git.html and git.1 in the
+ same directory).
+
+ The documentation liberally mixes US and UK English (en_US/UK)
+ norms for spelling and grammar, which is somewhat unfortunate.
+ In an ideal world, it would have been better if it consistently
+ used only one and not the other, and we would have picked en_US
+ (if you wish to correct the English of some of the existing
+ documentation, please see the documentation-related advice in the
+ Documentation/SubmittingPatches file).
+
+ In order to ensure the documentation is inclusive, avoid assuming
+ that an unspecified example person is male or female, and think
+ twice before using "he", "him", "she", or "her".  Here are some
+ tips to avoid use of gendered pronouns:
+
+  - Prefer succinctness and matter-of-factly describing functionality
+    in the abstract.  E.g.
+
+     --short:: Emit output in the short-format.
+
+    and avoid something like these overly verbose alternatives:
+
+     --short:: Use this to emit output in the short-format.
+     --short:: You can use this to get output in the short-format.
+     --short:: A user who prefers shorter output could....
+     --short:: Should a person and/or program want shorter output, he
+               she/they/it can...
+
+    This practice often eliminates the need to involve human actors in
+    your description, but it is a good practice regardless of the
+    avoidance of gendered pronouns.
+
+  - When it becomes awkward to stick to this style, prefer "you" when
+    addressing the hypothetical user, and possibly "we" when
+    discussing how the program might react to the user.  E.g.
+
+      You can use this option instead of --xyz, but we might remove
+      support for it in future versions.
+
+    while keeping in mind that you can probably be less verbose, e.g.
+
+      Use this instead of --xyz. This option might be removed in future
+      versions.
+
+  - If you still need to refer to an example person that is
+    third-person singular, you may resort to "singular they" to avoid
+    "he/she/him/her", e.g.
+
+      A contributor asks their upstream to pull from them.
+
+    Note that this sounds ungrammatical and unnatural to those who
+    learned that "they" is only used for third-person plural, e.g.
+    those who learn English as a second language in some parts of the
+    world.
+
+ Every user-visible change should be reflected in the documentation.
+ The same general rule as for code applies -- imitate the existing
+ conventions.
+
+ A few commented examples follow to provide reference when writing or
+ modifying command usage strings and synopsis sections in the manual
+ pages:
+
+ Placeholders are spelled in lowercase and enclosed in angle brackets:
+   <file>
+   --sort=<key>
+   --abbrev[=<n>]
+
+ If a placeholder has multiple words, they are separated by dashes:
+   <new-branch-name>
+   --template=<template-directory>
+
+ Possibility of multiple occurrences is indicated by three dots:
+   <file>...
+   (One or more of <file>.)
+
+ Optional parts are enclosed in square brackets:
+   [<file>...]
+   (Zero or more of <file>.)
+
+   --exec-path[=<path>]
+   (Option with an optional argument.  Note that the "=" is inside the
+   brackets.)
+
+   [<patch>...]
+   (Zero or more of <patch>.  Note that the dots are inside, not
+   outside the brackets.)
+
+ Multiple alternatives are indicated with vertical bars:
+   [-q | --quiet]
+   [--utf8 | --no-utf8]
+
+ Use spacing around "|" token(s), but not immediately after opening or
+ before closing a [] or () pair:
+   Do: [-q | --quiet]
+   Don't: [-q|--quiet]
+
+ Don't use spacing around "|" tokens when they're used to separate the
+ alternate arguments of an option:
+    Do: --track[=(direct|inherit)]
+    Don't: --track[=(direct | inherit)]
+
+ Parentheses are used for grouping:
+   [(<rev> | <range>)...]
+   (Any number of either <rev> or <range>.  Parens are needed to make
+   it clear that "..." pertains to both <rev> and <range>.)
+
+   [(-p <parent>)...]
+   (Any number of option -p, each with one <parent> argument.)
+
+   git remote set-head <name> (-a | -d | <branch>)
+   (One and only one of "-a", "-d" or "<branch>" _must_ (no square
+   brackets) be provided.)
+
+ And a somewhat more contrived example:
+   --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+   Here "=" is outside the brackets, because "--diff-filter=" is a
+   valid usage.  "*" has its own pair of brackets, because it can
+   (optionally) be specified only when one or more of the letters is
+   also provided.
+
+  A note on notation:
+   Use 'git' (all lowercase) when talking about commands i.e. something
+   the user would type into a shell and use 'Git' (uppercase first letter)
+   when talking about the version control system and its properties.
+
+ A few commented examples follow to provide reference when writing or
+ modifying paragraphs or option/command explanations that contain options
+ or commands:
+
+ Literal examples (e.g. use of command-line options, command names,
+ branch names, URLs, pathnames (files and directories), configuration and
+ environment variables) must be typeset in monospace (i.e. wrapped with
+ backticks):
+   `--pretty=oneline`
+   `git rev-list`
+   `remote.pushDefault`
+   `http://git.example.com`
+   `.git/config`
+   `GIT_DIR`
+   `HEAD`
+
+ An environment variable must be prefixed with "$" only when referring to its
+ value and not when referring to the variable itself, in this case there is
+ nothing to add except the backticks:
+   `GIT_DIR` is specified
+   `$GIT_DIR/hooks/pre-receive`
+
+ Word phrases enclosed in `backtick characters` are rendered literally
+ and will not be further expanded. The use of `backticks` to achieve the
+ previous rule means that literal examples should not use AsciiDoc
+ escapes.
+   Correct:
+      `--pretty=oneline`
+   Incorrect:
+      `\--pretty=oneline`
+
+ If some place in the documentation needs to typeset a command usage
+ example with inline substitutions, it is fine to use +monospaced and
+ inline substituted text+ instead of `monospaced literal text`, and with
+ the former, the part that should not get substituted must be
+ quoted/escaped.
diff --git a/external/docs/asciidoc/32f7e6163d58c1215034f5d599a90e3e9fcf84b4 b/external/docs/asciidoc/32f7e6163d58c1215034f5d599a90e3e9fcf84b4
new file mode 100644
index 0000000000..b20b2f94f1
--- /dev/null
+++ b/external/docs/asciidoc/32f7e6163d58c1215034f5d599a90e3e9fcf84b4
@@ -0,0 +1,735 @@
+Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, a few rough rules are:
+
+ - Most importantly, we never say "It's in POSIX; we'll happily
+   ignore your needs should your system not conform to it."
+   We live in the real world.
+
+ - However, we often say "Let's stay away from that construct,
+   it's not even in POSIX".
+
+ - In spite of the above two rules, we sometimes say "Although
+   this is not in POSIX, it (is so convenient | makes the code
+   much more readable | has other good characteristics) and
+   practically all the platforms we care about support it, so
+   let's use it".
+
+   Again, we live in the real world, and it is sometimes a
+   judgement call, the decision based more on real world
+   constraints people face than what the paper standard says.
+
+ - Fixing style violations while working on a real change as a
+   preparatory clean-up step is good, but otherwise avoid useless code
+   churn for the sake of conforming to the style.
+
+   "Once it _is_ in the tree, it's not really worth the patch noise to
+   go and fix it up."
+   Cf. http://lkml.iu.edu/hypermail/linux/kernel/1001.3/01069.html
+
+ - Log messages to explain your changes are as important as the
+   changes themselves.  Clearly written code and in-code comments
+   explain how the code works and what is assumed from the surrounding
+   context.  The log messages explain what the changes wanted to
+   achieve and why the changes were necessary (more on this in the
+   accompanying SubmittingPatches document).
+
+Make your code readable and sensible, and don't try to be clever.
+
+As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the _local_
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn't match the overall style of existing code).
+
+But if you must have a list of rules, here they are.
+
+For shell scripts specifically (not exhaustive):
+
+ - We use tabs for indentation.
+
+ - Case arms are indented at the same depth as case and esac lines,
+   like this:
+
+	case "$variable" in
+	pattern1)
+		do this
+		;;
+	pattern2)
+		do that
+		;;
+	esac
+
+ - Redirection operators should be written with space before, but no
+   space after them.  In other words, write 'echo test >"$file"'
+   instead of 'echo test> $file' or 'echo test > $file'.  Note that
+   even though it is not required by POSIX to double-quote the
+   redirection target in a variable (as shown above), our code does so
+   because some versions of bash issue a warning without the quotes.
+
+	(incorrect)
+	cat hello > world < universe
+	echo hello >$world
+
+	(correct)
+	cat hello >world <universe
+	echo hello >"$world"
+
+ - We prefer $( ... ) for command substitution; unlike ``, it
+   properly nests.  It should have been the way Bourne spelled
+   it from day one, but unfortunately isn't.
+
+ - If you want to find out if a command is available on the user's
+   $PATH, you should use 'type <command>', instead of 'which <command>'.
+   The output of 'which' is not machine parsable and its exit code
+   is not reliable across platforms.
+
+ - We use POSIX compliant parameter substitutions and avoid bashisms;
+   namely:
+
+   - We use ${parameter-word} and its [-=?+] siblings, and their
+     colon'ed "unset or null" form.
+
+   - We use ${parameter#word} and its [#%] siblings, and their
+     doubled "longest matching" form.
+
+   - No "Substring Expansion" ${parameter:offset:length}.
+
+   - No shell arrays.
+
+   - No pattern replacement ${parameter/pattern/string}.
+
+ - We use Arithmetic Expansion $(( ... )).
+
+ - We do not use Process Substitution <(list) or >(list).
+
+ - Do not write control structures on a single line with semicolon.
+   "then" should be on the next line for if statements, and "do"
+   should be on the next line for "while" and "for".
+
+	(incorrect)
+	if test -f hello; then
+		do this
+	fi
+
+	(correct)
+	if test -f hello
+	then
+		do this
+	fi
+
+ - If a command sequence joined with && or || or | spans multiple
+   lines, put each command on a separate line and put && and || and |
+   operators at the end of each line, rather than the start. This
+   means you don't need to use \ to join lines, since the above
+   operators imply the sequence isn't finished.
+
+	(incorrect)
+	grep blob verify_pack_result \
+	| awk -f print_1.awk \
+	| sort >actual &&
+	...
+
+	(correct)
+	grep blob verify_pack_result |
+	awk -f print_1.awk |
+	sort >actual &&
+	...
+
+ - We prefer "test" over "[ ... ]".
+
+ - We do not write the noiseword "function" in front of shell
+   functions.
+
+ - We prefer a space between the function name and the parentheses,
+   and no space inside the parentheses. The opening "{" should also
+   be on the same line.
+
+	(incorrect)
+	my_function(){
+		...
+
+	(correct)
+	my_function () {
+		...
+
+ - As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+   [::], [==], or [..]) for portability.
+
+   - We do not use \{m,n\};
+
+   - We do not use -E;
+
+   - We do not use ? or + (which are \{0,1\} and \{1,\}
+     respectively in BRE) but that goes without saying as these
+     are ERE elements not BRE (note that \? and \+ are not even part
+     of BRE -- making them accessible from BRE is a GNU extension).
+
+ - Use Git's gettext wrappers in git-sh-i18n to make the user
+   interface translatable. See "Marking strings for translation" in
+   po/README.
+
+ - We do not write our "test" command with "-a" and "-o" and use "&&"
+   or "||" to concatenate multiple "test" commands instead, because
+   the use of "-a/-o" is often error-prone.  E.g.
+
+     test -n "$x" -a "$a" = "$b"
+
+   is buggy and breaks when $x is "=", but
+
+     test -n "$x" && test "$a" = "$b"
+
+   does not have such a problem.
+
+ - Even though "local" is not part of POSIX, we make heavy use of it
+   in our test suite.  We do not use it in scripted Porcelains, and
+   hopefully nobody starts using "local" before they are reimplemented
+   in C ;-)
+
+
+For C programs:
+
+ - We use tabs to indent, and interpret tabs as taking up to
+   8 spaces.
+
+ - We try to keep to at most 80 characters per line.
+
+ - As a Git developer we assume you have a reasonably modern compiler
+   and we recommend you to enable the DEVELOPER makefile knob to
+   ensure your patch is clear of all compiler warnings we care about,
+   by e.g. "echo DEVELOPER=1 >>config.mak".
+
+ - We try to support a wide range of C compilers to compile Git with,
+   including old ones.  You should not use features from newer C
+   standard, even if your compiler groks them.
+
+   There are a few exceptions to this guideline:
+
+   . since early 2012 with e1327023ea, we have been using an enum
+     definition whose last element is followed by a comma.  This, like
+     an array initializer that ends with a trailing comma, can be used
+     to reduce the patch noise when adding a new identifier at the end.
+
+   . since mid 2017 with cbc0f81d, we have been using designated
+     initializers for struct (e.g. "struct t v = { .val = 'a' };").
+
+   . since mid 2017 with 512f41cf, we have been using designated
+     initializers for array (e.g. "int array[10] = { [5] = 2 }").
+
+   . since early 2021 with 765dc168882, we have been using variadic
+     macros, mostly for printf-like trace and debug macros.
+
+   These used to be forbidden, but we have not heard any breakage
+   report, and they are assumed to be safe.
+
+ - Variables have to be declared at the beginning of the block, before
+   the first statement (i.e. -Wdeclaration-after-statement).
+
+ - Declaring a variable in the for loop "for (int i = 0; i < 10; i++)"
+   is still not allowed in this codebase.  We are in the process of
+   allowing it by waiting to see that 44ba10d6 (revision: use C99
+   declaration of variable in for() loop, 2021-11-14) does not get
+   complaints.  Let's revisit this around November 2022.
+
+ - NULL pointers shall be written as NULL, not as 0.
+
+ - When declaring pointers, the star sides with the variable
+   name, i.e. "char *string", not "char* string" or
+   "char * string".  This makes it easier to understand code
+   like "char *string, c;".
+
+ - Use whitespace around operators and keywords, but not inside
+   parentheses and not around functions. So:
+
+        while (condition)
+		func(bar + 1);
+
+   and not:
+
+        while( condition )
+		func (bar+1);
+
+ - Do not explicitly compare an integral value with constant 0 or '\0',
+   or a pointer value with constant NULL.  For instance, to validate that
+   counted array <ptr, cnt> is initialized but has no elements, write:
+
+	if (!ptr || cnt)
+		BUG("empty array expected");
+
+   and not:
+
+	if (ptr == NULL || cnt != 0);
+		BUG("empty array expected");
+
+ - We avoid using braces unnecessarily.  I.e.
+
+	if (bla) {
+		x = 1;
+	}
+
+   is frowned upon. But there are a few exceptions:
+
+	- When the statement extends over a few lines (e.g., a while loop
+	  with an embedded conditional, or a comment). E.g.:
+
+		while (foo) {
+			if (x)
+				one();
+			else
+				two();
+		}
+
+		if (foo) {
+			/*
+			 * This one requires some explanation,
+			 * so we're better off with braces to make
+			 * it obvious that the indentation is correct.
+			 */
+			doit();
+		}
+
+	- When there are multiple arms to a conditional and some of them
+	  require braces, enclose even a single line block in braces for
+	  consistency. E.g.:
+
+		if (foo) {
+			doit();
+		} else {
+			one();
+			two();
+			three();
+		}
+
+ - We try to avoid assignments in the condition of an "if" statement.
+
+ - Try to make your code understandable.  You may put comments
+   in, but comments invariably tend to stale out when the code
+   they were describing changes.  Often splitting a function
+   into two makes the intention of the code much clearer.
+
+ - Multi-line comments include their delimiters on separate lines from
+   the text.  E.g.
+
+	/*
+	 * A very long
+	 * multi-line comment.
+	 */
+
+   Note however that a comment that explains a translatable string to
+   translators uses a convention of starting with a magic token
+   "TRANSLATORS: ", e.g.
+
+	/*
+	 * TRANSLATORS: here is a comment that explains the string to
+	 * be translated, that follows immediately after it.
+	 */
+	_("Here is a translatable string explained by the above.");
+
+ - Double negation is often harder to understand than no negation
+   at all.
+
+ - There are two schools of thought when it comes to comparison,
+   especially inside a loop. Some people prefer to have the less stable
+   value on the left hand side and the more stable value on the right hand
+   side, e.g. if you have a loop that counts variable i down to the
+   lower bound,
+
+	while (i > lower_bound) {
+		do something;
+		i--;
+	}
+
+   Other people prefer to have the textual order of values match the
+   actual order of values in their comparison, so that they can
+   mentally draw a number line from left to right and place these
+   values in order, i.e.
+
+	while (lower_bound < i) {
+		do something;
+		i--;
+	}
+
+   Both are valid, and we use both.  However, the more "stable" the
+   stable side becomes, the more we tend to prefer the former
+   (comparison with a constant, "i > 0", is an extreme example).
+   Just do not mix styles in the same part of the code and mimic
+   existing styles in the neighbourhood.
+
+ - There are two schools of thought when it comes to splitting a long
+   logical line into multiple lines.  Some people push the second and
+   subsequent lines far enough to the right with tabs and align them:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+		span_more_than_a_single_line_of ||
+		the_source_text) {
+                ...
+
+   while other people prefer to align the second and the subsequent
+   lines with the column immediately inside the opening parenthesis,
+   with tabs and spaces, following our "tabstop is always a multiple
+   of 8" convention:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of ||
+	    the_source_text) {
+                ...
+
+   Both are valid, and we use both.  Again, just do not mix styles in
+   the same part of the code and mimic existing styles in the
+   neighbourhood.
+
+ - When splitting a long logical line, some people change line before
+   a binary operator, so that the result looks like a parse tree when
+   you turn your head 90-degrees counterclockwise:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to
+	    || span_more_than_a_single_line_of_the_source_text) {
+
+   while other people prefer to leave the operator at the end of the
+   line:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of_the_source_text) {
+
+   Both are valid, but we tend to use the latter more, unless the
+   expression gets fairly complex, in which case the former tends to
+   be easier to read.  Again, just do not mix styles in the same part
+   of the code and mimic existing styles in the neighbourhood.
+
+ - When splitting a long logical line, with everything else being
+   equal, it is preferable to split after the operator at higher
+   level in the parse tree.  That is, this is more preferable:
+
+	if (a_very_long_variable * that_is_used_in +
+	    a_very_long_expression) {
+		...
+
+   than
+
+	if (a_very_long_variable *
+	    that_is_used_in + a_very_long_expression) {
+		...
+
+ - Some clever tricks, like using the !! operator with arithmetic
+   constructs, can be extremely confusing to others.  Avoid them,
+   unless there is a compelling reason to use them.
+
+ - Use the API.  No, really.  We have a strbuf (variable length
+   string), several arrays with the ALLOC_GROW() macro, a
+   string_list for sorted string lists, a hash map (mapping struct
+   objects) named "struct decorate", amongst other things.
+
+ - When you come up with an API, document its functions and structures
+   in the header file that exposes the API to its callers. Use what is
+   in "strbuf.h" as a model for the appropriate tone and level of
+   detail.
+
+ - The first #include in C files, except in platform specific compat/
+   implementations, must be either "git-compat-util.h", "cache.h" or
+   "builtin.h".  You do not have to include more than one of these.
+
+ - A C file must directly include the header files that declare the
+   functions and the types it uses, except for the functions and types
+   that are made available to it by including one of the header files
+   it must include by the previous rule.
+
+ - If you are planning a new command, consider writing it in shell
+   or perl first, so that changes in semantics can be easily
+   changed and discussed.  Many Git commands started out like
+   that, and a few are still scripts.
+
+ - Avoid introducing a new dependency into Git. This means you
+   usually should stay away from scripting languages not already
+   used in the Git core command set (unless your command is clearly
+   separate from it, such as an importer to convert random-scm-X
+   repositories to Git).
+
+ - When we pass <string, length> pair to functions, we should try to
+   pass them in that order.
+
+ - Use Git's gettext wrappers to make the user interface
+   translatable. See "Marking strings for translation" in po/README.
+
+ - Variables and functions local to a given source file should be marked
+   with "static". Variables that are visible to other source files
+   must be declared with "extern" in header files. However, function
+   declarations should not use "extern", as that is already the default.
+
+ - You can launch gdb around your program using the shorthand GIT_DEBUGGER.
+   Run `GIT_DEBUGGER=1 ./bin-wrappers/git foo` to simply use gdb as is, or
+   run `GIT_DEBUGGER="<debugger> <debugger-args>" ./bin-wrappers/git foo` to
+   use your own debugger and arguments. Example: `GIT_DEBUGGER="ddd --gdb"
+   ./bin-wrappers/git log` (See `wrap-for-bin.sh`.)
+
+For Perl programs:
+
+ - Most of the C guidelines above apply.
+
+ - We try to support Perl 5.8 and later ("use Perl 5.008").
+
+ - use strict and use warnings are strongly preferred.
+
+ - Don't overuse statement modifiers unless using them makes the
+   result easier to follow.
+
+	... do something ...
+	do_this() unless (condition);
+        ... do something else ...
+
+   is more readable than:
+
+	... do something ...
+	unless (condition) {
+		do_this();
+	}
+        ... do something else ...
+
+   *only* when the condition is so rare that do_this() will be almost
+   always called.
+
+ - We try to avoid assignments inside "if ()" conditions.
+
+ - Learn and use Git.pm if you need that functionality.
+
+ - For Emacs, it's useful to put the following in
+   GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode:
+
+    ;; note the first part is useful for C editing, too
+    ((nil . ((indent-tabs-mode . t)
+                  (tab-width . 8)
+                  (fill-column . 80)))
+     (cperl-mode . ((cperl-indent-level . 8)
+                    (cperl-extra-newline-before-brace . nil)
+                    (cperl-merge-trailing-else . t))))
+
+For Python scripts:
+
+ - We follow PEP-8 (http://www.python.org/dev/peps/pep-0008/).
+
+ - As a minimum, we aim to be compatible with Python 2.7.
+
+ - Where required libraries do not restrict us to Python 2, we try to
+   also be compatible with Python 3.1 and later.
+
+
+Program Output
+
+ We make a distinction between a Git command's primary output and
+ output which is merely chatty feedback (for instance, status
+ messages, running transcript, or progress display), as well as error
+ messages. Roughly speaking, a Git command's primary output is that
+ which one might want to capture to a file or send down a pipe; its
+ chatty output should not interfere with these use-cases.
+
+ As such, primary output should be sent to the standard output stream
+ (stdout), and chatty output should be sent to the standard error
+ stream (stderr). Examples of commands which produce primary output
+ include `git log`, `git show`, and `git branch --list` which generate
+ output on the stdout stream.
+
+ Not all Git commands have primary output; this is often true of
+ commands whose main function is to perform an action. Some action
+ commands are silent, whereas others are chatty. An example of a
+ chatty action commands is `git clone` with its "Cloning into
+ '<path>'..." and "Checking connectivity..." status messages which it
+ sends to the stderr stream.
+
+ Error messages from Git commands should always be sent to the stderr
+ stream.
+
+
+Error Messages
+
+ - Do not end error messages with a full stop.
+
+ - Do not capitalize the first word, only because it is the first word
+   in the message ("unable to open %s", not "Unable to open %s").  But
+   "SHA-3 not supported" is fine, because the reason the first word is
+   capitalized is not because it is at the beginning of the sentence,
+   but because the word would be spelled in capital letters even when
+   it appeared in the middle of the sentence.
+
+ - Say what the error is first ("cannot open %s", not "%s: cannot open")
+
+
+Externally Visible Names
+
+ - For configuration variable names, follow the existing convention:
+
+   . The section name indicates the affected subsystem.
+
+   . The subsection name, if any, indicates which of an unbounded set
+     of things to set the value for.
+
+   . The variable name describes the effect of tweaking this knob.
+
+   The section and variable names that consist of multiple words are
+   formed by concatenating the words without punctuations (e.g. `-`),
+   and are broken using bumpyCaps in documentation as a hint to the
+   reader.
+
+   When choosing the variable namespace, do not use variable name for
+   specifying possibly unbounded set of things, most notably anything
+   an end user can freely come up with (e.g. branch names).  Instead,
+   use subsection names or variable values, like the existing variable
+   branch.<name>.description does.
+
+
+Writing Documentation:
+
+ Most (if not all) of the documentation pages are written in the
+ AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+ processed into HTML and manpages (e.g. git.html and git.1 in the
+ same directory).
+
+ The documentation liberally mixes US and UK English (en_US/UK)
+ norms for spelling and grammar, which is somewhat unfortunate.
+ In an ideal world, it would have been better if it consistently
+ used only one and not the other, and we would have picked en_US
+ (if you wish to correct the English of some of the existing
+ documentation, please see the documentation-related advice in the
+ Documentation/SubmittingPatches file).
+
+ In order to ensure the documentation is inclusive, avoid assuming
+ that an unspecified example person is male or female, and think
+ twice before using "he", "him", "she", or "her".  Here are some
+ tips to avoid use of gendered pronouns:
+
+  - Prefer succinctness and matter-of-factly describing functionality
+    in the abstract.  E.g.
+
+     --short:: Emit output in the short-format.
+
+    and avoid something like these overly verbose alternatives:
+
+     --short:: Use this to emit output in the short-format.
+     --short:: You can use this to get output in the short-format.
+     --short:: A user who prefers shorter output could....
+     --short:: Should a person and/or program want shorter output, he
+               she/they/it can...
+
+    This practice often eliminates the need to involve human actors in
+    your description, but it is a good practice regardless of the
+    avoidance of gendered pronouns.
+
+  - When it becomes awkward to stick to this style, prefer "you" when
+    addressing the the hypothetical user, and possibly "we" when
+    discussing how the program might react to the user.  E.g.
+
+      You can use this option instead of --xyz, but we might remove
+      support for it in future versions.
+
+    while keeping in mind that you can probably be less verbose, e.g.
+
+      Use this instead of --xyz. This option might be removed in future
+      versions.
+
+  - If you still need to refer to an example person that is
+    third-person singular, you may resort to "singular they" to avoid
+    "he/she/him/her", e.g.
+
+      A contributor asks their upstream to pull from them.
+
+    Note that this sounds ungrammatical and unnatural to those who
+    learned that "they" is only used for third-person plural, e.g.
+    those who learn English as a second language in some parts of the
+    world.
+
+ Every user-visible change should be reflected in the documentation.
+ The same general rule as for code applies -- imitate the existing
+ conventions.
+
+ A few commented examples follow to provide reference when writing or
+ modifying command usage strings and synopsis sections in the manual
+ pages:
+
+ Placeholders are spelled in lowercase and enclosed in angle brackets:
+   <file>
+   --sort=<key>
+   --abbrev[=<n>]
+
+ If a placeholder has multiple words, they are separated by dashes:
+   <new-branch-name>
+   --template=<template-directory>
+
+ Possibility of multiple occurrences is indicated by three dots:
+   <file>...
+   (One or more of <file>.)
+
+ Optional parts are enclosed in square brackets:
+   [<extra>]
+   (Zero or one <extra>.)
+
+   --exec-path[=<path>]
+   (Option with an optional argument.  Note that the "=" is inside the
+   brackets.)
+
+   [<patch>...]
+   (Zero or more of <patch>.  Note that the dots are inside, not
+   outside the brackets.)
+
+ Multiple alternatives are indicated with vertical bars:
+   [-q | --quiet]
+   [--utf8 | --no-utf8]
+
+ Parentheses are used for grouping:
+   [(<rev> | <range>)...]
+   (Any number of either <rev> or <range>.  Parens are needed to make
+   it clear that "..." pertains to both <rev> and <range>.)
+
+   [(-p <parent>)...]
+   (Any number of option -p, each with one <parent> argument.)
+
+   git remote set-head <name> (-a | -d | <branch>)
+   (One and only one of "-a", "-d" or "<branch>" _must_ (no square
+   brackets) be provided.)
+
+ And a somewhat more contrived example:
+   --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+   Here "=" is outside the brackets, because "--diff-filter=" is a
+   valid usage.  "*" has its own pair of brackets, because it can
+   (optionally) be specified only when one or more of the letters is
+   also provided.
+
+  A note on notation:
+   Use 'git' (all lowercase) when talking about commands i.e. something
+   the user would type into a shell and use 'Git' (uppercase first letter)
+   when talking about the version control system and its properties.
+
+ A few commented examples follow to provide reference when writing or
+ modifying paragraphs or option/command explanations that contain options
+ or commands:
+
+ Literal examples (e.g. use of command-line options, command names,
+ branch names, URLs, pathnames (files and directories), configuration and
+ environment variables) must be typeset in monospace (i.e. wrapped with
+ backticks):
+   `--pretty=oneline`
+   `git rev-list`
+   `remote.pushDefault`
+   `http://git.example.com`
+   `.git/config`
+   `GIT_DIR`
+   `HEAD`
+
+ An environment variable must be prefixed with "$" only when referring to its
+ value and not when referring to the variable itself, in this case there is
+ nothing to add except the backticks:
+   `GIT_DIR` is specified
+   `$GIT_DIR/hooks/pre-receive`
+
+ Word phrases enclosed in `backtick characters` are rendered literally
+ and will not be further expanded. The use of `backticks` to achieve the
+ previous rule means that literal examples should not use AsciiDoc
+ escapes.
+   Correct:
+      `--pretty=oneline`
+   Incorrect:
+      `\--pretty=oneline`
+
+ If some place in the documentation needs to typeset a command usage
+ example with inline substitutions, it is fine to use +monospaced and
+ inline substituted text+ instead of `monospaced literal text`, and with
+ the former, the part that should not get substituted must be
+ quoted/escaped.
diff --git a/external/docs/asciidoc/384992bd708c35d0869455bfb756632a1ced33f2 b/external/docs/asciidoc/384992bd708c35d0869455bfb756632a1ced33f2
new file mode 100644
index 0000000000..227f46ae40
--- /dev/null
+++ b/external/docs/asciidoc/384992bd708c35d0869455bfb756632a1ced33f2
@@ -0,0 +1,645 @@
+Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, a few rough rules are:
+
+ - Most importantly, we never say "It's in POSIX; we'll happily
+   ignore your needs should your system not conform to it."
+   We live in the real world.
+
+ - However, we often say "Let's stay away from that construct,
+   it's not even in POSIX".
+
+ - In spite of the above two rules, we sometimes say "Although
+   this is not in POSIX, it (is so convenient | makes the code
+   much more readable | has other good characteristics) and
+   practically all the platforms we care about support it, so
+   let's use it".
+
+   Again, we live in the real world, and it is sometimes a
+   judgement call, the decision based more on real world
+   constraints people face than what the paper standard says.
+
+ - Fixing style violations while working on a real change as a
+   preparatory clean-up step is good, but otherwise avoid useless code
+   churn for the sake of conforming to the style.
+
+   "Once it _is_ in the tree, it's not really worth the patch noise to
+   go and fix it up."
+   Cf. http://lkml.iu.edu/hypermail/linux/kernel/1001.3/01069.html
+
+Make your code readable and sensible, and don't try to be clever.
+
+As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the _local_
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn't match the overall style of existing code).
+
+But if you must have a list of rules, here they are.
+
+For shell scripts specifically (not exhaustive):
+
+ - We use tabs for indentation.
+
+ - Case arms are indented at the same depth as case and esac lines,
+   like this:
+
+	case "$variable" in
+	pattern1)
+		do this
+		;;
+	pattern2)
+		do that
+		;;
+	esac
+
+ - Redirection operators should be written with space before, but no
+   space after them.  In other words, write 'echo test >"$file"'
+   instead of 'echo test> $file' or 'echo test > $file'.  Note that
+   even though it is not required by POSIX to double-quote the
+   redirection target in a variable (as shown above), our code does so
+   because some versions of bash issue a warning without the quotes.
+
+	(incorrect)
+	cat hello > world < universe
+	echo hello >$world
+
+	(correct)
+	cat hello >world <universe
+	echo hello >"$world"
+
+ - We prefer $( ... ) for command substitution; unlike ``, it
+   properly nests.  It should have been the way Bourne spelled
+   it from day one, but unfortunately isn't.
+
+ - If you want to find out if a command is available on the user's
+   $PATH, you should use 'type <command>', instead of 'which <command>'.
+   The output of 'which' is not machine parsable and its exit code
+   is not reliable across platforms.
+
+ - We use POSIX compliant parameter substitutions and avoid bashisms;
+   namely:
+
+   - We use ${parameter-word} and its [-=?+] siblings, and their
+     colon'ed "unset or null" form.
+
+   - We use ${parameter#word} and its [#%] siblings, and their
+     doubled "longest matching" form.
+
+   - No "Substring Expansion" ${parameter:offset:length}.
+
+   - No shell arrays.
+
+   - No pattern replacement ${parameter/pattern/string}.
+
+ - We use Arithmetic Expansion $(( ... )).
+
+ - We do not use Process Substitution <(list) or >(list).
+
+ - Do not write control structures on a single line with semicolon.
+   "then" should be on the next line for if statements, and "do"
+   should be on the next line for "while" and "for".
+
+	(incorrect)
+	if test -f hello; then
+		do this
+	fi
+
+	(correct)
+	if test -f hello
+	then
+		do this
+	fi
+
+ - If a command sequence joined with && or || or | spans multiple
+   lines, put each command on a separate line and put && and || and |
+   operators at the end of each line, rather than the start. This
+   means you don't need to use \ to join lines, since the above
+   operators imply the sequence isn't finished.
+
+	(incorrect)
+	grep blob verify_pack_result \
+	| awk -f print_1.awk \
+	| sort >actual &&
+	...
+
+	(correct)
+	grep blob verify_pack_result |
+	awk -f print_1.awk |
+	sort >actual &&
+	...
+
+ - We prefer "test" over "[ ... ]".
+
+ - We do not write the noiseword "function" in front of shell
+   functions.
+
+ - We prefer a space between the function name and the parentheses,
+   and no space inside the parentheses. The opening "{" should also
+   be on the same line.
+
+	(incorrect)
+	my_function(){
+		...
+
+	(correct)
+	my_function () {
+		...
+
+ - As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+   [::], [==], or [..]) for portability.
+
+   - We do not use \{m,n\};
+
+   - We do not use -E;
+
+   - We do not use ? or + (which are \{0,1\} and \{1,\}
+     respectively in BRE) but that goes without saying as these
+     are ERE elements not BRE (note that \? and \+ are not even part
+     of BRE -- making them accessible from BRE is a GNU extension).
+
+ - Use Git's gettext wrappers in git-sh-i18n to make the user
+   interface translatable. See "Marking strings for translation" in
+   po/README.
+
+ - We do not write our "test" command with "-a" and "-o" and use "&&"
+   or "||" to concatenate multiple "test" commands instead, because
+   the use of "-a/-o" is often error-prone.  E.g.
+
+     test -n "$x" -a "$a" = "$b"
+
+   is buggy and breaks when $x is "=", but
+
+     test -n "$x" && test "$a" = "$b"
+
+   does not have such a problem.
+
+
+For C programs:
+
+ - We use tabs to indent, and interpret tabs as taking up to
+   8 spaces.
+
+ - We try to keep to at most 80 characters per line.
+
+ - As a Git developer we assume you have a reasonably modern compiler
+   and we recommend you to enable the DEVELOPER makefile knob to
+   ensure your patch is clear of all compiler warnings we care about,
+   by e.g. "echo DEVELOPER=1 >>config.mak".
+
+ - We try to support a wide range of C compilers to compile Git with,
+   including old ones.  You should not use features from newer C
+   standard, even if your compiler groks them.
+
+   There are a few exceptions to this guideline:
+
+   . since early 2012 with e1327023ea, we have been using an enum
+     definition whose last element is followed by a comma.  This, like
+     an array initializer that ends with a trailing comma, can be used
+     to reduce the patch noise when adding a new identifier at the end.
+
+   . since mid 2017 with cbc0f81d, we have been using designated
+     initializers for struct (e.g. "struct t v = { .val = 'a' };").
+
+   . since mid 2017 with 512f41cf, we have been using designated
+     initializers for array (e.g. "int array[10] = { [5] = 2 }").
+
+   These used to be forbidden, but we have not heard any breakage
+   report, and they are assumed to be safe.
+
+ - Variables have to be declared at the beginning of the block, before
+   the first statement (i.e. -Wdeclaration-after-statement).
+
+ - Declaring a variable in the for loop "for (int i = 0; i < 10; i++)"
+   is still not allowed in this codebase.
+
+ - NULL pointers shall be written as NULL, not as 0.
+
+ - When declaring pointers, the star sides with the variable
+   name, i.e. "char *string", not "char* string" or
+   "char * string".  This makes it easier to understand code
+   like "char *string, c;".
+
+ - Use whitespace around operators and keywords, but not inside
+   parentheses and not around functions. So:
+
+        while (condition)
+		func(bar + 1);
+
+   and not:
+
+        while( condition )
+		func (bar+1);
+
+ - Do not explicitly compare an integral value with constant 0 or '\0',
+   or a pointer value with constant NULL.  For instance, to validate that
+   counted array <ptr, cnt> is initialized but has no elements, write:
+
+	if (!ptr || cnt)
+		BUG("empty array expected");
+
+   and not:
+
+	if (ptr == NULL || cnt != 0);
+		BUG("empty array expected");
+
+ - We avoid using braces unnecessarily.  I.e.
+
+	if (bla) {
+		x = 1;
+	}
+
+   is frowned upon. But there are a few exceptions:
+
+	- When the statement extends over a few lines (e.g., a while loop
+	  with an embedded conditional, or a comment). E.g.:
+
+		while (foo) {
+			if (x)
+				one();
+			else
+				two();
+		}
+
+		if (foo) {
+			/*
+			 * This one requires some explanation,
+			 * so we're better off with braces to make
+			 * it obvious that the indentation is correct.
+			 */
+			doit();
+		}
+
+	- When there are multiple arms to a conditional and some of them
+	  require braces, enclose even a single line block in braces for
+	  consistency. E.g.:
+
+		if (foo) {
+			doit();
+		} else {
+			one();
+			two();
+			three();
+		}
+
+ - We try to avoid assignments in the condition of an "if" statement.
+
+ - Try to make your code understandable.  You may put comments
+   in, but comments invariably tend to stale out when the code
+   they were describing changes.  Often splitting a function
+   into two makes the intention of the code much clearer.
+
+ - Multi-line comments include their delimiters on separate lines from
+   the text.  E.g.
+
+	/*
+	 * A very long
+	 * multi-line comment.
+	 */
+
+   Note however that a comment that explains a translatable string to
+   translators uses a convention of starting with a magic token
+   "TRANSLATORS: ", e.g.
+
+	/*
+	 * TRANSLATORS: here is a comment that explains the string to
+	 * be translated, that follows immediately after it.
+	 */
+	_("Here is a translatable string explained by the above.");
+
+ - Double negation is often harder to understand than no negation
+   at all.
+
+ - There are two schools of thought when it comes to comparison,
+   especially inside a loop. Some people prefer to have the less stable
+   value on the left hand side and the more stable value on the right hand
+   side, e.g. if you have a loop that counts variable i down to the
+   lower bound,
+
+	while (i > lower_bound) {
+		do something;
+		i--;
+	}
+
+   Other people prefer to have the textual order of values match the
+   actual order of values in their comparison, so that they can
+   mentally draw a number line from left to right and place these
+   values in order, i.e.
+
+	while (lower_bound < i) {
+		do something;
+		i--;
+	}
+
+   Both are valid, and we use both.  However, the more "stable" the
+   stable side becomes, the more we tend to prefer the former
+   (comparison with a constant, "i > 0", is an extreme example).
+   Just do not mix styles in the same part of the code and mimic
+   existing styles in the neighbourhood.
+
+ - There are two schools of thought when it comes to splitting a long
+   logical line into multiple lines.  Some people push the second and
+   subsequent lines far enough to the right with tabs and align them:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+		span_more_than_a_single_line_of ||
+		the_source_text) {
+                ...
+
+   while other people prefer to align the second and the subsequent
+   lines with the column immediately inside the opening parenthesis,
+   with tabs and spaces, following our "tabstop is always a multiple
+   of 8" convention:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of ||
+	    the_source_text) {
+                ...
+
+   Both are valid, and we use both.  Again, just do not mix styles in
+   the same part of the code and mimic existing styles in the
+   neighbourhood.
+
+ - When splitting a long logical line, some people change line before
+   a binary operator, so that the result looks like a parse tree when
+   you turn your head 90-degrees counterclockwise:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to
+	    || span_more_than_a_single_line_of_the_source_text) {
+
+   while other people prefer to leave the operator at the end of the
+   line:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of_the_source_text) {
+
+   Both are valid, but we tend to use the latter more, unless the
+   expression gets fairly complex, in which case the former tends to
+   be easier to read.  Again, just do not mix styles in the same part
+   of the code and mimic existing styles in the neighbourhood.
+
+ - When splitting a long logical line, with everything else being
+   equal, it is preferable to split after the operator at higher
+   level in the parse tree.  That is, this is more preferable:
+
+	if (a_very_long_variable * that_is_used_in +
+	    a_very_long_expression) {
+		...
+
+   than
+
+	if (a_very_long_variable *
+	    that_is_used_in + a_very_long_expression) {
+		...
+
+ - Some clever tricks, like using the !! operator with arithmetic
+   constructs, can be extremely confusing to others.  Avoid them,
+   unless there is a compelling reason to use them.
+
+ - Use the API.  No, really.  We have a strbuf (variable length
+   string), several arrays with the ALLOC_GROW() macro, a
+   string_list for sorted string lists, a hash map (mapping struct
+   objects) named "struct decorate", amongst other things.
+
+ - When you come up with an API, document its functions and structures
+   in the header file that exposes the API to its callers. Use what is
+   in "strbuf.h" as a model for the appropriate tone and level of
+   detail.
+
+ - The first #include in C files, except in platform specific compat/
+   implementations, must be either "git-compat-util.h", "cache.h" or
+   "builtin.h".  You do not have to include more than one of these.
+
+ - A C file must directly include the header files that declare the
+   functions and the types it uses, except for the functions and types
+   that are made available to it by including one of the header files
+   it must include by the previous rule.
+
+ - If you are planning a new command, consider writing it in shell
+   or perl first, so that changes in semantics can be easily
+   changed and discussed.  Many Git commands started out like
+   that, and a few are still scripts.
+
+ - Avoid introducing a new dependency into Git. This means you
+   usually should stay away from scripting languages not already
+   used in the Git core command set (unless your command is clearly
+   separate from it, such as an importer to convert random-scm-X
+   repositories to Git).
+
+ - When we pass <string, length> pair to functions, we should try to
+   pass them in that order.
+
+ - Use Git's gettext wrappers to make the user interface
+   translatable. See "Marking strings for translation" in po/README.
+
+ - Variables and functions local to a given source file should be marked
+   with "static". Variables that are visible to other source files
+   must be declared with "extern" in header files. However, function
+   declarations should not use "extern", as that is already the default.
+
+ - You can launch gdb around your program using the shorthand GIT_DEBUGGER.
+   Run `GIT_DEBUGGER=1 ./bin-wrappers/git foo` to simply use gdb as is, or
+   run `GIT_DEBUGGER="<debugger> <debugger-args>" ./bin-wrappers/git foo` to
+   use your own debugger and arguments. Example: `GIT_DEBUGGER="ddd --gdb"
+   ./bin-wrappers/git log` (See `wrap-for-bin.sh`.)
+
+For Perl programs:
+
+ - Most of the C guidelines above apply.
+
+ - We try to support Perl 5.8 and later ("use Perl 5.008").
+
+ - use strict and use warnings are strongly preferred.
+
+ - Don't overuse statement modifiers unless using them makes the
+   result easier to follow.
+
+	... do something ...
+	do_this() unless (condition);
+        ... do something else ...
+
+   is more readable than:
+
+	... do something ...
+	unless (condition) {
+		do_this();
+	}
+        ... do something else ...
+
+   *only* when the condition is so rare that do_this() will be almost
+   always called.
+
+ - We try to avoid assignments inside "if ()" conditions.
+
+ - Learn and use Git.pm if you need that functionality.
+
+ - For Emacs, it's useful to put the following in
+   GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode:
+
+    ;; note the first part is useful for C editing, too
+    ((nil . ((indent-tabs-mode . t)
+                  (tab-width . 8)
+                  (fill-column . 80)))
+     (cperl-mode . ((cperl-indent-level . 8)
+                    (cperl-extra-newline-before-brace . nil)
+                    (cperl-merge-trailing-else . t))))
+
+For Python scripts:
+
+ - We follow PEP-8 (http://www.python.org/dev/peps/pep-0008/).
+
+ - As a minimum, we aim to be compatible with Python 2.6 and 2.7.
+
+ - Where required libraries do not restrict us to Python 2, we try to
+   also be compatible with Python 3.1 and later.
+
+ - When you must differentiate between Unicode literals and byte string
+   literals, it is OK to use the 'b' prefix.  Even though the Python
+   documentation for version 2.6 does not mention this prefix, it has
+   been supported since version 2.6.0.
+
+Error Messages
+
+ - Do not end error messages with a full stop.
+
+ - Do not capitalize ("unable to open %s", not "Unable to open %s")
+
+ - Say what the error is first ("cannot open %s", not "%s: cannot open")
+
+
+Externally Visible Names
+
+ - For configuration variable names, follow the existing convention:
+
+   . The section name indicates the affected subsystem.
+
+   . The subsection name, if any, indicates which of an unbounded set
+     of things to set the value for.
+
+   . The variable name describes the effect of tweaking this knob.
+
+   The section and variable names that consist of multiple words are
+   formed by concatenating the words without punctuations (e.g. `-`),
+   and are broken using bumpyCaps in documentation as a hint to the
+   reader.
+
+   When choosing the variable namespace, do not use variable name for
+   specifying possibly unbounded set of things, most notably anything
+   an end user can freely come up with (e.g. branch names).  Instead,
+   use subsection names or variable values, like the existing variable
+   branch.<name>.description does.
+
+
+Writing Documentation:
+
+ Most (if not all) of the documentation pages are written in the
+ AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+ processed into HTML and manpages (e.g. git.html and git.1 in the
+ same directory).
+
+ The documentation liberally mixes US and UK English (en_US/UK)
+ norms for spelling and grammar, which is somewhat unfortunate.
+ In an ideal world, it would have been better if it consistently
+ used only one and not the other, and we would have picked en_US
+ (if you wish to correct the English of some of the existing
+ documentation, please see the documentation-related advice in the
+ Documentation/SubmittingPatches file).
+
+ Every user-visible change should be reflected in the documentation.
+ The same general rule as for code applies -- imitate the existing
+ conventions.
+
+ A few commented examples follow to provide reference when writing or
+ modifying command usage strings and synopsis sections in the manual
+ pages:
+
+ Placeholders are spelled in lowercase and enclosed in angle brackets:
+   <file>
+   --sort=<key>
+   --abbrev[=<n>]
+
+ If a placeholder has multiple words, they are separated by dashes:
+   <new-branch-name>
+   --template=<template-directory>
+
+ Possibility of multiple occurrences is indicated by three dots:
+   <file>...
+   (One or more of <file>.)
+
+ Optional parts are enclosed in square brackets:
+   [<extra>]
+   (Zero or one <extra>.)
+
+   --exec-path[=<path>]
+   (Option with an optional argument.  Note that the "=" is inside the
+   brackets.)
+
+   [<patch>...]
+   (Zero or more of <patch>.  Note that the dots are inside, not
+   outside the brackets.)
+
+ Multiple alternatives are indicated with vertical bars:
+   [-q | --quiet]
+   [--utf8 | --no-utf8]
+
+ Parentheses are used for grouping:
+   [(<rev> | <range>)...]
+   (Any number of either <rev> or <range>.  Parens are needed to make
+   it clear that "..." pertains to both <rev> and <range>.)
+
+   [(-p <parent>)...]
+   (Any number of option -p, each with one <parent> argument.)
+
+   git remote set-head <name> (-a | -d | <branch>)
+   (One and only one of "-a", "-d" or "<branch>" _must_ (no square
+   brackets) be provided.)
+
+ And a somewhat more contrived example:
+   --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+   Here "=" is outside the brackets, because "--diff-filter=" is a
+   valid usage.  "*" has its own pair of brackets, because it can
+   (optionally) be specified only when one or more of the letters is
+   also provided.
+
+  A note on notation:
+   Use 'git' (all lowercase) when talking about commands i.e. something
+   the user would type into a shell and use 'Git' (uppercase first letter)
+   when talking about the version control system and its properties.
+
+ A few commented examples follow to provide reference when writing or
+ modifying paragraphs or option/command explanations that contain options
+ or commands:
+
+ Literal examples (e.g. use of command-line options, command names,
+ branch names, URLs, pathnames (files and directories), configuration and
+ environment variables) must be typeset in monospace (i.e. wrapped with
+ backticks):
+   `--pretty=oneline`
+   `git rev-list`
+   `remote.pushDefault`
+   `http://git.example.com`
+   `.git/config`
+   `GIT_DIR`
+   `HEAD`
+
+ An environment variable must be prefixed with "$" only when referring to its
+ value and not when referring to the variable itself, in this case there is
+ nothing to add except the backticks:
+   `GIT_DIR` is specified
+   `$GIT_DIR/hooks/pre-receive`
+
+ Word phrases enclosed in `backtick characters` are rendered literally
+ and will not be further expanded. The use of `backticks` to achieve the
+ previous rule means that literal examples should not use AsciiDoc
+ escapes.
+   Correct:
+      `--pretty=oneline`
+   Incorrect:
+      `\--pretty=oneline`
+
+ If some place in the documentation needs to typeset a command usage
+ example with inline substitutions, it is fine to use +monospaced and
+ inline substituted text+ instead of `monospaced literal text`, and with
+ the former, the part that should not get substituted must be
+ quoted/escaped.
diff --git a/external/docs/asciidoc/384de0c2eb9bf8e5b95cd22ef5740abd694022d6 b/external/docs/asciidoc/384de0c2eb9bf8e5b95cd22ef5740abd694022d6
new file mode 100644
index 0000000000..fd27dcc85e
--- /dev/null
+++ b/external/docs/asciidoc/384de0c2eb9bf8e5b95cd22ef5740abd694022d6
@@ -0,0 +1,162 @@
+Reviewing Patches in the Git Project
+====================================
+
+Introduction
+------------
+The Git development community is a widely distributed, diverse, ever-changing
+group of individuals. Asynchronous communication via the Git mailing list poses
+unique challenges when reviewing or discussing patches. This document contains
+some guiding principles and helpful tools you can use to make your reviews both
+more efficient for yourself and more effective for other contributors.
+
+Note that none of the recommendations here are binding or in any way a
+requirement of participation in the Git community. They are provided as a
+resource to supplement your skills as a contributor.
+
+Principles
+----------
+
+Selecting patch(es) to review
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+If you are looking for a patch series in need of review, start by checking
+the latest "What's cooking in git.git" email
+(https://lore.kernel.org/git/xmqqilm1yp3m.fsf@gitster.g/[example]). The "What's
+cooking" emails & replies can be found using the query `s:"What's cooking"` on
+the https://lore.kernel.org/git/[`lore.kernel.org` mailing list archive];
+alternatively, you can find the contents of the "What's cooking" email tracked
+in `whats-cooking.txt` on the `todo` branch of Git. Topics tagged with "Needs
+review" and those in the "[New Topics]" section are typically those that would
+benefit the most from additional review.
+
+Patches can also be searched manually in the mailing list archive using a query
+like `s:"PATCH" -s:"Re:"`. You can browse these results for topics relevant to
+your expertise or interest.
+
+If you've already contributed to Git, you may also be CC'd in another
+contributor's patch series. These are topics where the author feels that your
+attention is warranted. This may be because their patch changes something you
+wrote previously (making you a good judge of whether the new approach does or
+doesn't work), or because you have the expertise to provide an exceptionally
+helpful review. There is no requirement to review these patches but, in the
+spirit of open source collaboration, you should strongly consider doing so.
+
+Reviewing patches
+~~~~~~~~~~~~~~~~~
+While every contributor takes their own approach to reviewing patches, here are
+some general pieces of advice to make your reviews as clear and helpful as
+possible. The advice is broken into two rough categories: high-level reviewing
+guidance, and concrete tips for interacting with patches on the mailing list.
+
+==== High-level guidance
+- Remember to review the content of commit messages for correctness and clarity,
+  in addition to the code change in the patch's diff. The commit message of a
+  patch should accurately and fully explain the code change being made in the
+  diff.
+
+- Reviewing test coverage is an important - but easy to overlook - component of
+  reviews. A patch's changes may be covered by existing tests, or new tests may
+  be introduced to exercise new behavior. Checking out a patch or series locally
+  allows you to manually mutate lines of new & existing tests to verify expected
+  pass/fail behavior. You can use this information to verify proper coverage or
+  to suggest additional tests the author could add.
+
+- When providing a recommendation, be as clear as possible about whether you
+  consider it "blocking" (the code would be broken or otherwise made worse if an
+  issue isn't fixed) or "non-blocking" (the patch could be made better by taking
+  the recommendation, but acceptance of the series does not require it).
+  Non-blocking recommendations can be particularly ambiguous when they are
+  related to - but outside the scope of - a series ("nice-to-have"s), or when
+  they represent only stylistic differences between the author and reviewer.
+
+- When commenting on an issue, try to include suggestions for how the author
+  could fix it. This not only helps the author to understand and fix the issue,
+  it also deepens and improves your understanding of the topic.
+
+- Reviews do not need to exclusively point out problems. Feel free to "think out
+  loud" in your review: describe how you read & understood a complex section of
+  a patch, ask a question about something that confused you, point out something
+  you found exceptionally well-written, etc. In particular, uplifting feedback
+  goes a long way towards encouraging contributors to participate more actively
+  in the Git community.
+
+==== Performing your review
+- Provide your review comments per-patch in a plaintext "Reply-All" email to the
+  relevant patch. Comments should be made inline, immediately below the relevant
+  section(s).
+
+- You may find that the limited context provided in the patch diff is sometimes
+  insufficient for a thorough review. In such cases, you can review patches in
+  your local tree by either applying patches with linkgit:git-am[1] or checking
+  out the associated branch from https://github.com/gitster/git once the series
+  is tracked there.
+
+- Large, complicated patch diffs are sometimes unavoidable, such as when they
+  refactor existing code. If you find such a patch difficult to parse, try
+  reviewing the diff produced with the `--color-moved` and/or
+  `--ignore-space-change` options.
+
+- If a patch is long, you are encouraged to delete parts of it that are
+  unrelated to your review from the email reply. Make sure to leave enough
+  context for readers to understand your comments!
+
+- If you cannot complete a full review of a series all at once, consider letting
+  the author know (on- or off-list) if/when you plan to review the rest of the
+  series.
+
+Completing a review
+~~~~~~~~~~~~~~~~~~~
+Once each patch of a series is reviewed, the author (and/or other contributors)
+may discuss the review(s). This may result in no changes being applied, or the
+author will send a new version of their patch(es).
+
+After a series is rerolled in response to your or others' review, make sure to
+re-review the updates. If you are happy with the state of the patch series,
+explicitly indicate your approval (typically with a reply to the latest
+version's cover letter). Optionally, you can let the author know that they can
+add a "Reviewed-by: <you>" trailer if they resubmit the reviewed patch verbatim
+in a later iteration of the series.
+
+Finally, subsequent "What's cooking" emails may explicitly ask whether a
+reviewed topic is ready for merging to the `next` branch (typically phrased
+"Will merge to \'next\'?"). You can help the maintainer and author by responding
+with a short description of the state of your (and others', if applicable)
+review, including the links to the relevant thread(s).
+
+Terminology
+-----------
+nit: ::
+	Denotes a small issue that should be fixed, such as a typographical error
+	or misalignment of conditions in an `if()` statement.
+
+aside: ::
+optional: ::
+non-blocking: ::
+	Indicates to the reader that the following comment should not block the
+	acceptance of the patch or series. These are typically recommendations
+	related to code organization & style, or musings about topics related to
+	the patch in question, but beyond its scope.
+
+s/<before>/<after>/::
+	Shorthand for "you wrote <before>, but I think you meant <after>," usually
+	for misspellings or other typographical errors. The syntax is a reference
+	to "substitute" command commonly found in Unix tools such as `ed`, `sed`,
+	`vim`, and `perl`.
+
+cover letter::
+	The "Patch 0" of a multi-patch series. This email describes the
+	high-level intent and structure of the patch series to readers on the
+	Git mailing list. It is also where the changelog notes and range-diff of
+	subsequent versions are provided by the author.
++
+On single-patch submissions, cover letter content is typically not sent as a
+separate email. Instead, it is inserted between the end of the patch's commit
+message (after the `---`) and the beginning of the diff.
+
+#leftoverbits::
+  Used by either an author or a reviewer to describe features or suggested
+  changes that are out-of-scope of a given patch or series, but are relevant
+  to the topic for the sake of discussion.
+
+See Also
+--------
+link:/docs/MyFirstContribution[MyFirstContribution]
diff --git a/external/docs/asciidoc/39bbf29f884e401a43d2af98c30539f335176513 b/external/docs/asciidoc/39bbf29f884e401a43d2af98c30539f335176513
new file mode 100644
index 0000000000..a4191aa388
--- /dev/null
+++ b/external/docs/asciidoc/39bbf29f884e401a43d2af98c30539f335176513
@@ -0,0 +1,584 @@
+Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, a few rough rules are:
+
+ - Most importantly, we never say "It's in POSIX; we'll happily
+   ignore your needs should your system not conform to it."
+   We live in the real world.
+
+ - However, we often say "Let's stay away from that construct,
+   it's not even in POSIX".
+
+ - In spite of the above two rules, we sometimes say "Although
+   this is not in POSIX, it (is so convenient | makes the code
+   much more readable | has other good characteristics) and
+   practically all the platforms we care about support it, so
+   let's use it".
+
+   Again, we live in the real world, and it is sometimes a
+   judgement call, the decision based more on real world
+   constraints people face than what the paper standard says.
+
+ - Fixing style violations while working on a real change as a
+   preparatory clean-up step is good, but otherwise avoid useless code
+   churn for the sake of conforming to the style.
+
+   "Once it _is_ in the tree, it's not really worth the patch noise to
+   go and fix it up."
+   Cf. http://article.gmane.org/gmane.linux.kernel/943020
+
+Make your code readable and sensible, and don't try to be clever.
+
+As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the _local_
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn't match the overall style of existing code).
+
+But if you must have a list of rules, here they are.
+
+For shell scripts specifically (not exhaustive):
+
+ - We use tabs for indentation.
+
+ - Case arms are indented at the same depth as case and esac lines,
+   like this:
+
+	case "$variable" in
+	pattern1)
+		do this
+		;;
+	pattern2)
+		do that
+		;;
+	esac
+
+ - Redirection operators should be written with space before, but no
+   space after them.  In other words, write 'echo test >"$file"'
+   instead of 'echo test> $file' or 'echo test > $file'.  Note that
+   even though it is not required by POSIX to double-quote the
+   redirection target in a variable (as shown above), our code does so
+   because some versions of bash issue a warning without the quotes.
+
+	(incorrect)
+	cat hello > world < universe
+	echo hello >$world
+
+	(correct)
+	cat hello >world <universe
+	echo hello >"$world"
+
+ - We prefer $( ... ) for command substitution; unlike ``, it
+   properly nests.  It should have been the way Bourne spelled
+   it from day one, but unfortunately isn't.
+
+ - If you want to find out if a command is available on the user's
+   $PATH, you should use 'type <command>', instead of 'which <command>'.
+   The output of 'which' is not machine parseable and its exit code
+   is not reliable across platforms.
+
+ - We use POSIX compliant parameter substitutions and avoid bashisms;
+   namely:
+
+   - We use ${parameter-word} and its [-=?+] siblings, and their
+     colon'ed "unset or null" form.
+
+   - We use ${parameter#word} and its [#%] siblings, and their
+     doubled "longest matching" form.
+
+   - No "Substring Expansion" ${parameter:offset:length}.
+
+   - No shell arrays.
+
+   - No strlen ${#parameter}.
+
+   - No pattern replacement ${parameter/pattern/string}.
+
+ - We use Arithmetic Expansion $(( ... )).
+
+ - Inside Arithmetic Expansion, spell shell variables with $ in front
+   of them, as some shells do not grok $((x)) while accepting $(($x))
+   just fine (e.g. dash older than 0.5.4).
+
+ - We do not use Process Substitution <(list) or >(list).
+
+ - Do not write control structures on a single line with semicolon.
+   "then" should be on the next line for if statements, and "do"
+   should be on the next line for "while" and "for".
+
+	(incorrect)
+	if test -f hello; then
+		do this
+	fi
+
+	(correct)
+	if test -f hello
+	then
+		do this
+	fi
+
+ - We prefer "test" over "[ ... ]".
+
+ - We do not write the noiseword "function" in front of shell
+   functions.
+
+ - We prefer a space between the function name and the parentheses,
+   and no space inside the parentheses. The opening "{" should also
+   be on the same line.
+
+	(incorrect)
+	my_function(){
+		...
+
+	(correct)
+	my_function () {
+		...
+
+ - As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+   [::], [==], or [..]) for portability.
+
+   - We do not use \{m,n\};
+
+   - We do not use -E;
+
+   - We do not use ? or + (which are \{0,1\} and \{1,\}
+     respectively in BRE) but that goes without saying as these
+     are ERE elements not BRE (note that \? and \+ are not even part
+     of BRE -- making them accessible from BRE is a GNU extension).
+
+ - Use Git's gettext wrappers in git-sh-i18n to make the user
+   interface translatable. See "Marking strings for translation" in
+   po/README.
+
+ - We do not write our "test" command with "-a" and "-o" and use "&&"
+   or "||" to concatenate multiple "test" commands instead, because
+   the use of "-a/-o" is often error-prone.  E.g.
+
+     test -n "$x" -a "$a" = "$b"
+
+   is buggy and breaks when $x is "=", but
+
+     test -n "$x" && test "$a" = "$b"
+
+   does not have such a problem.
+
+
+For C programs:
+
+ - We use tabs to indent, and interpret tabs as taking up to
+   8 spaces.
+
+ - We try to keep to at most 80 characters per line.
+
+ - As a Git developer we assume you have a reasonably modern compiler
+   and we recommend you to enable the DEVELOPER makefile knob to
+   ensure your patch is clear of all compiler warnings we care about,
+   by e.g. "echo DEVELOPER=1 >>config.mak".
+
+ - We try to support a wide range of C compilers to compile Git with,
+   including old ones. That means that you should not use C99
+   initializers, even if a lot of compilers grok it.
+
+ - Variables have to be declared at the beginning of the block.
+
+ - NULL pointers shall be written as NULL, not as 0.
+
+ - When declaring pointers, the star sides with the variable
+   name, i.e. "char *string", not "char* string" or
+   "char * string".  This makes it easier to understand code
+   like "char *string, c;".
+
+ - Use whitespace around operators and keywords, but not inside
+   parentheses and not around functions. So:
+
+        while (condition)
+		func(bar + 1);
+
+   and not:
+
+        while( condition )
+		func (bar+1);
+
+ - We avoid using braces unnecessarily.  I.e.
+
+	if (bla) {
+		x = 1;
+	}
+
+   is frowned upon. But there are a few exceptions:
+
+	- When the statement extends over a few lines (e.g., a while loop
+	  with an embedded conditional, or a comment). E.g.:
+
+		while (foo) {
+			if (x)
+				one();
+			else
+				two();
+		}
+
+		if (foo) {
+			/*
+			 * This one requires some explanation,
+			 * so we're better off with braces to make
+			 * it obvious that the indentation is correct.
+			 */
+			doit();
+		}
+
+	- When there are multiple arms to a conditional and some of them
+	  require braces, enclose even a single line block in braces for
+	  consistency. E.g.:
+
+		if (foo) {
+			doit();
+		} else {
+			one();
+			two();
+			three();
+		}
+
+ - We try to avoid assignments in the condition of an "if" statement.
+
+ - Try to make your code understandable.  You may put comments
+   in, but comments invariably tend to stale out when the code
+   they were describing changes.  Often splitting a function
+   into two makes the intention of the code much clearer.
+
+ - Multi-line comments include their delimiters on separate lines from
+   the text.  E.g.
+
+	/*
+	 * A very long
+	 * multi-line comment.
+	 */
+
+   Note however that a comment that explains a translatable string to
+   translators uses a convention of starting with a magic token
+   "TRANSLATORS: " immediately after the opening delimiter, even when
+   it spans multiple lines.  We do not add an asterisk at the beginning
+   of each line, either.  E.g.
+
+	/* TRANSLATORS: here is a comment that explains the string
+	   to be translated, that follows immediately after it */
+	_("Here is a translatable string explained by the above.");
+
+ - Double negation is often harder to understand than no negation
+   at all.
+
+ - There are two schools of thought when it comes to comparison,
+   especially inside a loop. Some people prefer to have the less stable
+   value on the left hand side and the more stable value on the right hand
+   side, e.g. if you have a loop that counts variable i down to the
+   lower bound,
+
+	while (i > lower_bound) {
+		do something;
+		i--;
+	}
+
+   Other people prefer to have the textual order of values match the
+   actual order of values in their comparison, so that they can
+   mentally draw a number line from left to right and place these
+   values in order, i.e.
+
+	while (lower_bound < i) {
+		do something;
+		i--;
+	}
+
+   Both are valid, and we use both.  However, the more "stable" the
+   stable side becomes, the more we tend to prefer the former
+   (comparison with a constant, "i > 0", is an extreme example).
+   Just do not mix styles in the same part of the code and mimic
+   existing styles in the neighbourhood.
+
+ - There are two schools of thought when it comes to splitting a long
+   logical line into multiple lines.  Some people push the second and
+   subsequent lines far enough to the right with tabs and align them:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+		span_more_than_a_single_line_of ||
+		the_source_text) {
+                ...
+
+   while other people prefer to align the second and the subsequent
+   lines with the column immediately inside the opening parenthesis,
+   with tabs and spaces, following our "tabstop is always a multiple
+   of 8" convention:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of ||
+	    the_source_text) {
+                ...
+
+   Both are valid, and we use both.  Again, just do not mix styles in
+   the same part of the code and mimic existing styles in the
+   neighbourhood.
+
+ - When splitting a long logical line, some people change line before
+   a binary operator, so that the result looks like a parse tree when
+   you turn your head 90-degrees counterclockwise:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to
+	    || span_more_than_a_single_line_of_the_source_text) {
+
+   while other people prefer to leave the operator at the end of the
+   line:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of_the_source_text) {
+
+   Both are valid, but we tend to use the latter more, unless the
+   expression gets fairly complex, in which case the former tends to
+   be easier to read.  Again, just do not mix styles in the same part
+   of the code and mimic existing styles in the neighbourhood.
+
+ - When splitting a long logical line, with everything else being
+   equal, it is preferable to split after the operator at higher
+   level in the parse tree.  That is, this is more preferable:
+
+	if (a_very_long_variable * that_is_used_in +
+	    a_very_long_expression) {
+		...
+
+   than
+
+	if (a_very_long_variable *
+	    that_is_used_in + a_very_long_expression) {
+		...
+
+ - Some clever tricks, like using the !! operator with arithmetic
+   constructs, can be extremely confusing to others.  Avoid them,
+   unless there is a compelling reason to use them.
+
+ - Use the API.  No, really.  We have a strbuf (variable length
+   string), several arrays with the ALLOC_GROW() macro, a
+   string_list for sorted string lists, a hash map (mapping struct
+   objects) named "struct decorate", amongst other things.
+
+ - When you come up with an API, document it.
+
+ - The first #include in C files, except in platform specific compat/
+   implementations, must be either "git-compat-util.h", "cache.h" or
+   "builtin.h".  You do not have to include more than one of these.
+
+ - A C file must directly include the header files that declare the
+   functions and the types it uses, except for the functions and types
+   that are made available to it by including one of the header files
+   it must include by the previous rule.
+
+ - If you are planning a new command, consider writing it in shell
+   or perl first, so that changes in semantics can be easily
+   changed and discussed.  Many Git commands started out like
+   that, and a few are still scripts.
+
+ - Avoid introducing a new dependency into Git. This means you
+   usually should stay away from scripting languages not already
+   used in the Git core command set (unless your command is clearly
+   separate from it, such as an importer to convert random-scm-X
+   repositories to Git).
+
+ - When we pass <string, length> pair to functions, we should try to
+   pass them in that order.
+
+ - Use Git's gettext wrappers to make the user interface
+   translatable. See "Marking strings for translation" in po/README.
+
+For Perl programs:
+
+ - Most of the C guidelines above apply.
+
+ - We try to support Perl 5.8 and later ("use Perl 5.008").
+
+ - use strict and use warnings are strongly preferred.
+
+ - Don't overuse statement modifiers unless using them makes the
+   result easier to follow.
+
+	... do something ...
+	do_this() unless (condition);
+        ... do something else ...
+
+   is more readable than:
+
+	... do something ...
+	unless (condition) {
+		do_this();
+	}
+        ... do something else ...
+
+   *only* when the condition is so rare that do_this() will be almost
+   always called.
+
+ - We try to avoid assignments inside "if ()" conditions.
+
+ - Learn and use Git.pm if you need that functionality.
+
+ - For Emacs, it's useful to put the following in
+   GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode:
+
+    ;; note the first part is useful for C editing, too
+    ((nil . ((indent-tabs-mode . t)
+                  (tab-width . 8)
+                  (fill-column . 80)))
+     (cperl-mode . ((cperl-indent-level . 8)
+                    (cperl-extra-newline-before-brace . nil)
+                    (cperl-merge-trailing-else . t))))
+
+For Python scripts:
+
+ - We follow PEP-8 (http://www.python.org/dev/peps/pep-0008/).
+
+ - As a minimum, we aim to be compatible with Python 2.6 and 2.7.
+
+ - Where required libraries do not restrict us to Python 2, we try to
+   also be compatible with Python 3.1 and later.
+
+ - When you must differentiate between Unicode literals and byte string
+   literals, it is OK to use the 'b' prefix.  Even though the Python
+   documentation for version 2.6 does not mention this prefix, it has
+   been supported since version 2.6.0.
+
+Error Messages
+
+ - Do not end error messages with a full stop.
+
+ - Do not capitalize ("unable to open %s", not "Unable to open %s")
+
+ - Say what the error is first ("cannot open %s", not "%s: cannot open")
+
+
+Externally Visible Names
+
+ - For configuration variable names, follow the existing convention:
+
+   . The section name indicates the affected subsystem.
+
+   . The subsection name, if any, indicates which of an unbounded set
+     of things to set the value for.
+
+   . The variable name describes the effect of tweaking this knob.
+
+   The section and variable names that consist of multiple words are
+   formed by concatenating the words without punctuations (e.g. `-`),
+   and are broken using bumpyCaps in documentation as a hint to the
+   reader.
+
+   When choosing the variable namespace, do not use variable name for
+   specifying possibly unbounded set of things, most notably anything
+   an end user can freely come up with (e.g. branch names).  Instead,
+   use subsection names or variable values, like the existing variable
+   branch.<name>.description does.
+
+
+Writing Documentation:
+
+ Most (if not all) of the documentation pages are written in the
+ AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+ processed into HTML and manpages (e.g. git.html and git.1 in the
+ same directory).
+
+ The documentation liberally mixes US and UK English (en_US/UK)
+ norms for spelling and grammar, which is somewhat unfortunate.
+ In an ideal world, it would have been better if it consistently
+ used only one and not the other, and we would have picked en_US
+ (if you wish to correct the English of some of the existing
+ documentation, please see the documentation-related advice in the
+ Documentation/SubmittingPatches file).
+
+ Every user-visible change should be reflected in the documentation.
+ The same general rule as for code applies -- imitate the existing
+ conventions.
+
+ A few commented examples follow to provide reference when writing or
+ modifying command usage strings and synopsis sections in the manual
+ pages:
+
+ Placeholders are spelled in lowercase and enclosed in angle brackets:
+   <file>
+   --sort=<key>
+   --abbrev[=<n>]
+
+ If a placeholder has multiple words, they are separated by dashes:
+   <new-branch-name>
+   --template=<template-directory>
+
+ Possibility of multiple occurrences is indicated by three dots:
+   <file>...
+   (One or more of <file>.)
+
+ Optional parts are enclosed in square brackets:
+   [<extra>]
+   (Zero or one <extra>.)
+
+   --exec-path[=<path>]
+   (Option with an optional argument.  Note that the "=" is inside the
+   brackets.)
+
+   [<patch>...]
+   (Zero or more of <patch>.  Note that the dots are inside, not
+   outside the brackets.)
+
+ Multiple alternatives are indicated with vertical bars:
+   [-q | --quiet]
+   [--utf8 | --no-utf8]
+
+ Parentheses are used for grouping:
+   [(<rev> | <range>)...]
+   (Any number of either <rev> or <range>.  Parens are needed to make
+   it clear that "..." pertains to both <rev> and <range>.)
+
+   [(-p <parent>)...]
+   (Any number of option -p, each with one <parent> argument.)
+
+   git remote set-head <name> (-a | -d | <branch>)
+   (One and only one of "-a", "-d" or "<branch>" _must_ (no square
+   brackets) be provided.)
+
+ And a somewhat more contrived example:
+   --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+   Here "=" is outside the brackets, because "--diff-filter=" is a
+   valid usage.  "*" has its own pair of brackets, because it can
+   (optionally) be specified only when one or more of the letters is
+   also provided.
+
+  A note on notation:
+   Use 'git' (all lowercase) when talking about commands i.e. something
+   the user would type into a shell and use 'Git' (uppercase first letter)
+   when talking about the version control system and its properties.
+
+ A few commented examples follow to provide reference when writing or
+ modifying paragraphs or option/command explanations that contain options
+ or commands:
+
+ Literal examples (e.g. use of command-line options, command names,
+ branch names, configuration and environment variables) must be
+ typeset in monospace (i.e. wrapped with backticks):
+   `--pretty=oneline`
+   `git rev-list`
+   `remote.pushDefault`
+   `GIT_DIR`
+   `HEAD`
+
+ An environment variable must be prefixed with "$" only when referring to its
+ value and not when referring to the variable itself, in this case there is
+ nothing to add except the backticks:
+   `GIT_DIR` is specified
+   `$GIT_DIR/hooks/pre-receive`
+
+ Word phrases enclosed in `backtick characters` are rendered literally
+ and will not be further expanded. The use of `backticks` to achieve the
+ previous rule means that literal examples should not use AsciiDoc
+ escapes.
+   Correct:
+      `--pretty=oneline`
+   Incorrect:
+      `\--pretty=oneline`
+
+ If some place in the documentation needs to typeset a command usage
+ example with inline substitutions, it is fine to use +monospaced and
+ inline substituted text+ instead of `monospaced literal text`, and with
+ the former, the part that should not get substituted must be
+ quoted/escaped.
diff --git a/external/docs/asciidoc/55011116bc4302d7dde275723d3fb60e9bf39d8e b/external/docs/asciidoc/55011116bc4302d7dde275723d3fb60e9bf39d8e
new file mode 100644
index 0000000000..0ddd36879a
--- /dev/null
+++ b/external/docs/asciidoc/55011116bc4302d7dde275723d3fb60e9bf39d8e
@@ -0,0 +1,549 @@
+Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, a few rough rules are:
+
+ - Most importantly, we never say "It's in POSIX; we'll happily
+   ignore your needs should your system not conform to it."
+   We live in the real world.
+
+ - However, we often say "Let's stay away from that construct,
+   it's not even in POSIX".
+
+ - In spite of the above two rules, we sometimes say "Although
+   this is not in POSIX, it (is so convenient | makes the code
+   much more readable | has other good characteristics) and
+   practically all the platforms we care about support it, so
+   let's use it".
+
+   Again, we live in the real world, and it is sometimes a
+   judgement call, the decision based more on real world
+   constraints people face than what the paper standard says.
+
+ - Fixing style violations while working on a real change as a
+   preparatory clean-up step is good, but otherwise avoid useless code
+   churn for the sake of conforming to the style.
+
+   "Once it _is_ in the tree, it's not really worth the patch noise to
+   go and fix it up."
+   Cf. http://article.gmane.org/gmane.linux.kernel/943020
+
+Make your code readable and sensible, and don't try to be clever.
+
+As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the _local_
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn't match the overall style of existing code).
+
+But if you must have a list of rules, here they are.
+
+For shell scripts specifically (not exhaustive):
+
+ - We use tabs for indentation.
+
+ - Case arms are indented at the same depth as case and esac lines,
+   like this:
+
+	case "$variable" in
+	pattern1)
+		do this
+		;;
+	pattern2)
+		do that
+		;;
+	esac
+
+ - Redirection operators should be written with space before, but no
+   space after them.  In other words, write 'echo test >"$file"'
+   instead of 'echo test> $file' or 'echo test > $file'.  Note that
+   even though it is not required by POSIX to double-quote the
+   redirection target in a variable (as shown above), our code does so
+   because some versions of bash issue a warning without the quotes.
+
+	(incorrect)
+	cat hello > world < universe
+	echo hello >$world
+
+	(correct)
+	cat hello >world <universe
+	echo hello >"$world"
+
+ - We prefer $( ... ) for command substitution; unlike ``, it
+   properly nests.  It should have been the way Bourne spelled
+   it from day one, but unfortunately isn't.
+
+ - If you want to find out if a command is available on the user's
+   $PATH, you should use 'type <command>', instead of 'which <command>'.
+   The output of 'which' is not machine parseable and its exit code
+   is not reliable across platforms.
+
+ - We use POSIX compliant parameter substitutions and avoid bashisms;
+   namely:
+
+   - We use ${parameter-word} and its [-=?+] siblings, and their
+     colon'ed "unset or null" form.
+
+   - We use ${parameter#word} and its [#%] siblings, and their
+     doubled "longest matching" form.
+
+   - No "Substring Expansion" ${parameter:offset:length}.
+
+   - No shell arrays.
+
+   - No strlen ${#parameter}.
+
+   - No pattern replacement ${parameter/pattern/string}.
+
+ - We use Arithmetic Expansion $(( ... )).
+
+ - Inside Arithmetic Expansion, spell shell variables with $ in front
+   of them, as some shells do not grok $((x)) while accepting $(($x))
+   just fine (e.g. dash older than 0.5.4).
+
+ - We do not use Process Substitution <(list) or >(list).
+
+ - Do not write control structures on a single line with semicolon.
+   "then" should be on the next line for if statements, and "do"
+   should be on the next line for "while" and "for".
+
+	(incorrect)
+	if test -f hello; then
+		do this
+	fi
+
+	(correct)
+	if test -f hello
+	then
+		do this
+	fi
+
+ - We prefer "test" over "[ ... ]".
+
+ - We do not write the noiseword "function" in front of shell
+   functions.
+
+ - We prefer a space between the function name and the parentheses,
+   and no space inside the parentheses. The opening "{" should also
+   be on the same line.
+
+	(incorrect)
+	my_function(){
+		...
+
+	(correct)
+	my_function () {
+		...
+
+ - As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+   [::], [==], or [..]) for portability.
+
+   - We do not use \{m,n\};
+
+   - We do not use -E;
+
+   - We do not use ? or + (which are \{0,1\} and \{1,\}
+     respectively in BRE) but that goes without saying as these
+     are ERE elements not BRE (note that \? and \+ are not even part
+     of BRE -- making them accessible from BRE is a GNU extension).
+
+ - Use Git's gettext wrappers in git-sh-i18n to make the user
+   interface translatable. See "Marking strings for translation" in
+   po/README.
+
+ - We do not write our "test" command with "-a" and "-o" and use "&&"
+   or "||" to concatenate multiple "test" commands instead, because
+   the use of "-a/-o" is often error-prone.  E.g.
+
+     test -n "$x" -a "$a" = "$b"
+
+   is buggy and breaks when $x is "=", but
+
+     test -n "$x" && test "$a" = "$b"
+
+   does not have such a problem.
+
+
+For C programs:
+
+ - We use tabs to indent, and interpret tabs as taking up to
+   8 spaces.
+
+ - We try to keep to at most 80 characters per line.
+
+ - As a Git developer we assume you have a reasonably modern compiler
+   and we recommend you to enable the DEVELOPER makefile knob to
+   ensure your patch is clear of all compiler warnings we care about,
+   by e.g. "echo DEVELOPER=1 >>config.mak".
+
+ - We try to support a wide range of C compilers to compile Git with,
+   including old ones. That means that you should not use C99
+   initializers, even if a lot of compilers grok it.
+
+ - Variables have to be declared at the beginning of the block.
+
+ - NULL pointers shall be written as NULL, not as 0.
+
+ - When declaring pointers, the star sides with the variable
+   name, i.e. "char *string", not "char* string" or
+   "char * string".  This makes it easier to understand code
+   like "char *string, c;".
+
+ - Use whitespace around operators and keywords, but not inside
+   parentheses and not around functions. So:
+
+        while (condition)
+		func(bar + 1);
+
+   and not:
+
+        while( condition )
+		func (bar+1);
+
+ - We avoid using braces unnecessarily.  I.e.
+
+	if (bla) {
+		x = 1;
+	}
+
+   is frowned upon.  A gray area is when the statement extends
+   over a few lines, and/or you have a lengthy comment atop of
+   it.  Also, like in the Linux kernel, if there is a long list
+   of "else if" statements, it can make sense to add braces to
+   single line blocks.
+
+ - We try to avoid assignments in the condition of an "if" statement.
+
+ - Try to make your code understandable.  You may put comments
+   in, but comments invariably tend to stale out when the code
+   they were describing changes.  Often splitting a function
+   into two makes the intention of the code much clearer.
+
+ - Multi-line comments include their delimiters on separate lines from
+   the text.  E.g.
+
+	/*
+	 * A very long
+	 * multi-line comment.
+	 */
+
+   Note however that a comment that explains a translatable string to
+   translators uses a convention of starting with a magic token
+   "TRANSLATORS: " immediately after the opening delimiter, even when
+   it spans multiple lines.  We do not add an asterisk at the beginning
+   of each line, either.  E.g.
+
+	/* TRANSLATORS: here is a comment that explains the string
+	   to be translated, that follows immediately after it */
+	_("Here is a translatable string explained by the above.");
+
+ - Double negation is often harder to understand than no negation
+   at all.
+
+ - There are two schools of thought when it comes to comparison,
+   especially inside a loop. Some people prefer to have the less stable
+   value on the left hand side and the more stable value on the right hand
+   side, e.g. if you have a loop that counts variable i down to the
+   lower bound,
+
+	while (i > lower_bound) {
+		do something;
+		i--;
+	}
+
+   Other people prefer to have the textual order of values match the
+   actual order of values in their comparison, so that they can
+   mentally draw a number line from left to right and place these
+   values in order, i.e.
+
+	while (lower_bound < i) {
+		do something;
+		i--;
+	}
+
+   Both are valid, and we use both.  However, the more "stable" the
+   stable side becomes, the more we tend to prefer the former
+   (comparison with a constant, "i > 0", is an extreme example).
+   Just do not mix styles in the same part of the code and mimic
+   existing styles in the neighbourhood.
+
+ - There are two schools of thought when it comes to splitting a long
+   logical line into multiple lines.  Some people push the second and
+   subsequent lines far enough to the right with tabs and align them:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+		span_more_than_a_single_line_of ||
+		the_source_text) {
+                ...
+
+   while other people prefer to align the second and the subsequent
+   lines with the column immediately inside the opening parenthesis,
+   with tabs and spaces, following our "tabstop is always a multiple
+   of 8" convention:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of ||
+	    the_source_text) {
+                ...
+
+   Both are valid, and we use both.  Again, just do not mix styles in
+   the same part of the code and mimic existing styles in the
+   neighbourhood.
+
+ - When splitting a long logical line, some people change line before
+   a binary operator, so that the result looks like a parse tree when
+   you turn your head 90-degrees counterclockwise:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to
+	    || span_more_than_a_single_line_of_the_source_text) {
+
+   while other people prefer to leave the operator at the end of the
+   line:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of_the_source_text) {
+
+   Both are valid, but we tend to use the latter more, unless the
+   expression gets fairly complex, in which case the former tends to
+   be easier to read.  Again, just do not mix styles in the same part
+   of the code and mimic existing styles in the neighbourhood.
+
+ - When splitting a long logical line, with everything else being
+   equal, it is preferable to split after the operator at higher
+   level in the parse tree.  That is, this is more preferable:
+
+	if (a_very_long_variable * that_is_used_in +
+	    a_very_long_expression) {
+		...
+
+   than
+
+	if (a_very_long_variable *
+	    that_is_used_in + a_very_long_expression) {
+		...
+
+ - Some clever tricks, like using the !! operator with arithmetic
+   constructs, can be extremely confusing to others.  Avoid them,
+   unless there is a compelling reason to use them.
+
+ - Use the API.  No, really.  We have a strbuf (variable length
+   string), several arrays with the ALLOC_GROW() macro, a
+   string_list for sorted string lists, a hash map (mapping struct
+   objects) named "struct decorate", amongst other things.
+
+ - When you come up with an API, document it.
+
+ - The first #include in C files, except in platform specific compat/
+   implementations, must be either "git-compat-util.h", "cache.h" or
+   "builtin.h".  You do not have to include more than one of these.
+
+ - A C file must directly include the header files that declare the
+   functions and the types it uses, except for the functions and types
+   that are made available to it by including one of the header files
+   it must include by the previous rule.
+
+ - If you are planning a new command, consider writing it in shell
+   or perl first, so that changes in semantics can be easily
+   changed and discussed.  Many Git commands started out like
+   that, and a few are still scripts.
+
+ - Avoid introducing a new dependency into Git. This means you
+   usually should stay away from scripting languages not already
+   used in the Git core command set (unless your command is clearly
+   separate from it, such as an importer to convert random-scm-X
+   repositories to Git).
+
+ - When we pass <string, length> pair to functions, we should try to
+   pass them in that order.
+
+ - Use Git's gettext wrappers to make the user interface
+   translatable. See "Marking strings for translation" in po/README.
+
+For Perl programs:
+
+ - Most of the C guidelines above apply.
+
+ - We try to support Perl 5.8 and later ("use Perl 5.008").
+
+ - use strict and use warnings are strongly preferred.
+
+ - Don't overuse statement modifiers unless using them makes the
+   result easier to follow.
+
+	... do something ...
+	do_this() unless (condition);
+        ... do something else ...
+
+   is more readable than:
+
+	... do something ...
+	unless (condition) {
+		do_this();
+	}
+        ... do something else ...
+
+   *only* when the condition is so rare that do_this() will be almost
+   always called.
+
+ - We try to avoid assignments inside "if ()" conditions.
+
+ - Learn and use Git.pm if you need that functionality.
+
+ - For Emacs, it's useful to put the following in
+   GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode:
+
+    ;; note the first part is useful for C editing, too
+    ((nil . ((indent-tabs-mode . t)
+                  (tab-width . 8)
+                  (fill-column . 80)))
+     (cperl-mode . ((cperl-indent-level . 8)
+                    (cperl-extra-newline-before-brace . nil)
+                    (cperl-merge-trailing-else . t))))
+
+For Python scripts:
+
+ - We follow PEP-8 (http://www.python.org/dev/peps/pep-0008/).
+
+ - As a minimum, we aim to be compatible with Python 2.6 and 2.7.
+
+ - Where required libraries do not restrict us to Python 2, we try to
+   also be compatible with Python 3.1 and later.
+
+ - When you must differentiate between Unicode literals and byte string
+   literals, it is OK to use the 'b' prefix.  Even though the Python
+   documentation for version 2.6 does not mention this prefix, it has
+   been supported since version 2.6.0.
+
+Error Messages
+
+ - Do not end error messages with a full stop.
+
+ - Do not capitalize ("unable to open %s", not "Unable to open %s")
+
+ - Say what the error is first ("cannot open %s", not "%s: cannot open")
+
+
+Externally Visible Names
+
+ - For configuration variable names, follow the existing convention:
+
+   . The section name indicates the affected subsystem.
+
+   . The subsection name, if any, indicates which of an unbounded set
+     of things to set the value for.
+
+   . The variable name describes the effect of tweaking this knob.
+
+   The section and variable names that consist of multiple words are
+   formed by concatenating the words without punctuations (e.g. `-`),
+   and are broken using bumpyCaps in documentation as a hint to the
+   reader.
+
+   When choosing the variable namespace, do not use variable name for
+   specifying possibly unbounded set of things, most notably anything
+   an end user can freely come up with (e.g. branch names).  Instead,
+   use subsection names or variable values, like the existing variable
+   branch.<name>.description does.
+
+
+Writing Documentation:
+
+ Most (if not all) of the documentation pages are written in the
+ AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+ processed into HTML and manpages (e.g. git.html and git.1 in the
+ same directory).
+
+ The documentation liberally mixes US and UK English (en_US/UK)
+ norms for spelling and grammar, which is somewhat unfortunate.
+ In an ideal world, it would have been better if it consistently
+ used only one and not the other, and we would have picked en_US
+ (if you wish to correct the English of some of the existing
+ documentation, please see the documentation-related advice in the
+ Documentation/SubmittingPatches file).
+
+ Every user-visible change should be reflected in the documentation.
+ The same general rule as for code applies -- imitate the existing
+ conventions.
+
+ A few commented examples follow to provide reference when writing or
+ modifying command usage strings and synopsis sections in the manual
+ pages:
+
+ Placeholders are spelled in lowercase and enclosed in angle brackets:
+   <file>
+   --sort=<key>
+   --abbrev[=<n>]
+
+ If a placeholder has multiple words, they are separated by dashes:
+   <new-branch-name>
+   --template=<template-directory>
+
+ Possibility of multiple occurrences is indicated by three dots:
+   <file>...
+   (One or more of <file>.)
+
+ Optional parts are enclosed in square brackets:
+   [<extra>]
+   (Zero or one <extra>.)
+
+   --exec-path[=<path>]
+   (Option with an optional argument.  Note that the "=" is inside the
+   brackets.)
+
+   [<patch>...]
+   (Zero or more of <patch>.  Note that the dots are inside, not
+   outside the brackets.)
+
+ Multiple alternatives are indicated with vertical bars:
+   [-q | --quiet]
+   [--utf8 | --no-utf8]
+
+ Parentheses are used for grouping:
+   [(<rev> | <range>)...]
+   (Any number of either <rev> or <range>.  Parens are needed to make
+   it clear that "..." pertains to both <rev> and <range>.)
+
+   [(-p <parent>)...]
+   (Any number of option -p, each with one <parent> argument.)
+
+   git remote set-head <name> (-a | -d | <branch>)
+   (One and only one of "-a", "-d" or "<branch>" _must_ (no square
+   brackets) be provided.)
+
+ And a somewhat more contrived example:
+   --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+   Here "=" is outside the brackets, because "--diff-filter=" is a
+   valid usage.  "*" has its own pair of brackets, because it can
+   (optionally) be specified only when one or more of the letters is
+   also provided.
+
+  A note on notation:
+   Use 'git' (all lowercase) when talking about commands i.e. something
+   the user would type into a shell and use 'Git' (uppercase first letter)
+   when talking about the version control system and its properties.
+
+ A few commented examples follow to provide reference when writing or
+ modifying paragraphs or option/command explanations that contain options
+ or commands:
+
+ Literal examples (e.g. use of command-line options, command names, and
+ configuration variables) are typeset in monospace, and if you can use
+ `backticks around word phrases`, do so.
+   `--pretty=oneline`
+   `git rev-list`
+   `remote.pushDefault`
+
+ Word phrases enclosed in `backtick characters` are rendered literally
+ and will not be further expanded. The use of `backticks` to achieve the
+ previous rule means that literal examples should not use AsciiDoc
+ escapes.
+   Correct:
+      `--pretty=oneline`
+   Incorrect:
+      `\--pretty=oneline`
+
+ If some place in the documentation needs to typeset a command usage
+ example with inline substitutions, it is fine to use +monospaced and
+ inline substituted text+ instead of `monospaced literal text`, and with
+ the former, the part that should not get substituted must be
+ quoted/escaped.
diff --git a/external/docs/asciidoc/660e60c007657c8aeaaf25cc41138f04b83f15ff b/external/docs/asciidoc/660e60c007657c8aeaaf25cc41138f04b83f15ff
new file mode 100644
index 0000000000..0279ca1cb7
--- /dev/null
+++ b/external/docs/asciidoc/660e60c007657c8aeaaf25cc41138f04b83f15ff
@@ -0,0 +1,162 @@
+Reviewing Patches in the Git Project
+====================================
+
+Introduction
+------------
+The Git development community is a widely distributed, diverse, ever-changing
+group of individuals. Asynchronous communication via the Git mailing list poses
+unique challenges when reviewing or discussing patches. This document contains
+some guiding principles and helpful tools you can use to make your reviews both
+more efficient for yourself and more effective for other contributors.
+
+Note that none of the recommendations here are binding or in any way a
+requirement of participation in the Git community. They are provided as a
+resource to supplement your skills as a contributor.
+
+Principles
+----------
+
+Selecting patch(es) to review
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+If you are looking for a patch series in need of review, start by checking
+latest "What's cooking in git.git" email
+(https://lore.kernel.org/git/xmqqilm1yp3m.fsf@gitster.g/[example]). The "What's
+cooking" emails & replies can be found using the query `s:"What's cooking"` on
+the https://lore.kernel.org/git/[`lore.kernel.org` mailing list archive];
+alternatively, you can find the contents of the "What's cooking" email tracked
+in `whats-cooking.txt` on the `todo` branch of Git. Topics tagged with "Needs
+review" and those in the "[New Topics]" section are typically those that would
+benefit the most from additional review.
+
+Patches can also be searched manually in the mailing list archive using a query
+like `s:"PATCH" -s:"Re:"`. You can browse these results for topics relevant to
+your expertise or interest.
+
+If you've already contributed to Git, you may also be CC'd in another
+contributor's patch series. These are topics where the author feels that your
+attention is warranted. This may be because their patch changes something you
+wrote previously (making you a good judge of whether the new approach does or
+doesn't work), or because you have the expertise to provide an exceptionally
+helpful review. There is no requirement to review these patches but, in the
+spirit of open source collaboration, you should strongly consider doing so.
+
+Reviewing patches
+~~~~~~~~~~~~~~~~~
+While every contributor takes their own approach to reviewing patches, here are
+some general pieces of advice to make your reviews as clear and helpful as
+possible. The advice is broken into two rough categories: high-level reviewing
+guidance, and concrete tips for interacting with patches on the mailing list.
+
+==== High-level guidance
+- Remember to review the content of commit messages for correctness and clarity,
+  in addition to the code change in the patch's diff. The commit message of a
+  patch should accurately and fully explain the code change being made in the
+  diff.
+
+- Reviewing test coverage is an important - but easy to overlook - component of
+  reviews. A patch's changes may be covered by existing tests, or new tests may
+  be introduced to exercise new behavior. Checking out a patch or series locally
+  allows you to manually mutate lines of new & existing tests to verify expected
+  pass/fail behavior. You can use this information to verify proper coverage or
+  to suggest additional tests the author could add.
+
+- When providing a recommendation, be as clear as possible about whether you
+  consider it "blocking" (the code would be broken or otherwise made worse if an
+  issue isn't fixed) or "non-blocking" (the patch could be made better by taking
+  the recommendation, but acceptance of the series does not require it).
+  Non-blocking recommendations can be particularly ambiguous when they are
+  related to - but outside the scope of - a series ("nice-to-have"s), or when
+  they represent only stylistic differences between the author and reviewer.
+
+- When commenting on an issue, try to include suggestions for how the author
+  could fix it. This not only helps the author to understand and fix the issue,
+  it also deepens and improves your understanding of the topic.
+
+- Reviews do not need to exclusively point out problems. Feel free to "think out
+  loud" in your review: describe how you read & understood a complex section of
+  a patch, ask a question about something that confused you, point out something
+  you found exceptionally well-written, etc. In particular, uplifting feedback
+  goes a long way towards encouraging contributors to participate more actively
+  in the Git community.
+
+==== Performing your review
+- Provide your review comments per-patch in a plaintext "Reply-All" email to the
+  relevant patch. Comments should be made inline, immediately below the relevant
+  section(s).
+
+- You may find that the limited context provided in the patch diff is sometimes
+  insufficient for a thorough review. In such cases, you can review patches in
+  your local tree by either applying patches with linkgit:git-am[1] or checking
+  out the associated branch from https://github.com/gitster/git once the series
+  is tracked there.
+
+- Large, complicated patch diffs are sometimes unavoidable, such as when they
+  refactor existing code. If you find such a patch difficult to parse, try
+  reviewing the diff produced with the `--color-moved` and/or
+  `--ignore-space-change` options.
+
+- If a patch is long, you are encouraged to delete parts of it that are
+  unrelated to your review from the email reply. Make sure to leave enough
+  context for readers to understand your comments!
+
+- If you cannot complete a full review of a series all at once, consider letting
+  the author know (on- or off-list) if/when you plan to review the rest of the
+  series.
+
+Completing a review
+~~~~~~~~~~~~~~~~~~~
+Once each patch of a series is reviewed, the author (and/or other contributors)
+may discuss the review(s). This may result in no changes being applied, or the
+author will send a new version of their patch(es).
+
+After a series is rerolled in response to your or others' review, make sure to
+re-review the updates. If you are happy with the state of the patch series,
+explicitly indicate your approval (typically with a reply to the latest
+version's cover letter). Optionally, you can let the author know that they can
+add a "Reviewed-by: <you>" trailer if they resubmit the reviewed patch verbatim
+in a later iteration of the series.
+
+Finally, subsequent "What's cooking" emails may explicitly ask whether a
+reviewed topic is ready for merging to the `next` branch (typically phrased
+"Will merge to \'next\'?"). You can help the maintainer and author by responding
+with a short description of the state of your (and others', if applicable)
+review, including the links to the relevant thread(s).
+
+Terminology
+-----------
+nit: ::
+	Denotes a small issue that should be fixed, such as a typographical error
+	or mis-alignment of conditions in an `if()` statement.
+
+aside: ::
+optional: ::
+non-blocking: ::
+	Indicates to the reader that the following comment should not block the
+	acceptance of the patch or series. These are typically recommendations
+	related to code organization & style, or musings about topics related to
+	the patch in question, but beyond its scope.
+
+s/<before>/<after>/::
+	Shorthand for "you wrote <before>, but I think you meant <after>," usually
+	for misspellings or other typographical errors. The syntax is a reference
+	to "substitute" command commonly found in Unix tools such as `ed`, `sed`,
+	`vim`, and `perl`.
+
+cover letter::
+	The "Patch 0" of a multi-patch series. This email describes the
+	high-level intent and structure of the patch series to readers on the
+	Git mailing list. It is also where the changelog notes and range-diff of
+	subsequent versions are provided by the author.
++
+On single-patch submissions, cover letter content is typically not sent as a
+separate email. Instead, it is inserted between the end of the patch's commit
+message (after the `---`) and the beginning of the diff.
+
+#leftoverbits::
+  Used by either an author or a reviewer to describe features or suggested
+  changes that are out-of-scope of a given patch or series, but are relevant
+  to the topic for the sake of discussion.
+
+See Also
+--------
+link:/docs/MyFirstContribution[MyFirstContribution]
diff --git a/external/docs/asciidoc/696065291c8dcb7cbec1a8dc47a55864ddd0d808 b/external/docs/asciidoc/696065291c8dcb7cbec1a8dc47a55864ddd0d808
new file mode 100644
index 0000000000..c4cb5ff0d4
--- /dev/null
+++ b/external/docs/asciidoc/696065291c8dcb7cbec1a8dc47a55864ddd0d808
@@ -0,0 +1,584 @@
+Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, a few rough rules are:
+
+ - Most importantly, we never say "It's in POSIX; we'll happily
+   ignore your needs should your system not conform to it."
+   We live in the real world.
+
+ - However, we often say "Let's stay away from that construct,
+   it's not even in POSIX".
+
+ - In spite of the above two rules, we sometimes say "Although
+   this is not in POSIX, it (is so convenient | makes the code
+   much more readable | has other good characteristics) and
+   practically all the platforms we care about support it, so
+   let's use it".
+
+   Again, we live in the real world, and it is sometimes a
+   judgement call, the decision based more on real world
+   constraints people face than what the paper standard says.
+
+ - Fixing style violations while working on a real change as a
+   preparatory clean-up step is good, but otherwise avoid useless code
+   churn for the sake of conforming to the style.
+
+   "Once it _is_ in the tree, it's not really worth the patch noise to
+   go and fix it up."
+   Cf. http://lkml.iu.edu/hypermail/linux/kernel/1001.3/01069.html
+
+Make your code readable and sensible, and don't try to be clever.
+
+As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the _local_
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn't match the overall style of existing code).
+
+But if you must have a list of rules, here they are.
+
+For shell scripts specifically (not exhaustive):
+
+ - We use tabs for indentation.
+
+ - Case arms are indented at the same depth as case and esac lines,
+   like this:
+
+	case "$variable" in
+	pattern1)
+		do this
+		;;
+	pattern2)
+		do that
+		;;
+	esac
+
+ - Redirection operators should be written with space before, but no
+   space after them.  In other words, write 'echo test >"$file"'
+   instead of 'echo test> $file' or 'echo test > $file'.  Note that
+   even though it is not required by POSIX to double-quote the
+   redirection target in a variable (as shown above), our code does so
+   because some versions of bash issue a warning without the quotes.
+
+	(incorrect)
+	cat hello > world < universe
+	echo hello >$world
+
+	(correct)
+	cat hello >world <universe
+	echo hello >"$world"
+
+ - We prefer $( ... ) for command substitution; unlike ``, it
+   properly nests.  It should have been the way Bourne spelled
+   it from day one, but unfortunately isn't.
+
+ - If you want to find out if a command is available on the user's
+   $PATH, you should use 'type <command>', instead of 'which <command>'.
+   The output of 'which' is not machine parseable and its exit code
+   is not reliable across platforms.
+
+ - We use POSIX compliant parameter substitutions and avoid bashisms;
+   namely:
+
+   - We use ${parameter-word} and its [-=?+] siblings, and their
+     colon'ed "unset or null" form.
+
+   - We use ${parameter#word} and its [#%] siblings, and their
+     doubled "longest matching" form.
+
+   - No "Substring Expansion" ${parameter:offset:length}.
+
+   - No shell arrays.
+
+   - No strlen ${#parameter}.
+
+   - No pattern replacement ${parameter/pattern/string}.
+
+ - We use Arithmetic Expansion $(( ... )).
+
+ - Inside Arithmetic Expansion, spell shell variables with $ in front
+   of them, as some shells do not grok $((x)) while accepting $(($x))
+   just fine (e.g. dash older than 0.5.4).
+
+ - We do not use Process Substitution <(list) or >(list).
+
+ - Do not write control structures on a single line with semicolon.
+   "then" should be on the next line for if statements, and "do"
+   should be on the next line for "while" and "for".
+
+	(incorrect)
+	if test -f hello; then
+		do this
+	fi
+
+	(correct)
+	if test -f hello
+	then
+		do this
+	fi
+
+ - We prefer "test" over "[ ... ]".
+
+ - We do not write the noiseword "function" in front of shell
+   functions.
+
+ - We prefer a space between the function name and the parentheses,
+   and no space inside the parentheses. The opening "{" should also
+   be on the same line.
+
+	(incorrect)
+	my_function(){
+		...
+
+	(correct)
+	my_function () {
+		...
+
+ - As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+   [::], [==], or [..]) for portability.
+
+   - We do not use \{m,n\};
+
+   - We do not use -E;
+
+   - We do not use ? or + (which are \{0,1\} and \{1,\}
+     respectively in BRE) but that goes without saying as these
+     are ERE elements not BRE (note that \? and \+ are not even part
+     of BRE -- making them accessible from BRE is a GNU extension).
+
+ - Use Git's gettext wrappers in git-sh-i18n to make the user
+   interface translatable. See "Marking strings for translation" in
+   po/README.
+
+ - We do not write our "test" command with "-a" and "-o" and use "&&"
+   or "||" to concatenate multiple "test" commands instead, because
+   the use of "-a/-o" is often error-prone.  E.g.
+
+     test -n "$x" -a "$a" = "$b"
+
+   is buggy and breaks when $x is "=", but
+
+     test -n "$x" && test "$a" = "$b"
+
+   does not have such a problem.
+
+
+For C programs:
+
+ - We use tabs to indent, and interpret tabs as taking up to
+   8 spaces.
+
+ - We try to keep to at most 80 characters per line.
+
+ - As a Git developer we assume you have a reasonably modern compiler
+   and we recommend you to enable the DEVELOPER makefile knob to
+   ensure your patch is clear of all compiler warnings we care about,
+   by e.g. "echo DEVELOPER=1 >>config.mak".
+
+ - We try to support a wide range of C compilers to compile Git with,
+   including old ones. That means that you should not use C99
+   initializers, even if a lot of compilers grok it.
+
+ - Variables have to be declared at the beginning of the block.
+
+ - NULL pointers shall be written as NULL, not as 0.
+
+ - When declaring pointers, the star sides with the variable
+   name, i.e. "char *string", not "char* string" or
+   "char * string".  This makes it easier to understand code
+   like "char *string, c;".
+
+ - Use whitespace around operators and keywords, but not inside
+   parentheses and not around functions. So:
+
+        while (condition)
+		func(bar + 1);
+
+   and not:
+
+        while( condition )
+		func (bar+1);
+
+ - We avoid using braces unnecessarily.  I.e.
+
+	if (bla) {
+		x = 1;
+	}
+
+   is frowned upon. But there are a few exceptions:
+
+	- When the statement extends over a few lines (e.g., a while loop
+	  with an embedded conditional, or a comment). E.g.:
+
+		while (foo) {
+			if (x)
+				one();
+			else
+				two();
+		}
+
+		if (foo) {
+			/*
+			 * This one requires some explanation,
+			 * so we're better off with braces to make
+			 * it obvious that the indentation is correct.
+			 */
+			doit();
+		}
+
+	- When there are multiple arms to a conditional and some of them
+	  require braces, enclose even a single line block in braces for
+	  consistency. E.g.:
+
+		if (foo) {
+			doit();
+		} else {
+			one();
+			two();
+			three();
+		}
+
+ - We try to avoid assignments in the condition of an "if" statement.
+
+ - Try to make your code understandable.  You may put comments
+   in, but comments invariably tend to stale out when the code
+   they were describing changes.  Often splitting a function
+   into two makes the intention of the code much clearer.
+
+ - Multi-line comments include their delimiters on separate lines from
+   the text.  E.g.
+
+	/*
+	 * A very long
+	 * multi-line comment.
+	 */
+
+   Note however that a comment that explains a translatable string to
+   translators uses a convention of starting with a magic token
+   "TRANSLATORS: ", e.g.
+
+	/*
+	 * TRANSLATORS: here is a comment that explains the string to
+	 * be translated, that follows immediately after it.
+	 */
+	_("Here is a translatable string explained by the above.");
+
+ - Double negation is often harder to understand than no negation
+   at all.
+
+ - There are two schools of thought when it comes to comparison,
+   especially inside a loop. Some people prefer to have the less stable
+   value on the left hand side and the more stable value on the right hand
+   side, e.g. if you have a loop that counts variable i down to the
+   lower bound,
+
+	while (i > lower_bound) {
+		do something;
+		i--;
+	}
+
+   Other people prefer to have the textual order of values match the
+   actual order of values in their comparison, so that they can
+   mentally draw a number line from left to right and place these
+   values in order, i.e.
+
+	while (lower_bound < i) {
+		do something;
+		i--;
+	}
+
+   Both are valid, and we use both.  However, the more "stable" the
+   stable side becomes, the more we tend to prefer the former
+   (comparison with a constant, "i > 0", is an extreme example).
+   Just do not mix styles in the same part of the code and mimic
+   existing styles in the neighbourhood.
+
+ - There are two schools of thought when it comes to splitting a long
+   logical line into multiple lines.  Some people push the second and
+   subsequent lines far enough to the right with tabs and align them:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+		span_more_than_a_single_line_of ||
+		the_source_text) {
+                ...
+
+   while other people prefer to align the second and the subsequent
+   lines with the column immediately inside the opening parenthesis,
+   with tabs and spaces, following our "tabstop is always a multiple
+   of 8" convention:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of ||
+	    the_source_text) {
+                ...
+
+   Both are valid, and we use both.  Again, just do not mix styles in
+   the same part of the code and mimic existing styles in the
+   neighbourhood.
+
+ - When splitting a long logical line, some people change line before
+   a binary operator, so that the result looks like a parse tree when
+   you turn your head 90-degrees counterclockwise:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to
+	    || span_more_than_a_single_line_of_the_source_text) {
+
+   while other people prefer to leave the operator at the end of the
+   line:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of_the_source_text) {
+
+   Both are valid, but we tend to use the latter more, unless the
+   expression gets fairly complex, in which case the former tends to
+   be easier to read.  Again, just do not mix styles in the same part
+   of the code and mimic existing styles in the neighbourhood.
+
+ - When splitting a long logical line, with everything else being
+   equal, it is preferable to split after the operator at higher
+   level in the parse tree.  That is, this is more preferable:
+
+	if (a_very_long_variable * that_is_used_in +
+	    a_very_long_expression) {
+		...
+
+   than
+
+	if (a_very_long_variable *
+	    that_is_used_in + a_very_long_expression) {
+		...
+
+ - Some clever tricks, like using the !! operator with arithmetic
+   constructs, can be extremely confusing to others.  Avoid them,
+   unless there is a compelling reason to use them.
+
+ - Use the API.  No, really.  We have a strbuf (variable length
+   string), several arrays with the ALLOC_GROW() macro, a
+   string_list for sorted string lists, a hash map (mapping struct
+   objects) named "struct decorate", amongst other things.
+
+ - When you come up with an API, document it.
+
+ - The first #include in C files, except in platform specific compat/
+   implementations, must be either "git-compat-util.h", "cache.h" or
+   "builtin.h".  You do not have to include more than one of these.
+
+ - A C file must directly include the header files that declare the
+   functions and the types it uses, except for the functions and types
+   that are made available to it by including one of the header files
+   it must include by the previous rule.
+
+ - If you are planning a new command, consider writing it in shell
+   or perl first, so that changes in semantics can be easily
+   changed and discussed.  Many Git commands started out like
+   that, and a few are still scripts.
+
+ - Avoid introducing a new dependency into Git. This means you
+   usually should stay away from scripting languages not already
+   used in the Git core command set (unless your command is clearly
+   separate from it, such as an importer to convert random-scm-X
+   repositories to Git).
+
+ - When we pass <string, length> pair to functions, we should try to
+   pass them in that order.
+
+ - Use Git's gettext wrappers to make the user interface
+   translatable. See "Marking strings for translation" in po/README.
+
+For Perl programs:
+
+ - Most of the C guidelines above apply.
+
+ - We try to support Perl 5.8 and later ("use Perl 5.008").
+
+ - use strict and use warnings are strongly preferred.
+
+ - Don't overuse statement modifiers unless using them makes the
+   result easier to follow.
+
+	... do something ...
+	do_this() unless (condition);
+        ... do something else ...
+
+   is more readable than:
+
+	... do something ...
+	unless (condition) {
+		do_this();
+	}
+        ... do something else ...
+
+   *only* when the condition is so rare that do_this() will be almost
+   always called.
+
+ - We try to avoid assignments inside "if ()" conditions.
+
+ - Learn and use Git.pm if you need that functionality.
+
+ - For Emacs, it's useful to put the following in
+   GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode:
+
+    ;; note the first part is useful for C editing, too
+    ((nil . ((indent-tabs-mode . t)
+                  (tab-width . 8)
+                  (fill-column . 80)))
+     (cperl-mode . ((cperl-indent-level . 8)
+                    (cperl-extra-newline-before-brace . nil)
+                    (cperl-merge-trailing-else . t))))
+
+For Python scripts:
+
+ - We follow PEP-8 (http://www.python.org/dev/peps/pep-0008/).
+
+ - As a minimum, we aim to be compatible with Python 2.6 and 2.7.
+
+ - Where required libraries do not restrict us to Python 2, we try to
+   also be compatible with Python 3.1 and later.
+
+ - When you must differentiate between Unicode literals and byte string
+   literals, it is OK to use the 'b' prefix.  Even though the Python
+   documentation for version 2.6 does not mention this prefix, it has
+   been supported since version 2.6.0.
+
+Error Messages
+
+ - Do not end error messages with a full stop.
+
+ - Do not capitalize ("unable to open %s", not "Unable to open %s")
+
+ - Say what the error is first ("cannot open %s", not "%s: cannot open")
+
+
+Externally Visible Names
+
+ - For configuration variable names, follow the existing convention:
+
+   . The section name indicates the affected subsystem.
+
+   . The subsection name, if any, indicates which of an unbounded set
+     of things to set the value for.
+
+   . The variable name describes the effect of tweaking this knob.
+
+   The section and variable names that consist of multiple words are
+   formed by concatenating the words without punctuations (e.g. `-`),
+   and are broken using bumpyCaps in documentation as a hint to the
+   reader.
+
+   When choosing the variable namespace, do not use variable name for
+   specifying possibly unbounded set of things, most notably anything
+   an end user can freely come up with (e.g. branch names).  Instead,
+   use subsection names or variable values, like the existing variable
+   branch.<name>.description does.
+
+
+Writing Documentation:
+
+ Most (if not all) of the documentation pages are written in the
+ AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+ processed into HTML and manpages (e.g. git.html and git.1 in the
+ same directory).
+
+ The documentation liberally mixes US and UK English (en_US/UK)
+ norms for spelling and grammar, which is somewhat unfortunate.
+ In an ideal world, it would have been better if it consistently
+ used only one and not the other, and we would have picked en_US
+ (if you wish to correct the English of some of the existing
+ documentation, please see the documentation-related advice in the
+ Documentation/SubmittingPatches file).
+
+ Every user-visible change should be reflected in the documentation.
+ The same general rule as for code applies -- imitate the existing
+ conventions.
+
+ A few commented examples follow to provide reference when writing or
+ modifying command usage strings and synopsis sections in the manual
+ pages:
+
+ Placeholders are spelled in lowercase and enclosed in angle brackets:
+   <file>
+   --sort=<key>
+   --abbrev[=<n>]
+
+ If a placeholder has multiple words, they are separated by dashes:
+   <new-branch-name>
+   --template=<template-directory>
+
+ Possibility of multiple occurrences is indicated by three dots:
+   <file>...
+   (One or more of <file>.)
+
+ Optional parts are enclosed in square brackets:
+   [<extra>]
+   (Zero or one <extra>.)
+
+   --exec-path[=<path>]
+   (Option with an optional argument.  Note that the "=" is inside the
+   brackets.)
+
+   [<patch>...]
+   (Zero or more of <patch>.  Note that the dots are inside, not
+   outside the brackets.)
+
+ Multiple alternatives are indicated with vertical bars:
+   [-q | --quiet]
+   [--utf8 | --no-utf8]
+
+ Parentheses are used for grouping:
+   [(<rev> | <range>)...]
+   (Any number of either <rev> or <range>.  Parens are needed to make
+   it clear that "..." pertains to both <rev> and <range>.)
+
+   [(-p <parent>)...]
+   (Any number of option -p, each with one <parent> argument.)
+
+   git remote set-head <name> (-a | -d | <branch>)
+   (One and only one of "-a", "-d" or "<branch>" _must_ (no square
+   brackets) be provided.)
+
+ And a somewhat more contrived example:
+   --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+   Here "=" is outside the brackets, because "--diff-filter=" is a
+   valid usage.  "*" has its own pair of brackets, because it can
+   (optionally) be specified only when one or more of the letters is
+   also provided.
+
+  A note on notation:
+   Use 'git' (all lowercase) when talking about commands i.e. something
+   the user would type into a shell and use 'Git' (uppercase first letter)
+   when talking about the version control system and its properties.
+
+ A few commented examples follow to provide reference when writing or
+ modifying paragraphs or option/command explanations that contain options
+ or commands:
+
+ Literal examples (e.g. use of command-line options, command names,
+ branch names, configuration and environment variables) must be
+ typeset in monospace (i.e. wrapped with backticks):
+   `--pretty=oneline`
+   `git rev-list`
+   `remote.pushDefault`
+   `GIT_DIR`
+   `HEAD`
+
+ An environment variable must be prefixed with "$" only when referring to its
+ value and not when referring to the variable itself, in this case there is
+ nothing to add except the backticks:
+   `GIT_DIR` is specified
+   `$GIT_DIR/hooks/pre-receive`
+
+ Word phrases enclosed in `backtick characters` are rendered literally
+ and will not be further expanded. The use of `backticks` to achieve the
+ previous rule means that literal examples should not use AsciiDoc
+ escapes.
+   Correct:
+      `--pretty=oneline`
+   Incorrect:
+      `\--pretty=oneline`
+
+ If some place in the documentation needs to typeset a command usage
+ example with inline substitutions, it is fine to use +monospaced and
+ inline substituted text+ instead of `monospaced literal text`, and with
+ the former, the part that should not get substituted must be
+ quoted/escaped.
diff --git a/external/docs/asciidoc/69f4ac48c946a35bba57c7c8797511ee65231d47 b/external/docs/asciidoc/69f4ac48c946a35bba57c7c8797511ee65231d47
new file mode 100644
index 0000000000..4c756be517
--- /dev/null
+++ b/external/docs/asciidoc/69f4ac48c946a35bba57c7c8797511ee65231d47
@@ -0,0 +1,727 @@
+Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, a few rough rules are:
+
+ - Most importantly, we never say "It's in POSIX; we'll happily
+   ignore your needs should your system not conform to it."
+   We live in the real world.
+
+ - However, we often say "Let's stay away from that construct,
+   it's not even in POSIX".
+
+ - In spite of the above two rules, we sometimes say "Although
+   this is not in POSIX, it (is so convenient | makes the code
+   much more readable | has other good characteristics) and
+   practically all the platforms we care about support it, so
+   let's use it".
+
+   Again, we live in the real world, and it is sometimes a
+   judgement call, the decision based more on real world
+   constraints people face than what the paper standard says.
+
+ - Fixing style violations while working on a real change as a
+   preparatory clean-up step is good, but otherwise avoid useless code
+   churn for the sake of conforming to the style.
+
+   "Once it _is_ in the tree, it's not really worth the patch noise to
+   go and fix it up."
+   Cf. http://lkml.iu.edu/hypermail/linux/kernel/1001.3/01069.html
+
+ - Log messages to explain your changes are as important as the
+   changes themselves.  Clearly written code and in-code comments
+   explain how the code works and what is assumed from the surrounding
+   context.  The log messages explain what the changes wanted to
+   achieve and why the changes were necessary (more on this in the
+   accompanying SubmittingPatches document).
+
+Make your code readable and sensible, and don't try to be clever.
+
+As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the _local_
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn't match the overall style of existing code).
+
+But if you must have a list of rules, here are some language
+specific ones. Note that Documentation/ToolsForGit.txt document
+has a collection of tips to help you use some external tools
+to conform to these guidelines.
+
+For shell scripts specifically (not exhaustive):
+
+ - We use tabs for indentation.
+
+ - Case arms are indented at the same depth as case and esac lines,
+   like this:
+
+	case "$variable" in
+	pattern1)
+		do this
+		;;
+	pattern2)
+		do that
+		;;
+	esac
+
+ - Redirection operators should be written with space before, but no
+   space after them.  In other words, write 'echo test >"$file"'
+   instead of 'echo test> $file' or 'echo test > $file'.  Note that
+   even though it is not required by POSIX to double-quote the
+   redirection target in a variable (as shown above), our code does so
+   because some versions of bash issue a warning without the quotes.
+
+	(incorrect)
+	cat hello > world < universe
+	echo hello >$world
+
+	(correct)
+	cat hello >world <universe
+	echo hello >"$world"
+
+ - We prefer $( ... ) for command substitution; unlike ``, it
+   properly nests.  It should have been the way Bourne spelled
+   it from day one, but unfortunately isn't.
+
+ - If you want to find out if a command is available on the user's
+   $PATH, you should use 'type <command>', instead of 'which <command>'.
+   The output of 'which' is not machine parsable and its exit code
+   is not reliable across platforms.
+
+ - We use POSIX compliant parameter substitutions and avoid bashisms;
+   namely:
+
+   - We use ${parameter-word} and its [-=?+] siblings, and their
+     colon'ed "unset or null" form.
+
+   - We use ${parameter#word} and its [#%] siblings, and their
+     doubled "longest matching" form.
+
+   - No "Substring Expansion" ${parameter:offset:length}.
+
+   - No shell arrays.
+
+   - No pattern replacement ${parameter/pattern/string}.
+
+ - We use Arithmetic Expansion $(( ... )).
+
+ - We do not use Process Substitution <(list) or >(list).
+
+ - Do not write control structures on a single line with semicolon.
+   "then" should be on the next line for if statements, and "do"
+   should be on the next line for "while" and "for".
+
+	(incorrect)
+	if test -f hello; then
+		do this
+	fi
+
+	(correct)
+	if test -f hello
+	then
+		do this
+	fi
+
+ - If a command sequence joined with && or || or | spans multiple
+   lines, put each command on a separate line and put && and || and |
+   operators at the end of each line, rather than the start. This
+   means you don't need to use \ to join lines, since the above
+   operators imply the sequence isn't finished.
+
+	(incorrect)
+	grep blob verify_pack_result \
+	| awk -f print_1.awk \
+	| sort >actual &&
+	...
+
+	(correct)
+	grep blob verify_pack_result |
+	awk -f print_1.awk |
+	sort >actual &&
+	...
+
+ - We prefer "test" over "[ ... ]".
+
+ - We do not write the noiseword "function" in front of shell
+   functions.
+
+ - We prefer a space between the function name and the parentheses,
+   and no space inside the parentheses. The opening "{" should also
+   be on the same line.
+
+	(incorrect)
+	my_function(){
+		...
+
+	(correct)
+	my_function () {
+		...
+
+ - As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+   [::], [==], or [..]) for portability.
+
+   - We do not use \{m,n\};
+
+   - We do not use -E;
+
+   - We do not use ? or + (which are \{0,1\} and \{1,\}
+     respectively in BRE) but that goes without saying as these
+     are ERE elements not BRE (note that \? and \+ are not even part
+     of BRE -- making them accessible from BRE is a GNU extension).
+
+ - Use Git's gettext wrappers in git-sh-i18n to make the user
+   interface translatable. See "Marking strings for translation" in
+   po/README.
+
+ - We do not write our "test" command with "-a" and "-o" and use "&&"
+   or "||" to concatenate multiple "test" commands instead, because
+   the use of "-a/-o" is often error-prone.  E.g.
+
+     test -n "$x" -a "$a" = "$b"
+
+   is buggy and breaks when $x is "=", but
+
+     test -n "$x" && test "$a" = "$b"
+
+   does not have such a problem.
+
+ - Even though "local" is not part of POSIX, we make heavy use of it
+   in our test suite.  We do not use it in scripted Porcelains, and
+   hopefully nobody starts using "local" before they are reimplemented
+   in C ;-)
+
+
+For C programs:
+
+ - We use tabs to indent, and interpret tabs as taking up to
+   8 spaces.
+
+ - We try to keep to at most 80 characters per line.
+
+ - As a Git developer we assume you have a reasonably modern compiler
+   and we recommend you to enable the DEVELOPER makefile knob to
+   ensure your patch is clear of all compiler warnings we care about,
+   by e.g. "echo DEVELOPER=1 >>config.mak".
+
+ - We try to support a wide range of C compilers to compile Git with,
+   including old ones.  You should not use features from newer C
+   standard, even if your compiler groks them.
+
+   There are a few exceptions to this guideline:
+
+   . since early 2012 with e1327023ea, we have been using an enum
+     definition whose last element is followed by a comma.  This, like
+     an array initializer that ends with a trailing comma, can be used
+     to reduce the patch noise when adding a new identifier at the end.
+
+   . since mid 2017 with cbc0f81d, we have been using designated
+     initializers for struct (e.g. "struct t v = { .val = 'a' };").
+
+   . since mid 2017 with 512f41cf, we have been using designated
+     initializers for array (e.g. "int array[10] = { [5] = 2 }").
+
+   . since early 2021 with 765dc168882, we have been using variadic
+     macros, mostly for printf-like trace and debug macros.
+
+   These used to be forbidden, but we have not heard any breakage
+   report, and they are assumed to be safe.
+
+ - Variables have to be declared at the beginning of the block, before
+   the first statement (i.e. -Wdeclaration-after-statement).
+
+ - Declaring a variable in the for loop "for (int i = 0; i < 10; i++)"
+   is still not allowed in this codebase.  We are in the process of
+   allowing it by waiting to see that 44ba10d6 (revision: use C99
+   declaration of variable in for() loop, 2021-11-14) does not get
+   complaints.  Let's revisit this around November 2022.
+
+ - NULL pointers shall be written as NULL, not as 0.
+
+ - When declaring pointers, the star sides with the variable
+   name, i.e. "char *string", not "char* string" or
+   "char * string".  This makes it easier to understand code
+   like "char *string, c;".
+
+ - Use whitespace around operators and keywords, but not inside
+   parentheses and not around functions. So:
+
+        while (condition)
+		func(bar + 1);
+
+   and not:
+
+        while( condition )
+		func (bar+1);
+
+ - Do not explicitly compare an integral value with constant 0 or '\0',
+   or a pointer value with constant NULL.  For instance, to validate that
+   counted array <ptr, cnt> is initialized but has no elements, write:
+
+	if (!ptr || cnt)
+		BUG("empty array expected");
+
+   and not:
+
+	if (ptr == NULL || cnt != 0);
+		BUG("empty array expected");
+
+ - We avoid using braces unnecessarily.  I.e.
+
+	if (bla) {
+		x = 1;
+	}
+
+   is frowned upon. But there are a few exceptions:
+
+	- When the statement extends over a few lines (e.g., a while loop
+	  with an embedded conditional, or a comment). E.g.:
+
+		while (foo) {
+			if (x)
+				one();
+			else
+				two();
+		}
+
+		if (foo) {
+			/*
+			 * This one requires some explanation,
+			 * so we're better off with braces to make
+			 * it obvious that the indentation is correct.
+			 */
+			doit();
+		}
+
+	- When there are multiple arms to a conditional and some of them
+	  require braces, enclose even a single line block in braces for
+	  consistency. E.g.:
+
+		if (foo) {
+			doit();
+		} else {
+			one();
+			two();
+			three();
+		}
+
+ - We try to avoid assignments in the condition of an "if" statement.
+
+ - Try to make your code understandable.  You may put comments
+   in, but comments invariably tend to stale out when the code
+   they were describing changes.  Often splitting a function
+   into two makes the intention of the code much clearer.
+
+ - Multi-line comments include their delimiters on separate lines from
+   the text.  E.g.
+
+	/*
+	 * A very long
+	 * multi-line comment.
+	 */
+
+   Note however that a comment that explains a translatable string to
+   translators uses a convention of starting with a magic token
+   "TRANSLATORS: ", e.g.
+
+	/*
+	 * TRANSLATORS: here is a comment that explains the string to
+	 * be translated, that follows immediately after it.
+	 */
+	_("Here is a translatable string explained by the above.");
+
+ - Double negation is often harder to understand than no negation
+   at all.
+
+ - There are two schools of thought when it comes to comparison,
+   especially inside a loop. Some people prefer to have the less stable
+   value on the left hand side and the more stable value on the right hand
+   side, e.g. if you have a loop that counts variable i down to the
+   lower bound,
+
+	while (i > lower_bound) {
+		do something;
+		i--;
+	}
+
+   Other people prefer to have the textual order of values match the
+   actual order of values in their comparison, so that they can
+   mentally draw a number line from left to right and place these
+   values in order, i.e.
+
+	while (lower_bound < i) {
+		do something;
+		i--;
+	}
+
+   Both are valid, and we use both.  However, the more "stable" the
+   stable side becomes, the more we tend to prefer the former
+   (comparison with a constant, "i > 0", is an extreme example).
+   Just do not mix styles in the same part of the code and mimic
+   existing styles in the neighbourhood.
+
+ - There are two schools of thought when it comes to splitting a long
+   logical line into multiple lines.  Some people push the second and
+   subsequent lines far enough to the right with tabs and align them:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+		span_more_than_a_single_line_of ||
+		the_source_text) {
+                ...
+
+   while other people prefer to align the second and the subsequent
+   lines with the column immediately inside the opening parenthesis,
+   with tabs and spaces, following our "tabstop is always a multiple
+   of 8" convention:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of ||
+	    the_source_text) {
+                ...
+
+   Both are valid, and we use both.  Again, just do not mix styles in
+   the same part of the code and mimic existing styles in the
+   neighbourhood.
+
+ - When splitting a long logical line, some people change line before
+   a binary operator, so that the result looks like a parse tree when
+   you turn your head 90-degrees counterclockwise:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to
+	    || span_more_than_a_single_line_of_the_source_text) {
+
+   while other people prefer to leave the operator at the end of the
+   line:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of_the_source_text) {
+
+   Both are valid, but we tend to use the latter more, unless the
+   expression gets fairly complex, in which case the former tends to
+   be easier to read.  Again, just do not mix styles in the same part
+   of the code and mimic existing styles in the neighbourhood.
+
+ - When splitting a long logical line, with everything else being
+   equal, it is preferable to split after the operator at higher
+   level in the parse tree.  That is, this is more preferable:
+
+	if (a_very_long_variable * that_is_used_in +
+	    a_very_long_expression) {
+		...
+
+   than
+
+	if (a_very_long_variable *
+	    that_is_used_in + a_very_long_expression) {
+		...
+
+ - Some clever tricks, like using the !! operator with arithmetic
+   constructs, can be extremely confusing to others.  Avoid them,
+   unless there is a compelling reason to use them.
+
+ - Use the API.  No, really.  We have a strbuf (variable length
+   string), several arrays with the ALLOC_GROW() macro, a
+   string_list for sorted string lists, a hash map (mapping struct
+   objects) named "struct decorate", amongst other things.
+
+ - When you come up with an API, document its functions and structures
+   in the header file that exposes the API to its callers. Use what is
+   in "strbuf.h" as a model for the appropriate tone and level of
+   detail.
+
+ - The first #include in C files, except in platform specific compat/
+   implementations, must be either "git-compat-util.h", "cache.h" or
+   "builtin.h".  You do not have to include more than one of these.
+
+ - A C file must directly include the header files that declare the
+   functions and the types it uses, except for the functions and types
+   that are made available to it by including one of the header files
+   it must include by the previous rule.
+
+ - If you are planning a new command, consider writing it in shell
+   or perl first, so that changes in semantics can be easily
+   changed and discussed.  Many Git commands started out like
+   that, and a few are still scripts.
+
+ - Avoid introducing a new dependency into Git. This means you
+   usually should stay away from scripting languages not already
+   used in the Git core command set (unless your command is clearly
+   separate from it, such as an importer to convert random-scm-X
+   repositories to Git).
+
+ - When we pass <string, length> pair to functions, we should try to
+   pass them in that order.
+
+ - Use Git's gettext wrappers to make the user interface
+   translatable. See "Marking strings for translation" in po/README.
+
+ - Variables and functions local to a given source file should be marked
+   with "static". Variables that are visible to other source files
+   must be declared with "extern" in header files. However, function
+   declarations should not use "extern", as that is already the default.
+
+ - You can launch gdb around your program using the shorthand GIT_DEBUGGER.
+   Run `GIT_DEBUGGER=1 ./bin-wrappers/git foo` to simply use gdb as is, or
+   run `GIT_DEBUGGER="<debugger> <debugger-args>" ./bin-wrappers/git foo` to
+   use your own debugger and arguments. Example: `GIT_DEBUGGER="ddd --gdb"
+   ./bin-wrappers/git log` (See `wrap-for-bin.sh`.)
+
+For Perl programs:
+
+ - Most of the C guidelines above apply.
+
+ - We try to support Perl 5.8 and later ("use Perl 5.008").
+
+ - use strict and use warnings are strongly preferred.
+
+ - Don't overuse statement modifiers unless using them makes the
+   result easier to follow.
+
+	... do something ...
+	do_this() unless (condition);
+        ... do something else ...
+
+   is more readable than:
+
+	... do something ...
+	unless (condition) {
+		do_this();
+	}
+        ... do something else ...
+
+   *only* when the condition is so rare that do_this() will be almost
+   always called.
+
+ - We try to avoid assignments inside "if ()" conditions.
+
+ - Learn and use Git.pm if you need that functionality.
+
+For Python scripts:
+
+ - We follow PEP-8 (http://www.python.org/dev/peps/pep-0008/).
+
+ - As a minimum, we aim to be compatible with Python 2.7.
+
+ - Where required libraries do not restrict us to Python 2, we try to
+   also be compatible with Python 3.1 and later.
+
+
+Program Output
+
+ We make a distinction between a Git command's primary output and
+ output which is merely chatty feedback (for instance, status
+ messages, running transcript, or progress display), as well as error
+ messages. Roughly speaking, a Git command's primary output is that
+ which one might want to capture to a file or send down a pipe; its
+ chatty output should not interfere with these use-cases.
+
+ As such, primary output should be sent to the standard output stream
+ (stdout), and chatty output should be sent to the standard error
+ stream (stderr). Examples of commands which produce primary output
+ include `git log`, `git show`, and `git branch --list` which generate
+ output on the stdout stream.
+
+ Not all Git commands have primary output; this is often true of
+ commands whose main function is to perform an action. Some action
+ commands are silent, whereas others are chatty. An example of a
+ chatty action commands is `git clone` with its "Cloning into
+ '<path>'..." and "Checking connectivity..." status messages which it
+ sends to the stderr stream.
+
+ Error messages from Git commands should always be sent to the stderr
+ stream.
+
+
+Error Messages
+
+ - Do not end error messages with a full stop.
+
+ - Do not capitalize the first word, only because it is the first word
+   in the message ("unable to open %s", not "Unable to open %s").  But
+   "SHA-3 not supported" is fine, because the reason the first word is
+   capitalized is not because it is at the beginning of the sentence,
+   but because the word would be spelled in capital letters even when
+   it appeared in the middle of the sentence.
+
+ - Say what the error is first ("cannot open %s", not "%s: cannot open")
+
+
+Externally Visible Names
+
+ - For configuration variable names, follow the existing convention:
+
+   . The section name indicates the affected subsystem.
+
+   . The subsection name, if any, indicates which of an unbounded set
+     of things to set the value for.
+
+   . The variable name describes the effect of tweaking this knob.
+
+   The section and variable names that consist of multiple words are
+   formed by concatenating the words without punctuations (e.g. `-`),
+   and are broken using bumpyCaps in documentation as a hint to the
+   reader.
+
+   When choosing the variable namespace, do not use variable name for
+   specifying possibly unbounded set of things, most notably anything
+   an end user can freely come up with (e.g. branch names).  Instead,
+   use subsection names or variable values, like the existing variable
+   branch.<name>.description does.
+
+
+Writing Documentation:
+
+ Most (if not all) of the documentation pages are written in the
+ AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+ processed into HTML and manpages (e.g. git.html and git.1 in the
+ same directory).
+
+ The documentation liberally mixes US and UK English (en_US/UK)
+ norms for spelling and grammar, which is somewhat unfortunate.
+ In an ideal world, it would have been better if it consistently
+ used only one and not the other, and we would have picked en_US
+ (if you wish to correct the English of some of the existing
+ documentation, please see the documentation-related advice in the
+ Documentation/SubmittingPatches file).
+
+ In order to ensure the documentation is inclusive, avoid assuming
+ that an unspecified example person is male or female, and think
+ twice before using "he", "him", "she", or "her".  Here are some
+ tips to avoid use of gendered pronouns:
+
+  - Prefer succinctness and matter-of-factly describing functionality
+    in the abstract.  E.g.
+
+     --short:: Emit output in the short-format.
+
+    and avoid something like these overly verbose alternatives:
+
+     --short:: Use this to emit output in the short-format.
+     --short:: You can use this to get output in the short-format.
+     --short:: A user who prefers shorter output could....
+     --short:: Should a person and/or program want shorter output, he
+               she/they/it can...
+
+    This practice often eliminates the need to involve human actors in
+    your description, but it is a good practice regardless of the
+    avoidance of gendered pronouns.
+
+  - When it becomes awkward to stick to this style, prefer "you" when
+    addressing the the hypothetical user, and possibly "we" when
+    discussing how the program might react to the user.  E.g.
+
+      You can use this option instead of --xyz, but we might remove
+      support for it in future versions.
+
+    while keeping in mind that you can probably be less verbose, e.g.
+
+      Use this instead of --xyz. This option might be removed in future
+      versions.
+
+  - If you still need to refer to an example person that is
+    third-person singular, you may resort to "singular they" to avoid
+    "he/she/him/her", e.g.
+
+      A contributor asks their upstream to pull from them.
+
+    Note that this sounds ungrammatical and unnatural to those who
+    learned that "they" is only used for third-person plural, e.g.
+    those who learn English as a second language in some parts of the
+    world.
+
+ Every user-visible change should be reflected in the documentation.
+ The same general rule as for code applies -- imitate the existing
+ conventions.
+
+ A few commented examples follow to provide reference when writing or
+ modifying command usage strings and synopsis sections in the manual
+ pages:
+
+ Placeholders are spelled in lowercase and enclosed in angle brackets:
+   <file>
+   --sort=<key>
+   --abbrev[=<n>]
+
+ If a placeholder has multiple words, they are separated by dashes:
+   <new-branch-name>
+   --template=<template-directory>
+
+ Possibility of multiple occurrences is indicated by three dots:
+   <file>...
+   (One or more of <file>.)
+
+ Optional parts are enclosed in square brackets:
+   [<extra>]
+   (Zero or one <extra>.)
+
+   --exec-path[=<path>]
+   (Option with an optional argument.  Note that the "=" is inside the
+   brackets.)
+
+   [<patch>...]
+   (Zero or more of <patch>.  Note that the dots are inside, not
+   outside the brackets.)
+
+ Multiple alternatives are indicated with vertical bars:
+   [-q | --quiet]
+   [--utf8 | --no-utf8]
+
+ Parentheses are used for grouping:
+   [(<rev> | <range>)...]
+   (Any number of either <rev> or <range>.  Parens are needed to make
+   it clear that "..." pertains to both <rev> and <range>.)
+
+   [(-p <parent>)...]
+   (Any number of option -p, each with one <parent> argument.)
+
+   git remote set-head <name> (-a | -d | <branch>)
+   (One and only one of "-a", "-d" or "<branch>" _must_ (no square
+   brackets) be provided.)
+
+ And a somewhat more contrived example:
+   --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+   Here "=" is outside the brackets, because "--diff-filter=" is a
+   valid usage.  "*" has its own pair of brackets, because it can
+   (optionally) be specified only when one or more of the letters is
+   also provided.
+
+  A note on notation:
+   Use 'git' (all lowercase) when talking about commands i.e. something
+   the user would type into a shell and use 'Git' (uppercase first letter)
+   when talking about the version control system and its properties.
+
+ A few commented examples follow to provide reference when writing or
+ modifying paragraphs or option/command explanations that contain options
+ or commands:
+
+ Literal examples (e.g. use of command-line options, command names,
+ branch names, URLs, pathnames (files and directories), configuration and
+ environment variables) must be typeset in monospace (i.e. wrapped with
+ backticks):
+   `--pretty=oneline`
+   `git rev-list`
+   `remote.pushDefault`
+   `http://git.example.com`
+   `.git/config`
+   `GIT_DIR`
+   `HEAD`
+
+ An environment variable must be prefixed with "$" only when referring to its
+ value and not when referring to the variable itself, in this case there is
+ nothing to add except the backticks:
+   `GIT_DIR` is specified
+   `$GIT_DIR/hooks/pre-receive`
+
+ Word phrases enclosed in `backtick characters` are rendered literally
+ and will not be further expanded. The use of `backticks` to achieve the
+ previous rule means that literal examples should not use AsciiDoc
+ escapes.
+   Correct:
+      `--pretty=oneline`
+   Incorrect:
+      `\--pretty=oneline`
+
+ If some place in the documentation needs to typeset a command usage
+ example with inline substitutions, it is fine to use +monospaced and
+ inline substituted text+ instead of `monospaced literal text`, and with
+ the former, the part that should not get substituted must be
+ quoted/escaped.
diff --git a/external/docs/asciidoc/71b2434bb15acfa6720c087f54107b20b61a1b0c b/external/docs/asciidoc/71b2434bb15acfa6720c087f54107b20b61a1b0c
new file mode 100644
index 0000000000..9fca21cc5f
--- /dev/null
+++ b/external/docs/asciidoc/71b2434bb15acfa6720c087f54107b20b61a1b0c
@@ -0,0 +1,727 @@
+Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, a few rough rules are:
+
+ - Most importantly, we never say "It's in POSIX; we'll happily
+   ignore your needs should your system not conform to it."
+   We live in the real world.
+
+ - However, we often say "Let's stay away from that construct,
+   it's not even in POSIX".
+
+ - In spite of the above two rules, we sometimes say "Although
+   this is not in POSIX, it (is so convenient | makes the code
+   much more readable | has other good characteristics) and
+   practically all the platforms we care about support it, so
+   let's use it".
+
+   Again, we live in the real world, and it is sometimes a
+   judgement call, the decision based more on real world
+   constraints people face than what the paper standard says.
+
+ - Fixing style violations while working on a real change as a
+   preparatory clean-up step is good, but otherwise avoid useless code
+   churn for the sake of conforming to the style.
+
+   "Once it _is_ in the tree, it's not really worth the patch noise to
+   go and fix it up."
+   Cf. http://lkml.iu.edu/hypermail/linux/kernel/1001.3/01069.html
+
+ - Log messages to explain your changes are as important as the
+   changes themselves.  Clearly written code and in-code comments
+   explain how the code works and what is assumed from the surrounding
+   context.  The log messages explain what the changes wanted to
+   achieve and why the changes were necessary (more on this in the
+   accompanying SubmittingPatches document).
+
+Make your code readable and sensible, and don't try to be clever.
+
+As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the _local_
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn't match the overall style of existing code).
+
+But if you must have a list of rules, here are some language
+specific ones. Note that Documentation/ToolsForGit.txt document
+has a collection of tips to help you use some external tools
+to conform to these guidelines.
+
+For shell scripts specifically (not exhaustive):
+
+ - We use tabs for indentation.
+
+ - Case arms are indented at the same depth as case and esac lines,
+   like this:
+
+	case "$variable" in
+	pattern1)
+		do this
+		;;
+	pattern2)
+		do that
+		;;
+	esac
+
+ - Redirection operators should be written with space before, but no
+   space after them.  In other words, write 'echo test >"$file"'
+   instead of 'echo test> $file' or 'echo test > $file'.  Note that
+   even though it is not required by POSIX to double-quote the
+   redirection target in a variable (as shown above), our code does so
+   because some versions of bash issue a warning without the quotes.
+
+	(incorrect)
+	cat hello > world < universe
+	echo hello >$world
+
+	(correct)
+	cat hello >world <universe
+	echo hello >"$world"
+
+ - We prefer $( ... ) for command substitution; unlike ``, it
+   properly nests.  It should have been the way Bourne spelled
+   it from day one, but unfortunately isn't.
+
+ - If you want to find out if a command is available on the user's
+   $PATH, you should use 'type <command>', instead of 'which <command>'.
+   The output of 'which' is not machine parsable and its exit code
+   is not reliable across platforms.
+
+ - We use POSIX compliant parameter substitutions and avoid bashisms;
+   namely:
+
+   - We use ${parameter-word} and its [-=?+] siblings, and their
+     colon'ed "unset or null" form.
+
+   - We use ${parameter#word} and its [#%] siblings, and their
+     doubled "longest matching" form.
+
+   - No "Substring Expansion" ${parameter:offset:length}.
+
+   - No shell arrays.
+
+   - No pattern replacement ${parameter/pattern/string}.
+
+ - We use Arithmetic Expansion $(( ... )).
+
+ - We do not use Process Substitution <(list) or >(list).
+
+ - Do not write control structures on a single line with semicolon.
+   "then" should be on the next line for if statements, and "do"
+   should be on the next line for "while" and "for".
+
+	(incorrect)
+	if test -f hello; then
+		do this
+	fi
+
+	(correct)
+	if test -f hello
+	then
+		do this
+	fi
+
+ - If a command sequence joined with && or || or | spans multiple
+   lines, put each command on a separate line and put && and || and |
+   operators at the end of each line, rather than the start. This
+   means you don't need to use \ to join lines, since the above
+   operators imply the sequence isn't finished.
+
+	(incorrect)
+	grep blob verify_pack_result \
+	| awk -f print_1.awk \
+	| sort >actual &&
+	...
+
+	(correct)
+	grep blob verify_pack_result |
+	awk -f print_1.awk |
+	sort >actual &&
+	...
+
+ - We prefer "test" over "[ ... ]".
+
+ - We do not write the noiseword "function" in front of shell
+   functions.
+
+ - We prefer a space between the function name and the parentheses,
+   and no space inside the parentheses. The opening "{" should also
+   be on the same line.
+
+	(incorrect)
+	my_function(){
+		...
+
+	(correct)
+	my_function () {
+		...
+
+ - As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+   [::], [==], or [..]) for portability.
+
+   - We do not use \{m,n\};
+
+   - We do not use -E;
+
+   - We do not use ? or + (which are \{0,1\} and \{1,\}
+     respectively in BRE) but that goes without saying as these
+     are ERE elements not BRE (note that \? and \+ are not even part
+     of BRE -- making them accessible from BRE is a GNU extension).
+
+ - Use Git's gettext wrappers in git-sh-i18n to make the user
+   interface translatable. See "Marking strings for translation" in
+   po/README.
+
+ - We do not write our "test" command with "-a" and "-o" and use "&&"
+   or "||" to concatenate multiple "test" commands instead, because
+   the use of "-a/-o" is often error-prone.  E.g.
+
+     test -n "$x" -a "$a" = "$b"
+
+   is buggy and breaks when $x is "=", but
+
+     test -n "$x" && test "$a" = "$b"
+
+   does not have such a problem.
+
+ - Even though "local" is not part of POSIX, we make heavy use of it
+   in our test suite.  We do not use it in scripted Porcelains, and
+   hopefully nobody starts using "local" before they are reimplemented
+   in C ;-)
+
+
+For C programs:
+
+ - We use tabs to indent, and interpret tabs as taking up to
+   8 spaces.
+
+ - We try to keep to at most 80 characters per line.
+
+ - As a Git developer we assume you have a reasonably modern compiler
+   and we recommend you to enable the DEVELOPER makefile knob to
+   ensure your patch is clear of all compiler warnings we care about,
+   by e.g. "echo DEVELOPER=1 >>config.mak".
+
+ - We try to support a wide range of C compilers to compile Git with,
+   including old ones.  You should not use features from newer C
+   standard, even if your compiler groks them.
+
+   There are a few exceptions to this guideline:
+
+   . since early 2012 with e1327023ea, we have been using an enum
+     definition whose last element is followed by a comma.  This, like
+     an array initializer that ends with a trailing comma, can be used
+     to reduce the patch noise when adding a new identifier at the end.
+
+   . since mid 2017 with cbc0f81d, we have been using designated
+     initializers for struct (e.g. "struct t v = { .val = 'a' };").
+
+   . since mid 2017 with 512f41cf, we have been using designated
+     initializers for array (e.g. "int array[10] = { [5] = 2 }").
+
+   . since early 2021 with 765dc168882, we have been using variadic
+     macros, mostly for printf-like trace and debug macros.
+
+   These used to be forbidden, but we have not heard any breakage
+   report, and they are assumed to be safe.
+
+ - Variables have to be declared at the beginning of the block, before
+   the first statement (i.e. -Wdeclaration-after-statement).
+
+ - Declaring a variable in the for loop "for (int i = 0; i < 10; i++)"
+   is still not allowed in this codebase.  We are in the process of
+   allowing it by waiting to see that 44ba10d6 (revision: use C99
+   declaration of variable in for() loop, 2021-11-14) does not get
+   complaints.  Let's revisit this around November 2022.
+
+ - NULL pointers shall be written as NULL, not as 0.
+
+ - When declaring pointers, the star sides with the variable
+   name, i.e. "char *string", not "char* string" or
+   "char * string".  This makes it easier to understand code
+   like "char *string, c;".
+
+ - Use whitespace around operators and keywords, but not inside
+   parentheses and not around functions. So:
+
+        while (condition)
+		func(bar + 1);
+
+   and not:
+
+        while( condition )
+		func (bar+1);
+
+ - Do not explicitly compare an integral value with constant 0 or '\0',
+   or a pointer value with constant NULL.  For instance, to validate that
+   counted array <ptr, cnt> is initialized but has no elements, write:
+
+	if (!ptr || cnt)
+		BUG("empty array expected");
+
+   and not:
+
+	if (ptr == NULL || cnt != 0);
+		BUG("empty array expected");
+
+ - We avoid using braces unnecessarily.  I.e.
+
+	if (bla) {
+		x = 1;
+	}
+
+   is frowned upon. But there are a few exceptions:
+
+	- When the statement extends over a few lines (e.g., a while loop
+	  with an embedded conditional, or a comment). E.g.:
+
+		while (foo) {
+			if (x)
+				one();
+			else
+				two();
+		}
+
+		if (foo) {
+			/*
+			 * This one requires some explanation,
+			 * so we're better off with braces to make
+			 * it obvious that the indentation is correct.
+			 */
+			doit();
+		}
+
+	- When there are multiple arms to a conditional and some of them
+	  require braces, enclose even a single line block in braces for
+	  consistency. E.g.:
+
+		if (foo) {
+			doit();
+		} else {
+			one();
+			two();
+			three();
+		}
+
+ - We try to avoid assignments in the condition of an "if" statement.
+
+ - Try to make your code understandable.  You may put comments
+   in, but comments invariably tend to stale out when the code
+   they were describing changes.  Often splitting a function
+   into two makes the intention of the code much clearer.
+
+ - Multi-line comments include their delimiters on separate lines from
+   the text.  E.g.
+
+	/*
+	 * A very long
+	 * multi-line comment.
+	 */
+
+   Note however that a comment that explains a translatable string to
+   translators uses a convention of starting with a magic token
+   "TRANSLATORS: ", e.g.
+
+	/*
+	 * TRANSLATORS: here is a comment that explains the string to
+	 * be translated, that follows immediately after it.
+	 */
+	_("Here is a translatable string explained by the above.");
+
+ - Double negation is often harder to understand than no negation
+   at all.
+
+ - There are two schools of thought when it comes to comparison,
+   especially inside a loop. Some people prefer to have the less stable
+   value on the left hand side and the more stable value on the right hand
+   side, e.g. if you have a loop that counts variable i down to the
+   lower bound,
+
+	while (i > lower_bound) {
+		do something;
+		i--;
+	}
+
+   Other people prefer to have the textual order of values match the
+   actual order of values in their comparison, so that they can
+   mentally draw a number line from left to right and place these
+   values in order, i.e.
+
+	while (lower_bound < i) {
+		do something;
+		i--;
+	}
+
+   Both are valid, and we use both.  However, the more "stable" the
+   stable side becomes, the more we tend to prefer the former
+   (comparison with a constant, "i > 0", is an extreme example).
+   Just do not mix styles in the same part of the code and mimic
+   existing styles in the neighbourhood.
+
+ - There are two schools of thought when it comes to splitting a long
+   logical line into multiple lines.  Some people push the second and
+   subsequent lines far enough to the right with tabs and align them:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+		span_more_than_a_single_line_of ||
+		the_source_text) {
+                ...
+
+   while other people prefer to align the second and the subsequent
+   lines with the column immediately inside the opening parenthesis,
+   with tabs and spaces, following our "tabstop is always a multiple
+   of 8" convention:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of ||
+	    the_source_text) {
+                ...
+
+   Both are valid, and we use both.  Again, just do not mix styles in
+   the same part of the code and mimic existing styles in the
+   neighbourhood.
+
+ - When splitting a long logical line, some people change line before
+   a binary operator, so that the result looks like a parse tree when
+   you turn your head 90-degrees counterclockwise:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to
+	    || span_more_than_a_single_line_of_the_source_text) {
+
+   while other people prefer to leave the operator at the end of the
+   line:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of_the_source_text) {
+
+   Both are valid, but we tend to use the latter more, unless the
+   expression gets fairly complex, in which case the former tends to
+   be easier to read.  Again, just do not mix styles in the same part
+   of the code and mimic existing styles in the neighbourhood.
+
+ - When splitting a long logical line, with everything else being
+   equal, it is preferable to split after the operator at higher
+   level in the parse tree.  That is, this is more preferable:
+
+	if (a_very_long_variable * that_is_used_in +
+	    a_very_long_expression) {
+		...
+
+   than
+
+	if (a_very_long_variable *
+	    that_is_used_in + a_very_long_expression) {
+		...
+
+ - Some clever tricks, like using the !! operator with arithmetic
+   constructs, can be extremely confusing to others.  Avoid them,
+   unless there is a compelling reason to use them.
+
+ - Use the API.  No, really.  We have a strbuf (variable length
+   string), several arrays with the ALLOC_GROW() macro, a
+   string_list for sorted string lists, a hash map (mapping struct
+   objects) named "struct decorate", amongst other things.
+
+ - When you come up with an API, document its functions and structures
+   in the header file that exposes the API to its callers. Use what is
+   in "strbuf.h" as a model for the appropriate tone and level of
+   detail.
+
+ - The first #include in C files, except in platform specific compat/
+   implementations, must be either "git-compat-util.h", "cache.h" or
+   "builtin.h".  You do not have to include more than one of these.
+
+ - A C file must directly include the header files that declare the
+   functions and the types it uses, except for the functions and types
+   that are made available to it by including one of the header files
+   it must include by the previous rule.
+
+ - If you are planning a new command, consider writing it in shell
+   or perl first, so that changes in semantics can be easily
+   changed and discussed.  Many Git commands started out like
+   that, and a few are still scripts.
+
+ - Avoid introducing a new dependency into Git. This means you
+   usually should stay away from scripting languages not already
+   used in the Git core command set (unless your command is clearly
+   separate from it, such as an importer to convert random-scm-X
+   repositories to Git).
+
+ - When we pass <string, length> pair to functions, we should try to
+   pass them in that order.
+
+ - Use Git's gettext wrappers to make the user interface
+   translatable. See "Marking strings for translation" in po/README.
+
+ - Variables and functions local to a given source file should be marked
+   with "static". Variables that are visible to other source files
+   must be declared with "extern" in header files. However, function
+   declarations should not use "extern", as that is already the default.
+
+ - You can launch gdb around your program using the shorthand GIT_DEBUGGER.
+   Run `GIT_DEBUGGER=1 ./bin-wrappers/git foo` to simply use gdb as is, or
+   run `GIT_DEBUGGER="<debugger> <debugger-args>" ./bin-wrappers/git foo` to
+   use your own debugger and arguments. Example: `GIT_DEBUGGER="ddd --gdb"
+   ./bin-wrappers/git log` (See `wrap-for-bin.sh`.)
+
+For Perl programs:
+
+ - Most of the C guidelines above apply.
+
+ - We try to support Perl 5.8 and later ("use Perl 5.008").
+
+ - use strict and use warnings are strongly preferred.
+
+ - Don't overuse statement modifiers unless using them makes the
+   result easier to follow.
+
+	... do something ...
+	do_this() unless (condition);
+        ... do something else ...
+
+   is more readable than:
+
+	... do something ...
+	unless (condition) {
+		do_this();
+	}
+        ... do something else ...
+
+   *only* when the condition is so rare that do_this() will be almost
+   always called.
+
+ - We try to avoid assignments inside "if ()" conditions.
+
+ - Learn and use Git.pm if you need that functionality.
+
+For Python scripts:
+
+ - We follow PEP-8 (http://www.python.org/dev/peps/pep-0008/).
+
+ - As a minimum, we aim to be compatible with Python 2.7.
+
+ - Where required libraries do not restrict us to Python 2, we try to
+   also be compatible with Python 3.1 and later.
+
+
+Program Output
+
+ We make a distinction between a Git command's primary output and
+ output which is merely chatty feedback (for instance, status
+ messages, running transcript, or progress display), as well as error
+ messages. Roughly speaking, a Git command's primary output is that
+ which one might want to capture to a file or send down a pipe; its
+ chatty output should not interfere with these use-cases.
+
+ As such, primary output should be sent to the standard output stream
+ (stdout), and chatty output should be sent to the standard error
+ stream (stderr). Examples of commands which produce primary output
+ include `git log`, `git show`, and `git branch --list` which generate
+ output on the stdout stream.
+
+ Not all Git commands have primary output; this is often true of
+ commands whose main function is to perform an action. Some action
+ commands are silent, whereas others are chatty. An example of a
+ chatty action commands is `git clone` with its "Cloning into
+ '<path>'..." and "Checking connectivity..." status messages which it
+ sends to the stderr stream.
+
+ Error messages from Git commands should always be sent to the stderr
+ stream.
+
+
+Error Messages
+
+ - Do not end error messages with a full stop.
+
+ - Do not capitalize the first word, only because it is the first word
+   in the message ("unable to open %s", not "Unable to open %s").  But
+   "SHA-3 not supported" is fine, because the reason the first word is
+   capitalized is not because it is at the beginning of the sentence,
+   but because the word would be spelled in capital letters even when
+   it appeared in the middle of the sentence.
+
+ - Say what the error is first ("cannot open %s", not "%s: cannot open")
+
+
+Externally Visible Names
+
+ - For configuration variable names, follow the existing convention:
+
+   . The section name indicates the affected subsystem.
+
+   . The subsection name, if any, indicates which of an unbounded set
+     of things to set the value for.
+
+   . The variable name describes the effect of tweaking this knob.
+
+   The section and variable names that consist of multiple words are
+   formed by concatenating the words without punctuations (e.g. `-`),
+   and are broken using bumpyCaps in documentation as a hint to the
+   reader.
+
+   When choosing the variable namespace, do not use variable name for
+   specifying possibly unbounded set of things, most notably anything
+   an end user can freely come up with (e.g. branch names).  Instead,
+   use subsection names or variable values, like the existing variable
+   branch.<name>.description does.
+
+
+Writing Documentation:
+
+ Most (if not all) of the documentation pages are written in the
+ AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+ processed into HTML and manpages (e.g. git.html and git.1 in the
+ same directory).
+
+ The documentation liberally mixes US and UK English (en_US/UK)
+ norms for spelling and grammar, which is somewhat unfortunate.
+ In an ideal world, it would have been better if it consistently
+ used only one and not the other, and we would have picked en_US
+ (if you wish to correct the English of some of the existing
+ documentation, please see the documentation-related advice in the
+ Documentation/SubmittingPatches file).
+
+ In order to ensure the documentation is inclusive, avoid assuming
+ that an unspecified example person is male or female, and think
+ twice before using "he", "him", "she", or "her".  Here are some
+ tips to avoid use of gendered pronouns:
+
+  - Prefer succinctness and matter-of-factly describing functionality
+    in the abstract.  E.g.
+
+     --short:: Emit output in the short-format.
+
+    and avoid something like these overly verbose alternatives:
+
+     --short:: Use this to emit output in the short-format.
+     --short:: You can use this to get output in the short-format.
+     --short:: A user who prefers shorter output could....
+     --short:: Should a person and/or program want shorter output, he
+               she/they/it can...
+
+    This practice often eliminates the need to involve human actors in
+    your description, but it is a good practice regardless of the
+    avoidance of gendered pronouns.
+
+  - When it becomes awkward to stick to this style, prefer "you" when
+    addressing the hypothetical user, and possibly "we" when
+    discussing how the program might react to the user.  E.g.
+
+      You can use this option instead of --xyz, but we might remove
+      support for it in future versions.
+
+    while keeping in mind that you can probably be less verbose, e.g.
+
+      Use this instead of --xyz. This option might be removed in future
+      versions.
+
+  - If you still need to refer to an example person that is
+    third-person singular, you may resort to "singular they" to avoid
+    "he/she/him/her", e.g.
+
+      A contributor asks their upstream to pull from them.
+
+    Note that this sounds ungrammatical and unnatural to those who
+    learned that "they" is only used for third-person plural, e.g.
+    those who learn English as a second language in some parts of the
+    world.
+
+ Every user-visible change should be reflected in the documentation.
+ The same general rule as for code applies -- imitate the existing
+ conventions.
+
+ A few commented examples follow to provide reference when writing or
+ modifying command usage strings and synopsis sections in the manual
+ pages:
+
+ Placeholders are spelled in lowercase and enclosed in angle brackets:
+   <file>
+   --sort=<key>
+   --abbrev[=<n>]
+
+ If a placeholder has multiple words, they are separated by dashes:
+   <new-branch-name>
+   --template=<template-directory>
+
+ Possibility of multiple occurrences is indicated by three dots:
+   <file>...
+   (One or more of <file>.)
+
+ Optional parts are enclosed in square brackets:
+   [<extra>]
+   (Zero or one <extra>.)
+
+   --exec-path[=<path>]
+   (Option with an optional argument.  Note that the "=" is inside the
+   brackets.)
+
+   [<patch>...]
+   (Zero or more of <patch>.  Note that the dots are inside, not
+   outside the brackets.)
+
+ Multiple alternatives are indicated with vertical bars:
+   [-q | --quiet]
+   [--utf8 | --no-utf8]
+
+ Parentheses are used for grouping:
+   [(<rev> | <range>)...]
+   (Any number of either <rev> or <range>.  Parens are needed to make
+   it clear that "..." pertains to both <rev> and <range>.)
+
+   [(-p <parent>)...]
+   (Any number of option -p, each with one <parent> argument.)
+
+   git remote set-head <name> (-a | -d | <branch>)
+   (One and only one of "-a", "-d" or "<branch>" _must_ (no square
+   brackets) be provided.)
+
+ And a somewhat more contrived example:
+   --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+   Here "=" is outside the brackets, because "--diff-filter=" is a
+   valid usage.  "*" has its own pair of brackets, because it can
+   (optionally) be specified only when one or more of the letters is
+   also provided.
+
+  A note on notation:
+   Use 'git' (all lowercase) when talking about commands i.e. something
+   the user would type into a shell and use 'Git' (uppercase first letter)
+   when talking about the version control system and its properties.
+
+ A few commented examples follow to provide reference when writing or
+ modifying paragraphs or option/command explanations that contain options
+ or commands:
+
+ Literal examples (e.g. use of command-line options, command names,
+ branch names, URLs, pathnames (files and directories), configuration and
+ environment variables) must be typeset in monospace (i.e. wrapped with
+ backticks):
+   `--pretty=oneline`
+   `git rev-list`
+   `remote.pushDefault`
+   `http://git.example.com`
+   `.git/config`
+   `GIT_DIR`
+   `HEAD`
+
+ An environment variable must be prefixed with "$" only when referring to its
+ value and not when referring to the variable itself, in this case there is
+ nothing to add except the backticks:
+   `GIT_DIR` is specified
+   `$GIT_DIR/hooks/pre-receive`
+
+ Word phrases enclosed in `backtick characters` are rendered literally
+ and will not be further expanded. The use of `backticks` to achieve the
+ previous rule means that literal examples should not use AsciiDoc
+ escapes.
+   Correct:
+      `--pretty=oneline`
+   Incorrect:
+      `\--pretty=oneline`
+
+ If some place in the documentation needs to typeset a command usage
+ example with inline substitutions, it is fine to use +monospaced and
+ inline substituted text+ instead of `monospaced literal text`, and with
+ the former, the part that should not get substituted must be
+ quoted/escaped.
diff --git a/external/docs/asciidoc/77f797459e96e94e3a6014d10c0c1bda00c8768d b/external/docs/asciidoc/77f797459e96e94e3a6014d10c0c1bda00c8768d
new file mode 100644
index 0000000000..45465bc0c9
--- /dev/null
+++ b/external/docs/asciidoc/77f797459e96e94e3a6014d10c0c1bda00c8768d
@@ -0,0 +1,640 @@
+Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, a few rough rules are:
+
+ - Most importantly, we never say "It's in POSIX; we'll happily
+   ignore your needs should your system not conform to it."
+   We live in the real world.
+
+ - However, we often say "Let's stay away from that construct,
+   it's not even in POSIX".
+
+ - In spite of the above two rules, we sometimes say "Although
+   this is not in POSIX, it (is so convenient | makes the code
+   much more readable | has other good characteristics) and
+   practically all the platforms we care about support it, so
+   let's use it".
+
+   Again, we live in the real world, and it is sometimes a
+   judgement call, the decision based more on real world
+   constraints people face than what the paper standard says.
+
+ - Fixing style violations while working on a real change as a
+   preparatory clean-up step is good, but otherwise avoid useless code
+   churn for the sake of conforming to the style.
+
+   "Once it _is_ in the tree, it's not really worth the patch noise to
+   go and fix it up."
+   Cf. http://lkml.iu.edu/hypermail/linux/kernel/1001.3/01069.html
+
+Make your code readable and sensible, and don't try to be clever.
+
+As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the _local_
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn't match the overall style of existing code).
+
+But if you must have a list of rules, here they are.
+
+For shell scripts specifically (not exhaustive):
+
+ - We use tabs for indentation.
+
+ - Case arms are indented at the same depth as case and esac lines,
+   like this:
+
+	case "$variable" in
+	pattern1)
+		do this
+		;;
+	pattern2)
+		do that
+		;;
+	esac
+
+ - Redirection operators should be written with space before, but no
+   space after them.  In other words, write 'echo test >"$file"'
+   instead of 'echo test> $file' or 'echo test > $file'.  Note that
+   even though it is not required by POSIX to double-quote the
+   redirection target in a variable (as shown above), our code does so
+   because some versions of bash issue a warning without the quotes.
+
+	(incorrect)
+	cat hello > world < universe
+	echo hello >$world
+
+	(correct)
+	cat hello >world <universe
+	echo hello >"$world"
+
+ - We prefer $( ... ) for command substitution; unlike ``, it
+   properly nests.  It should have been the way Bourne spelled
+   it from day one, but unfortunately isn't.
+
+ - If you want to find out if a command is available on the user's
+   $PATH, you should use 'type <command>', instead of 'which <command>'.
+   The output of 'which' is not machine parsable and its exit code
+   is not reliable across platforms.
+
+ - We use POSIX compliant parameter substitutions and avoid bashisms;
+   namely:
+
+   - We use ${parameter-word} and its [-=?+] siblings, and their
+     colon'ed "unset or null" form.
+
+   - We use ${parameter#word} and its [#%] siblings, and their
+     doubled "longest matching" form.
+
+   - No "Substring Expansion" ${parameter:offset:length}.
+
+   - No shell arrays.
+
+   - No pattern replacement ${parameter/pattern/string}.
+
+ - We use Arithmetic Expansion $(( ... )).
+
+ - We do not use Process Substitution <(list) or >(list).
+
+ - Do not write control structures on a single line with semicolon.
+   "then" should be on the next line for if statements, and "do"
+   should be on the next line for "while" and "for".
+
+	(incorrect)
+	if test -f hello; then
+		do this
+	fi
+
+	(correct)
+	if test -f hello
+	then
+		do this
+	fi
+
+ - If a command sequence joined with && or || or | spans multiple
+   lines, put each command on a separate line and put && and || and |
+   operators at the end of each line, rather than the start. This
+   means you don't need to use \ to join lines, since the above
+   operators imply the sequence isn't finished.
+
+	(incorrect)
+	grep blob verify_pack_result \
+	| awk -f print_1.awk \
+	| sort >actual &&
+	...
+
+	(correct)
+	grep blob verify_pack_result |
+	awk -f print_1.awk |
+	sort >actual &&
+	...
+
+ - We prefer "test" over "[ ... ]".
+
+ - We do not write the noiseword "function" in front of shell
+   functions.
+
+ - We prefer a space between the function name and the parentheses,
+   and no space inside the parentheses. The opening "{" should also
+   be on the same line.
+
+	(incorrect)
+	my_function(){
+		...
+
+	(correct)
+	my_function () {
+		...
+
+ - As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+   [::], [==], or [..]) for portability.
+
+   - We do not use \{m,n\};
+
+   - We do not use -E;
+
+   - We do not use ? or + (which are \{0,1\} and \{1,\}
+     respectively in BRE) but that goes without saying as these
+     are ERE elements not BRE (note that \? and \+ are not even part
+     of BRE -- making them accessible from BRE is a GNU extension).
+
+ - Use Git's gettext wrappers in git-sh-i18n to make the user
+   interface translatable. See "Marking strings for translation" in
+   po/README.
+
+ - We do not write our "test" command with "-a" and "-o" and use "&&"
+   or "||" to concatenate multiple "test" commands instead, because
+   the use of "-a/-o" is often error-prone.  E.g.
+
+     test -n "$x" -a "$a" = "$b"
+
+   is buggy and breaks when $x is "=", but
+
+     test -n "$x" && test "$a" = "$b"
+
+   does not have such a problem.
+
+
+For C programs:
+
+ - We use tabs to indent, and interpret tabs as taking up to
+   8 spaces.
+
+ - We try to keep to at most 80 characters per line.
+
+ - As a Git developer we assume you have a reasonably modern compiler
+   and we recommend you to enable the DEVELOPER makefile knob to
+   ensure your patch is clear of all compiler warnings we care about,
+   by e.g. "echo DEVELOPER=1 >>config.mak".
+
+ - We try to support a wide range of C compilers to compile Git with,
+   including old ones.  You should not use features from newer C
+   standard, even if your compiler groks them.
+
+   There are a few exceptions to this guideline:
+
+   . since early 2012 with e1327023ea, we have been using an enum
+     definition whose last element is followed by a comma.  This, like
+     an array initializer that ends with a trailing comma, can be used
+     to reduce the patch noise when adding a new identifier at the end.
+
+   . since mid 2017 with cbc0f81d, we have been using designated
+     initializers for struct (e.g. "struct t v = { .val = 'a' };").
+
+   . since mid 2017 with 512f41cf, we have been using designated
+     initializers for array (e.g. "int array[10] = { [5] = 2 }").
+
+   These used to be forbidden, but we have not heard any breakage
+   report, and they are assumed to be safe.
+
+ - Variables have to be declared at the beginning of the block, before
+   the first statement (i.e. -Wdeclaration-after-statement).
+
+ - Declaring a variable in the for loop "for (int i = 0; i < 10; i++)"
+   is still not allowed in this codebase.
+
+ - NULL pointers shall be written as NULL, not as 0.
+
+ - When declaring pointers, the star sides with the variable
+   name, i.e. "char *string", not "char* string" or
+   "char * string".  This makes it easier to understand code
+   like "char *string, c;".
+
+ - Use whitespace around operators and keywords, but not inside
+   parentheses and not around functions. So:
+
+        while (condition)
+		func(bar + 1);
+
+   and not:
+
+        while( condition )
+		func (bar+1);
+
+ - Do not explicitly compare an integral value with constant 0 or '\0',
+   or a pointer value with constant NULL.  For instance, to validate that
+   counted array <ptr, cnt> is initialized but has no elements, write:
+
+	if (!ptr || cnt)
+		BUG("empty array expected");
+
+   and not:
+
+	if (ptr == NULL || cnt != 0);
+		BUG("empty array expected");
+
+ - We avoid using braces unnecessarily.  I.e.
+
+	if (bla) {
+		x = 1;
+	}
+
+   is frowned upon. But there are a few exceptions:
+
+	- When the statement extends over a few lines (e.g., a while loop
+	  with an embedded conditional, or a comment). E.g.:
+
+		while (foo) {
+			if (x)
+				one();
+			else
+				two();
+		}
+
+		if (foo) {
+			/*
+			 * This one requires some explanation,
+			 * so we're better off with braces to make
+			 * it obvious that the indentation is correct.
+			 */
+			doit();
+		}
+
+	- When there are multiple arms to a conditional and some of them
+	  require braces, enclose even a single line block in braces for
+	  consistency. E.g.:
+
+		if (foo) {
+			doit();
+		} else {
+			one();
+			two();
+			three();
+		}
+
+ - We try to avoid assignments in the condition of an "if" statement.
+
+ - Try to make your code understandable.  You may put comments
+   in, but comments invariably tend to stale out when the code
+   they were describing changes.  Often splitting a function
+   into two makes the intention of the code much clearer.
+
+ - Multi-line comments include their delimiters on separate lines from
+   the text.  E.g.
+
+	/*
+	 * A very long
+	 * multi-line comment.
+	 */
+
+   Note however that a comment that explains a translatable string to
+   translators uses a convention of starting with a magic token
+   "TRANSLATORS: ", e.g.
+
+	/*
+	 * TRANSLATORS: here is a comment that explains the string to
+	 * be translated, that follows immediately after it.
+	 */
+	_("Here is a translatable string explained by the above.");
+
+ - Double negation is often harder to understand than no negation
+   at all.
+
+ - There are two schools of thought when it comes to comparison,
+   especially inside a loop. Some people prefer to have the less stable
+   value on the left hand side and the more stable value on the right hand
+   side, e.g. if you have a loop that counts variable i down to the
+   lower bound,
+
+	while (i > lower_bound) {
+		do something;
+		i--;
+	}
+
+   Other people prefer to have the textual order of values match the
+   actual order of values in their comparison, so that they can
+   mentally draw a number line from left to right and place these
+   values in order, i.e.
+
+	while (lower_bound < i) {
+		do something;
+		i--;
+	}
+
+   Both are valid, and we use both.  However, the more "stable" the
+   stable side becomes, the more we tend to prefer the former
+   (comparison with a constant, "i > 0", is an extreme example).
+   Just do not mix styles in the same part of the code and mimic
+   existing styles in the neighbourhood.
+
+ - There are two schools of thought when it comes to splitting a long
+   logical line into multiple lines.  Some people push the second and
+   subsequent lines far enough to the right with tabs and align them:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+		span_more_than_a_single_line_of ||
+		the_source_text) {
+                ...
+
+   while other people prefer to align the second and the subsequent
+   lines with the column immediately inside the opening parenthesis,
+   with tabs and spaces, following our "tabstop is always a multiple
+   of 8" convention:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of ||
+	    the_source_text) {
+                ...
+
+   Both are valid, and we use both.  Again, just do not mix styles in
+   the same part of the code and mimic existing styles in the
+   neighbourhood.
+
+ - When splitting a long logical line, some people change line before
+   a binary operator, so that the result looks like a parse tree when
+   you turn your head 90-degrees counterclockwise:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to
+	    || span_more_than_a_single_line_of_the_source_text) {
+
+   while other people prefer to leave the operator at the end of the
+   line:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of_the_source_text) {
+
+   Both are valid, but we tend to use the latter more, unless the
+   expression gets fairly complex, in which case the former tends to
+   be easier to read.  Again, just do not mix styles in the same part
+   of the code and mimic existing styles in the neighbourhood.
+
+ - When splitting a long logical line, with everything else being
+   equal, it is preferable to split after the operator at higher
+   level in the parse tree.  That is, this is more preferable:
+
+	if (a_very_long_variable * that_is_used_in +
+	    a_very_long_expression) {
+		...
+
+   than
+
+	if (a_very_long_variable *
+	    that_is_used_in + a_very_long_expression) {
+		...
+
+ - Some clever tricks, like using the !! operator with arithmetic
+   constructs, can be extremely confusing to others.  Avoid them,
+   unless there is a compelling reason to use them.
+
+ - Use the API.  No, really.  We have a strbuf (variable length
+   string), several arrays with the ALLOC_GROW() macro, a
+   string_list for sorted string lists, a hash map (mapping struct
+   objects) named "struct decorate", amongst other things.
+
+ - When you come up with an API, document its functions and structures
+   in the header file that exposes the API to its callers. Use what is
+   in "strbuf.h" as a model for the appropriate tone and level of
+   detail.
+
+ - The first #include in C files, except in platform specific compat/
+   implementations, must be either "git-compat-util.h", "cache.h" or
+   "builtin.h".  You do not have to include more than one of these.
+
+ - A C file must directly include the header files that declare the
+   functions and the types it uses, except for the functions and types
+   that are made available to it by including one of the header files
+   it must include by the previous rule.
+
+ - If you are planning a new command, consider writing it in shell
+   or perl first, so that changes in semantics can be easily
+   changed and discussed.  Many Git commands started out like
+   that, and a few are still scripts.
+
+ - Avoid introducing a new dependency into Git. This means you
+   usually should stay away from scripting languages not already
+   used in the Git core command set (unless your command is clearly
+   separate from it, such as an importer to convert random-scm-X
+   repositories to Git).
+
+ - When we pass <string, length> pair to functions, we should try to
+   pass them in that order.
+
+ - Use Git's gettext wrappers to make the user interface
+   translatable. See "Marking strings for translation" in po/README.
+
+ - Variables and functions local to a given source file should be marked
+   with "static". Variables that are visible to other source files
+   must be declared with "extern" in header files. However, function
+   declarations should not use "extern", as that is already the default.
+
+ - You can launch gdb around your program using the shorthand GIT_DEBUGGER.
+   Run `GIT_DEBUGGER=1 ./bin-wrappers/git foo` to simply use gdb as is, or
+   run `GIT_DEBUGGER="<debugger> <debugger-args>" ./bin-wrappers/git foo` to
+   use your own debugger and arguments. Example: `GIT_DEBUGGER="ddd --gdb"
+   ./bin-wrappers/git log` (See `wrap-for-bin.sh`.)
+
+For Perl programs:
+
+ - Most of the C guidelines above apply.
+
+ - We try to support Perl 5.8 and later ("use Perl 5.008").
+
+ - use strict and use warnings are strongly preferred.
+
+ - Don't overuse statement modifiers unless using them makes the
+   result easier to follow.
+
+	... do something ...
+	do_this() unless (condition);
+        ... do something else ...
+
+   is more readable than:
+
+	... do something ...
+	unless (condition) {
+		do_this();
+	}
+        ... do something else ...
+
+   *only* when the condition is so rare that do_this() will be almost
+   always called.
+
+ - We try to avoid assignments inside "if ()" conditions.
+
+ - Learn and use Git.pm if you need that functionality.
+
+ - For Emacs, it's useful to put the following in
+   GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode:
+
+    ;; note the first part is useful for C editing, too
+    ((nil . ((indent-tabs-mode . t)
+                  (tab-width . 8)
+                  (fill-column . 80)))
+     (cperl-mode . ((cperl-indent-level . 8)
+                    (cperl-extra-newline-before-brace . nil)
+                    (cperl-merge-trailing-else . t))))
+
+For Python scripts:
+
+ - We follow PEP-8 (http://www.python.org/dev/peps/pep-0008/).
+
+ - As a minimum, we aim to be compatible with Python 2.7.
+
+ - Where required libraries do not restrict us to Python 2, we try to
+   also be compatible with Python 3.1 and later.
+
+Error Messages
+
+ - Do not end error messages with a full stop.
+
+ - Do not capitalize ("unable to open %s", not "Unable to open %s")
+
+ - Say what the error is first ("cannot open %s", not "%s: cannot open")
+
+
+Externally Visible Names
+
+ - For configuration variable names, follow the existing convention:
+
+   . The section name indicates the affected subsystem.
+
+   . The subsection name, if any, indicates which of an unbounded set
+     of things to set the value for.
+
+   . The variable name describes the effect of tweaking this knob.
+
+   The section and variable names that consist of multiple words are
+   formed by concatenating the words without punctuations (e.g. `-`),
+   and are broken using bumpyCaps in documentation as a hint to the
+   reader.
+
+   When choosing the variable namespace, do not use variable name for
+   specifying possibly unbounded set of things, most notably anything
+   an end user can freely come up with (e.g. branch names).  Instead,
+   use subsection names or variable values, like the existing variable
+   branch.<name>.description does.
+
+
+Writing Documentation:
+
+ Most (if not all) of the documentation pages are written in the
+ AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+ processed into HTML and manpages (e.g. git.html and git.1 in the
+ same directory).
+
+ The documentation liberally mixes US and UK English (en_US/UK)
+ norms for spelling and grammar, which is somewhat unfortunate.
+ In an ideal world, it would have been better if it consistently
+ used only one and not the other, and we would have picked en_US
+ (if you wish to correct the English of some of the existing
+ documentation, please see the documentation-related advice in the
+ Documentation/SubmittingPatches file).
+
+ Every user-visible change should be reflected in the documentation.
+ The same general rule as for code applies -- imitate the existing
+ conventions.
+
+ A few commented examples follow to provide reference when writing or
+ modifying command usage strings and synopsis sections in the manual
+ pages:
+
+ Placeholders are spelled in lowercase and enclosed in angle brackets:
+   <file>
+   --sort=<key>
+   --abbrev[=<n>]
+
+ If a placeholder has multiple words, they are separated by dashes:
+   <new-branch-name>
+   --template=<template-directory>
+
+ Possibility of multiple occurrences is indicated by three dots:
+   <file>...
+   (One or more of <file>.)
+
+ Optional parts are enclosed in square brackets:
+   [<extra>]
+   (Zero or one <extra>.)
+
+   --exec-path[=<path>]
+   (Option with an optional argument.  Note that the "=" is inside the
+   brackets.)
+
+   [<patch>...]
+   (Zero or more of <patch>.  Note that the dots are inside, not
+   outside the brackets.)
+
+ Multiple alternatives are indicated with vertical bars:
+   [-q | --quiet]
+   [--utf8 | --no-utf8]
+
+ Parentheses are used for grouping:
+   [(<rev> | <range>)...]
+   (Any number of either <rev> or <range>.  Parens are needed to make
+   it clear that "..." pertains to both <rev> and <range>.)
+
+   [(-p <parent>)...]
+   (Any number of option -p, each with one <parent> argument.)
+
+   git remote set-head <name> (-a | -d | <branch>)
+   (One and only one of "-a", "-d" or "<branch>" _must_ (no square
+   brackets) be provided.)
+
+ And a somewhat more contrived example:
+   --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+   Here "=" is outside the brackets, because "--diff-filter=" is a
+   valid usage.  "*" has its own pair of brackets, because it can
+   (optionally) be specified only when one or more of the letters is
+   also provided.
+
+  A note on notation:
+   Use 'git' (all lowercase) when talking about commands i.e. something
+   the user would type into a shell and use 'Git' (uppercase first letter)
+   when talking about the version control system and its properties.
+
+ A few commented examples follow to provide reference when writing or
+ modifying paragraphs or option/command explanations that contain options
+ or commands:
+
+ Literal examples (e.g. use of command-line options, command names,
+ branch names, URLs, pathnames (files and directories), configuration and
+ environment variables) must be typeset in monospace (i.e. wrapped with
+ backticks):
+   `--pretty=oneline`
+   `git rev-list`
+   `remote.pushDefault`
+   `http://git.example.com`
+   `.git/config`
+   `GIT_DIR`
+   `HEAD`
+
+ An environment variable must be prefixed with "$" only when referring to its
+ value and not when referring to the variable itself, in this case there is
+ nothing to add except the backticks:
+   `GIT_DIR` is specified
+   `$GIT_DIR/hooks/pre-receive`
+
+ Word phrases enclosed in `backtick characters` are rendered literally
+ and will not be further expanded. The use of `backticks` to achieve the
+ previous rule means that literal examples should not use AsciiDoc
+ escapes.
+   Correct:
+      `--pretty=oneline`
+   Incorrect:
+      `\--pretty=oneline`
+
+ If some place in the documentation needs to typeset a command usage
+ example with inline substitutions, it is fine to use +monospaced and
+ inline substituted text+ instead of `monospaced literal text`, and with
+ the former, the part that should not get substituted must be
+ quoted/escaped.
diff --git a/external/docs/asciidoc/7983213f3ace118da2fd286c613aba364e124b89 b/external/docs/asciidoc/7983213f3ace118da2fd286c613aba364e124b89
new file mode 100644
index 0000000000..c6e536f180
--- /dev/null
+++ b/external/docs/asciidoc/7983213f3ace118da2fd286c613aba364e124b89
@@ -0,0 +1,544 @@
+Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, a few rough rules are:
+
+ - Most importantly, we never say "It's in POSIX; we'll happily
+   ignore your needs should your system not conform to it."
+   We live in the real world.
+
+ - However, we often say "Let's stay away from that construct,
+   it's not even in POSIX".
+
+ - In spite of the above two rules, we sometimes say "Although
+   this is not in POSIX, it (is so convenient | makes the code
+   much more readable | has other good characteristics) and
+   practically all the platforms we care about support it, so
+   let's use it".
+
+   Again, we live in the real world, and it is sometimes a
+   judgement call, the decision based more on real world
+   constraints people face than what the paper standard says.
+
+ - Fixing style violations while working on a real change as a
+   preparatory clean-up step is good, but otherwise avoid useless code
+   churn for the sake of conforming to the style.
+
+   "Once it _is_ in the tree, it's not really worth the patch noise to
+   go and fix it up."
+   Cf. http://article.gmane.org/gmane.linux.kernel/943020
+
+Make your code readable and sensible, and don't try to be clever.
+
+As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the _local_
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn't match the overall style of existing code).
+
+But if you must have a list of rules, here they are.
+
+For shell scripts specifically (not exhaustive):
+
+ - We use tabs for indentation.
+
+ - Case arms are indented at the same depth as case and esac lines,
+   like this:
+
+	case "$variable" in
+	pattern1)
+		do this
+		;;
+	pattern2)
+		do that
+		;;
+	esac
+
+ - Redirection operators should be written with space before, but no
+   space after them.  In other words, write 'echo test >"$file"'
+   instead of 'echo test> $file' or 'echo test > $file'.  Note that
+   even though it is not required by POSIX to double-quote the
+   redirection target in a variable (as shown above), our code does so
+   because some versions of bash issue a warning without the quotes.
+
+	(incorrect)
+	cat hello > world < universe
+	echo hello >$world
+
+	(correct)
+	cat hello >world <universe
+	echo hello >"$world"
+
+ - We prefer $( ... ) for command substitution; unlike ``, it
+   properly nests.  It should have been the way Bourne spelled
+   it from day one, but unfortunately isn't.
+
+ - If you want to find out if a command is available on the user's
+   $PATH, you should use 'type <command>', instead of 'which <command>'.
+   The output of 'which' is not machine parseable and its exit code
+   is not reliable across platforms.
+
+ - We use POSIX compliant parameter substitutions and avoid bashisms;
+   namely:
+
+   - We use ${parameter-word} and its [-=?+] siblings, and their
+     colon'ed "unset or null" form.
+
+   - We use ${parameter#word} and its [#%] siblings, and their
+     doubled "longest matching" form.
+
+   - No "Substring Expansion" ${parameter:offset:length}.
+
+   - No shell arrays.
+
+   - No strlen ${#parameter}.
+
+   - No pattern replacement ${parameter/pattern/string}.
+
+ - We use Arithmetic Expansion $(( ... )).
+
+ - Inside Arithmetic Expansion, spell shell variables with $ in front
+   of them, as some shells do not grok $((x)) while accepting $(($x))
+   just fine (e.g. dash older than 0.5.4).
+
+ - We do not use Process Substitution <(list) or >(list).
+
+ - Do not write control structures on a single line with semicolon.
+   "then" should be on the next line for if statements, and "do"
+   should be on the next line for "while" and "for".
+
+	(incorrect)
+	if test -f hello; then
+		do this
+	fi
+
+	(correct)
+	if test -f hello
+	then
+		do this
+	fi
+
+ - We prefer "test" over "[ ... ]".
+
+ - We do not write the noiseword "function" in front of shell
+   functions.
+
+ - We prefer a space between the function name and the parentheses,
+   and no space inside the parentheses. The opening "{" should also
+   be on the same line.
+
+	(incorrect)
+	my_function(){
+		...
+
+	(correct)
+	my_function () {
+		...
+
+ - As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+   [::], [==], or [..]) for portability.
+
+   - We do not use \{m,n\};
+
+   - We do not use -E;
+
+   - We do not use ? or + (which are \{0,1\} and \{1,\}
+     respectively in BRE) but that goes without saying as these
+     are ERE elements not BRE (note that \? and \+ are not even part
+     of BRE -- making them accessible from BRE is a GNU extension).
+
+ - Use Git's gettext wrappers in git-sh-i18n to make the user
+   interface translatable. See "Marking strings for translation" in
+   po/README.
+
+ - We do not write our "test" command with "-a" and "-o" and use "&&"
+   or "||" to concatenate multiple "test" commands instead, because
+   the use of "-a/-o" is often error-prone.  E.g.
+
+     test -n "$x" -a "$a" = "$b"
+
+   is buggy and breaks when $x is "=", but
+
+     test -n "$x" && test "$a" = "$b"
+
+   does not have such a problem.
+
+
+For C programs:
+
+ - We use tabs to indent, and interpret tabs as taking up to
+   8 spaces.
+
+ - We try to keep to at most 80 characters per line.
+
+ - We try to support a wide range of C compilers to compile Git with,
+   including old ones. That means that you should not use C99
+   initializers, even if a lot of compilers grok it.
+
+ - Variables have to be declared at the beginning of the block.
+
+ - NULL pointers shall be written as NULL, not as 0.
+
+ - When declaring pointers, the star sides with the variable
+   name, i.e. "char *string", not "char* string" or
+   "char * string".  This makes it easier to understand code
+   like "char *string, c;".
+
+ - Use whitespace around operators and keywords, but not inside
+   parentheses and not around functions. So:
+
+        while (condition)
+		func(bar + 1);
+
+   and not:
+
+        while( condition )
+		func (bar+1);
+
+ - We avoid using braces unnecessarily.  I.e.
+
+	if (bla) {
+		x = 1;
+	}
+
+   is frowned upon.  A gray area is when the statement extends
+   over a few lines, and/or you have a lengthy comment atop of
+   it.  Also, like in the Linux kernel, if there is a long list
+   of "else if" statements, it can make sense to add braces to
+   single line blocks.
+
+ - We try to avoid assignments in the condition of an "if" statement.
+
+ - Try to make your code understandable.  You may put comments
+   in, but comments invariably tend to stale out when the code
+   they were describing changes.  Often splitting a function
+   into two makes the intention of the code much clearer.
+
+ - Multi-line comments include their delimiters on separate lines from
+   the text.  E.g.
+
+	/*
+	 * A very long
+	 * multi-line comment.
+	 */
+
+   Note however that a comment that explains a translatable string to
+   translators uses a convention of starting with a magic token
+   "TRANSLATORS: " immediately after the opening delimiter, even when
+   it spans multiple lines.  We do not add an asterisk at the beginning
+   of each line, either.  E.g.
+
+	/* TRANSLATORS: here is a comment that explains the string
+	   to be translated, that follows immediately after it */
+	_("Here is a translatable string explained by the above.");
+
+ - Double negation is often harder to understand than no negation
+   at all.
+
+ - There are two schools of thought when it comes to comparison,
+   especially inside a loop. Some people prefer to have the less stable
+   value on the left hand side and the more stable value on the right hand
+   side, e.g. if you have a loop that counts variable i down to the
+   lower bound,
+
+	while (i > lower_bound) {
+		do something;
+		i--;
+	}
+
+   Other people prefer to have the textual order of values match the
+   actual order of values in their comparison, so that they can
+   mentally draw a number line from left to right and place these
+   values in order, i.e.
+
+	while (lower_bound < i) {
+		do something;
+		i--;
+	}
+
+   Both are valid, and we use both.  However, the more "stable" the
+   stable side becomes, the more we tend to prefer the former
+   (comparison with a constant, "i > 0", is an extreme example).
+   Just do not mix styles in the same part of the code and mimic
+   existing styles in the neighbourhood.
+
+ - There are two schools of thought when it comes to splitting a long
+   logical line into multiple lines.  Some people push the second and
+   subsequent lines far enough to the right with tabs and align them:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+		span_more_than_a_single_line_of ||
+		the_source_text) {
+                ...
+
+   while other people prefer to align the second and the subsequent
+   lines with the column immediately inside the opening parenthesis,
+   with tabs and spaces, following our "tabstop is always a multiple
+   of 8" convention:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of ||
+	    the_source_text) {
+                ...
+
+   Both are valid, and we use both.  Again, just do not mix styles in
+   the same part of the code and mimic existing styles in the
+   neighbourhood.
+
+ - When splitting a long logical line, some people change line before
+   a binary operator, so that the result looks like a parse tree when
+   you turn your head 90-degrees counterclockwise:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to
+	    || span_more_than_a_single_line_of_the_source_text) {
+
+   while other people prefer to leave the operator at the end of the
+   line:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of_the_source_text) {
+
+   Both are valid, but we tend to use the latter more, unless the
+   expression gets fairly complex, in which case the former tends to
+   be easier to read.  Again, just do not mix styles in the same part
+   of the code and mimic existing styles in the neighbourhood.
+
+ - When splitting a long logical line, with everything else being
+   equal, it is preferable to split after the operator at higher
+   level in the parse tree.  That is, this is more preferable:
+
+	if (a_very_long_variable * that_is_used_in +
+	    a_very_long_expression) {
+		...
+
+   than
+
+	if (a_very_long_variable *
+	    that_is_used_in + a_very_long_expression) {
+		...
+
+ - Some clever tricks, like using the !! operator with arithmetic
+   constructs, can be extremely confusing to others.  Avoid them,
+   unless there is a compelling reason to use them.
+
+ - Use the API.  No, really.  We have a strbuf (variable length
+   string), several arrays with the ALLOC_GROW() macro, a
+   string_list for sorted string lists, a hash map (mapping struct
+   objects) named "struct decorate", amongst other things.
+
+ - When you come up with an API, document it.
+
+ - The first #include in C files, except in platform specific compat/
+   implementations, must be either "git-compat-util.h", "cache.h" or
+   "builtin.h".  You do not have to include more than one of these.
+
+ - A C file must directly include the header files that declare the
+   functions and the types it uses, except for the functions and types
+   that are made available to it by including one of the header files
+   it must include by the previous rule.
+
+ - If you are planning a new command, consider writing it in shell
+   or perl first, so that changes in semantics can be easily
+   changed and discussed.  Many Git commands started out like
+   that, and a few are still scripts.
+
+ - Avoid introducing a new dependency into Git. This means you
+   usually should stay away from scripting languages not already
+   used in the Git core command set (unless your command is clearly
+   separate from it, such as an importer to convert random-scm-X
+   repositories to Git).
+
+ - When we pass <string, length> pair to functions, we should try to
+   pass them in that order.
+
+ - Use Git's gettext wrappers to make the user interface
+   translatable. See "Marking strings for translation" in po/README.
+
+For Perl programs:
+
+ - Most of the C guidelines above apply.
+
+ - We try to support Perl 5.8 and later ("use Perl 5.008").
+
+ - use strict and use warnings are strongly preferred.
+
+ - Don't overuse statement modifiers unless using them makes the
+   result easier to follow.
+
+	... do something ...
+	do_this() unless (condition);
+        ... do something else ...
+
+   is more readable than:
+
+	... do something ...
+	unless (condition) {
+		do_this();
+	}
+        ... do something else ...
+
+   *only* when the condition is so rare that do_this() will be almost
+   always called.
+
+ - We try to avoid assignments inside "if ()" conditions.
+
+ - Learn and use Git.pm if you need that functionality.
+
+ - For Emacs, it's useful to put the following in
+   GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode:
+
+    ;; note the first part is useful for C editing, too
+    ((nil . ((indent-tabs-mode . t)
+                  (tab-width . 8)
+                  (fill-column . 80)))
+     (cperl-mode . ((cperl-indent-level . 8)
+                    (cperl-extra-newline-before-brace . nil)
+                    (cperl-merge-trailing-else . t))))
+
+For Python scripts:
+
+ - We follow PEP-8 (http://www.python.org/dev/peps/pep-0008/).
+
+ - As a minimum, we aim to be compatible with Python 2.6 and 2.7.
+
+ - Where required libraries do not restrict us to Python 2, we try to
+   also be compatible with Python 3.1 and later.
+
+ - When you must differentiate between Unicode literals and byte string
+   literals, it is OK to use the 'b' prefix.  Even though the Python
+   documentation for version 2.6 does not mention this prefix, it has
+   been supported since version 2.6.0.
+
+Error Messages
+
+ - Do not end error messages with a full stop.
+
+ - Do not capitalize ("unable to open %s", not "Unable to open %s")
+
+ - Say what the error is first ("cannot open %s", not "%s: cannot open")
+
+
+Externally Visible Names
+
+ - For configuration variable names, follow the existing convention:
+
+   . The section name indicates the affected subsystem.
+
+   . The subsection name, if any, indicates which of an unbounded set
+     of things to set the value for.
+
+   . The variable name describes the effect of tweaking this knob.
+
+   The section and variable names that consist of multiple words are
+   formed by concatenating the words without punctuations (e.g. `-`),
+   and are broken using bumpyCaps in documentation as a hint to the
+   reader.
+
+   When choosing the variable namespace, do not use variable name for
+   specifying possibly unbounded set of things, most notably anything
+   an end user can freely come up with (e.g. branch names).  Instead,
+   use subsection names or variable values, like the existing variable
+   branch.<name>.description does.
+
+
+Writing Documentation:
+
+ Most (if not all) of the documentation pages are written in the
+ AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+ processed into HTML and manpages (e.g. git.html and git.1 in the
+ same directory).
+
+ The documentation liberally mixes US and UK English (en_US/UK)
+ norms for spelling and grammar, which is somewhat unfortunate.
+ In an ideal world, it would have been better if it consistently
+ used only one and not the other, and we would have picked en_US
+ (if you wish to correct the English of some of the existing
+ documentation, please see the documentation-related advice in the
+ Documentation/SubmittingPatches file).
+
+ Every user-visible change should be reflected in the documentation.
+ The same general rule as for code applies -- imitate the existing
+ conventions.
+
+ A few commented examples follow to provide reference when writing or
+ modifying command usage strings and synopsis sections in the manual
+ pages:
+
+ Placeholders are spelled in lowercase and enclosed in angle brackets:
+   <file>
+   --sort=<key>
+   --abbrev[=<n>]
+
+ If a placeholder has multiple words, they are separated by dashes:
+   <new-branch-name>
+   --template=<template-directory>
+
+ Possibility of multiple occurrences is indicated by three dots:
+   <file>...
+   (One or more of <file>.)
+
+ Optional parts are enclosed in square brackets:
+   [<extra>]
+   (Zero or one <extra>.)
+
+   --exec-path[=<path>]
+   (Option with an optional argument.  Note that the "=" is inside the
+   brackets.)
+
+   [<patch>...]
+   (Zero or more of <patch>.  Note that the dots are inside, not
+   outside the brackets.)
+
+ Multiple alternatives are indicated with vertical bars:
+   [-q | --quiet]
+   [--utf8 | --no-utf8]
+
+ Parentheses are used for grouping:
+   [(<rev> | <range>)...]
+   (Any number of either <rev> or <range>.  Parens are needed to make
+   it clear that "..." pertains to both <rev> and <range>.)
+
+   [(-p <parent>)...]
+   (Any number of option -p, each with one <parent> argument.)
+
+   git remote set-head <name> (-a | -d | <branch>)
+   (One and only one of "-a", "-d" or "<branch>" _must_ (no square
+   brackets) be provided.)
+
+ And a somewhat more contrived example:
+   --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+   Here "=" is outside the brackets, because "--diff-filter=" is a
+   valid usage.  "*" has its own pair of brackets, because it can
+   (optionally) be specified only when one or more of the letters is
+   also provided.
+
+  A note on notation:
+   Use 'git' (all lowercase) when talking about commands i.e. something
+   the user would type into a shell and use 'Git' (uppercase first letter)
+   when talking about the version control system and its properties.
+
+ A few commented examples follow to provide reference when writing or
+ modifying paragraphs or option/command explanations that contain options
+ or commands:
+
+ Literal examples (e.g. use of command-line options, command names, and
+ configuration variables) are typeset in monospace, and if you can use
+ `backticks around word phrases`, do so.
+   `--pretty=oneline`
+   `git rev-list`
+   `remote.pushDefault`
+
+ Word phrases enclosed in `backtick characters` are rendered literally
+ and will not be further expanded. The use of `backticks` to achieve the
+ previous rule means that literal examples should not use AsciiDoc
+ escapes.
+   Correct:
+      `--pretty=oneline`
+   Incorrect:
+      `\--pretty=oneline`
+
+ If some place in the documentation needs to typeset a command usage
+ example with inline substitutions, it is fine to use +monospaced and
+ inline substituted text+ instead of `monospaced literal text`, and with
+ the former, the part that should not get substituted must be
+ quoted/escaped.
diff --git a/external/docs/asciidoc/8496395b740ea161bc89ea066db49eb95e228c26 b/external/docs/asciidoc/8496395b740ea161bc89ea066db49eb95e228c26
new file mode 100644
index 0000000000..e3af089ecf
--- /dev/null
+++ b/external/docs/asciidoc/8496395b740ea161bc89ea066db49eb95e228c26
@@ -0,0 +1,650 @@
+Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, a few rough rules are:
+
+ - Most importantly, we never say "It's in POSIX; we'll happily
+   ignore your needs should your system not conform to it."
+   We live in the real world.
+
+ - However, we often say "Let's stay away from that construct,
+   it's not even in POSIX".
+
+ - In spite of the above two rules, we sometimes say "Although
+   this is not in POSIX, it (is so convenient | makes the code
+   much more readable | has other good characteristics) and
+   practically all the platforms we care about support it, so
+   let's use it".
+
+   Again, we live in the real world, and it is sometimes a
+   judgement call, the decision based more on real world
+   constraints people face than what the paper standard says.
+
+ - Fixing style violations while working on a real change as a
+   preparatory clean-up step is good, but otherwise avoid useless code
+   churn for the sake of conforming to the style.
+
+   "Once it _is_ in the tree, it's not really worth the patch noise to
+   go and fix it up."
+   Cf. http://lkml.iu.edu/hypermail/linux/kernel/1001.3/01069.html
+
+Make your code readable and sensible, and don't try to be clever.
+
+As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the _local_
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn't match the overall style of existing code).
+
+But if you must have a list of rules, here they are.
+
+For shell scripts specifically (not exhaustive):
+
+ - We use tabs for indentation.
+
+ - Case arms are indented at the same depth as case and esac lines,
+   like this:
+
+	case "$variable" in
+	pattern1)
+		do this
+		;;
+	pattern2)
+		do that
+		;;
+	esac
+
+ - Redirection operators should be written with space before, but no
+   space after them.  In other words, write 'echo test >"$file"'
+   instead of 'echo test> $file' or 'echo test > $file'.  Note that
+   even though it is not required by POSIX to double-quote the
+   redirection target in a variable (as shown above), our code does so
+   because some versions of bash issue a warning without the quotes.
+
+	(incorrect)
+	cat hello > world < universe
+	echo hello >$world
+
+	(correct)
+	cat hello >world <universe
+	echo hello >"$world"
+
+ - We prefer $( ... ) for command substitution; unlike ``, it
+   properly nests.  It should have been the way Bourne spelled
+   it from day one, but unfortunately isn't.
+
+ - If you want to find out if a command is available on the user's
+   $PATH, you should use 'type <command>', instead of 'which <command>'.
+   The output of 'which' is not machine parsable and its exit code
+   is not reliable across platforms.
+
+ - We use POSIX compliant parameter substitutions and avoid bashisms;
+   namely:
+
+   - We use ${parameter-word} and its [-=?+] siblings, and their
+     colon'ed "unset or null" form.
+
+   - We use ${parameter#word} and its [#%] siblings, and their
+     doubled "longest matching" form.
+
+   - No "Substring Expansion" ${parameter:offset:length}.
+
+   - No shell arrays.
+
+   - No pattern replacement ${parameter/pattern/string}.
+
+ - We use Arithmetic Expansion $(( ... )).
+
+ - We do not use Process Substitution <(list) or >(list).
+
+ - Do not write control structures on a single line with semicolon.
+   "then" should be on the next line for if statements, and "do"
+   should be on the next line for "while" and "for".
+
+	(incorrect)
+	if test -f hello; then
+		do this
+	fi
+
+	(correct)
+	if test -f hello
+	then
+		do this
+	fi
+
+ - If a command sequence joined with && or || or | spans multiple
+   lines, put each command on a separate line and put && and || and |
+   operators at the end of each line, rather than the start. This
+   means you don't need to use \ to join lines, since the above
+   operators imply the sequence isn't finished.
+
+	(incorrect)
+	grep blob verify_pack_result \
+	| awk -f print_1.awk \
+	| sort >actual &&
+	...
+
+	(correct)
+	grep blob verify_pack_result |
+	awk -f print_1.awk |
+	sort >actual &&
+	...
+
+ - We prefer "test" over "[ ... ]".
+
+ - We do not write the noiseword "function" in front of shell
+   functions.
+
+ - We prefer a space between the function name and the parentheses,
+   and no space inside the parentheses. The opening "{" should also
+   be on the same line.
+
+	(incorrect)
+	my_function(){
+		...
+
+	(correct)
+	my_function () {
+		...
+
+ - As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+   [::], [==], or [..]) for portability.
+
+   - We do not use \{m,n\};
+
+   - We do not use -E;
+
+   - We do not use ? or + (which are \{0,1\} and \{1,\}
+     respectively in BRE) but that goes without saying as these
+     are ERE elements not BRE (note that \? and \+ are not even part
+     of BRE -- making them accessible from BRE is a GNU extension).
+
+ - Use Git's gettext wrappers in git-sh-i18n to make the user
+   interface translatable. See "Marking strings for translation" in
+   po/README.
+
+ - We do not write our "test" command with "-a" and "-o" and use "&&"
+   or "||" to concatenate multiple "test" commands instead, because
+   the use of "-a/-o" is often error-prone.  E.g.
+
+     test -n "$x" -a "$a" = "$b"
+
+   is buggy and breaks when $x is "=", but
+
+     test -n "$x" && test "$a" = "$b"
+
+   does not have such a problem.
+
+ - Even though "local" is not part of POSIX, we make heavy use of it
+   in our test suite.  We do not use it in scripted Porcelains, and
+   hopefully nobody starts using "local" before they are reimplemented
+   in C ;-)
+
+
+For C programs:
+
+ - We use tabs to indent, and interpret tabs as taking up to
+   8 spaces.
+
+ - We try to keep to at most 80 characters per line.
+
+ - As a Git developer we assume you have a reasonably modern compiler
+   and we recommend you to enable the DEVELOPER makefile knob to
+   ensure your patch is clear of all compiler warnings we care about,
+   by e.g. "echo DEVELOPER=1 >>config.mak".
+
+ - We try to support a wide range of C compilers to compile Git with,
+   including old ones.  You should not use features from newer C
+   standard, even if your compiler groks them.
+
+   There are a few exceptions to this guideline:
+
+   . since early 2012 with e1327023ea, we have been using an enum
+     definition whose last element is followed by a comma.  This, like
+     an array initializer that ends with a trailing comma, can be used
+     to reduce the patch noise when adding a new identifier at the end.
+
+   . since mid 2017 with cbc0f81d, we have been using designated
+     initializers for struct (e.g. "struct t v = { .val = 'a' };").
+
+   . since mid 2017 with 512f41cf, we have been using designated
+     initializers for array (e.g. "int array[10] = { [5] = 2 }").
+
+   These used to be forbidden, but we have not heard any breakage
+   report, and they are assumed to be safe.
+
+ - Variables have to be declared at the beginning of the block, before
+   the first statement (i.e. -Wdeclaration-after-statement).
+
+ - Declaring a variable in the for loop "for (int i = 0; i < 10; i++)"
+   is still not allowed in this codebase.
+
+ - NULL pointers shall be written as NULL, not as 0.
+
+ - When declaring pointers, the star sides with the variable
+   name, i.e. "char *string", not "char* string" or
+   "char * string".  This makes it easier to understand code
+   like "char *string, c;".
+
+ - Use whitespace around operators and keywords, but not inside
+   parentheses and not around functions. So:
+
+        while (condition)
+		func(bar + 1);
+
+   and not:
+
+        while( condition )
+		func (bar+1);
+
+ - Do not explicitly compare an integral value with constant 0 or '\0',
+   or a pointer value with constant NULL.  For instance, to validate that
+   counted array <ptr, cnt> is initialized but has no elements, write:
+
+	if (!ptr || cnt)
+		BUG("empty array expected");
+
+   and not:
+
+	if (ptr == NULL || cnt != 0);
+		BUG("empty array expected");
+
+ - We avoid using braces unnecessarily.  I.e.
+
+	if (bla) {
+		x = 1;
+	}
+
+   is frowned upon. But there are a few exceptions:
+
+	- When the statement extends over a few lines (e.g., a while loop
+	  with an embedded conditional, or a comment). E.g.:
+
+		while (foo) {
+			if (x)
+				one();
+			else
+				two();
+		}
+
+		if (foo) {
+			/*
+			 * This one requires some explanation,
+			 * so we're better off with braces to make
+			 * it obvious that the indentation is correct.
+			 */
+			doit();
+		}
+
+	- When there are multiple arms to a conditional and some of them
+	  require braces, enclose even a single line block in braces for
+	  consistency. E.g.:
+
+		if (foo) {
+			doit();
+		} else {
+			one();
+			two();
+			three();
+		}
+
+ - We try to avoid assignments in the condition of an "if" statement.
+
+ - Try to make your code understandable.  You may put comments
+   in, but comments invariably tend to stale out when the code
+   they were describing changes.  Often splitting a function
+   into two makes the intention of the code much clearer.
+
+ - Multi-line comments include their delimiters on separate lines from
+   the text.  E.g.
+
+	/*
+	 * A very long
+	 * multi-line comment.
+	 */
+
+   Note however that a comment that explains a translatable string to
+   translators uses a convention of starting with a magic token
+   "TRANSLATORS: ", e.g.
+
+	/*
+	 * TRANSLATORS: here is a comment that explains the string to
+	 * be translated, that follows immediately after it.
+	 */
+	_("Here is a translatable string explained by the above.");
+
+ - Double negation is often harder to understand than no negation
+   at all.
+
+ - There are two schools of thought when it comes to comparison,
+   especially inside a loop. Some people prefer to have the less stable
+   value on the left hand side and the more stable value on the right hand
+   side, e.g. if you have a loop that counts variable i down to the
+   lower bound,
+
+	while (i > lower_bound) {
+		do something;
+		i--;
+	}
+
+   Other people prefer to have the textual order of values match the
+   actual order of values in their comparison, so that they can
+   mentally draw a number line from left to right and place these
+   values in order, i.e.
+
+	while (lower_bound < i) {
+		do something;
+		i--;
+	}
+
+   Both are valid, and we use both.  However, the more "stable" the
+   stable side becomes, the more we tend to prefer the former
+   (comparison with a constant, "i > 0", is an extreme example).
+   Just do not mix styles in the same part of the code and mimic
+   existing styles in the neighbourhood.
+
+ - There are two schools of thought when it comes to splitting a long
+   logical line into multiple lines.  Some people push the second and
+   subsequent lines far enough to the right with tabs and align them:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+		span_more_than_a_single_line_of ||
+		the_source_text) {
+                ...
+
+   while other people prefer to align the second and the subsequent
+   lines with the column immediately inside the opening parenthesis,
+   with tabs and spaces, following our "tabstop is always a multiple
+   of 8" convention:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of ||
+	    the_source_text) {
+                ...
+
+   Both are valid, and we use both.  Again, just do not mix styles in
+   the same part of the code and mimic existing styles in the
+   neighbourhood.
+
+ - When splitting a long logical line, some people change line before
+   a binary operator, so that the result looks like a parse tree when
+   you turn your head 90-degrees counterclockwise:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to
+	    || span_more_than_a_single_line_of_the_source_text) {
+
+   while other people prefer to leave the operator at the end of the
+   line:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of_the_source_text) {
+
+   Both are valid, but we tend to use the latter more, unless the
+   expression gets fairly complex, in which case the former tends to
+   be easier to read.  Again, just do not mix styles in the same part
+   of the code and mimic existing styles in the neighbourhood.
+
+ - When splitting a long logical line, with everything else being
+   equal, it is preferable to split after the operator at higher
+   level in the parse tree.  That is, this is more preferable:
+
+	if (a_very_long_variable * that_is_used_in +
+	    a_very_long_expression) {
+		...
+
+   than
+
+	if (a_very_long_variable *
+	    that_is_used_in + a_very_long_expression) {
+		...
+
+ - Some clever tricks, like using the !! operator with arithmetic
+   constructs, can be extremely confusing to others.  Avoid them,
+   unless there is a compelling reason to use them.
+
+ - Use the API.  No, really.  We have a strbuf (variable length
+   string), several arrays with the ALLOC_GROW() macro, a
+   string_list for sorted string lists, a hash map (mapping struct
+   objects) named "struct decorate", amongst other things.
+
+ - When you come up with an API, document its functions and structures
+   in the header file that exposes the API to its callers. Use what is
+   in "strbuf.h" as a model for the appropriate tone and level of
+   detail.
+
+ - The first #include in C files, except in platform specific compat/
+   implementations, must be either "git-compat-util.h", "cache.h" or
+   "builtin.h".  You do not have to include more than one of these.
+
+ - A C file must directly include the header files that declare the
+   functions and the types it uses, except for the functions and types
+   that are made available to it by including one of the header files
+   it must include by the previous rule.
+
+ - If you are planning a new command, consider writing it in shell
+   or perl first, so that changes in semantics can be easily
+   changed and discussed.  Many Git commands started out like
+   that, and a few are still scripts.
+
+ - Avoid introducing a new dependency into Git. This means you
+   usually should stay away from scripting languages not already
+   used in the Git core command set (unless your command is clearly
+   separate from it, such as an importer to convert random-scm-X
+   repositories to Git).
+
+ - When we pass <string, length> pair to functions, we should try to
+   pass them in that order.
+
+ - Use Git's gettext wrappers to make the user interface
+   translatable. See "Marking strings for translation" in po/README.
+
+ - Variables and functions local to a given source file should be marked
+   with "static". Variables that are visible to other source files
+   must be declared with "extern" in header files. However, function
+   declarations should not use "extern", as that is already the default.
+
+ - You can launch gdb around your program using the shorthand GIT_DEBUGGER.
+   Run `GIT_DEBUGGER=1 ./bin-wrappers/git foo` to simply use gdb as is, or
+   run `GIT_DEBUGGER="<debugger> <debugger-args>" ./bin-wrappers/git foo` to
+   use your own debugger and arguments. Example: `GIT_DEBUGGER="ddd --gdb"
+   ./bin-wrappers/git log` (See `wrap-for-bin.sh`.)
+
+For Perl programs:
+
+ - Most of the C guidelines above apply.
+
+ - We try to support Perl 5.8 and later ("use Perl 5.008").
+
+ - use strict and use warnings are strongly preferred.
+
+ - Don't overuse statement modifiers unless using them makes the
+   result easier to follow.
+
+	... do something ...
+	do_this() unless (condition);
+        ... do something else ...
+
+   is more readable than:
+
+	... do something ...
+	unless (condition) {
+		do_this();
+	}
+        ... do something else ...
+
+   *only* when the condition is so rare that do_this() will be almost
+   always called.
+
+ - We try to avoid assignments inside "if ()" conditions.
+
+ - Learn and use Git.pm if you need that functionality.
+
+ - For Emacs, it's useful to put the following in
+   GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode:
+
+    ;; note the first part is useful for C editing, too
+    ((nil . ((indent-tabs-mode . t)
+                  (tab-width . 8)
+                  (fill-column . 80)))
+     (cperl-mode . ((cperl-indent-level . 8)
+                    (cperl-extra-newline-before-brace . nil)
+                    (cperl-merge-trailing-else . t))))
+
+For Python scripts:
+
+ - We follow PEP-8 (http://www.python.org/dev/peps/pep-0008/).
+
+ - As a minimum, we aim to be compatible with Python 2.7.
+
+ - Where required libraries do not restrict us to Python 2, we try to
+   also be compatible with Python 3.1 and later.
+
+Error Messages
+
+ - Do not end error messages with a full stop.
+
+ - Do not capitalize the first word, only because it is the first word
+   in the message ("unable to open %s", not "Unable to open %s").  But
+   "SHA-3 not supported" is fine, because the reason the first word is
+   capitalized is not because it is at the beginning of the sentence,
+   but because the word would be spelled in capital letters even when
+   it appeared in the middle of the sentence.
+
+ - Say what the error is first ("cannot open %s", not "%s: cannot open")
+
+
+Externally Visible Names
+
+ - For configuration variable names, follow the existing convention:
+
+   . The section name indicates the affected subsystem.
+
+   . The subsection name, if any, indicates which of an unbounded set
+     of things to set the value for.
+
+   . The variable name describes the effect of tweaking this knob.
+
+   The section and variable names that consist of multiple words are
+   formed by concatenating the words without punctuations (e.g. `-`),
+   and are broken using bumpyCaps in documentation as a hint to the
+   reader.
+
+   When choosing the variable namespace, do not use variable name for
+   specifying possibly unbounded set of things, most notably anything
+   an end user can freely come up with (e.g. branch names).  Instead,
+   use subsection names or variable values, like the existing variable
+   branch.<name>.description does.
+
+
+Writing Documentation:
+
+ Most (if not all) of the documentation pages are written in the
+ AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+ processed into HTML and manpages (e.g. git.html and git.1 in the
+ same directory).
+
+ The documentation liberally mixes US and UK English (en_US/UK)
+ norms for spelling and grammar, which is somewhat unfortunate.
+ In an ideal world, it would have been better if it consistently
+ used only one and not the other, and we would have picked en_US
+ (if you wish to correct the English of some of the existing
+ documentation, please see the documentation-related advice in the
+ Documentation/SubmittingPatches file).
+
+ Every user-visible change should be reflected in the documentation.
+ The same general rule as for code applies -- imitate the existing
+ conventions.
+
+ A few commented examples follow to provide reference when writing or
+ modifying command usage strings and synopsis sections in the manual
+ pages:
+
+ Placeholders are spelled in lowercase and enclosed in angle brackets:
+   <file>
+   --sort=<key>
+   --abbrev[=<n>]
+
+ If a placeholder has multiple words, they are separated by dashes:
+   <new-branch-name>
+   --template=<template-directory>
+
+ Possibility of multiple occurrences is indicated by three dots:
+   <file>...
+   (One or more of <file>.)
+
+ Optional parts are enclosed in square brackets:
+   [<extra>]
+   (Zero or one <extra>.)
+
+   --exec-path[=<path>]
+   (Option with an optional argument.  Note that the "=" is inside the
+   brackets.)
+
+   [<patch>...]
+   (Zero or more of <patch>.  Note that the dots are inside, not
+   outside the brackets.)
+
+ Multiple alternatives are indicated with vertical bars:
+   [-q | --quiet]
+   [--utf8 | --no-utf8]
+
+ Parentheses are used for grouping:
+   [(<rev> | <range>)...]
+   (Any number of either <rev> or <range>.  Parens are needed to make
+   it clear that "..." pertains to both <rev> and <range>.)
+
+   [(-p <parent>)...]
+   (Any number of option -p, each with one <parent> argument.)
+
+   git remote set-head <name> (-a | -d | <branch>)
+   (One and only one of "-a", "-d" or "<branch>" _must_ (no square
+   brackets) be provided.)
+
+ And a somewhat more contrived example:
+   --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+   Here "=" is outside the brackets, because "--diff-filter=" is a
+   valid usage.  "*" has its own pair of brackets, because it can
+   (optionally) be specified only when one or more of the letters is
+   also provided.
+
+  A note on notation:
+   Use 'git' (all lowercase) when talking about commands i.e. something
+   the user would type into a shell and use 'Git' (uppercase first letter)
+   when talking about the version control system and its properties.
+
+ A few commented examples follow to provide reference when writing or
+ modifying paragraphs or option/command explanations that contain options
+ or commands:
+
+ Literal examples (e.g. use of command-line options, command names,
+ branch names, URLs, pathnames (files and directories), configuration and
+ environment variables) must be typeset in monospace (i.e. wrapped with
+ backticks):
+   `--pretty=oneline`
+   `git rev-list`
+   `remote.pushDefault`
+   `http://git.example.com`
+   `.git/config`
+   `GIT_DIR`
+   `HEAD`
+
+ An environment variable must be prefixed with "$" only when referring to its
+ value and not when referring to the variable itself, in this case there is
+ nothing to add except the backticks:
+   `GIT_DIR` is specified
+   `$GIT_DIR/hooks/pre-receive`
+
+ Word phrases enclosed in `backtick characters` are rendered literally
+ and will not be further expanded. The use of `backticks` to achieve the
+ previous rule means that literal examples should not use AsciiDoc
+ escapes.
+   Correct:
+      `--pretty=oneline`
+   Incorrect:
+      `\--pretty=oneline`
+
+ If some place in the documentation needs to typeset a command usage
+ example with inline substitutions, it is fine to use +monospaced and
+ inline substituted text+ instead of `monospaced literal text`, and with
+ the former, the part that should not get substituted must be
+ quoted/escaped.
diff --git a/external/docs/asciidoc/8567155f3e546b061f4a64aee252b80ab3e27e2a b/external/docs/asciidoc/8567155f3e546b061f4a64aee252b80ab3e27e2a
new file mode 100644
index 0000000000..0e27b5395d
--- /dev/null
+++ b/external/docs/asciidoc/8567155f3e546b061f4a64aee252b80ab3e27e2a
@@ -0,0 +1,722 @@
+Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, a few rough rules are:
+
+ - Most importantly, we never say "It's in POSIX; we'll happily
+   ignore your needs should your system not conform to it."
+   We live in the real world.
+
+ - However, we often say "Let's stay away from that construct,
+   it's not even in POSIX".
+
+ - In spite of the above two rules, we sometimes say "Although
+   this is not in POSIX, it (is so convenient | makes the code
+   much more readable | has other good characteristics) and
+   practically all the platforms we care about support it, so
+   let's use it".
+
+   Again, we live in the real world, and it is sometimes a
+   judgement call, the decision based more on real world
+   constraints people face than what the paper standard says.
+
+ - Fixing style violations while working on a real change as a
+   preparatory clean-up step is good, but otherwise avoid useless code
+   churn for the sake of conforming to the style.
+
+   "Once it _is_ in the tree, it's not really worth the patch noise to
+   go and fix it up."
+   Cf. http://lkml.iu.edu/hypermail/linux/kernel/1001.3/01069.html
+
+Make your code readable and sensible, and don't try to be clever.
+
+As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the _local_
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn't match the overall style of existing code).
+
+But if you must have a list of rules, here they are.
+
+For shell scripts specifically (not exhaustive):
+
+ - We use tabs for indentation.
+
+ - Case arms are indented at the same depth as case and esac lines,
+   like this:
+
+	case "$variable" in
+	pattern1)
+		do this
+		;;
+	pattern2)
+		do that
+		;;
+	esac
+
+ - Redirection operators should be written with space before, but no
+   space after them.  In other words, write 'echo test >"$file"'
+   instead of 'echo test> $file' or 'echo test > $file'.  Note that
+   even though it is not required by POSIX to double-quote the
+   redirection target in a variable (as shown above), our code does so
+   because some versions of bash issue a warning without the quotes.
+
+	(incorrect)
+	cat hello > world < universe
+	echo hello >$world
+
+	(correct)
+	cat hello >world <universe
+	echo hello >"$world"
+
+ - We prefer $( ... ) for command substitution; unlike ``, it
+   properly nests.  It should have been the way Bourne spelled
+   it from day one, but unfortunately isn't.
+
+ - If you want to find out if a command is available on the user's
+   $PATH, you should use 'type <command>', instead of 'which <command>'.
+   The output of 'which' is not machine parsable and its exit code
+   is not reliable across platforms.
+
+ - We use POSIX compliant parameter substitutions and avoid bashisms;
+   namely:
+
+   - We use ${parameter-word} and its [-=?+] siblings, and their
+     colon'ed "unset or null" form.
+
+   - We use ${parameter#word} and its [#%] siblings, and their
+     doubled "longest matching" form.
+
+   - No "Substring Expansion" ${parameter:offset:length}.
+
+   - No shell arrays.
+
+   - No pattern replacement ${parameter/pattern/string}.
+
+ - We use Arithmetic Expansion $(( ... )).
+
+ - We do not use Process Substitution <(list) or >(list).
+
+ - Do not write control structures on a single line with semicolon.
+   "then" should be on the next line for if statements, and "do"
+   should be on the next line for "while" and "for".
+
+	(incorrect)
+	if test -f hello; then
+		do this
+	fi
+
+	(correct)
+	if test -f hello
+	then
+		do this
+	fi
+
+ - If a command sequence joined with && or || or | spans multiple
+   lines, put each command on a separate line and put && and || and |
+   operators at the end of each line, rather than the start. This
+   means you don't need to use \ to join lines, since the above
+   operators imply the sequence isn't finished.
+
+	(incorrect)
+	grep blob verify_pack_result \
+	| awk -f print_1.awk \
+	| sort >actual &&
+	...
+
+	(correct)
+	grep blob verify_pack_result |
+	awk -f print_1.awk |
+	sort >actual &&
+	...
+
+ - We prefer "test" over "[ ... ]".
+
+ - We do not write the noiseword "function" in front of shell
+   functions.
+
+ - We prefer a space between the function name and the parentheses,
+   and no space inside the parentheses. The opening "{" should also
+   be on the same line.
+
+	(incorrect)
+	my_function(){
+		...
+
+	(correct)
+	my_function () {
+		...
+
+ - As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+   [::], [==], or [..]) for portability.
+
+   - We do not use \{m,n\};
+
+   - We do not use -E;
+
+   - We do not use ? or + (which are \{0,1\} and \{1,\}
+     respectively in BRE) but that goes without saying as these
+     are ERE elements not BRE (note that \? and \+ are not even part
+     of BRE -- making them accessible from BRE is a GNU extension).
+
+ - Use Git's gettext wrappers in git-sh-i18n to make the user
+   interface translatable. See "Marking strings for translation" in
+   po/README.
+
+ - We do not write our "test" command with "-a" and "-o" and use "&&"
+   or "||" to concatenate multiple "test" commands instead, because
+   the use of "-a/-o" is often error-prone.  E.g.
+
+     test -n "$x" -a "$a" = "$b"
+
+   is buggy and breaks when $x is "=", but
+
+     test -n "$x" && test "$a" = "$b"
+
+   does not have such a problem.
+
+ - Even though "local" is not part of POSIX, we make heavy use of it
+   in our test suite.  We do not use it in scripted Porcelains, and
+   hopefully nobody starts using "local" before they are reimplemented
+   in C ;-)
+
+
+For C programs:
+
+ - We use tabs to indent, and interpret tabs as taking up to
+   8 spaces.
+
+ - We try to keep to at most 80 characters per line.
+
+ - As a Git developer we assume you have a reasonably modern compiler
+   and we recommend you to enable the DEVELOPER makefile knob to
+   ensure your patch is clear of all compiler warnings we care about,
+   by e.g. "echo DEVELOPER=1 >>config.mak".
+
+ - We try to support a wide range of C compilers to compile Git with,
+   including old ones.  You should not use features from newer C
+   standard, even if your compiler groks them.
+
+   There are a few exceptions to this guideline:
+
+   . since early 2012 with e1327023ea, we have been using an enum
+     definition whose last element is followed by a comma.  This, like
+     an array initializer that ends with a trailing comma, can be used
+     to reduce the patch noise when adding a new identifier at the end.
+
+   . since mid 2017 with cbc0f81d, we have been using designated
+     initializers for struct (e.g. "struct t v = { .val = 'a' };").
+
+   . since mid 2017 with 512f41cf, we have been using designated
+     initializers for array (e.g. "int array[10] = { [5] = 2 }").
+
+   These used to be forbidden, but we have not heard any breakage
+   report, and they are assumed to be safe.
+
+ - Variables have to be declared at the beginning of the block, before
+   the first statement (i.e. -Wdeclaration-after-statement).
+
+ - Declaring a variable in the for loop "for (int i = 0; i < 10; i++)"
+   is still not allowed in this codebase.
+
+ - NULL pointers shall be written as NULL, not as 0.
+
+ - When declaring pointers, the star sides with the variable
+   name, i.e. "char *string", not "char* string" or
+   "char * string".  This makes it easier to understand code
+   like "char *string, c;".
+
+ - Use whitespace around operators and keywords, but not inside
+   parentheses and not around functions. So:
+
+        while (condition)
+		func(bar + 1);
+
+   and not:
+
+        while( condition )
+		func (bar+1);
+
+ - Do not explicitly compare an integral value with constant 0 or '\0',
+   or a pointer value with constant NULL.  For instance, to validate that
+   counted array <ptr, cnt> is initialized but has no elements, write:
+
+	if (!ptr || cnt)
+		BUG("empty array expected");
+
+   and not:
+
+	if (ptr == NULL || cnt != 0);
+		BUG("empty array expected");
+
+ - We avoid using braces unnecessarily.  I.e.
+
+	if (bla) {
+		x = 1;
+	}
+
+   is frowned upon. But there are a few exceptions:
+
+	- When the statement extends over a few lines (e.g., a while loop
+	  with an embedded conditional, or a comment). E.g.:
+
+		while (foo) {
+			if (x)
+				one();
+			else
+				two();
+		}
+
+		if (foo) {
+			/*
+			 * This one requires some explanation,
+			 * so we're better off with braces to make
+			 * it obvious that the indentation is correct.
+			 */
+			doit();
+		}
+
+	- When there are multiple arms to a conditional and some of them
+	  require braces, enclose even a single line block in braces for
+	  consistency. E.g.:
+
+		if (foo) {
+			doit();
+		} else {
+			one();
+			two();
+			three();
+		}
+
+ - We try to avoid assignments in the condition of an "if" statement.
+
+ - Try to make your code understandable.  You may put comments
+   in, but comments invariably tend to stale out when the code
+   they were describing changes.  Often splitting a function
+   into two makes the intention of the code much clearer.
+
+ - Multi-line comments include their delimiters on separate lines from
+   the text.  E.g.
+
+	/*
+	 * A very long
+	 * multi-line comment.
+	 */
+
+   Note however that a comment that explains a translatable string to
+   translators uses a convention of starting with a magic token
+   "TRANSLATORS: ", e.g.
+
+	/*
+	 * TRANSLATORS: here is a comment that explains the string to
+	 * be translated, that follows immediately after it.
+	 */
+	_("Here is a translatable string explained by the above.");
+
+ - Double negation is often harder to understand than no negation
+   at all.
+
+ - There are two schools of thought when it comes to comparison,
+   especially inside a loop. Some people prefer to have the less stable
+   value on the left hand side and the more stable value on the right hand
+   side, e.g. if you have a loop that counts variable i down to the
+   lower bound,
+
+	while (i > lower_bound) {
+		do something;
+		i--;
+	}
+
+   Other people prefer to have the textual order of values match the
+   actual order of values in their comparison, so that they can
+   mentally draw a number line from left to right and place these
+   values in order, i.e.
+
+	while (lower_bound < i) {
+		do something;
+		i--;
+	}
+
+   Both are valid, and we use both.  However, the more "stable" the
+   stable side becomes, the more we tend to prefer the former
+   (comparison with a constant, "i > 0", is an extreme example).
+   Just do not mix styles in the same part of the code and mimic
+   existing styles in the neighbourhood.
+
+ - There are two schools of thought when it comes to splitting a long
+   logical line into multiple lines.  Some people push the second and
+   subsequent lines far enough to the right with tabs and align them:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+		span_more_than_a_single_line_of ||
+		the_source_text) {
+                ...
+
+   while other people prefer to align the second and the subsequent
+   lines with the column immediately inside the opening parenthesis,
+   with tabs and spaces, following our "tabstop is always a multiple
+   of 8" convention:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of ||
+	    the_source_text) {
+                ...
+
+   Both are valid, and we use both.  Again, just do not mix styles in
+   the same part of the code and mimic existing styles in the
+   neighbourhood.
+
+ - When splitting a long logical line, some people change line before
+   a binary operator, so that the result looks like a parse tree when
+   you turn your head 90-degrees counterclockwise:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to
+	    || span_more_than_a_single_line_of_the_source_text) {
+
+   while other people prefer to leave the operator at the end of the
+   line:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of_the_source_text) {
+
+   Both are valid, but we tend to use the latter more, unless the
+   expression gets fairly complex, in which case the former tends to
+   be easier to read.  Again, just do not mix styles in the same part
+   of the code and mimic existing styles in the neighbourhood.
+
+ - When splitting a long logical line, with everything else being
+   equal, it is preferable to split after the operator at higher
+   level in the parse tree.  That is, this is more preferable:
+
+	if (a_very_long_variable * that_is_used_in +
+	    a_very_long_expression) {
+		...
+
+   than
+
+	if (a_very_long_variable *
+	    that_is_used_in + a_very_long_expression) {
+		...
+
+ - Some clever tricks, like using the !! operator with arithmetic
+   constructs, can be extremely confusing to others.  Avoid them,
+   unless there is a compelling reason to use them.
+
+ - Use the API.  No, really.  We have a strbuf (variable length
+   string), several arrays with the ALLOC_GROW() macro, a
+   string_list for sorted string lists, a hash map (mapping struct
+   objects) named "struct decorate", amongst other things.
+
+ - When you come up with an API, document its functions and structures
+   in the header file that exposes the API to its callers. Use what is
+   in "strbuf.h" as a model for the appropriate tone and level of
+   detail.
+
+ - The first #include in C files, except in platform specific compat/
+   implementations, must be either "git-compat-util.h", "cache.h" or
+   "builtin.h".  You do not have to include more than one of these.
+
+ - A C file must directly include the header files that declare the
+   functions and the types it uses, except for the functions and types
+   that are made available to it by including one of the header files
+   it must include by the previous rule.
+
+ - If you are planning a new command, consider writing it in shell
+   or perl first, so that changes in semantics can be easily
+   changed and discussed.  Many Git commands started out like
+   that, and a few are still scripts.
+
+ - Avoid introducing a new dependency into Git. This means you
+   usually should stay away from scripting languages not already
+   used in the Git core command set (unless your command is clearly
+   separate from it, such as an importer to convert random-scm-X
+   repositories to Git).
+
+ - When we pass <string, length> pair to functions, we should try to
+   pass them in that order.
+
+ - Use Git's gettext wrappers to make the user interface
+   translatable. See "Marking strings for translation" in po/README.
+
+ - Variables and functions local to a given source file should be marked
+   with "static". Variables that are visible to other source files
+   must be declared with "extern" in header files. However, function
+   declarations should not use "extern", as that is already the default.
+
+ - You can launch gdb around your program using the shorthand GIT_DEBUGGER.
+   Run `GIT_DEBUGGER=1 ./bin-wrappers/git foo` to simply use gdb as is, or
+   run `GIT_DEBUGGER="<debugger> <debugger-args>" ./bin-wrappers/git foo` to
+   use your own debugger and arguments. Example: `GIT_DEBUGGER="ddd --gdb"
+   ./bin-wrappers/git log` (See `wrap-for-bin.sh`.)
+
+For Perl programs:
+
+ - Most of the C guidelines above apply.
+
+ - We try to support Perl 5.8 and later ("use Perl 5.008").
+
+ - use strict and use warnings are strongly preferred.
+
+ - Don't overuse statement modifiers unless using them makes the
+   result easier to follow.
+
+	... do something ...
+	do_this() unless (condition);
+        ... do something else ...
+
+   is more readable than:
+
+	... do something ...
+	unless (condition) {
+		do_this();
+	}
+        ... do something else ...
+
+   *only* when the condition is so rare that do_this() will be almost
+   always called.
+
+ - We try to avoid assignments inside "if ()" conditions.
+
+ - Learn and use Git.pm if you need that functionality.
+
+ - For Emacs, it's useful to put the following in
+   GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode:
+
+    ;; note the first part is useful for C editing, too
+    ((nil . ((indent-tabs-mode . t)
+                  (tab-width . 8)
+                  (fill-column . 80)))
+     (cperl-mode . ((cperl-indent-level . 8)
+                    (cperl-extra-newline-before-brace . nil)
+                    (cperl-merge-trailing-else . t))))
+
+For Python scripts:
+
+ - We follow PEP-8 (http://www.python.org/dev/peps/pep-0008/).
+
+ - As a minimum, we aim to be compatible with Python 2.7.
+
+ - Where required libraries do not restrict us to Python 2, we try to
+   also be compatible with Python 3.1 and later.
+
+
+Program Output
+
+ We make a distinction between a Git command's primary output and
+ output which is merely chatty feedback (for instance, status
+ messages, running transcript, or progress display), as well as error
+ messages. Roughly speaking, a Git command's primary output is that
+ which one might want to capture to a file or send down a pipe; its
+ chatty output should not interfere with these use-cases.
+
+ As such, primary output should be sent to the standard output stream
+ (stdout), and chatty output should be sent to the standard error
+ stream (stderr). Examples of commands which produce primary output
+ include `git log`, `git show`, and `git branch --list` which generate
+ output on the stdout stream.
+
+ Not all Git commands have primary output; this is often true of
+ commands whose main function is to perform an action. Some action
+ commands are silent, whereas others are chatty. An example of a
+ chatty action commands is `git clone` with its "Cloning into
+ '<path>'..." and "Checking connectivity..." status messages which it
+ sends to the stderr stream.
+
+ Error messages from Git commands should always be sent to the stderr
+ stream.
+
+
+Error Messages
+
+ - Do not end error messages with a full stop.
+
+ - Do not capitalize the first word, only because it is the first word
+   in the message ("unable to open %s", not "Unable to open %s").  But
+   "SHA-3 not supported" is fine, because the reason the first word is
+   capitalized is not because it is at the beginning of the sentence,
+   but because the word would be spelled in capital letters even when
+   it appeared in the middle of the sentence.
+
+ - Say what the error is first ("cannot open %s", not "%s: cannot open")
+
+
+Externally Visible Names
+
+ - For configuration variable names, follow the existing convention:
+
+   . The section name indicates the affected subsystem.
+
+   . The subsection name, if any, indicates which of an unbounded set
+     of things to set the value for.
+
+   . The variable name describes the effect of tweaking this knob.
+
+   The section and variable names that consist of multiple words are
+   formed by concatenating the words without punctuations (e.g. `-`),
+   and are broken using bumpyCaps in documentation as a hint to the
+   reader.
+
+   When choosing the variable namespace, do not use variable name for
+   specifying possibly unbounded set of things, most notably anything
+   an end user can freely come up with (e.g. branch names).  Instead,
+   use subsection names or variable values, like the existing variable
+   branch.<name>.description does.
+
+
+Writing Documentation:
+
+ Most (if not all) of the documentation pages are written in the
+ AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+ processed into HTML and manpages (e.g. git.html and git.1 in the
+ same directory).
+
+ The documentation liberally mixes US and UK English (en_US/UK)
+ norms for spelling and grammar, which is somewhat unfortunate.
+ In an ideal world, it would have been better if it consistently
+ used only one and not the other, and we would have picked en_US
+ (if you wish to correct the English of some of the existing
+ documentation, please see the documentation-related advice in the
+ Documentation/SubmittingPatches file).
+
+ In order to ensure the documentation is inclusive, avoid assuming
+ that an unspecified example person is male or female, and think
+ twice before using "he", "him", "she", or "her".  Here are some
+ tips to avoid use of gendered pronouns:
+
+  - Prefer succinctness and matter-of-factly describing functionality
+    in the abstract.  E.g.
+
+     --short:: Emit output in the short-format.
+
+    and avoid something like these overly verbose alternatives:
+
+     --short:: Use this to emit output in the short-format.
+     --short:: You can use this to get output in the short-format.
+     --short:: A user who prefers shorter output could....
+     --short:: Should a person and/or program want shorter output, he
+               she/they/it can...
+
+    This practice often eliminates the need to involve human actors in
+    your description, but it is a good practice regardless of the
+    avoidance of gendered pronouns.
+
+  - When it becomes awkward to stick to this style, prefer "you" when
+    addressing the the hypothetical user, and possibly "we" when
+    discussing how the program might react to the user.  E.g.
+
+      You can use this option instead of --xyz, but we might remove
+      support for it in future versions.
+
+    while keeping in mind that you can probably be less verbose, e.g.
+
+      Use this instead of --xyz. This option might be removed in future
+      versions.
+
+  - If you still need to refer to an example person that is
+    third-person singular, you may resort to "singular they" to avoid
+    "he/she/him/her", e.g.
+
+      A contributor asks their upstream to pull from them.
+
+    Note that this sounds ungrammatical and unnatural to those who
+    learned that "they" is only used for third-person plural, e.g.
+    those who learn English as a second language in some parts of the
+    world.
+
+ Every user-visible change should be reflected in the documentation.
+ The same general rule as for code applies -- imitate the existing
+ conventions.
+
+ A few commented examples follow to provide reference when writing or
+ modifying command usage strings and synopsis sections in the manual
+ pages:
+
+ Placeholders are spelled in lowercase and enclosed in angle brackets:
+   <file>
+   --sort=<key>
+   --abbrev[=<n>]
+
+ If a placeholder has multiple words, they are separated by dashes:
+   <new-branch-name>
+   --template=<template-directory>
+
+ Possibility of multiple occurrences is indicated by three dots:
+   <file>...
+   (One or more of <file>.)
+
+ Optional parts are enclosed in square brackets:
+   [<extra>]
+   (Zero or one <extra>.)
+
+   --exec-path[=<path>]
+   (Option with an optional argument.  Note that the "=" is inside the
+   brackets.)
+
+   [<patch>...]
+   (Zero or more of <patch>.  Note that the dots are inside, not
+   outside the brackets.)
+
+ Multiple alternatives are indicated with vertical bars:
+   [-q | --quiet]
+   [--utf8 | --no-utf8]
+
+ Parentheses are used for grouping:
+   [(<rev> | <range>)...]
+   (Any number of either <rev> or <range>.  Parens are needed to make
+   it clear that "..." pertains to both <rev> and <range>.)
+
+   [(-p <parent>)...]
+   (Any number of option -p, each with one <parent> argument.)
+
+   git remote set-head <name> (-a | -d | <branch>)
+   (One and only one of "-a", "-d" or "<branch>" _must_ (no square
+   brackets) be provided.)
+
+ And a somewhat more contrived example:
+   --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+   Here "=" is outside the brackets, because "--diff-filter=" is a
+   valid usage.  "*" has its own pair of brackets, because it can
+   (optionally) be specified only when one or more of the letters is
+   also provided.
+
+  A note on notation:
+   Use 'git' (all lowercase) when talking about commands i.e. something
+   the user would type into a shell and use 'Git' (uppercase first letter)
+   when talking about the version control system and its properties.
+
+ A few commented examples follow to provide reference when writing or
+ modifying paragraphs or option/command explanations that contain options
+ or commands:
+
+ Literal examples (e.g. use of command-line options, command names,
+ branch names, URLs, pathnames (files and directories), configuration and
+ environment variables) must be typeset in monospace (i.e. wrapped with
+ backticks):
+   `--pretty=oneline`
+   `git rev-list`
+   `remote.pushDefault`
+   `http://git.example.com`
+   `.git/config`
+   `GIT_DIR`
+   `HEAD`
+
+ An environment variable must be prefixed with "$" only when referring to its
+ value and not when referring to the variable itself, in this case there is
+ nothing to add except the backticks:
+   `GIT_DIR` is specified
+   `$GIT_DIR/hooks/pre-receive`
+
+ Word phrases enclosed in `backtick characters` are rendered literally
+ and will not be further expanded. The use of `backticks` to achieve the
+ previous rule means that literal examples should not use AsciiDoc
+ escapes.
+   Correct:
+      `--pretty=oneline`
+   Incorrect:
+      `\--pretty=oneline`
+
+ If some place in the documentation needs to typeset a command usage
+ example with inline substitutions, it is fine to use +monospaced and
+ inline substituted text+ instead of `monospaced literal text`, and with
+ the former, the part that should not get substituted must be
+ quoted/escaped.
diff --git a/external/docs/asciidoc/975b191d029bc4676e7ea0c0223f018da61f129c b/external/docs/asciidoc/975b191d029bc4676e7ea0c0223f018da61f129c
new file mode 100644
index 0000000000..9495df835d
--- /dev/null
+++ b/external/docs/asciidoc/975b191d029bc4676e7ea0c0223f018da61f129c
@@ -0,0 +1,758 @@
+Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, a few rough rules are:
+
+ - Most importantly, we never say "It's in POSIX; we'll happily
+   ignore your needs should your system not conform to it."
+   We live in the real world.
+
+ - However, we often say "Let's stay away from that construct,
+   it's not even in POSIX".
+
+ - In spite of the above two rules, we sometimes say "Although
+   this is not in POSIX, it (is so convenient | makes the code
+   much more readable | has other good characteristics) and
+   practically all the platforms we care about support it, so
+   let's use it".
+
+   Again, we live in the real world, and it is sometimes a
+   judgement call, the decision based more on real world
+   constraints people face than what the paper standard says.
+
+ - Fixing style violations while working on a real change as a
+   preparatory clean-up step is good, but otherwise avoid useless code
+   churn for the sake of conforming to the style.
+
+   "Once it _is_ in the tree, it's not really worth the patch noise to
+   go and fix it up."
+   Cf. https://lore.kernel.org/all/20100126160632.3bdbe172.akpm@linux-foundation.org/
+
+ - Log messages to explain your changes are as important as the
+   changes themselves.  Clearly written code and in-code comments
+   explain how the code works and what is assumed from the surrounding
+   context.  The log messages explain what the changes wanted to
+   achieve and why the changes were necessary (more on this in the
+   accompanying SubmittingPatches document).
+
+Make your code readable and sensible, and don't try to be clever.
+
+As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the _local_
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn't match the overall style of existing code).
+
+But if you must have a list of rules, here are some language
+specific ones. Note that Documentation/ToolsForGit.txt document
+has a collection of tips to help you use some external tools
+to conform to these guidelines.
+
+For shell scripts specifically (not exhaustive):
+
+ - We use tabs for indentation.
+
+ - Case arms are indented at the same depth as case and esac lines,
+   like this:
+
+	case "$variable" in
+	pattern1)
+		do this
+		;;
+	pattern2)
+		do that
+		;;
+	esac
+
+ - Redirection operators should be written with space before, but no
+   space after them.  In other words, write 'echo test >"$file"'
+   instead of 'echo test> $file' or 'echo test > $file'.  Note that
+   even though it is not required by POSIX to double-quote the
+   redirection target in a variable (as shown above), our code does so
+   because some versions of bash issue a warning without the quotes.
+
+	(incorrect)
+	cat hello > world < universe
+	echo hello >$world
+
+	(correct)
+	cat hello >world <universe
+	echo hello >"$world"
+
+ - We prefer $( ... ) for command substitution; unlike ``, it
+   properly nests.  It should have been the way Bourne spelled
+   it from day one, but unfortunately isn't.
+
+ - If you want to find out if a command is available on the user's
+   $PATH, you should use 'type <command>', instead of 'which <command>'.
+   The output of 'which' is not machine parsable and its exit code
+   is not reliable across platforms.
+
+ - We use POSIX compliant parameter substitutions and avoid bashisms;
+   namely:
+
+   - We use ${parameter-word} and its [-=?+] siblings, and their
+     colon'ed "unset or null" form.
+
+   - We use ${parameter#word} and its [#%] siblings, and their
+     doubled "longest matching" form.
+
+   - No "Substring Expansion" ${parameter:offset:length}.
+
+   - No shell arrays.
+
+   - No pattern replacement ${parameter/pattern/string}.
+
+ - We use Arithmetic Expansion $(( ... )).
+
+ - We do not use Process Substitution <(list) or >(list).
+
+ - Do not write control structures on a single line with semicolon.
+   "then" should be on the next line for if statements, and "do"
+   should be on the next line for "while" and "for".
+
+	(incorrect)
+	if test -f hello; then
+		do this
+	fi
+
+	(correct)
+	if test -f hello
+	then
+		do this
+	fi
+
+ - If a command sequence joined with && or || or | spans multiple
+   lines, put each command on a separate line and put && and || and |
+   operators at the end of each line, rather than the start. This
+   means you don't need to use \ to join lines, since the above
+   operators imply the sequence isn't finished.
+
+	(incorrect)
+	grep blob verify_pack_result \
+	| awk -f print_1.awk \
+	| sort >actual &&
+	...
+
+	(correct)
+	grep blob verify_pack_result |
+	awk -f print_1.awk |
+	sort >actual &&
+	...
+
+ - We prefer "test" over "[ ... ]".
+
+ - We do not write the noiseword "function" in front of shell
+   functions.
+
+ - We prefer a space between the function name and the parentheses,
+   and no space inside the parentheses. The opening "{" should also
+   be on the same line.
+
+	(incorrect)
+	my_function(){
+		...
+
+	(correct)
+	my_function () {
+		...
+
+ - As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+   [::], [==], or [..]) for portability.
+
+   - We do not use \{m,n\};
+
+   - We do not use ? or + (which are \{0,1\} and \{1,\}
+     respectively in BRE) but that goes without saying as these
+     are ERE elements not BRE (note that \? and \+ are not even part
+     of BRE -- making them accessible from BRE is a GNU extension).
+
+ - Use Git's gettext wrappers in git-sh-i18n to make the user
+   interface translatable. See "Marking strings for translation" in
+   po/README.
+
+ - We do not write our "test" command with "-a" and "-o" and use "&&"
+   or "||" to concatenate multiple "test" commands instead, because
+   the use of "-a/-o" is often error-prone.  E.g.
+
+     test -n "$x" -a "$a" = "$b"
+
+   is buggy and breaks when $x is "=", but
+
+     test -n "$x" && test "$a" = "$b"
+
+   does not have such a problem.
+
+ - Even though "local" is not part of POSIX, we make heavy use of it
+   in our test suite.  We do not use it in scripted Porcelains, and
+   hopefully nobody starts using "local" before they are reimplemented
+   in C ;-)
+
+ - Use octal escape sequences (e.g. "\302\242"), not hexadecimal (e.g.
+   "\xc2\xa2") in printf format strings, since hexadecimal escape
+   sequences are not portable.
+
+
+For C programs:
+
+ - We use tabs to indent, and interpret tabs as taking up to
+   8 spaces.
+
+ - We try to keep to at most 80 characters per line.
+
+ - As a Git developer we assume you have a reasonably modern compiler
+   and we recommend you to enable the DEVELOPER makefile knob to
+   ensure your patch is clear of all compiler warnings we care about,
+   by e.g. "echo DEVELOPER=1 >>config.mak".
+
+ - We try to support a wide range of C compilers to compile Git with,
+   including old ones.  As of Git v2.35.0 Git requires C99 (we check
+   "__STDC_VERSION__"). You should not use features from a newer C
+   standard, even if your compiler groks them.
+
+   New C99 features have been phased in gradually, if something's new
+   in C99 but not used yet don't assume that it's safe to use, some
+   compilers we target have only partial support for it. These are
+   considered safe to use:
+
+   . since around 2007 with 2b6854c863a, we have been using
+     initializer elements which are not computable at load time. E.g.:
+
+	const char *args[] = {"constant", variable, NULL};
+
+   . since early 2012 with e1327023ea, we have been using an enum
+     definition whose last element is followed by a comma.  This, like
+     an array initializer that ends with a trailing comma, can be used
+     to reduce the patch noise when adding a new identifier at the end.
+
+   . since mid 2017 with cbc0f81d, we have been using designated
+     initializers for struct (e.g. "struct t v = { .val = 'a' };").
+
+   . since mid 2017 with 512f41cf, we have been using designated
+     initializers for array (e.g. "int array[10] = { [5] = 2 }").
+
+   . since early 2021 with 765dc168882, we have been using variadic
+     macros, mostly for printf-like trace and debug macros.
+
+   . since late 2021 with 44ba10d6, we have had variables declared in
+     the for loop "for (int i = 0; i < 10; i++)".
+
+   New C99 features that we cannot use yet:
+
+   . %z and %zu as a printf() argument for a size_t (the %z being for
+     the POSIX-specific ssize_t). Instead you should use
+     printf("%"PRIuMAX, (uintmax_t)v).  These days the MSVC version we
+     rely on supports %z, but the C library used by MinGW does not.
+
+   . Shorthand like ".a.b = *c" in struct initializations is known to
+     trip up an older IBM XLC version, use ".a = { .b = *c }" instead.
+     See the 33665d98 (reftable: make assignments portable to AIX xlc
+     v12.01, 2022-03-28).
+
+ - Variables have to be declared at the beginning of the block, before
+   the first statement (i.e. -Wdeclaration-after-statement).
+
+ - NULL pointers shall be written as NULL, not as 0.
+
+ - When declaring pointers, the star sides with the variable
+   name, i.e. "char *string", not "char* string" or
+   "char * string".  This makes it easier to understand code
+   like "char *string, c;".
+
+ - Use whitespace around operators and keywords, but not inside
+   parentheses and not around functions. So:
+
+        while (condition)
+		func(bar + 1);
+
+   and not:
+
+        while( condition )
+		func (bar+1);
+
+ - Do not explicitly compare an integral value with constant 0 or '\0',
+   or a pointer value with constant NULL.  For instance, to validate that
+   counted array <ptr, cnt> is initialized but has no elements, write:
+
+	if (!ptr || cnt)
+		BUG("empty array expected");
+
+   and not:
+
+	if (ptr == NULL || cnt != 0);
+		BUG("empty array expected");
+
+ - We avoid using braces unnecessarily.  I.e.
+
+	if (bla) {
+		x = 1;
+	}
+
+   is frowned upon. But there are a few exceptions:
+
+	- When the statement extends over a few lines (e.g., a while loop
+	  with an embedded conditional, or a comment). E.g.:
+
+		while (foo) {
+			if (x)
+				one();
+			else
+				two();
+		}
+
+		if (foo) {
+			/*
+			 * This one requires some explanation,
+			 * so we're better off with braces to make
+			 * it obvious that the indentation is correct.
+			 */
+			doit();
+		}
+
+	- When there are multiple arms to a conditional and some of them
+	  require braces, enclose even a single line block in braces for
+	  consistency. E.g.:
+
+		if (foo) {
+			doit();
+		} else {
+			one();
+			two();
+			three();
+		}
+
+ - We try to avoid assignments in the condition of an "if" statement.
+
+ - Try to make your code understandable.  You may put comments
+   in, but comments invariably tend to stale out when the code
+   they were describing changes.  Often splitting a function
+   into two makes the intention of the code much clearer.
+
+ - Multi-line comments include their delimiters on separate lines from
+   the text.  E.g.
+
+	/*
+	 * A very long
+	 * multi-line comment.
+	 */
+
+   Note however that a comment that explains a translatable string to
+   translators uses a convention of starting with a magic token
+   "TRANSLATORS: ", e.g.
+
+	/*
+	 * TRANSLATORS: here is a comment that explains the string to
+	 * be translated, that follows immediately after it.
+	 */
+	_("Here is a translatable string explained by the above.");
+
+ - Double negation is often harder to understand than no negation
+   at all.
+
+ - There are two schools of thought when it comes to comparison,
+   especially inside a loop. Some people prefer to have the less stable
+   value on the left hand side and the more stable value on the right hand
+   side, e.g. if you have a loop that counts variable i down to the
+   lower bound,
+
+	while (i > lower_bound) {
+		do something;
+		i--;
+	}
+
+   Other people prefer to have the textual order of values match the
+   actual order of values in their comparison, so that they can
+   mentally draw a number line from left to right and place these
+   values in order, i.e.
+
+	while (lower_bound < i) {
+		do something;
+		i--;
+	}
+
+   Both are valid, and we use both.  However, the more "stable" the
+   stable side becomes, the more we tend to prefer the former
+   (comparison with a constant, "i > 0", is an extreme example).
+   Just do not mix styles in the same part of the code and mimic
+   existing styles in the neighbourhood.
+
+ - There are two schools of thought when it comes to splitting a long
+   logical line into multiple lines.  Some people push the second and
+   subsequent lines far enough to the right with tabs and align them:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+		span_more_than_a_single_line_of ||
+		the_source_text) {
+                ...
+
+   while other people prefer to align the second and the subsequent
+   lines with the column immediately inside the opening parenthesis,
+   with tabs and spaces, following our "tabstop is always a multiple
+   of 8" convention:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of ||
+	    the_source_text) {
+                ...
+
+   Both are valid, and we use both.  Again, just do not mix styles in
+   the same part of the code and mimic existing styles in the
+   neighbourhood.
+
+ - When splitting a long logical line, some people change line before
+   a binary operator, so that the result looks like a parse tree when
+   you turn your head 90-degrees counterclockwise:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to
+	    || span_more_than_a_single_line_of_the_source_text) {
+
+   while other people prefer to leave the operator at the end of the
+   line:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of_the_source_text) {
+
+   Both are valid, but we tend to use the latter more, unless the
+   expression gets fairly complex, in which case the former tends to
+   be easier to read.  Again, just do not mix styles in the same part
+   of the code and mimic existing styles in the neighbourhood.
+
+ - When splitting a long logical line, with everything else being
+   equal, it is preferable to split after the operator at higher
+   level in the parse tree.  That is, this is more preferable:
+
+	if (a_very_long_variable * that_is_used_in +
+	    a_very_long_expression) {
+		...
+
+   than
+
+	if (a_very_long_variable *
+	    that_is_used_in + a_very_long_expression) {
+		...
+
+ - Some clever tricks, like using the !! operator with arithmetic
+   constructs, can be extremely confusing to others.  Avoid them,
+   unless there is a compelling reason to use them.
+
+ - Use the API.  No, really.  We have a strbuf (variable length
+   string), several arrays with the ALLOC_GROW() macro, a
+   string_list for sorted string lists, a hash map (mapping struct
+   objects) named "struct decorate", amongst other things.
+
+ - When you come up with an API, document its functions and structures
+   in the header file that exposes the API to its callers. Use what is
+   in "strbuf.h" as a model for the appropriate tone and level of
+   detail.
+
+ - The first #include in C files, except in platform specific compat/
+   implementations and sha1dc/, must be either "git-compat-util.h" or
+   one of the approved headers that includes it first for you.  (The
+   approved headers currently include "builtin.h",
+   "t/helper/test-tool.h", "xdiff/xinclude.h", or
+   "reftable/system.h").  You do not have to include more than one of
+   these.
+
+ - A C file must directly include the header files that declare the
+   functions and the types it uses, except for the functions and types
+   that are made available to it by including one of the header files
+   it must include by the previous rule.
+
+ - If you are planning a new command, consider writing it in shell
+   or perl first, so that changes in semantics can be easily
+   changed and discussed.  Many Git commands started out like
+   that, and a few are still scripts.
+
+ - Avoid introducing a new dependency into Git. This means you
+   usually should stay away from scripting languages not already
+   used in the Git core command set (unless your command is clearly
+   separate from it, such as an importer to convert random-scm-X
+   repositories to Git).
+
+ - When we pass <string, length> pair to functions, we should try to
+   pass them in that order.
+
+ - Use Git's gettext wrappers to make the user interface
+   translatable. See "Marking strings for translation" in po/README.
+
+ - Variables and functions local to a given source file should be marked
+   with "static". Variables that are visible to other source files
+   must be declared with "extern" in header files. However, function
+   declarations should not use "extern", as that is already the default.
+
+ - You can launch gdb around your program using the shorthand GIT_DEBUGGER.
+   Run `GIT_DEBUGGER=1 ./bin-wrappers/git foo` to simply use gdb as is, or
+   run `GIT_DEBUGGER="<debugger> <debugger-args>" ./bin-wrappers/git foo` to
+   use your own debugger and arguments. Example: `GIT_DEBUGGER="ddd --gdb"
+   ./bin-wrappers/git log` (See `wrap-for-bin.sh`.)
+
+For Perl programs:
+
+ - Most of the C guidelines above apply.
+
+ - We try to support Perl 5.8 and later ("use Perl 5.008").
+
+ - use strict and use warnings are strongly preferred.
+
+ - Don't overuse statement modifiers unless using them makes the
+   result easier to follow.
+
+	... do something ...
+	do_this() unless (condition);
+        ... do something else ...
+
+   is more readable than:
+
+	... do something ...
+	unless (condition) {
+		do_this();
+	}
+        ... do something else ...
+
+   *only* when the condition is so rare that do_this() will be almost
+   always called.
+
+ - We try to avoid assignments inside "if ()" conditions.
+
+ - Learn and use Git.pm if you need that functionality.
+
+For Python scripts:
+
+ - We follow PEP-8 (http://www.python.org/dev/peps/pep-0008/).
+
+ - As a minimum, we aim to be compatible with Python 2.7.
+
+ - Where required libraries do not restrict us to Python 2, we try to
+   also be compatible with Python 3.1 and later.
+
+
+Program Output
+
+ We make a distinction between a Git command's primary output and
+ output which is merely chatty feedback (for instance, status
+ messages, running transcript, or progress display), as well as error
+ messages. Roughly speaking, a Git command's primary output is that
+ which one might want to capture to a file or send down a pipe; its
+ chatty output should not interfere with these use-cases.
+
+ As such, primary output should be sent to the standard output stream
+ (stdout), and chatty output should be sent to the standard error
+ stream (stderr). Examples of commands which produce primary output
+ include `git log`, `git show`, and `git branch --list` which generate
+ output on the stdout stream.
+
+ Not all Git commands have primary output; this is often true of
+ commands whose main function is to perform an action. Some action
+ commands are silent, whereas others are chatty. An example of a
+ chatty action commands is `git clone` with its "Cloning into
+ '<path>'..." and "Checking connectivity..." status messages which it
+ sends to the stderr stream.
+
+ Error messages from Git commands should always be sent to the stderr
+ stream.
+
+
+Error Messages
+
+ - Do not end error messages with a full stop.
+
+ - Do not capitalize the first word, only because it is the first word
+   in the message ("unable to open %s", not "Unable to open %s").  But
+   "SHA-3 not supported" is fine, because the reason the first word is
+   capitalized is not because it is at the beginning of the sentence,
+   but because the word would be spelled in capital letters even when
+   it appeared in the middle of the sentence.
+
+ - Say what the error is first ("cannot open %s", not "%s: cannot open")
+
+
+Externally Visible Names
+
+ - For configuration variable names, follow the existing convention:
+
+   . The section name indicates the affected subsystem.
+
+   . The subsection name, if any, indicates which of an unbounded set
+     of things to set the value for.
+
+   . The variable name describes the effect of tweaking this knob.
+
+   The section and variable names that consist of multiple words are
+   formed by concatenating the words without punctuations (e.g. `-`),
+   and are broken using bumpyCaps in documentation as a hint to the
+   reader.
+
+   When choosing the variable namespace, do not use variable name for
+   specifying possibly unbounded set of things, most notably anything
+   an end user can freely come up with (e.g. branch names).  Instead,
+   use subsection names or variable values, like the existing variable
+   branch.<name>.description does.
+
+
+Writing Documentation:
+
+ Most (if not all) of the documentation pages are written in the
+ AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+ processed into HTML and manpages (e.g. git.html and git.1 in the
+ same directory).
+
+ The documentation liberally mixes US and UK English (en_US/UK)
+ norms for spelling and grammar, which is somewhat unfortunate.
+ In an ideal world, it would have been better if it consistently
+ used only one and not the other, and we would have picked en_US
+ (if you wish to correct the English of some of the existing
+ documentation, please see the documentation-related advice in the
+ Documentation/SubmittingPatches file).
+
+ In order to ensure the documentation is inclusive, avoid assuming
+ that an unspecified example person is male or female, and think
+ twice before using "he", "him", "she", or "her".  Here are some
+ tips to avoid use of gendered pronouns:
+
+  - Prefer succinctness and matter-of-factly describing functionality
+    in the abstract.  E.g.
+
+     --short:: Emit output in the short-format.
+
+    and avoid something like these overly verbose alternatives:
+
+     --short:: Use this to emit output in the short-format.
+     --short:: You can use this to get output in the short-format.
+     --short:: A user who prefers shorter output could....
+     --short:: Should a person and/or program want shorter output, he
+               she/they/it can...
+
+    This practice often eliminates the need to involve human actors in
+    your description, but it is a good practice regardless of the
+    avoidance of gendered pronouns.
+
+  - When it becomes awkward to stick to this style, prefer "you" when
+    addressing the hypothetical user, and possibly "we" when
+    discussing how the program might react to the user.  E.g.
+
+      You can use this option instead of --xyz, but we might remove
+      support for it in future versions.
+
+    while keeping in mind that you can probably be less verbose, e.g.
+
+      Use this instead of --xyz. This option might be removed in future
+      versions.
+
+  - If you still need to refer to an example person that is
+    third-person singular, you may resort to "singular they" to avoid
+    "he/she/him/her", e.g.
+
+      A contributor asks their upstream to pull from them.
+
+    Note that this sounds ungrammatical and unnatural to those who
+    learned that "they" is only used for third-person plural, e.g.
+    those who learn English as a second language in some parts of the
+    world.
+
+ Every user-visible change should be reflected in the documentation.
+ The same general rule as for code applies -- imitate the existing
+ conventions.
+
+ A few commented examples follow to provide reference when writing or
+ modifying command usage strings and synopsis sections in the manual
+ pages:
+
+ Placeholders are spelled in lowercase and enclosed in angle brackets:
+   <file>
+   --sort=<key>
+   --abbrev[=<n>]
+
+ If a placeholder has multiple words, they are separated by dashes:
+   <new-branch-name>
+   --template=<template-directory>
+
+ Possibility of multiple occurrences is indicated by three dots:
+   <file>...
+   (One or more of <file>.)
+
+ Optional parts are enclosed in square brackets:
+   [<file>...]
+   (Zero or more of <file>.)
+
+   --exec-path[=<path>]
+   (Option with an optional argument.  Note that the "=" is inside the
+   brackets.)
+
+   [<patch>...]
+   (Zero or more of <patch>.  Note that the dots are inside, not
+   outside the brackets.)
+
+ Multiple alternatives are indicated with vertical bars:
+   [-q | --quiet]
+   [--utf8 | --no-utf8]
+
+ Use spacing around "|" token(s), but not immediately after opening or
+ before closing a [] or () pair:
+   Do: [-q | --quiet]
+   Don't: [-q|--quiet]
+
+ Don't use spacing around "|" tokens when they're used to separate the
+ alternate arguments of an option:
+    Do: --track[=(direct|inherit)]
+    Don't: --track[=(direct | inherit)]
+
+ Parentheses are used for grouping:
+   [(<rev> | <range>)...]
+   (Any number of either <rev> or <range>.  Parens are needed to make
+   it clear that "..." pertains to both <rev> and <range>.)
+
+   [(-p <parent>)...]
+   (Any number of option -p, each with one <parent> argument.)
+
+   git remote set-head <name> (-a | -d | <branch>)
+   (One and only one of "-a", "-d" or "<branch>" _must_ (no square
+   brackets) be provided.)
+
+ And a somewhat more contrived example:
+   --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+   Here "=" is outside the brackets, because "--diff-filter=" is a
+   valid usage.  "*" has its own pair of brackets, because it can
+   (optionally) be specified only when one or more of the letters is
+   also provided.
+
+  A note on notation:
+   Use 'git' (all lowercase) when talking about commands i.e. something
+   the user would type into a shell and use 'Git' (uppercase first letter)
+   when talking about the version control system and its properties.
+
+ A few commented examples follow to provide reference when writing or
+ modifying paragraphs or option/command explanations that contain options
+ or commands:
+
+ Literal examples (e.g. use of command-line options, command names,
+ branch names, URLs, pathnames (files and directories), configuration and
+ environment variables) must be typeset in monospace (i.e. wrapped with
+ backticks):
+   `--pretty=oneline`
+   `git rev-list`
+   `remote.pushDefault`
+   `http://git.example.com`
+   `.git/config`
+   `GIT_DIR`
+   `HEAD`
+
+ An environment variable must be prefixed with "$" only when referring to its
+ value and not when referring to the variable itself, in this case there is
+ nothing to add except the backticks:
+   `GIT_DIR` is specified
+   `$GIT_DIR/hooks/pre-receive`
+
+ Word phrases enclosed in `backtick characters` are rendered literally
+ and will not be further expanded. The use of `backticks` to achieve the
+ previous rule means that literal examples should not use AsciiDoc
+ escapes.
+   Correct:
+      `--pretty=oneline`
+   Incorrect:
+      `\--pretty=oneline`
+
+ If some place in the documentation needs to typeset a command usage
+ example with inline substitutions, it is fine to use +monospaced and
+ inline substituted text+ instead of `monospaced literal text`, and with
+ the former, the part that should not get substituted must be
+ quoted/escaped.
diff --git a/external/docs/asciidoc/9776886cc5f18c5859d4e3af0bc22df96113a881 b/external/docs/asciidoc/9776886cc5f18c5859d4e3af0bc22df96113a881
new file mode 100644
index 0000000000..32210a4386
--- /dev/null
+++ b/external/docs/asciidoc/9776886cc5f18c5859d4e3af0bc22df96113a881
@@ -0,0 +1,613 @@
+Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, a few rough rules are:
+
+ - Most importantly, we never say "It's in POSIX; we'll happily
+   ignore your needs should your system not conform to it."
+   We live in the real world.
+
+ - However, we often say "Let's stay away from that construct,
+   it's not even in POSIX".
+
+ - In spite of the above two rules, we sometimes say "Although
+   this is not in POSIX, it (is so convenient | makes the code
+   much more readable | has other good characteristics) and
+   practically all the platforms we care about support it, so
+   let's use it".
+
+   Again, we live in the real world, and it is sometimes a
+   judgement call, the decision based more on real world
+   constraints people face than what the paper standard says.
+
+ - Fixing style violations while working on a real change as a
+   preparatory clean-up step is good, but otherwise avoid useless code
+   churn for the sake of conforming to the style.
+
+   "Once it _is_ in the tree, it's not really worth the patch noise to
+   go and fix it up."
+   Cf. http://lkml.iu.edu/hypermail/linux/kernel/1001.3/01069.html
+
+Make your code readable and sensible, and don't try to be clever.
+
+As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the _local_
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn't match the overall style of existing code).
+
+But if you must have a list of rules, here they are.
+
+For shell scripts specifically (not exhaustive):
+
+ - We use tabs for indentation.
+
+ - Case arms are indented at the same depth as case and esac lines,
+   like this:
+
+	case "$variable" in
+	pattern1)
+		do this
+		;;
+	pattern2)
+		do that
+		;;
+	esac
+
+ - Redirection operators should be written with space before, but no
+   space after them.  In other words, write 'echo test >"$file"'
+   instead of 'echo test> $file' or 'echo test > $file'.  Note that
+   even though it is not required by POSIX to double-quote the
+   redirection target in a variable (as shown above), our code does so
+   because some versions of bash issue a warning without the quotes.
+
+	(incorrect)
+	cat hello > world < universe
+	echo hello >$world
+
+	(correct)
+	cat hello >world <universe
+	echo hello >"$world"
+
+ - We prefer $( ... ) for command substitution; unlike ``, it
+   properly nests.  It should have been the way Bourne spelled
+   it from day one, but unfortunately isn't.
+
+ - If you want to find out if a command is available on the user's
+   $PATH, you should use 'type <command>', instead of 'which <command>'.
+   The output of 'which' is not machine parseable and its exit code
+   is not reliable across platforms.
+
+ - We use POSIX compliant parameter substitutions and avoid bashisms;
+   namely:
+
+   - We use ${parameter-word} and its [-=?+] siblings, and their
+     colon'ed "unset or null" form.
+
+   - We use ${parameter#word} and its [#%] siblings, and their
+     doubled "longest matching" form.
+
+   - No "Substring Expansion" ${parameter:offset:length}.
+
+   - No shell arrays.
+
+   - No strlen ${#parameter}.
+
+   - No pattern replacement ${parameter/pattern/string}.
+
+ - We use Arithmetic Expansion $(( ... )).
+
+ - Inside Arithmetic Expansion, spell shell variables with $ in front
+   of them, as some shells do not grok $((x)) while accepting $(($x))
+   just fine (e.g. dash older than 0.5.4).
+
+ - We do not use Process Substitution <(list) or >(list).
+
+ - Do not write control structures on a single line with semicolon.
+   "then" should be on the next line for if statements, and "do"
+   should be on the next line for "while" and "for".
+
+	(incorrect)
+	if test -f hello; then
+		do this
+	fi
+
+	(correct)
+	if test -f hello
+	then
+		do this
+	fi
+
+ - If a command sequence joined with && or || or | spans multiple
+   lines, put each command on a separate line and put && and || and |
+   operators at the end of each line, rather than the start. This
+   means you don't need to use \ to join lines, since the above
+   operators imply the sequence isn't finished.
+
+	(incorrect)
+	grep blob verify_pack_result \
+	| awk -f print_1.awk \
+	| sort >actual &&
+	...
+
+	(correct)
+	grep blob verify_pack_result |
+	awk -f print_1.awk |
+	sort >actual &&
+	...
+
+ - We prefer "test" over "[ ... ]".
+
+ - We do not write the noiseword "function" in front of shell
+   functions.
+
+ - We prefer a space between the function name and the parentheses,
+   and no space inside the parentheses. The opening "{" should also
+   be on the same line.
+
+	(incorrect)
+	my_function(){
+		...
+
+	(correct)
+	my_function () {
+		...
+
+ - As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+   [::], [==], or [..]) for portability.
+
+   - We do not use \{m,n\};
+
+   - We do not use -E;
+
+   - We do not use ? or + (which are \{0,1\} and \{1,\}
+     respectively in BRE) but that goes without saying as these
+     are ERE elements not BRE (note that \? and \+ are not even part
+     of BRE -- making them accessible from BRE is a GNU extension).
+
+ - Use Git's gettext wrappers in git-sh-i18n to make the user
+   interface translatable. See "Marking strings for translation" in
+   po/README.
+
+ - We do not write our "test" command with "-a" and "-o" and use "&&"
+   or "||" to concatenate multiple "test" commands instead, because
+   the use of "-a/-o" is often error-prone.  E.g.
+
+     test -n "$x" -a "$a" = "$b"
+
+   is buggy and breaks when $x is "=", but
+
+     test -n "$x" && test "$a" = "$b"
+
+   does not have such a problem.
+
+
+For C programs:
+
+ - We use tabs to indent, and interpret tabs as taking up to
+   8 spaces.
+
+ - We try to keep to at most 80 characters per line.
+
+ - As a Git developer we assume you have a reasonably modern compiler
+   and we recommend you to enable the DEVELOPER makefile knob to
+   ensure your patch is clear of all compiler warnings we care about,
+   by e.g. "echo DEVELOPER=1 >>config.mak".
+
+ - We try to support a wide range of C compilers to compile Git with,
+   including old ones. That means that you should not use C99
+   initializers, even if a lot of compilers grok it.
+
+ - Variables have to be declared at the beginning of the block.
+
+ - NULL pointers shall be written as NULL, not as 0.
+
+ - When declaring pointers, the star sides with the variable
+   name, i.e. "char *string", not "char* string" or
+   "char * string".  This makes it easier to understand code
+   like "char *string, c;".
+
+ - Use whitespace around operators and keywords, but not inside
+   parentheses and not around functions. So:
+
+        while (condition)
+		func(bar + 1);
+
+   and not:
+
+        while( condition )
+		func (bar+1);
+
+ - We avoid using braces unnecessarily.  I.e.
+
+	if (bla) {
+		x = 1;
+	}
+
+   is frowned upon. But there are a few exceptions:
+
+	- When the statement extends over a few lines (e.g., a while loop
+	  with an embedded conditional, or a comment). E.g.:
+
+		while (foo) {
+			if (x)
+				one();
+			else
+				two();
+		}
+
+		if (foo) {
+			/*
+			 * This one requires some explanation,
+			 * so we're better off with braces to make
+			 * it obvious that the indentation is correct.
+			 */
+			doit();
+		}
+
+	- When there are multiple arms to a conditional and some of them
+	  require braces, enclose even a single line block in braces for
+	  consistency. E.g.:
+
+		if (foo) {
+			doit();
+		} else {
+			one();
+			two();
+			three();
+		}
+
+ - We try to avoid assignments in the condition of an "if" statement.
+
+ - Try to make your code understandable.  You may put comments
+   in, but comments invariably tend to stale out when the code
+   they were describing changes.  Often splitting a function
+   into two makes the intention of the code much clearer.
+
+ - Multi-line comments include their delimiters on separate lines from
+   the text.  E.g.
+
+	/*
+	 * A very long
+	 * multi-line comment.
+	 */
+
+   Note however that a comment that explains a translatable string to
+   translators uses a convention of starting with a magic token
+   "TRANSLATORS: ", e.g.
+
+	/*
+	 * TRANSLATORS: here is a comment that explains the string to
+	 * be translated, that follows immediately after it.
+	 */
+	_("Here is a translatable string explained by the above.");
+
+ - Double negation is often harder to understand than no negation
+   at all.
+
+ - There are two schools of thought when it comes to comparison,
+   especially inside a loop. Some people prefer to have the less stable
+   value on the left hand side and the more stable value on the right hand
+   side, e.g. if you have a loop that counts variable i down to the
+   lower bound,
+
+	while (i > lower_bound) {
+		do something;
+		i--;
+	}
+
+   Other people prefer to have the textual order of values match the
+   actual order of values in their comparison, so that they can
+   mentally draw a number line from left to right and place these
+   values in order, i.e.
+
+	while (lower_bound < i) {
+		do something;
+		i--;
+	}
+
+   Both are valid, and we use both.  However, the more "stable" the
+   stable side becomes, the more we tend to prefer the former
+   (comparison with a constant, "i > 0", is an extreme example).
+   Just do not mix styles in the same part of the code and mimic
+   existing styles in the neighbourhood.
+
+ - There are two schools of thought when it comes to splitting a long
+   logical line into multiple lines.  Some people push the second and
+   subsequent lines far enough to the right with tabs and align them:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+		span_more_than_a_single_line_of ||
+		the_source_text) {
+                ...
+
+   while other people prefer to align the second and the subsequent
+   lines with the column immediately inside the opening parenthesis,
+   with tabs and spaces, following our "tabstop is always a multiple
+   of 8" convention:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of ||
+	    the_source_text) {
+                ...
+
+   Both are valid, and we use both.  Again, just do not mix styles in
+   the same part of the code and mimic existing styles in the
+   neighbourhood.
+
+ - When splitting a long logical line, some people change line before
+   a binary operator, so that the result looks like a parse tree when
+   you turn your head 90-degrees counterclockwise:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to
+	    || span_more_than_a_single_line_of_the_source_text) {
+
+   while other people prefer to leave the operator at the end of the
+   line:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of_the_source_text) {
+
+   Both are valid, but we tend to use the latter more, unless the
+   expression gets fairly complex, in which case the former tends to
+   be easier to read.  Again, just do not mix styles in the same part
+   of the code and mimic existing styles in the neighbourhood.
+
+ - When splitting a long logical line, with everything else being
+   equal, it is preferable to split after the operator at higher
+   level in the parse tree.  That is, this is more preferable:
+
+	if (a_very_long_variable * that_is_used_in +
+	    a_very_long_expression) {
+		...
+
+   than
+
+	if (a_very_long_variable *
+	    that_is_used_in + a_very_long_expression) {
+		...
+
+ - Some clever tricks, like using the !! operator with arithmetic
+   constructs, can be extremely confusing to others.  Avoid them,
+   unless there is a compelling reason to use them.
+
+ - Use the API.  No, really.  We have a strbuf (variable length
+   string), several arrays with the ALLOC_GROW() macro, a
+   string_list for sorted string lists, a hash map (mapping struct
+   objects) named "struct decorate", amongst other things.
+
+ - When you come up with an API, document its functions and structures
+   in the header file that exposes the API to its callers. Use what is
+   in "strbuf.h" as a model for the appropriate tone and level of
+   detail.
+
+ - The first #include in C files, except in platform specific compat/
+   implementations, must be either "git-compat-util.h", "cache.h" or
+   "builtin.h".  You do not have to include more than one of these.
+
+ - A C file must directly include the header files that declare the
+   functions and the types it uses, except for the functions and types
+   that are made available to it by including one of the header files
+   it must include by the previous rule.
+
+ - If you are planning a new command, consider writing it in shell
+   or perl first, so that changes in semantics can be easily
+   changed and discussed.  Many Git commands started out like
+   that, and a few are still scripts.
+
+ - Avoid introducing a new dependency into Git. This means you
+   usually should stay away from scripting languages not already
+   used in the Git core command set (unless your command is clearly
+   separate from it, such as an importer to convert random-scm-X
+   repositories to Git).
+
+ - When we pass <string, length> pair to functions, we should try to
+   pass them in that order.
+
+ - Use Git's gettext wrappers to make the user interface
+   translatable. See "Marking strings for translation" in po/README.
+
+ - Variables and functions local to a given source file should be marked
+   with "static". Variables that are visible to other source files
+   must be declared with "extern" in header files. However, function
+   declarations should not use "extern", as that is already the default.
+
+For Perl programs:
+
+ - Most of the C guidelines above apply.
+
+ - We try to support Perl 5.8 and later ("use Perl 5.008").
+
+ - use strict and use warnings are strongly preferred.
+
+ - Don't overuse statement modifiers unless using them makes the
+   result easier to follow.
+
+	... do something ...
+	do_this() unless (condition);
+        ... do something else ...
+
+   is more readable than:
+
+	... do something ...
+	unless (condition) {
+		do_this();
+	}
+        ... do something else ...
+
+   *only* when the condition is so rare that do_this() will be almost
+   always called.
+
+ - We try to avoid assignments inside "if ()" conditions.
+
+ - Learn and use Git.pm if you need that functionality.
+
+ - For Emacs, it's useful to put the following in
+   GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode:
+
+    ;; note the first part is useful for C editing, too
+    ((nil . ((indent-tabs-mode . t)
+                  (tab-width . 8)
+                  (fill-column . 80)))
+     (cperl-mode . ((cperl-indent-level . 8)
+                    (cperl-extra-newline-before-brace . nil)
+                    (cperl-merge-trailing-else . t))))
+
+For Python scripts:
+
+ - We follow PEP-8 (http://www.python.org/dev/peps/pep-0008/).
+
+ - As a minimum, we aim to be compatible with Python 2.6 and 2.7.
+
+ - Where required libraries do not restrict us to Python 2, we try to
+   also be compatible with Python 3.1 and later.
+
+ - When you must differentiate between Unicode literals and byte string
+   literals, it is OK to use the 'b' prefix.  Even though the Python
+   documentation for version 2.6 does not mention this prefix, it has
+   been supported since version 2.6.0.
+
+Error Messages
+
+ - Do not end error messages with a full stop.
+
+ - Do not capitalize ("unable to open %s", not "Unable to open %s")
+
+ - Say what the error is first ("cannot open %s", not "%s: cannot open")
+
+
+Externally Visible Names
+
+ - For configuration variable names, follow the existing convention:
+
+   . The section name indicates the affected subsystem.
+
+   . The subsection name, if any, indicates which of an unbounded set
+     of things to set the value for.
+
+   . The variable name describes the effect of tweaking this knob.
+
+   The section and variable names that consist of multiple words are
+   formed by concatenating the words without punctuations (e.g. `-`),
+   and are broken using bumpyCaps in documentation as a hint to the
+   reader.
+
+   When choosing the variable namespace, do not use variable name for
+   specifying possibly unbounded set of things, most notably anything
+   an end user can freely come up with (e.g. branch names).  Instead,
+   use subsection names or variable values, like the existing variable
+   branch.<name>.description does.
+
+
+Writing Documentation:
+
+ Most (if not all) of the documentation pages are written in the
+ AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+ processed into HTML and manpages (e.g. git.html and git.1 in the
+ same directory).
+
+ The documentation liberally mixes US and UK English (en_US/UK)
+ norms for spelling and grammar, which is somewhat unfortunate.
+ In an ideal world, it would have been better if it consistently
+ used only one and not the other, and we would have picked en_US
+ (if you wish to correct the English of some of the existing
+ documentation, please see the documentation-related advice in the
+ Documentation/SubmittingPatches file).
+
+ Every user-visible change should be reflected in the documentation.
+ The same general rule as for code applies -- imitate the existing
+ conventions.
+
+ A few commented examples follow to provide reference when writing or
+ modifying command usage strings and synopsis sections in the manual
+ pages:
+
+ Placeholders are spelled in lowercase and enclosed in angle brackets:
+   <file>
+   --sort=<key>
+   --abbrev[=<n>]
+
+ If a placeholder has multiple words, they are separated by dashes:
+   <new-branch-name>
+   --template=<template-directory>
+
+ Possibility of multiple occurrences is indicated by three dots:
+   <file>...
+   (One or more of <file>.)
+
+ Optional parts are enclosed in square brackets:
+   [<extra>]
+   (Zero or one <extra>.)
+
+   --exec-path[=<path>]
+   (Option with an optional argument.  Note that the "=" is inside the
+   brackets.)
+
+   [<patch>...]
+   (Zero or more of <patch>.  Note that the dots are inside, not
+   outside the brackets.)
+
+ Multiple alternatives are indicated with vertical bars:
+   [-q | --quiet]
+   [--utf8 | --no-utf8]
+
+ Parentheses are used for grouping:
+   [(<rev> | <range>)...]
+   (Any number of either <rev> or <range>.  Parens are needed to make
+   it clear that "..." pertains to both <rev> and <range>.)
+
+   [(-p <parent>)...]
+   (Any number of option -p, each with one <parent> argument.)
+
+   git remote set-head <name> (-a | -d | <branch>)
+   (One and only one of "-a", "-d" or "<branch>" _must_ (no square
+   brackets) be provided.)
+
+ And a somewhat more contrived example:
+   --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+   Here "=" is outside the brackets, because "--diff-filter=" is a
+   valid usage.  "*" has its own pair of brackets, because it can
+   (optionally) be specified only when one or more of the letters is
+   also provided.
+
+  A note on notation:
+   Use 'git' (all lowercase) when talking about commands i.e. something
+   the user would type into a shell and use 'Git' (uppercase first letter)
+   when talking about the version control system and its properties.
+
+ A few commented examples follow to provide reference when writing or
+ modifying paragraphs or option/command explanations that contain options
+ or commands:
+
+ Literal examples (e.g. use of command-line options, command names,
+ branch names, URLs, pathnames (files and directories), configuration and
+ environment variables) must be typeset in monospace (i.e. wrapped with
+ backticks):
+   `--pretty=oneline`
+   `git rev-list`
+   `remote.pushDefault`
+   `http://git.example.com`
+   `.git/config`
+   `GIT_DIR`
+   `HEAD`
+
+ An environment variable must be prefixed with "$" only when referring to its
+ value and not when referring to the variable itself, in this case there is
+ nothing to add except the backticks:
+   `GIT_DIR` is specified
+   `$GIT_DIR/hooks/pre-receive`
+
+ Word phrases enclosed in `backtick characters` are rendered literally
+ and will not be further expanded. The use of `backticks` to achieve the
+ previous rule means that literal examples should not use AsciiDoc
+ escapes.
+   Correct:
+      `--pretty=oneline`
+   Incorrect:
+      `\--pretty=oneline`
+
+ If some place in the documentation needs to typeset a command usage
+ example with inline substitutions, it is fine to use +monospaced and
+ inline substituted text+ instead of `monospaced literal text`, and with
+ the former, the part that should not get substituted must be
+ quoted/escaped.
diff --git a/external/docs/asciidoc/9c32b5e746e13047c56b6acd89d1308b139d8cd1 b/external/docs/asciidoc/9c32b5e746e13047c56b6acd89d1308b139d8cd1
new file mode 100644
index 0000000000..ba047ed224
--- /dev/null
+++ b/external/docs/asciidoc/9c32b5e746e13047c56b6acd89d1308b139d8cd1
@@ -0,0 +1,947 @@
+Like other projects, we also have some guidelines for our code.  For
+Git in general, a few rough rules are:
+
+ - Most importantly, we never say "It's in POSIX; we'll happily
+   ignore your needs should your system not conform to it."
+   We live in the real world.
+
+ - However, we often say "Let's stay away from that construct,
+   it's not even in POSIX".
+
+ - In spite of the above two rules, we sometimes say "Although
+   this is not in POSIX, it (is so convenient | makes the code
+   much more readable | has other good characteristics) and
+   practically all the platforms we care about support it, so
+   let's use it".
+
+   Again, we live in the real world, and it is sometimes a
+   judgement call, the decision based more on real world
+   constraints people face than what the paper standard says.
+
+ - Fixing style violations while working on a real change as a
+   preparatory clean-up step is good, but otherwise avoid useless code
+   churn for the sake of conforming to the style.
+
+   "Once it _is_ in the tree, it's not really worth the patch noise to
+   go and fix it up."
+   Cf. https://lore.kernel.org/all/20100126160632.3bdbe172.akpm@linux-foundation.org/
+
+ - Log messages to explain your changes are as important as the
+   changes themselves.  Clearly written code and in-code comments
+   explain how the code works and what is assumed from the surrounding
+   context.  The log messages explain what the changes wanted to
+   achieve and why the changes were necessary (more on this in the
+   accompanying SubmittingPatches document).
+
+Make your code readable and sensible, and don't try to be clever.
+
+As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the _local_
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code are expected to match the style the surrounding code already
+uses (even if it doesn't match the overall style of existing code).
+
+But if you must have a list of rules, here are some language
+specific ones. Note that Documentation/ToolsForGit.txt document
+has a collection of tips to help you use some external tools
+to conform to these guidelines.
+
+For shell scripts specifically (not exhaustive):
+
+ - We use tabs for indentation.
+
+ - Case arms are indented at the same depth as case and esac lines,
+   like this:
+
+	case "$variable" in
+	pattern1)
+		do this
+		;;
+	pattern2)
+		do that
+		;;
+	esac
+
+ - Redirection operators should be written with space before, but no
+   space after them.  In other words, write 'echo test >"$file"'
+   instead of 'echo test> $file' or 'echo test > $file'.  Note that
+   even though it is not required by POSIX to double-quote the
+   redirection target in a variable (as shown above), our code does so
+   because some versions of bash issue a warning without the quotes.
+
+	(incorrect)
+	cat hello > world < universe
+	echo hello >$world
+
+	(correct)
+	cat hello >world <universe
+	echo hello >"$world"
+
+ - We prefer $( ... ) for command substitution; unlike ``, it
+   properly nests.  It should have been the way Bourne spelled
+   it from day one, but unfortunately isn't.
+
+ - If you want to find out if a command is available on the user's
+   $PATH, you should use 'type <command>', instead of 'which <command>'.
+   The output of 'which' is not machine parsable and its exit code
+   is not reliable across platforms.
+
+ - We use POSIX compliant parameter substitutions and avoid bashisms;
+   namely:
+
+   - We use ${parameter-word} and its [-=?+] siblings, and their
+     colon'ed "unset or null" form.
+
+   - We use ${parameter#word} and its [#%] siblings, and their
+     doubled "longest matching" form.
+
+   - No "Substring Expansion" ${parameter:offset:length}.
+
+   - No shell arrays.
+
+   - No pattern replacement ${parameter/pattern/string}.
+
+ - We use Arithmetic Expansion $(( ... )).
+
+ - We do not use Process Substitution <(list) or >(list).
+
+ - Do not write control structures on a single line with semicolon.
+   "then" should be on the next line for if statements, and "do"
+   should be on the next line for "while" and "for".
+
+	(incorrect)
+	if test -f hello; then
+		do this
+	fi
+
+	(correct)
+	if test -f hello
+	then
+		do this
+	fi
+
+ - If a command sequence joined with && or || or | spans multiple
+   lines, put each command on a separate line and put && and || and |
+   operators at the end of each line, rather than the start. This
+   means you don't need to use \ to join lines, since the above
+   operators imply the sequence isn't finished.
+
+	(incorrect)
+	grep blob verify_pack_result \
+	| awk -f print_1.awk \
+	| sort >actual &&
+	...
+
+	(correct)
+	grep blob verify_pack_result |
+	awk -f print_1.awk |
+	sort >actual &&
+	...
+
+ - We prefer "test" over "[ ... ]".
+
+ - We do not write the noiseword "function" in front of shell
+   functions.
+
+ - We prefer a space between the function name and the parentheses,
+   and no space inside the parentheses. The opening "{" should also
+   be on the same line.
+
+	(incorrect)
+	my_function(){
+		...
+
+	(correct)
+	my_function () {
+		...
+
+ - As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+   [::], [==], or [..]) for portability.
+
+   - We do not use \{m,n\};
+
+   - We do not use ? or + (which are \{0,1\} and \{1,\}
+     respectively in BRE) but that goes without saying as these
+     are ERE elements not BRE (note that \? and \+ are not even part
+     of BRE -- making them accessible from BRE is a GNU extension).
+
+ - Use Git's gettext wrappers in git-sh-i18n to make the user
+   interface translatable. See "Marking strings for translation" in
+   po/README.
+
+ - We do not write our "test" command with "-a" and "-o" and use "&&"
+   or "||" to concatenate multiple "test" commands instead, because
+   the use of "-a/-o" is often error-prone.  E.g.
+
+     test -n "$x" -a "$a" = "$b"
+
+   is buggy and breaks when $x is "=", but
+
+     test -n "$x" && test "$a" = "$b"
+
+   does not have such a problem.
+
+ - Even though "local" is not part of POSIX, we make heavy use of it
+   in our test suite.  We do not use it in scripted Porcelains, and
+   hopefully nobody starts using "local" before all shells that matter
+   support it (notably, ksh from AT&T Research does not support it yet).
+
+ - Some versions of shell do not understand "export variable=value",
+   so we write "variable=value" and then "export variable" on two
+   separate lines.
+
+ - Some versions of dash have broken variable assignment when prefixed
+   with "local", "export", and "readonly", in that the value to be
+   assigned goes through field splitting at $IFS unless quoted.
+
+	(incorrect)
+	local variable=$value
+	local variable=$(command args)
+
+	(correct)
+	local variable="$value"
+	local variable="$(command args)"
+
+ - The common construct
+
+	VAR=VAL command args
+
+   to temporarily set and export environment variable VAR only while
+   "command args" is running is handy, but this triggers an
+   unspecified behaviour according to POSIX when used for a command
+   that is not an external command (like shell functions).  Indeed,
+   dash 0.5.10.2-6 on Ubuntu 20.04, /bin/sh on FreeBSD 13, and AT&T
+   ksh all make a temporary assignment without exporting the variable,
+   in such a case.  As it does not work portably across shells, do not
+   use this syntax for shell functions.  A common workaround is to do
+   an explicit export in a subshell, like so:
+
+	(incorrect)
+	VAR=VAL func args
+
+	(correct)
+	(
+		VAR=VAL &&
+		export VAR &&
+		func args
+	)
+
+   but be careful that the effect "func" makes to the variables in the
+   current shell will be lost across the subshell boundary.
+
+ - Use octal escape sequences (e.g. "\302\242"), not hexadecimal (e.g.
+   "\xc2\xa2") in printf format strings, since hexadecimal escape
+   sequences are not portable.
+
+
+For C programs:
+
+ - We use tabs to indent, and interpret tabs as taking up to
+   8 spaces.
+
+ - Nested C preprocessor directives are indented after the hash by one
+   space per nesting level.
+
+	#if FOO
+	# include <foo.h>
+	# if BAR
+	#  include <bar.h>
+	# endif
+	#endif
+
+ - We try to keep to at most 80 characters per line.
+
+ - As a Git developer we assume you have a reasonably modern compiler
+   and we recommend you to enable the DEVELOPER makefile knob to
+   ensure your patch is clear of all compiler warnings we care about,
+   by e.g. "echo DEVELOPER=1 >>config.mak".
+
+ - When using DEVELOPER=1 mode, you may see warnings from the compiler
+   like "error: unused parameter 'foo' [-Werror=unused-parameter]",
+   which indicates that a function ignores its argument. If the unused
+   parameter can't be removed (e.g., because the function is used as a
+   callback and has to match a certain interface), you can annotate
+   the individual parameters with the UNUSED (or MAYBE_UNUSED)
+   keyword, like "int foo UNUSED".
+
+ - We try to support a wide range of C compilers to compile Git with,
+   including old ones.  As of Git v2.35.0 Git requires C99 (we check
+   "__STDC_VERSION__"). You should not use features from a newer C
+   standard, even if your compiler groks them.
+
+   New C99 features have been phased in gradually, if something's new
+   in C99 but not used yet don't assume that it's safe to use, some
+   compilers we target have only partial support for it. These are
+   considered safe to use:
+
+   . since around 2007 with 2b6854c863a, we have been using
+     initializer elements which are not computable at load time. E.g.:
+
+	const char *args[] = { "constant", variable, NULL };
+
+   . since early 2012 with e1327023ea, we have been using an enum
+     definition whose last element is followed by a comma.  This, like
+     an array initializer that ends with a trailing comma, can be used
+     to reduce the patch noise when adding a new identifier at the end.
+
+   . since mid 2017 with cbc0f81d, we have been using designated
+     initializers for struct (e.g. "struct t v = { .val = 'a' };").
+
+   . since mid 2017 with 512f41cf, we have been using designated
+     initializers for array (e.g. "int array[10] = { [5] = 2 }").
+
+   . since early 2021 with 765dc168882, we have been using variadic
+     macros, mostly for printf-like trace and debug macros.
+
+   . since late 2021 with 44ba10d6, we have had variables declared in
+     the for loop "for (int i = 0; i < 10; i++)".
+
+   New C99 features that we cannot use yet:
+
+   . %z and %zu as a printf() argument for a size_t (the %z being for
+     the POSIX-specific ssize_t). Instead you should use
+     printf("%"PRIuMAX, (uintmax_t)v).  These days the MSVC version we
+     rely on supports %z, but the C library used by MinGW does not.
+
+   . Shorthand like ".a.b = *c" in struct initializations is known to
+     trip up an older IBM XLC version, use ".a = { .b = *c }" instead.
+     See the 33665d98 (reftable: make assignments portable to AIX xlc
+     v12.01, 2022-03-28).
+
+ - Variables have to be declared at the beginning of the block, before
+   the first statement (i.e. -Wdeclaration-after-statement).  It is
+   encouraged to have a blank line between the end of the declarations
+   and the first statement in the block.
+
+ - NULL pointers shall be written as NULL, not as 0.
+
+ - When declaring pointers, the star sides with the variable
+   name, i.e. "char *string", not "char* string" or
+   "char * string".  This makes it easier to understand code
+   like "char *string, c;".
+
+ - Use whitespace around operators and keywords, but not inside
+   parentheses and not around functions. So:
+
+        while (condition)
+		func(bar + 1);
+
+   and not:
+
+        while( condition )
+		func (bar+1);
+
+ - A binary operator (other than ",") and ternary conditional "?:"
+   have a space on each side of the operator to separate it from its
+   operands.  E.g. "A + 1", not "A+1".
+
+ - A unary operator (other than "." and "->") have no space between it
+   and its operand.  E.g. "(char *)ptr", not "(char *) ptr".
+
+ - Do not explicitly compare an integral value with constant 0 or '\0',
+   or a pointer value with constant NULL.  For instance, to validate that
+   counted array <ptr, cnt> is initialized but has no elements, write:
+
+	if (!ptr || cnt)
+		BUG("empty array expected");
+
+   and not:
+
+	if (ptr == NULL || cnt != 0);
+		BUG("empty array expected");
+
+ - We avoid using braces unnecessarily.  I.e.
+
+	if (bla) {
+		x = 1;
+	}
+
+   is frowned upon. But there are a few exceptions:
+
+	- When the statement extends over a few lines (e.g., a while loop
+	  with an embedded conditional, or a comment). E.g.:
+
+		while (foo) {
+			if (x)
+				one();
+			else
+				two();
+		}
+
+		if (foo) {
+			/*
+			 * This one requires some explanation,
+			 * so we're better off with braces to make
+			 * it obvious that the indentation is correct.
+			 */
+			doit();
+		}
+
+	- When there are multiple arms to a conditional and some of them
+	  require braces, enclose even a single line block in braces for
+	  consistency. E.g.:
+
+		if (foo) {
+			doit();
+		} else {
+			one();
+			two();
+			three();
+		}
+
+ - We try to avoid assignments in the condition of an "if" statement.
+
+ - Try to make your code understandable.  You may put comments
+   in, but comments invariably tend to stale out when the code
+   they were describing changes.  Often splitting a function
+   into two makes the intention of the code much clearer.
+
+ - Multi-line comments include their delimiters on separate lines from
+   the text.  E.g.
+
+	/*
+	 * A very long
+	 * multi-line comment.
+	 */
+
+   Note however that a comment that explains a translatable string to
+   translators uses a convention of starting with a magic token
+   "TRANSLATORS: ", e.g.
+
+	/*
+	 * TRANSLATORS: here is a comment that explains the string to
+	 * be translated, that follows immediately after it.
+	 */
+	_("Here is a translatable string explained by the above.");
+
+ - Double negation is often harder to understand than no negation
+   at all.
+
+ - There are two schools of thought when it comes to comparison,
+   especially inside a loop. Some people prefer to have the less stable
+   value on the left hand side and the more stable value on the right hand
+   side, e.g. if you have a loop that counts variable i down to the
+   lower bound,
+
+	while (i > lower_bound) {
+		do something;
+		i--;
+	}
+
+   Other people prefer to have the textual order of values match the
+   actual order of values in their comparison, so that they can
+   mentally draw a number line from left to right and place these
+   values in order, i.e.
+
+	while (lower_bound < i) {
+		do something;
+		i--;
+	}
+
+   Both are valid, and we use both.  However, the more "stable" the
+   stable side becomes, the more we tend to prefer the former
+   (comparison with a constant, "i > 0", is an extreme example).
+   Just do not mix styles in the same part of the code and mimic
+   existing styles in the neighbourhood.
+
+ - There are two schools of thought when it comes to splitting a long
+   logical line into multiple lines.  Some people push the second and
+   subsequent lines far enough to the right with tabs and align them:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+		span_more_than_a_single_line_of ||
+		the_source_text) {
+                ...
+
+   while other people prefer to align the second and the subsequent
+   lines with the column immediately inside the opening parenthesis,
+   with tabs and spaces, following our "tabstop is always a multiple
+   of 8" convention:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of ||
+	    the_source_text) {
+                ...
+
+   Both are valid, and we use both.  Again, just do not mix styles in
+   the same part of the code and mimic existing styles in the
+   neighbourhood.
+
+ - When splitting a long logical line, some people change line before
+   a binary operator, so that the result looks like a parse tree when
+   you turn your head 90-degrees counterclockwise:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to
+	    || span_more_than_a_single_line_of_the_source_text) {
+
+   while other people prefer to leave the operator at the end of the
+   line:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of_the_source_text) {
+
+   Both are valid, but we tend to use the latter more, unless the
+   expression gets fairly complex, in which case the former tends to
+   be easier to read.  Again, just do not mix styles in the same part
+   of the code and mimic existing styles in the neighbourhood.
+
+ - When splitting a long logical line, with everything else being
+   equal, it is preferable to split after the operator at higher
+   level in the parse tree.  That is, this is more preferable:
+
+	if (a_very_long_variable * that_is_used_in +
+	    a_very_long_expression) {
+		...
+
+   than
+
+	if (a_very_long_variable *
+	    that_is_used_in + a_very_long_expression) {
+		...
+
+ - Some clever tricks, like using the !! operator with arithmetic
+   constructs, can be extremely confusing to others.  Avoid them,
+   unless there is a compelling reason to use them.
+
+ - Use the API.  No, really.  We have a strbuf (variable length
+   string), several arrays with the ALLOC_GROW() macro, a
+   string_list for sorted string lists, a hash map (mapping struct
+   objects) named "struct decorate", amongst other things.
+
+ - When you come up with an API, document its functions and structures
+   in the header file that exposes the API to its callers. Use what is
+   in "strbuf.h" as a model for the appropriate tone and level of
+   detail.
+
+ - The first #include in C files, except in platform specific compat/
+   implementations and sha1dc/, must be <git-compat-util.h>.  This
+   header file insulates other header files and source files from
+   platform differences, like which system header files must be
+   included in what order, and what C preprocessor feature macros must
+   be defined to trigger certain features we expect out of the system.
+   A collorary to this is that C files should not directly include
+   system header files themselves.
+
+   There are some exceptions, because certain group of files that
+   implement an API all have to include the same header file that
+   defines the API and it is convenient to include <git-compat-util.h>
+   there.  Namely:
+
+   - the implementation of the built-in commands in the "builtin/"
+     directory that include "builtin.h" for the cmd_foo() prototype
+     definition,
+
+   - the test helper programs in the "t/helper/" directory that include
+     "t/helper/test-tool.h" for the cmd__foo() prototype definition,
+
+   - the xdiff implementation in the "xdiff/" directory that includes
+     "xdiff/xinclude.h" for the xdiff machinery internals,
+
+   - the unit test programs in "t/unit-tests/" directory that include
+     "t/unit-tests/test-lib.h" that gives them the unit-tests
+     framework, and
+
+   - the source files that implement reftable in the "reftable/"
+     directory that include "reftable/system.h" for the reftable
+     internals,
+
+   are allowed to assume that they do not have to include
+   <git-compat-util.h> themselves, as it is included as the first
+   '#include' in these header files.  These headers must be the first
+   header file to be "#include"d in them, though.
+
+ - A C file must directly include the header files that declare the
+   functions and the types it uses, except for the functions and types
+   that are made available to it by including one of the header files
+   it must include by the previous rule.
+
+ - If you are planning a new command, consider writing it in shell
+   or perl first, so that changes in semantics can be easily
+   changed and discussed.  Many Git commands started out like
+   that, and a few are still scripts.
+
+ - Avoid introducing a new dependency into Git. This means you
+   usually should stay away from scripting languages not already
+   used in the Git core command set (unless your command is clearly
+   separate from it, such as an importer to convert random-scm-X
+   repositories to Git).
+
+ - When we pass <string, length> pair to functions, we should try to
+   pass them in that order.
+
+ - Use Git's gettext wrappers to make the user interface
+   translatable. See "Marking strings for translation" in po/README.
+
+ - Variables and functions local to a given source file should be marked
+   with "static". Variables that are visible to other source files
+   must be declared with "extern" in header files. However, function
+   declarations should not use "extern", as that is already the default.
+
+ - You can launch gdb around your program using the shorthand GIT_DEBUGGER.
+   Run `GIT_DEBUGGER=1 ./bin-wrappers/git foo` to simply use gdb as is, or
+   run `GIT_DEBUGGER="<debugger> <debugger-args>" ./bin-wrappers/git foo` to
+   use your own debugger and arguments. Example: `GIT_DEBUGGER="ddd --gdb"
+   ./bin-wrappers/git log` (See `bin-wrappers/wrap-for-bin.sh`.)
+
+ - The primary data structure that a subsystem 'S' deals with is called
+   `struct S`. Functions that operate on `struct S` are named
+   `S_<verb>()` and should generally receive a pointer to `struct S` as
+   first parameter. E.g.
+
+	struct strbuf;
+
+	void strbuf_add(struct strbuf *buf, ...);
+
+	void strbuf_reset(struct strbuf *buf);
+
+    is preferred over:
+
+	struct strbuf;
+
+	void add_string(struct strbuf *buf, ...);
+
+	void reset_strbuf(struct strbuf *buf);
+
+ - There are several common idiomatic names for functions performing
+   specific tasks on a structure `S`:
+
+    - `S_init()` initializes a structure without allocating the
+      structure itself.
+
+    - `S_release()` releases a structure's contents without freeing the
+      structure.
+
+    - `S_clear()` is equivalent to `S_release()` followed by `S_init()`
+      such that the structure is directly usable after clearing it. When
+      `S_clear()` is provided, `S_init()` shall not allocate resources
+      that need to be released again.
+
+    - `S_free()` releases a structure's contents and frees the
+      structure.
+
+ - Function names should be clear and descriptive, accurately reflecting
+   their purpose or behavior. Arbitrary suffixes that do not add meaningful
+   context can lead to confusion, particularly for newcomers to the codebase.
+
+   Historically, the '_1' suffix has been used in situations where:
+
+   - A function handles one element among a group that requires similar
+     processing.
+   - A recursive function has been separated from its setup phase.
+
+   The '_1' suffix can be used as a concise way to indicate these specific
+   cases. However, it is recommended to find a more descriptive name wherever
+   possible to improve the readability and maintainability of the code.
+
+For Perl programs:
+
+ - Most of the C guidelines above apply.
+
+ - We try to support Perl 5.8.1 and later ("use Perl 5.008001").
+
+ - use strict and use warnings are strongly preferred.
+
+ - Don't overuse statement modifiers unless using them makes the
+   result easier to follow.
+
+	... do something ...
+	do_this() unless (condition);
+        ... do something else ...
+
+   is more readable than:
+
+	... do something ...
+	unless (condition) {
+		do_this();
+	}
+        ... do something else ...
+
+   *only* when the condition is so rare that do_this() will be almost
+   always called.
+
+ - We try to avoid assignments inside "if ()" conditions.
+
+ - Learn and use Git.pm if you need that functionality.
+
+For Python scripts:
+
+ - We follow PEP-8 (https://peps.python.org/pep-0008/).
+
+ - As a minimum, we aim to be compatible with Python 2.7.
+
+ - Where required libraries do not restrict us to Python 2, we try to
+   also be compatible with Python 3.1 and later.
+
+
+Program Output
+
+ We make a distinction between a Git command's primary output and
+ output which is merely chatty feedback (for instance, status
+ messages, running transcript, or progress display), as well as error
+ messages. Roughly speaking, a Git command's primary output is that
+ which one might want to capture to a file or send down a pipe; its
+ chatty output should not interfere with these use-cases.
+
+ As such, primary output should be sent to the standard output stream
+ (stdout), and chatty output should be sent to the standard error
+ stream (stderr). Examples of commands which produce primary output
+ include `git log`, `git show`, and `git branch --list` which generate
+ output on the stdout stream.
+
+ Not all Git commands have primary output; this is often true of
+ commands whose main function is to perform an action. Some action
+ commands are silent, whereas others are chatty. An example of a
+ chatty action commands is `git clone` with its "Cloning into
+ '<path>'..." and "Checking connectivity..." status messages which it
+ sends to the stderr stream.
+
+ Error messages from Git commands should always be sent to the stderr
+ stream.
+
+
+Error Messages
+
+ - Do not end a single-sentence error message with a full stop.
+
+ - Do not capitalize the first word, only because it is the first word
+   in the message ("unable to open '%s'", not "Unable to open '%s'").  But
+   "SHA-3 not supported" is fine, because the reason the first word is
+   capitalized is not because it is at the beginning of the sentence,
+   but because the word would be spelled in capital letters even when
+   it appeared in the middle of the sentence.
+
+ - Say what the error is first ("cannot open '%s'", not "%s: cannot open").
+
+ - Enclose the subject of an error inside a pair of single quotes,
+   e.g. `die(_("unable to open '%s'"), path)`.
+
+ - Unless there is a compelling reason not to, error messages from
+   porcelain commands should be marked for translation, e.g.
+   `die(_("bad revision %s"), revision)`.
+
+ - Error messages from the plumbing commands are sometimes meant for
+   machine consumption and should not be marked for translation,
+   e.g., `die("bad revision %s", revision)`.
+
+ - BUG("message") are for communicating the specific error to developers,
+   thus should not be translated.
+
+
+Externally Visible Names
+
+ - For configuration variable names, follow the existing convention:
+
+   . The section name indicates the affected subsystem.
+
+   . The subsection name, if any, indicates which of an unbounded set
+     of things to set the value for.
+
+   . The variable name describes the effect of tweaking this knob.
+
+   The section and variable names that consist of multiple words are
+   formed by concatenating the words without punctuation marks (e.g. `-`),
+   and are broken using bumpyCaps in documentation as a hint to the
+   reader.
+
+   When choosing the variable namespace, do not use variable name for
+   specifying possibly unbounded set of things, most notably anything
+   an end user can freely come up with (e.g. branch names).  Instead,
+   use subsection names or variable values, like the existing variable
+   branch.<name>.description does.
+
+
+Writing Documentation:
+
+ Most (if not all) of the documentation pages are written in the
+ AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+ processed into HTML and manpages (e.g. git.html and git.1 in the
+ same directory).
+
+ The documentation liberally mixes US and UK English (en_US/UK)
+ norms for spelling and grammar, which is somewhat unfortunate.
+ In an ideal world, it would have been better if it consistently
+ used only one and not the other, and we would have picked en_US
+ (if you wish to correct the English of some of the existing
+ documentation, please see the documentation-related advice in the
+ Documentation/SubmittingPatches file).
+
+ In order to ensure the documentation is inclusive, avoid assuming
+ that an unspecified example person is male or female, and think
+ twice before using "he", "him", "she", or "her".  Here are some
+ tips to avoid use of gendered pronouns:
+
+  - Prefer succinctness and matter-of-factly describing functionality
+    in the abstract.  E.g.
+
+     `--short`:: Emit output in the short-format.
+
+    and avoid something like these overly verbose alternatives:
+
+     `--short`:: Use this to emit output in the short-format.
+     `--short`:: You can use this to get output in the short-format.
+     `--short`:: A user who prefers shorter output could....
+     `--short`:: Should a person and/or program want shorter output, he
+                 she/they/it can...
+
+    This practice often eliminates the need to involve human actors in
+    your description, but it is a good practice regardless of the
+    avoidance of gendered pronouns.
+
+  - When it becomes awkward to stick to this style, prefer "you" when
+    addressing the hypothetical user, and possibly "we" when
+    discussing how the program might react to the user.  E.g.
+
+      You can use this option instead of `--xyz`, but we might remove
+      support for it in future versions.
+
+    while keeping in mind that you can probably be less verbose, e.g.
+
+      Use this instead of `--xyz`. This option might be removed in future
+      versions.
+
+  - If you still need to refer to an example person that is
+    third-person singular, you may resort to "singular they" to avoid
+    "he/she/him/her", e.g.
+
+      A contributor asks their upstream to pull from them.
+
+    Note that this sounds ungrammatical and unnatural to those who
+    learned that "they" is only used for third-person plural, e.g.
+    those who learn English as a second language in some parts of the
+    world.
+
+ Every user-visible change should be reflected in the documentation.
+ The same general rule as for code applies -- imitate the existing
+ conventions.
+
+
+Markup:
+
+ Literal parts (e.g. use of command-line options, command names,
+ branch names, URLs, pathnames (files and directories), configuration and
+ environment variables) must be typeset as verbatim (i.e. wrapped with
+ backticks):
+   `--pretty=oneline`
+   `git rev-list`
+   `remote.pushDefault`
+   `http://git.example.com`
+   `.git/config`
+   `GIT_DIR`
+   `HEAD`
+   `umask`(2)
+
+ An environment variable must be prefixed with "$" only when referring to its
+ value and not when referring to the variable itself, in this case there is
+ nothing to add except the backticks:
+   `GIT_DIR` is specified
+   `$GIT_DIR/hooks/pre-receive`
+
+ Word phrases enclosed in `backtick characters` are rendered literally
+ and will not be further expanded. The use of `backticks` to achieve the
+ previous rule means that literal examples should not use AsciiDoc
+ escapes.
+   Correct:
+      `--pretty=oneline`
+   Incorrect:
+      `\--pretty=oneline`
+
+ Placeholders are spelled in lowercase and enclosed in
+ angle brackets surrounded by underscores:
+   _<file>_
+   _<commit>_
+
+ If a placeholder has multiple words, they are separated by dashes:
+   _<new-branch-name>_
+   _<template-directory>_
+
+ When needed, use a distinctive identifier for placeholders, usually
+ made of a qualification and a type:
+   _<git-dir>_
+   _<key-id>_
+
+ Git's Asciidoc processor has been tailored to treat backticked text
+ as complex synopsis. When literal and placeholders are mixed, you can
+ use the backtick notation which will take care of correctly typesetting
+ the content.
+   `--jobs <n>`
+   `--sort=<key>`
+   `<directory>/.git`
+   `remote.<name>.mirror`
+   `ssh://[<user>@]<host>[:<port>]/<path-to-git-repo>`
+
+As a side effect, backquoted placeholders are correctly typeset, but
+this style is not recommended.
+
+Synopsis Syntax
+
+ The synopsis (a paragraph with [synopsis] attribute) is automatically
+ formatted by the toolchain and does not need typesetting.
+
+ A few commented examples follow to provide reference when writing or
+ modifying command usage strings and synopsis sections in the manual
+ pages:
+
+ Possibility of multiple occurrences is indicated by three dots:
+   <file>...
+   (One or more of <file>.)
+
+ Optional parts are enclosed in square brackets:
+   [<file>...]
+   (Zero or more of <file>.)
+
+ An optional parameter needs to be typeset with unconstrained pairs
+   [<repository>]
+
+   --exec-path[=<path>]
+   (Option with an optional argument.  Note that the "=" is inside the
+   brackets.)
+
+   [<patch>...]
+   (Zero or more of <patch>.  Note that the dots are inside, not
+   outside the brackets.)
+
+ Multiple alternatives are indicated with vertical bars:
+   [-q | --quiet]
+   [--utf8 | --no-utf8]
+
+ Use spacing around "|" token(s), but not immediately after opening or
+ before closing a [] or () pair:
+   Do: [-q | --quiet]
+   Don't: [-q|--quiet]
+
+ Don't use spacing around "|" tokens when they're used to separate the
+ alternate arguments of an option:
+    Do: --track[=(direct|inherit)]
+    Don't: --track[=(direct | inherit)]
+
+ Parentheses are used for grouping:
+   [(<rev>|<range>)...]
+   (Any number of either <rev> or <range>.  Parens are needed to make
+   it clear that "..." pertains to both <rev> and <range>.)
+
+   [(-p <parent>)...]
+   (Any number of option -p, each with one <parent> argument.)
+
+   git remote set-head <name> (-a|-d|<branch>)
+   (One and only one of "-a", "-d" or "<branch>" _must_ (no square
+   brackets) be provided.)
+
+ And a somewhat more contrived example:
+   --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+   Here "=" is outside the brackets, because "--diff-filter=" is a
+   valid usage.  "*" has its own pair of brackets, because it can
+   (optionally) be specified only when one or more of the letters is
+   also provided.
+
+  A note on notation:
+   Use 'git' (all lowercase) when talking about commands i.e. something
+   the user would type into a shell and use 'Git' (uppercase first letter)
+   when talking about the version control system and its properties.
+
+ If some place in the documentation needs to typeset a command usage
+ example with inline substitutions, it is fine to use +monospaced and
+ inline substituted text+ instead of `monospaced literal text`, and with
+ the former, the part that should not get substituted must be
+ quoted/escaped.
diff --git a/external/docs/asciidoc/a3aac268363085b0e36d5392bafb6bc7c2e17d1a b/external/docs/asciidoc/a3aac268363085b0e36d5392bafb6bc7c2e17d1a
new file mode 100644
index 0000000000..4cd95da6b1
--- /dev/null
+++ b/external/docs/asciidoc/a3aac268363085b0e36d5392bafb6bc7c2e17d1a
@@ -0,0 +1,557 @@
+Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, a few rough rules are:
+
+ - Most importantly, we never say "It's in POSIX; we'll happily
+   ignore your needs should your system not conform to it."
+   We live in the real world.
+
+ - However, we often say "Let's stay away from that construct,
+   it's not even in POSIX".
+
+ - In spite of the above two rules, we sometimes say "Although
+   this is not in POSIX, it (is so convenient | makes the code
+   much more readable | has other good characteristics) and
+   practically all the platforms we care about support it, so
+   let's use it".
+
+   Again, we live in the real world, and it is sometimes a
+   judgement call, the decision based more on real world
+   constraints people face than what the paper standard says.
+
+ - Fixing style violations while working on a real change as a
+   preparatory clean-up step is good, but otherwise avoid useless code
+   churn for the sake of conforming to the style.
+
+   "Once it _is_ in the tree, it's not really worth the patch noise to
+   go and fix it up."
+   Cf. http://article.gmane.org/gmane.linux.kernel/943020
+
+Make your code readable and sensible, and don't try to be clever.
+
+As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the _local_
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn't match the overall style of existing code).
+
+But if you must have a list of rules, here they are.
+
+For shell scripts specifically (not exhaustive):
+
+ - We use tabs for indentation.
+
+ - Case arms are indented at the same depth as case and esac lines,
+   like this:
+
+	case "$variable" in
+	pattern1)
+		do this
+		;;
+	pattern2)
+		do that
+		;;
+	esac
+
+ - Redirection operators should be written with space before, but no
+   space after them.  In other words, write 'echo test >"$file"'
+   instead of 'echo test> $file' or 'echo test > $file'.  Note that
+   even though it is not required by POSIX to double-quote the
+   redirection target in a variable (as shown above), our code does so
+   because some versions of bash issue a warning without the quotes.
+
+	(incorrect)
+	cat hello > world < universe
+	echo hello >$world
+
+	(correct)
+	cat hello >world <universe
+	echo hello >"$world"
+
+ - We prefer $( ... ) for command substitution; unlike ``, it
+   properly nests.  It should have been the way Bourne spelled
+   it from day one, but unfortunately isn't.
+
+ - If you want to find out if a command is available on the user's
+   $PATH, you should use 'type <command>', instead of 'which <command>'.
+   The output of 'which' is not machine parseable and its exit code
+   is not reliable across platforms.
+
+ - We use POSIX compliant parameter substitutions and avoid bashisms;
+   namely:
+
+   - We use ${parameter-word} and its [-=?+] siblings, and their
+     colon'ed "unset or null" form.
+
+   - We use ${parameter#word} and its [#%] siblings, and their
+     doubled "longest matching" form.
+
+   - No "Substring Expansion" ${parameter:offset:length}.
+
+   - No shell arrays.
+
+   - No strlen ${#parameter}.
+
+   - No pattern replacement ${parameter/pattern/string}.
+
+ - We use Arithmetic Expansion $(( ... )).
+
+ - Inside Arithmetic Expansion, spell shell variables with $ in front
+   of them, as some shells do not grok $((x)) while accepting $(($x))
+   just fine (e.g. dash older than 0.5.4).
+
+ - We do not use Process Substitution <(list) or >(list).
+
+ - Do not write control structures on a single line with semicolon.
+   "then" should be on the next line for if statements, and "do"
+   should be on the next line for "while" and "for".
+
+	(incorrect)
+	if test -f hello; then
+		do this
+	fi
+
+	(correct)
+	if test -f hello
+	then
+		do this
+	fi
+
+ - We prefer "test" over "[ ... ]".
+
+ - We do not write the noiseword "function" in front of shell
+   functions.
+
+ - We prefer a space between the function name and the parentheses,
+   and no space inside the parentheses. The opening "{" should also
+   be on the same line.
+
+	(incorrect)
+	my_function(){
+		...
+
+	(correct)
+	my_function () {
+		...
+
+ - As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+   [::], [==], or [..]) for portability.
+
+   - We do not use \{m,n\};
+
+   - We do not use -E;
+
+   - We do not use ? or + (which are \{0,1\} and \{1,\}
+     respectively in BRE) but that goes without saying as these
+     are ERE elements not BRE (note that \? and \+ are not even part
+     of BRE -- making them accessible from BRE is a GNU extension).
+
+ - Use Git's gettext wrappers in git-sh-i18n to make the user
+   interface translatable. See "Marking strings for translation" in
+   po/README.
+
+ - We do not write our "test" command with "-a" and "-o" and use "&&"
+   or "||" to concatenate multiple "test" commands instead, because
+   the use of "-a/-o" is often error-prone.  E.g.
+
+     test -n "$x" -a "$a" = "$b"
+
+   is buggy and breaks when $x is "=", but
+
+     test -n "$x" && test "$a" = "$b"
+
+   does not have such a problem.
+
+
+For C programs:
+
+ - We use tabs to indent, and interpret tabs as taking up to
+   8 spaces.
+
+ - We try to keep to at most 80 characters per line.
+
+ - As a Git developer we assume you have a reasonably modern compiler
+   and we recommend you to enable the DEVELOPER makefile knob to
+   ensure your patch is clear of all compiler warnings we care about,
+   by e.g. "echo DEVELOPER=1 >>config.mak".
+
+ - We try to support a wide range of C compilers to compile Git with,
+   including old ones. That means that you should not use C99
+   initializers, even if a lot of compilers grok it.
+
+ - Variables have to be declared at the beginning of the block.
+
+ - NULL pointers shall be written as NULL, not as 0.
+
+ - When declaring pointers, the star sides with the variable
+   name, i.e. "char *string", not "char* string" or
+   "char * string".  This makes it easier to understand code
+   like "char *string, c;".
+
+ - Use whitespace around operators and keywords, but not inside
+   parentheses and not around functions. So:
+
+        while (condition)
+		func(bar + 1);
+
+   and not:
+
+        while( condition )
+		func (bar+1);
+
+ - We avoid using braces unnecessarily.  I.e.
+
+	if (bla) {
+		x = 1;
+	}
+
+   is frowned upon.  A gray area is when the statement extends
+   over a few lines, and/or you have a lengthy comment atop of
+   it.  Also, like in the Linux kernel, if there is a long list
+   of "else if" statements, it can make sense to add braces to
+   single line blocks.
+
+ - We try to avoid assignments in the condition of an "if" statement.
+
+ - Try to make your code understandable.  You may put comments
+   in, but comments invariably tend to stale out when the code
+   they were describing changes.  Often splitting a function
+   into two makes the intention of the code much clearer.
+
+ - Multi-line comments include their delimiters on separate lines from
+   the text.  E.g.
+
+	/*
+	 * A very long
+	 * multi-line comment.
+	 */
+
+   Note however that a comment that explains a translatable string to
+   translators uses a convention of starting with a magic token
+   "TRANSLATORS: " immediately after the opening delimiter, even when
+   it spans multiple lines.  We do not add an asterisk at the beginning
+   of each line, either.  E.g.
+
+	/* TRANSLATORS: here is a comment that explains the string
+	   to be translated, that follows immediately after it */
+	_("Here is a translatable string explained by the above.");
+
+ - Double negation is often harder to understand than no negation
+   at all.
+
+ - There are two schools of thought when it comes to comparison,
+   especially inside a loop. Some people prefer to have the less stable
+   value on the left hand side and the more stable value on the right hand
+   side, e.g. if you have a loop that counts variable i down to the
+   lower bound,
+
+	while (i > lower_bound) {
+		do something;
+		i--;
+	}
+
+   Other people prefer to have the textual order of values match the
+   actual order of values in their comparison, so that they can
+   mentally draw a number line from left to right and place these
+   values in order, i.e.
+
+	while (lower_bound < i) {
+		do something;
+		i--;
+	}
+
+   Both are valid, and we use both.  However, the more "stable" the
+   stable side becomes, the more we tend to prefer the former
+   (comparison with a constant, "i > 0", is an extreme example).
+   Just do not mix styles in the same part of the code and mimic
+   existing styles in the neighbourhood.
+
+ - There are two schools of thought when it comes to splitting a long
+   logical line into multiple lines.  Some people push the second and
+   subsequent lines far enough to the right with tabs and align them:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+		span_more_than_a_single_line_of ||
+		the_source_text) {
+                ...
+
+   while other people prefer to align the second and the subsequent
+   lines with the column immediately inside the opening parenthesis,
+   with tabs and spaces, following our "tabstop is always a multiple
+   of 8" convention:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of ||
+	    the_source_text) {
+                ...
+
+   Both are valid, and we use both.  Again, just do not mix styles in
+   the same part of the code and mimic existing styles in the
+   neighbourhood.
+
+ - When splitting a long logical line, some people change line before
+   a binary operator, so that the result looks like a parse tree when
+   you turn your head 90-degrees counterclockwise:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to
+	    || span_more_than_a_single_line_of_the_source_text) {
+
+   while other people prefer to leave the operator at the end of the
+   line:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of_the_source_text) {
+
+   Both are valid, but we tend to use the latter more, unless the
+   expression gets fairly complex, in which case the former tends to
+   be easier to read.  Again, just do not mix styles in the same part
+   of the code and mimic existing styles in the neighbourhood.
+
+ - When splitting a long logical line, with everything else being
+   equal, it is preferable to split after the operator at higher
+   level in the parse tree.  That is, this is more preferable:
+
+	if (a_very_long_variable * that_is_used_in +
+	    a_very_long_expression) {
+		...
+
+   than
+
+	if (a_very_long_variable *
+	    that_is_used_in + a_very_long_expression) {
+		...
+
+ - Some clever tricks, like using the !! operator with arithmetic
+   constructs, can be extremely confusing to others.  Avoid them,
+   unless there is a compelling reason to use them.
+
+ - Use the API.  No, really.  We have a strbuf (variable length
+   string), several arrays with the ALLOC_GROW() macro, a
+   string_list for sorted string lists, a hash map (mapping struct
+   objects) named "struct decorate", amongst other things.
+
+ - When you come up with an API, document it.
+
+ - The first #include in C files, except in platform specific compat/
+   implementations, must be either "git-compat-util.h", "cache.h" or
+   "builtin.h".  You do not have to include more than one of these.
+
+ - A C file must directly include the header files that declare the
+   functions and the types it uses, except for the functions and types
+   that are made available to it by including one of the header files
+   it must include by the previous rule.
+
+ - If you are planning a new command, consider writing it in shell
+   or perl first, so that changes in semantics can be easily
+   changed and discussed.  Many Git commands started out like
+   that, and a few are still scripts.
+
+ - Avoid introducing a new dependency into Git. This means you
+   usually should stay away from scripting languages not already
+   used in the Git core command set (unless your command is clearly
+   separate from it, such as an importer to convert random-scm-X
+   repositories to Git).
+
+ - When we pass <string, length> pair to functions, we should try to
+   pass them in that order.
+
+ - Use Git's gettext wrappers to make the user interface
+   translatable. See "Marking strings for translation" in po/README.
+
+For Perl programs:
+
+ - Most of the C guidelines above apply.
+
+ - We try to support Perl 5.8 and later ("use Perl 5.008").
+
+ - use strict and use warnings are strongly preferred.
+
+ - Don't overuse statement modifiers unless using them makes the
+   result easier to follow.
+
+	... do something ...
+	do_this() unless (condition);
+        ... do something else ...
+
+   is more readable than:
+
+	... do something ...
+	unless (condition) {
+		do_this();
+	}
+        ... do something else ...
+
+   *only* when the condition is so rare that do_this() will be almost
+   always called.
+
+ - We try to avoid assignments inside "if ()" conditions.
+
+ - Learn and use Git.pm if you need that functionality.
+
+ - For Emacs, it's useful to put the following in
+   GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode:
+
+    ;; note the first part is useful for C editing, too
+    ((nil . ((indent-tabs-mode . t)
+                  (tab-width . 8)
+                  (fill-column . 80)))
+     (cperl-mode . ((cperl-indent-level . 8)
+                    (cperl-extra-newline-before-brace . nil)
+                    (cperl-merge-trailing-else . t))))
+
+For Python scripts:
+
+ - We follow PEP-8 (http://www.python.org/dev/peps/pep-0008/).
+
+ - As a minimum, we aim to be compatible with Python 2.6 and 2.7.
+
+ - Where required libraries do not restrict us to Python 2, we try to
+   also be compatible with Python 3.1 and later.
+
+ - When you must differentiate between Unicode literals and byte string
+   literals, it is OK to use the 'b' prefix.  Even though the Python
+   documentation for version 2.6 does not mention this prefix, it has
+   been supported since version 2.6.0.
+
+Error Messages
+
+ - Do not end error messages with a full stop.
+
+ - Do not capitalize ("unable to open %s", not "Unable to open %s")
+
+ - Say what the error is first ("cannot open %s", not "%s: cannot open")
+
+
+Externally Visible Names
+
+ - For configuration variable names, follow the existing convention:
+
+   . The section name indicates the affected subsystem.
+
+   . The subsection name, if any, indicates which of an unbounded set
+     of things to set the value for.
+
+   . The variable name describes the effect of tweaking this knob.
+
+   The section and variable names that consist of multiple words are
+   formed by concatenating the words without punctuations (e.g. `-`),
+   and are broken using bumpyCaps in documentation as a hint to the
+   reader.
+
+   When choosing the variable namespace, do not use variable name for
+   specifying possibly unbounded set of things, most notably anything
+   an end user can freely come up with (e.g. branch names).  Instead,
+   use subsection names or variable values, like the existing variable
+   branch.<name>.description does.
+
+
+Writing Documentation:
+
+ Most (if not all) of the documentation pages are written in the
+ AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+ processed into HTML and manpages (e.g. git.html and git.1 in the
+ same directory).
+
+ The documentation liberally mixes US and UK English (en_US/UK)
+ norms for spelling and grammar, which is somewhat unfortunate.
+ In an ideal world, it would have been better if it consistently
+ used only one and not the other, and we would have picked en_US
+ (if you wish to correct the English of some of the existing
+ documentation, please see the documentation-related advice in the
+ Documentation/SubmittingPatches file).
+
+ Every user-visible change should be reflected in the documentation.
+ The same general rule as for code applies -- imitate the existing
+ conventions.
+
+ A few commented examples follow to provide reference when writing or
+ modifying command usage strings and synopsis sections in the manual
+ pages:
+
+ Placeholders are spelled in lowercase and enclosed in angle brackets:
+   <file>
+   --sort=<key>
+   --abbrev[=<n>]
+
+ If a placeholder has multiple words, they are separated by dashes:
+   <new-branch-name>
+   --template=<template-directory>
+
+ Possibility of multiple occurrences is indicated by three dots:
+   <file>...
+   (One or more of <file>.)
+
+ Optional parts are enclosed in square brackets:
+   [<extra>]
+   (Zero or one <extra>.)
+
+   --exec-path[=<path>]
+   (Option with an optional argument.  Note that the "=" is inside the
+   brackets.)
+
+   [<patch>...]
+   (Zero or more of <patch>.  Note that the dots are inside, not
+   outside the brackets.)
+
+ Multiple alternatives are indicated with vertical bars:
+   [-q | --quiet]
+   [--utf8 | --no-utf8]
+
+ Parentheses are used for grouping:
+   [(<rev> | <range>)...]
+   (Any number of either <rev> or <range>.  Parens are needed to make
+   it clear that "..." pertains to both <rev> and <range>.)
+
+   [(-p <parent>)...]
+   (Any number of option -p, each with one <parent> argument.)
+
+   git remote set-head <name> (-a | -d | <branch>)
+   (One and only one of "-a", "-d" or "<branch>" _must_ (no square
+   brackets) be provided.)
+
+ And a somewhat more contrived example:
+   --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+   Here "=" is outside the brackets, because "--diff-filter=" is a
+   valid usage.  "*" has its own pair of brackets, because it can
+   (optionally) be specified only when one or more of the letters is
+   also provided.
+
+  A note on notation:
+   Use 'git' (all lowercase) when talking about commands i.e. something
+   the user would type into a shell and use 'Git' (uppercase first letter)
+   when talking about the version control system and its properties.
+
+ A few commented examples follow to provide reference when writing or
+ modifying paragraphs or option/command explanations that contain options
+ or commands:
+
+ Literal examples (e.g. use of command-line options, command names,
+ branch names, configuration and environment variables) must be
+ typeset in monospace (i.e. wrapped with backticks):
+   `--pretty=oneline`
+   `git rev-list`
+   `remote.pushDefault`
+   `GIT_DIR`
+   `HEAD`
+
+ An environment variable must be prefixed with "$" only when referring to its
+ value and not when referring to the variable itself, in this case there is
+ nothing to add except the backticks:
+   `GIT_DIR` is specified
+   `$GIT_DIR/hooks/pre-receive`
+
+ Word phrases enclosed in `backtick characters` are rendered literally
+ and will not be further expanded. The use of `backticks` to achieve the
+ previous rule means that literal examples should not use AsciiDoc
+ escapes.
+   Correct:
+      `--pretty=oneline`
+   Incorrect:
+      `\--pretty=oneline`
+
+ If some place in the documentation needs to typeset a command usage
+ example with inline substitutions, it is fine to use +monospaced and
+ inline substituted text+ instead of `monospaced literal text`, and with
+ the former, the part that should not get substituted must be
+ quoted/escaped.
diff --git a/external/docs/asciidoc/b8a56b0af0407301072e4e43a966b7a784900549 b/external/docs/asciidoc/b8a56b0af0407301072e4e43a966b7a784900549
new file mode 100644
index 0000000000..0532bfcf7f
--- /dev/null
+++ b/external/docs/asciidoc/b8a56b0af0407301072e4e43a966b7a784900549
@@ -0,0 +1,135 @@
+= Upcoming breaking changes
+
+The Git project aims to ensure backwards compatibility to the best extent
+possible. Minor releases will not break backwards compatibility unless there is
+a very strong reason to do so, like for example a security vulnerability.
+
+Regardless of that, due to the age of the Git project, it is only natural to
+accumulate a backlog of backwards-incompatible changes that will eventually be
+required to keep the project aligned with a changing world. These changes fall
+into several categories:
+
+* Changes to long established defaults.
+* Concepts that have been replaced with a superior design.
+* Concepts, commands, configuration or options that have been lacking in major
+  ways and that cannot be fixed and which will thus be removed without any
+  replacement.
+
+Explicitly not included in this list are fixes to minor bugs that may cause a
+change in user-visible behavior.
+
+The Git project irregularly releases breaking versions that deliberately break
+backwards compatibility with older versions. This is done to ensure that Git
+remains relevant, safe and maintainable going forward. The release cadence of
+breaking versions is typically measured in multiple years. We had the following
+major breaking releases in the past:
+
+* Git 1.6.0, released in August 2008.
+* Git 2.0, released in May 2014.
+
+We use <major>.<minor> release numbers these days, starting from Git 2.0. For
+future releases, our plan is to increment <major> in the release number when we
+make the next breaking release. Before Git 2.0, the release numbers were
+1.<major>.<minor> with the intention to increment <major> for "usual" breaking
+releases, reserving the jump to Git 2.0 for really large backward-compatibility
+breaking changes.
+
+The intent of this document is to track upcoming deprecations for future
+breaking releases. Furthermore, this document also tracks what will _not_ be
+deprecated. This is done such that the outcome of discussions document both
+when the discussion favors deprecation, but also when it rejects a deprecation.
+
+Items should have a clear summary of the reasons why we do or do not want to
+make the described change that can be easily understood without having to read
+the mailing list discussions. If there are alternatives to the changed feature,
+those alternatives should be pointed out to our users.
+
+All items should be accompanied by references to relevant mailing list threads
+where the deprecation was discussed. These references use message-IDs, which
+can visited via
+
+  https://lore.kernel.org/git/$message_id/
+
+to see the message and its surrounding discussion. Such a reference is there to
+make it easier for you to find how the project reached consensus on the
+described item back then.
+
+This is a living document as the environment surrounding the project changes
+over time. If circumstances change, an earlier decision to deprecate or change
+something may need to be revisited from time to time. So do not take items on
+this list to mean "it is settled, do not waste our time bringing it up again".
+
+== Git 3.0
+
+The following subsections document upcoming breaking changes for Git 3.0. There
+is no planned release date for this breaking version yet.
+
+Proposed changes and removals only include items which are "ready" to be done.
+In other words, this is not supposed to be a wishlist of features that should
+be changed to or replaced in case the alternative was implemented already.
+
+=== Changes
+
+* The default hash function for new repositories will be changed from "sha1"
+  to "sha256". SHA-1 has been deprecated by NIST in 2011 and is nowadays
+  recommended against in FIPS 140-2 and similar certifications. Furthermore,
+  there are practical attacks on SHA-1 that weaken its cryptographic properties:
++
+  ** The SHAppening (2015). The first demonstration of a practical attack
+     against SHA-1 with 2^57 operations.
+  ** SHAttered (2017). Generation of two valid PDF files with 2^63 operations.
+  ** Birthday-Near-Collision (2019). This attack allows for chosen prefix
+     attacks with 2^68 operations.
+  ** Shambles (2020). This attack allows for chosen prefix attacks with 2^63
+     operations.
++
+While we have protections in place against known attacks, it is expected
+that more attacks against SHA-1 will be found by future research. Paired
+with the ever-growing capability of hardware, it is only a matter of time
+before SHA-1 will be considered broken completely. We want to be prepared
+and will thus change the default hash algorithm to "sha256" for newly
+initialized repositories.
++
+An important requirement for this change is that the ecosystem is ready to
+support the "sha256" object format. This includes popular Git libraries,
+applications and forges.
++
+There is no plan to deprecate the "sha1" object format at this point in time.
++
+Cf. <2f5de416-04ba-c23d-1e0b-83bb655829a7@zombino.com>,
+<20170223155046.e7nxivfwqqoprsqj@LykOS.localdomain>,
+<CA+EOSBncr=4a4d8n9xS4FNehyebpmX8JiUwCsXD47EQDE+DiUQ@mail.gmail.com>.
+
+=== Removals
+
+* Support for grafting commits has long been superseded by git-replace(1).
+  Grafts are inferior to replacement refs:
++
+  ** Grafts are a local-only mechanism and cannot be shared across
+     repositories.
+  ** Grafts can lead to hard-to-diagnose problems when transferring objects
+     between repositories.
++
+The grafting mechanism has been marked as outdated since e650d0643b (docs: mark
+info/grafts as outdated, 2014-03-05) and will be removed.
++
+Cf. <20140304174806.GA11561@sigill.intra.peff.net>.
+
+== Superseded features that will not be deprecated
+
+Some features have gained newer replacements that aim to improve the design in
+certain ways. The fact that there is a replacement does not automatically mean
+that the old way of doing things will eventually be removed. This section tracks
+those features with newer alternatives.
+
+* The features git-checkout(1) offers are covered by the pair of commands
+  git-restore(1) and git-switch(1). Because the use of git-checkout(1) is still
+  widespread, and it is not expected that this will change anytime soon, all
+  three commands will stay.
++
+This decision may get revisited in case we ever figure out that there are
+almost no users of any of the commands anymore.
++
+Cf. <xmqqttjazwwa.fsf@gitster.g>,
+<xmqqleeubork.fsf@gitster.g>,
+<112b6568912a6de6672bf5592c3a718e@manjaro.org>.
diff --git a/external/docs/asciidoc/c1f2cd288d496192b1029e59ff7a92359e1b1198 b/external/docs/asciidoc/c1f2cd288d496192b1029e59ff7a92359e1b1198
new file mode 100644
index 0000000000..711cb9171e
--- /dev/null
+++ b/external/docs/asciidoc/c1f2cd288d496192b1029e59ff7a92359e1b1198
@@ -0,0 +1,695 @@
+Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, a few rough rules are:
+
+ - Most importantly, we never say "It's in POSIX; we'll happily
+   ignore your needs should your system not conform to it."
+   We live in the real world.
+
+ - However, we often say "Let's stay away from that construct,
+   it's not even in POSIX".
+
+ - In spite of the above two rules, we sometimes say "Although
+   this is not in POSIX, it (is so convenient | makes the code
+   much more readable | has other good characteristics) and
+   practically all the platforms we care about support it, so
+   let's use it".
+
+   Again, we live in the real world, and it is sometimes a
+   judgement call, the decision based more on real world
+   constraints people face than what the paper standard says.
+
+ - Fixing style violations while working on a real change as a
+   preparatory clean-up step is good, but otherwise avoid useless code
+   churn for the sake of conforming to the style.
+
+   "Once it _is_ in the tree, it's not really worth the patch noise to
+   go and fix it up."
+   Cf. http://lkml.iu.edu/hypermail/linux/kernel/1001.3/01069.html
+
+Make your code readable and sensible, and don't try to be clever.
+
+As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the _local_
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn't match the overall style of existing code).
+
+But if you must have a list of rules, here they are.
+
+For shell scripts specifically (not exhaustive):
+
+ - We use tabs for indentation.
+
+ - Case arms are indented at the same depth as case and esac lines,
+   like this:
+
+	case "$variable" in
+	pattern1)
+		do this
+		;;
+	pattern2)
+		do that
+		;;
+	esac
+
+ - Redirection operators should be written with space before, but no
+   space after them.  In other words, write 'echo test >"$file"'
+   instead of 'echo test> $file' or 'echo test > $file'.  Note that
+   even though it is not required by POSIX to double-quote the
+   redirection target in a variable (as shown above), our code does so
+   because some versions of bash issue a warning without the quotes.
+
+	(incorrect)
+	cat hello > world < universe
+	echo hello >$world
+
+	(correct)
+	cat hello >world <universe
+	echo hello >"$world"
+
+ - We prefer $( ... ) for command substitution; unlike ``, it
+   properly nests.  It should have been the way Bourne spelled
+   it from day one, but unfortunately isn't.
+
+ - If you want to find out if a command is available on the user's
+   $PATH, you should use 'type <command>', instead of 'which <command>'.
+   The output of 'which' is not machine parsable and its exit code
+   is not reliable across platforms.
+
+ - We use POSIX compliant parameter substitutions and avoid bashisms;
+   namely:
+
+   - We use ${parameter-word} and its [-=?+] siblings, and their
+     colon'ed "unset or null" form.
+
+   - We use ${parameter#word} and its [#%] siblings, and their
+     doubled "longest matching" form.
+
+   - No "Substring Expansion" ${parameter:offset:length}.
+
+   - No shell arrays.
+
+   - No pattern replacement ${parameter/pattern/string}.
+
+ - We use Arithmetic Expansion $(( ... )).
+
+ - We do not use Process Substitution <(list) or >(list).
+
+ - Do not write control structures on a single line with semicolon.
+   "then" should be on the next line for if statements, and "do"
+   should be on the next line for "while" and "for".
+
+	(incorrect)
+	if test -f hello; then
+		do this
+	fi
+
+	(correct)
+	if test -f hello
+	then
+		do this
+	fi
+
+ - If a command sequence joined with && or || or | spans multiple
+   lines, put each command on a separate line and put && and || and |
+   operators at the end of each line, rather than the start. This
+   means you don't need to use \ to join lines, since the above
+   operators imply the sequence isn't finished.
+
+	(incorrect)
+	grep blob verify_pack_result \
+	| awk -f print_1.awk \
+	| sort >actual &&
+	...
+
+	(correct)
+	grep blob verify_pack_result |
+	awk -f print_1.awk |
+	sort >actual &&
+	...
+
+ - We prefer "test" over "[ ... ]".
+
+ - We do not write the noiseword "function" in front of shell
+   functions.
+
+ - We prefer a space between the function name and the parentheses,
+   and no space inside the parentheses. The opening "{" should also
+   be on the same line.
+
+	(incorrect)
+	my_function(){
+		...
+
+	(correct)
+	my_function () {
+		...
+
+ - As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+   [::], [==], or [..]) for portability.
+
+   - We do not use \{m,n\};
+
+   - We do not use -E;
+
+   - We do not use ? or + (which are \{0,1\} and \{1,\}
+     respectively in BRE) but that goes without saying as these
+     are ERE elements not BRE (note that \? and \+ are not even part
+     of BRE -- making them accessible from BRE is a GNU extension).
+
+ - Use Git's gettext wrappers in git-sh-i18n to make the user
+   interface translatable. See "Marking strings for translation" in
+   po/README.
+
+ - We do not write our "test" command with "-a" and "-o" and use "&&"
+   or "||" to concatenate multiple "test" commands instead, because
+   the use of "-a/-o" is often error-prone.  E.g.
+
+     test -n "$x" -a "$a" = "$b"
+
+   is buggy and breaks when $x is "=", but
+
+     test -n "$x" && test "$a" = "$b"
+
+   does not have such a problem.
+
+ - Even though "local" is not part of POSIX, we make heavy use of it
+   in our test suite.  We do not use it in scripted Porcelains, and
+   hopefully nobody starts using "local" before they are reimplemented
+   in C ;-)
+
+
+For C programs:
+
+ - We use tabs to indent, and interpret tabs as taking up to
+   8 spaces.
+
+ - We try to keep to at most 80 characters per line.
+
+ - As a Git developer we assume you have a reasonably modern compiler
+   and we recommend you to enable the DEVELOPER makefile knob to
+   ensure your patch is clear of all compiler warnings we care about,
+   by e.g. "echo DEVELOPER=1 >>config.mak".
+
+ - We try to support a wide range of C compilers to compile Git with,
+   including old ones.  You should not use features from newer C
+   standard, even if your compiler groks them.
+
+   There are a few exceptions to this guideline:
+
+   . since early 2012 with e1327023ea, we have been using an enum
+     definition whose last element is followed by a comma.  This, like
+     an array initializer that ends with a trailing comma, can be used
+     to reduce the patch noise when adding a new identifier at the end.
+
+   . since mid 2017 with cbc0f81d, we have been using designated
+     initializers for struct (e.g. "struct t v = { .val = 'a' };").
+
+   . since mid 2017 with 512f41cf, we have been using designated
+     initializers for array (e.g. "int array[10] = { [5] = 2 }").
+
+   These used to be forbidden, but we have not heard any breakage
+   report, and they are assumed to be safe.
+
+ - Variables have to be declared at the beginning of the block, before
+   the first statement (i.e. -Wdeclaration-after-statement).
+
+ - Declaring a variable in the for loop "for (int i = 0; i < 10; i++)"
+   is still not allowed in this codebase.
+
+ - NULL pointers shall be written as NULL, not as 0.
+
+ - When declaring pointers, the star sides with the variable
+   name, i.e. "char *string", not "char* string" or
+   "char * string".  This makes it easier to understand code
+   like "char *string, c;".
+
+ - Use whitespace around operators and keywords, but not inside
+   parentheses and not around functions. So:
+
+        while (condition)
+		func(bar + 1);
+
+   and not:
+
+        while( condition )
+		func (bar+1);
+
+ - Do not explicitly compare an integral value with constant 0 or '\0',
+   or a pointer value with constant NULL.  For instance, to validate that
+   counted array <ptr, cnt> is initialized but has no elements, write:
+
+	if (!ptr || cnt)
+		BUG("empty array expected");
+
+   and not:
+
+	if (ptr == NULL || cnt != 0);
+		BUG("empty array expected");
+
+ - We avoid using braces unnecessarily.  I.e.
+
+	if (bla) {
+		x = 1;
+	}
+
+   is frowned upon. But there are a few exceptions:
+
+	- When the statement extends over a few lines (e.g., a while loop
+	  with an embedded conditional, or a comment). E.g.:
+
+		while (foo) {
+			if (x)
+				one();
+			else
+				two();
+		}
+
+		if (foo) {
+			/*
+			 * This one requires some explanation,
+			 * so we're better off with braces to make
+			 * it obvious that the indentation is correct.
+			 */
+			doit();
+		}
+
+	- When there are multiple arms to a conditional and some of them
+	  require braces, enclose even a single line block in braces for
+	  consistency. E.g.:
+
+		if (foo) {
+			doit();
+		} else {
+			one();
+			two();
+			three();
+		}
+
+ - We try to avoid assignments in the condition of an "if" statement.
+
+ - Try to make your code understandable.  You may put comments
+   in, but comments invariably tend to stale out when the code
+   they were describing changes.  Often splitting a function
+   into two makes the intention of the code much clearer.
+
+ - Multi-line comments include their delimiters on separate lines from
+   the text.  E.g.
+
+	/*
+	 * A very long
+	 * multi-line comment.
+	 */
+
+   Note however that a comment that explains a translatable string to
+   translators uses a convention of starting with a magic token
+   "TRANSLATORS: ", e.g.
+
+	/*
+	 * TRANSLATORS: here is a comment that explains the string to
+	 * be translated, that follows immediately after it.
+	 */
+	_("Here is a translatable string explained by the above.");
+
+ - Double negation is often harder to understand than no negation
+   at all.
+
+ - There are two schools of thought when it comes to comparison,
+   especially inside a loop. Some people prefer to have the less stable
+   value on the left hand side and the more stable value on the right hand
+   side, e.g. if you have a loop that counts variable i down to the
+   lower bound,
+
+	while (i > lower_bound) {
+		do something;
+		i--;
+	}
+
+   Other people prefer to have the textual order of values match the
+   actual order of values in their comparison, so that they can
+   mentally draw a number line from left to right and place these
+   values in order, i.e.
+
+	while (lower_bound < i) {
+		do something;
+		i--;
+	}
+
+   Both are valid, and we use both.  However, the more "stable" the
+   stable side becomes, the more we tend to prefer the former
+   (comparison with a constant, "i > 0", is an extreme example).
+   Just do not mix styles in the same part of the code and mimic
+   existing styles in the neighbourhood.
+
+ - There are two schools of thought when it comes to splitting a long
+   logical line into multiple lines.  Some people push the second and
+   subsequent lines far enough to the right with tabs and align them:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+		span_more_than_a_single_line_of ||
+		the_source_text) {
+                ...
+
+   while other people prefer to align the second and the subsequent
+   lines with the column immediately inside the opening parenthesis,
+   with tabs and spaces, following our "tabstop is always a multiple
+   of 8" convention:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of ||
+	    the_source_text) {
+                ...
+
+   Both are valid, and we use both.  Again, just do not mix styles in
+   the same part of the code and mimic existing styles in the
+   neighbourhood.
+
+ - When splitting a long logical line, some people change line before
+   a binary operator, so that the result looks like a parse tree when
+   you turn your head 90-degrees counterclockwise:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to
+	    || span_more_than_a_single_line_of_the_source_text) {
+
+   while other people prefer to leave the operator at the end of the
+   line:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of_the_source_text) {
+
+   Both are valid, but we tend to use the latter more, unless the
+   expression gets fairly complex, in which case the former tends to
+   be easier to read.  Again, just do not mix styles in the same part
+   of the code and mimic existing styles in the neighbourhood.
+
+ - When splitting a long logical line, with everything else being
+   equal, it is preferable to split after the operator at higher
+   level in the parse tree.  That is, this is more preferable:
+
+	if (a_very_long_variable * that_is_used_in +
+	    a_very_long_expression) {
+		...
+
+   than
+
+	if (a_very_long_variable *
+	    that_is_used_in + a_very_long_expression) {
+		...
+
+ - Some clever tricks, like using the !! operator with arithmetic
+   constructs, can be extremely confusing to others.  Avoid them,
+   unless there is a compelling reason to use them.
+
+ - Use the API.  No, really.  We have a strbuf (variable length
+   string), several arrays with the ALLOC_GROW() macro, a
+   string_list for sorted string lists, a hash map (mapping struct
+   objects) named "struct decorate", amongst other things.
+
+ - When you come up with an API, document its functions and structures
+   in the header file that exposes the API to its callers. Use what is
+   in "strbuf.h" as a model for the appropriate tone and level of
+   detail.
+
+ - The first #include in C files, except in platform specific compat/
+   implementations, must be either "git-compat-util.h", "cache.h" or
+   "builtin.h".  You do not have to include more than one of these.
+
+ - A C file must directly include the header files that declare the
+   functions and the types it uses, except for the functions and types
+   that are made available to it by including one of the header files
+   it must include by the previous rule.
+
+ - If you are planning a new command, consider writing it in shell
+   or perl first, so that changes in semantics can be easily
+   changed and discussed.  Many Git commands started out like
+   that, and a few are still scripts.
+
+ - Avoid introducing a new dependency into Git. This means you
+   usually should stay away from scripting languages not already
+   used in the Git core command set (unless your command is clearly
+   separate from it, such as an importer to convert random-scm-X
+   repositories to Git).
+
+ - When we pass <string, length> pair to functions, we should try to
+   pass them in that order.
+
+ - Use Git's gettext wrappers to make the user interface
+   translatable. See "Marking strings for translation" in po/README.
+
+ - Variables and functions local to a given source file should be marked
+   with "static". Variables that are visible to other source files
+   must be declared with "extern" in header files. However, function
+   declarations should not use "extern", as that is already the default.
+
+ - You can launch gdb around your program using the shorthand GIT_DEBUGGER.
+   Run `GIT_DEBUGGER=1 ./bin-wrappers/git foo` to simply use gdb as is, or
+   run `GIT_DEBUGGER="<debugger> <debugger-args>" ./bin-wrappers/git foo` to
+   use your own debugger and arguments. Example: `GIT_DEBUGGER="ddd --gdb"
+   ./bin-wrappers/git log` (See `wrap-for-bin.sh`.)
+
+For Perl programs:
+
+ - Most of the C guidelines above apply.
+
+ - We try to support Perl 5.8 and later ("use Perl 5.008").
+
+ - use strict and use warnings are strongly preferred.
+
+ - Don't overuse statement modifiers unless using them makes the
+   result easier to follow.
+
+	... do something ...
+	do_this() unless (condition);
+        ... do something else ...
+
+   is more readable than:
+
+	... do something ...
+	unless (condition) {
+		do_this();
+	}
+        ... do something else ...
+
+   *only* when the condition is so rare that do_this() will be almost
+   always called.
+
+ - We try to avoid assignments inside "if ()" conditions.
+
+ - Learn and use Git.pm if you need that functionality.
+
+ - For Emacs, it's useful to put the following in
+   GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode:
+
+    ;; note the first part is useful for C editing, too
+    ((nil . ((indent-tabs-mode . t)
+                  (tab-width . 8)
+                  (fill-column . 80)))
+     (cperl-mode . ((cperl-indent-level . 8)
+                    (cperl-extra-newline-before-brace . nil)
+                    (cperl-merge-trailing-else . t))))
+
+For Python scripts:
+
+ - We follow PEP-8 (http://www.python.org/dev/peps/pep-0008/).
+
+ - As a minimum, we aim to be compatible with Python 2.7.
+
+ - Where required libraries do not restrict us to Python 2, we try to
+   also be compatible with Python 3.1 and later.
+
+Error Messages
+
+ - Do not end error messages with a full stop.
+
+ - Do not capitalize the first word, only because it is the first word
+   in the message ("unable to open %s", not "Unable to open %s").  But
+   "SHA-3 not supported" is fine, because the reason the first word is
+   capitalized is not because it is at the beginning of the sentence,
+   but because the word would be spelled in capital letters even when
+   it appeared in the middle of the sentence.
+
+ - Say what the error is first ("cannot open %s", not "%s: cannot open")
+
+
+Externally Visible Names
+
+ - For configuration variable names, follow the existing convention:
+
+   . The section name indicates the affected subsystem.
+
+   . The subsection name, if any, indicates which of an unbounded set
+     of things to set the value for.
+
+   . The variable name describes the effect of tweaking this knob.
+
+   The section and variable names that consist of multiple words are
+   formed by concatenating the words without punctuations (e.g. `-`),
+   and are broken using bumpyCaps in documentation as a hint to the
+   reader.
+
+   When choosing the variable namespace, do not use variable name for
+   specifying possibly unbounded set of things, most notably anything
+   an end user can freely come up with (e.g. branch names).  Instead,
+   use subsection names or variable values, like the existing variable
+   branch.<name>.description does.
+
+
+Writing Documentation:
+
+ Most (if not all) of the documentation pages are written in the
+ AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+ processed into HTML and manpages (e.g. git.html and git.1 in the
+ same directory).
+
+ The documentation liberally mixes US and UK English (en_US/UK)
+ norms for spelling and grammar, which is somewhat unfortunate.
+ In an ideal world, it would have been better if it consistently
+ used only one and not the other, and we would have picked en_US
+ (if you wish to correct the English of some of the existing
+ documentation, please see the documentation-related advice in the
+ Documentation/SubmittingPatches file).
+
+ In order to ensure the documentation is inclusive, avoid assuming
+ that an unspecified example person is male or female, and think
+ twice before using "he", "him", "she", or "her".  Here are some
+ tips to avoid use of gendered pronouns:
+
+  - Prefer succinctness and matter-of-factly describing functionality
+    in the abstract.  E.g.
+
+     --short:: Emit output in the short-format.
+
+    and avoid something like these overly verbose alternatives:
+
+     --short:: Use this to emit output in the short-format.
+     --short:: You can use this to get output in the short-format.
+     --short:: A user who prefers shorter output could....
+     --short:: Should a person and/or program want shorter output, he
+               she/they/it can...
+
+    This practice often eliminates the need to involve human actors in
+    your description, but it is a good practice regardless of the
+    avoidance of gendered pronouns.
+
+  - When it becomes awkward to stick to this style, prefer "you" when
+    addressing the the hypothetical user, and possibly "we" when
+    discussing how the program might react to the user.  E.g.
+
+      You can use this option instead of --xyz, but we might remove
+      support for it in future versions.
+
+    while keeping in mind that you can probably be less verbose, e.g.
+
+      Use this instead of --xyz. This option might be removed in future
+      versions.
+
+  - If you still need to refer to an example person that is
+    third-person singular, you may resort to "singular they" to avoid
+    "he/she/him/her", e.g.
+
+      A contributor asks their upstream to pull from them.
+
+    Note that this sounds ungrammatical and unnatural to those who
+    learned that "they" is only used for third-person plural, e.g.
+    those who learn English as a second language in some parts of the
+    world.
+
+ Every user-visible change should be reflected in the documentation.
+ The same general rule as for code applies -- imitate the existing
+ conventions.
+
+ A few commented examples follow to provide reference when writing or
+ modifying command usage strings and synopsis sections in the manual
+ pages:
+
+ Placeholders are spelled in lowercase and enclosed in angle brackets:
+   <file>
+   --sort=<key>
+   --abbrev[=<n>]
+
+ If a placeholder has multiple words, they are separated by dashes:
+   <new-branch-name>
+   --template=<template-directory>
+
+ Possibility of multiple occurrences is indicated by three dots:
+   <file>...
+   (One or more of <file>.)
+
+ Optional parts are enclosed in square brackets:
+   [<extra>]
+   (Zero or one <extra>.)
+
+   --exec-path[=<path>]
+   (Option with an optional argument.  Note that the "=" is inside the
+   brackets.)
+
+   [<patch>...]
+   (Zero or more of <patch>.  Note that the dots are inside, not
+   outside the brackets.)
+
+ Multiple alternatives are indicated with vertical bars:
+   [-q | --quiet]
+   [--utf8 | --no-utf8]
+
+ Parentheses are used for grouping:
+   [(<rev> | <range>)...]
+   (Any number of either <rev> or <range>.  Parens are needed to make
+   it clear that "..." pertains to both <rev> and <range>.)
+
+   [(-p <parent>)...]
+   (Any number of option -p, each with one <parent> argument.)
+
+   git remote set-head <name> (-a | -d | <branch>)
+   (One and only one of "-a", "-d" or "<branch>" _must_ (no square
+   brackets) be provided.)
+
+ And a somewhat more contrived example:
+   --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+   Here "=" is outside the brackets, because "--diff-filter=" is a
+   valid usage.  "*" has its own pair of brackets, because it can
+   (optionally) be specified only when one or more of the letters is
+   also provided.
+
+  A note on notation:
+   Use 'git' (all lowercase) when talking about commands i.e. something
+   the user would type into a shell and use 'Git' (uppercase first letter)
+   when talking about the version control system and its properties.
+
+ A few commented examples follow to provide reference when writing or
+ modifying paragraphs or option/command explanations that contain options
+ or commands:
+
+ Literal examples (e.g. use of command-line options, command names,
+ branch names, URLs, pathnames (files and directories), configuration and
+ environment variables) must be typeset in monospace (i.e. wrapped with
+ backticks):
+   `--pretty=oneline`
+   `git rev-list`
+   `remote.pushDefault`
+   `http://git.example.com`
+   `.git/config`
+   `GIT_DIR`
+   `HEAD`
+
+ An environment variable must be prefixed with "$" only when referring to its
+ value and not when referring to the variable itself, in this case there is
+ nothing to add except the backticks:
+   `GIT_DIR` is specified
+   `$GIT_DIR/hooks/pre-receive`
+
+ Word phrases enclosed in `backtick characters` are rendered literally
+ and will not be further expanded. The use of `backticks` to achieve the
+ previous rule means that literal examples should not use AsciiDoc
+ escapes.
+   Correct:
+      `--pretty=oneline`
+   Incorrect:
+      `\--pretty=oneline`
+
+ If some place in the documentation needs to typeset a command usage
+ example with inline substitutions, it is fine to use +monospaced and
+ inline substituted text+ instead of `monospaced literal text`, and with
+ the former, the part that should not get substituted must be
+ quoted/escaped.
diff --git a/external/docs/asciidoc/c6e5fb1cba5ded1146eafe7b92bfcd9d2a4ee162 b/external/docs/asciidoc/c6e5fb1cba5ded1146eafe7b92bfcd9d2a4ee162
new file mode 100644
index 0000000000..5edd3a0b9d
--- /dev/null
+++ b/external/docs/asciidoc/c6e5fb1cba5ded1146eafe7b92bfcd9d2a4ee162
@@ -0,0 +1,863 @@
+Like other projects, we also have some guidelines for our code.  For
+Git in general, a few rough rules are:
+
+ - Most importantly, we never say "It's in POSIX; we'll happily
+   ignore your needs should your system not conform to it."
+   We live in the real world.
+
+ - However, we often say "Let's stay away from that construct,
+   it's not even in POSIX".
+
+ - In spite of the above two rules, we sometimes say "Although
+   this is not in POSIX, it (is so convenient | makes the code
+   much more readable | has other good characteristics) and
+   practically all the platforms we care about support it, so
+   let's use it".
+
+   Again, we live in the real world, and it is sometimes a
+   judgement call, the decision based more on real world
+   constraints people face than what the paper standard says.
+
+ - Fixing style violations while working on a real change as a
+   preparatory clean-up step is good, but otherwise avoid useless code
+   churn for the sake of conforming to the style.
+
+   "Once it _is_ in the tree, it's not really worth the patch noise to
+   go and fix it up."
+   Cf. https://lore.kernel.org/all/20100126160632.3bdbe172.akpm@linux-foundation.org/
+
+ - Log messages to explain your changes are as important as the
+   changes themselves.  Clearly written code and in-code comments
+   explain how the code works and what is assumed from the surrounding
+   context.  The log messages explain what the changes wanted to
+   achieve and why the changes were necessary (more on this in the
+   accompanying SubmittingPatches document).
+
+Make your code readable and sensible, and don't try to be clever.
+
+As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the _local_
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code are expected to match the style the surrounding code already
+uses (even if it doesn't match the overall style of existing code).
+
+But if you must have a list of rules, here are some language
+specific ones. Note that Documentation/ToolsForGit.txt document
+has a collection of tips to help you use some external tools
+to conform to these guidelines.
+
+For shell scripts specifically (not exhaustive):
+
+ - We use tabs for indentation.
+
+ - Case arms are indented at the same depth as case and esac lines,
+   like this:
+
+	case "$variable" in
+	pattern1)
+		do this
+		;;
+	pattern2)
+		do that
+		;;
+	esac
+
+ - Redirection operators should be written with space before, but no
+   space after them.  In other words, write 'echo test >"$file"'
+   instead of 'echo test> $file' or 'echo test > $file'.  Note that
+   even though it is not required by POSIX to double-quote the
+   redirection target in a variable (as shown above), our code does so
+   because some versions of bash issue a warning without the quotes.
+
+	(incorrect)
+	cat hello > world < universe
+	echo hello >$world
+
+	(correct)
+	cat hello >world <universe
+	echo hello >"$world"
+
+ - We prefer $( ... ) for command substitution; unlike ``, it
+   properly nests.  It should have been the way Bourne spelled
+   it from day one, but unfortunately isn't.
+
+ - If you want to find out if a command is available on the user's
+   $PATH, you should use 'type <command>', instead of 'which <command>'.
+   The output of 'which' is not machine parsable and its exit code
+   is not reliable across platforms.
+
+ - We use POSIX compliant parameter substitutions and avoid bashisms;
+   namely:
+
+   - We use ${parameter-word} and its [-=?+] siblings, and their
+     colon'ed "unset or null" form.
+
+   - We use ${parameter#word} and its [#%] siblings, and their
+     doubled "longest matching" form.
+
+   - No "Substring Expansion" ${parameter:offset:length}.
+
+   - No shell arrays.
+
+   - No pattern replacement ${parameter/pattern/string}.
+
+ - We use Arithmetic Expansion $(( ... )).
+
+ - We do not use Process Substitution <(list) or >(list).
+
+ - Do not write control structures on a single line with semicolon.
+   "then" should be on the next line for if statements, and "do"
+   should be on the next line for "while" and "for".
+
+	(incorrect)
+	if test -f hello; then
+		do this
+	fi
+
+	(correct)
+	if test -f hello
+	then
+		do this
+	fi
+
+ - If a command sequence joined with && or || or | spans multiple
+   lines, put each command on a separate line and put && and || and |
+   operators at the end of each line, rather than the start. This
+   means you don't need to use \ to join lines, since the above
+   operators imply the sequence isn't finished.
+
+	(incorrect)
+	grep blob verify_pack_result \
+	| awk -f print_1.awk \
+	| sort >actual &&
+	...
+
+	(correct)
+	grep blob verify_pack_result |
+	awk -f print_1.awk |
+	sort >actual &&
+	...
+
+ - We prefer "test" over "[ ... ]".
+
+ - We do not write the noiseword "function" in front of shell
+   functions.
+
+ - We prefer a space between the function name and the parentheses,
+   and no space inside the parentheses. The opening "{" should also
+   be on the same line.
+
+	(incorrect)
+	my_function(){
+		...
+
+	(correct)
+	my_function () {
+		...
+
+ - As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+   [::], [==], or [..]) for portability.
+
+   - We do not use \{m,n\};
+
+   - We do not use ? or + (which are \{0,1\} and \{1,\}
+     respectively in BRE) but that goes without saying as these
+     are ERE elements not BRE (note that \? and \+ are not even part
+     of BRE -- making them accessible from BRE is a GNU extension).
+
+ - Use Git's gettext wrappers in git-sh-i18n to make the user
+   interface translatable. See "Marking strings for translation" in
+   po/README.
+
+ - We do not write our "test" command with "-a" and "-o" and use "&&"
+   or "||" to concatenate multiple "test" commands instead, because
+   the use of "-a/-o" is often error-prone.  E.g.
+
+     test -n "$x" -a "$a" = "$b"
+
+   is buggy and breaks when $x is "=", but
+
+     test -n "$x" && test "$a" = "$b"
+
+   does not have such a problem.
+
+ - Even though "local" is not part of POSIX, we make heavy use of it
+   in our test suite.  We do not use it in scripted Porcelains, and
+   hopefully nobody starts using "local" before all shells that matter
+   support it (notably, ksh from AT&T Research does not support it yet).
+
+ - Some versions of shell do not understand "export variable=value",
+   so we write "variable=value" and then "export variable" on two
+   separate lines.
+
+ - Some versions of dash have broken variable assignment when prefixed
+   with "local", "export", and "readonly", in that the value to be
+   assigned goes through field splitting at $IFS unless quoted.
+
+	(incorrect)
+	local variable=$value
+	local variable=$(command args)
+
+	(correct)
+	local variable="$value"
+	local variable="$(command args)"
+
+ - The common construct
+
+	VAR=VAL command args
+
+   to temporarily set and export environment variable VAR only while
+   "command args" is running is handy, but this triggers an
+   unspecified behaviour according to POSIX when used for a command
+   that is not an external command (like shell functions).  Indeed,
+   dash 0.5.10.2-6 on Ubuntu 20.04, /bin/sh on FreeBSD 13, and AT&T
+   ksh all make a temporary assignment without exporting the variable,
+   in such a case.  As it does not work portably across shells, do not
+   use this syntax for shell functions.  A common workaround is to do
+   an explicit export in a subshell, like so:
+
+	(incorrect)
+	VAR=VAL func args
+
+	(correct)
+	(
+		VAR=VAL &&
+		export VAR &&
+		func args
+	)
+
+   but be careful that the effect "func" makes to the variables in the
+   current shell will be lost across the subshell boundary.
+
+ - Use octal escape sequences (e.g. "\302\242"), not hexadecimal (e.g.
+   "\xc2\xa2") in printf format strings, since hexadecimal escape
+   sequences are not portable.
+
+
+For C programs:
+
+ - We use tabs to indent, and interpret tabs as taking up to
+   8 spaces.
+
+ - We try to keep to at most 80 characters per line.
+
+ - As a Git developer we assume you have a reasonably modern compiler
+   and we recommend you to enable the DEVELOPER makefile knob to
+   ensure your patch is clear of all compiler warnings we care about,
+   by e.g. "echo DEVELOPER=1 >>config.mak".
+
+ - We try to support a wide range of C compilers to compile Git with,
+   including old ones.  As of Git v2.35.0 Git requires C99 (we check
+   "__STDC_VERSION__"). You should not use features from a newer C
+   standard, even if your compiler groks them.
+
+   New C99 features have been phased in gradually, if something's new
+   in C99 but not used yet don't assume that it's safe to use, some
+   compilers we target have only partial support for it. These are
+   considered safe to use:
+
+   . since around 2007 with 2b6854c863a, we have been using
+     initializer elements which are not computable at load time. E.g.:
+
+	const char *args[] = {"constant", variable, NULL};
+
+   . since early 2012 with e1327023ea, we have been using an enum
+     definition whose last element is followed by a comma.  This, like
+     an array initializer that ends with a trailing comma, can be used
+     to reduce the patch noise when adding a new identifier at the end.
+
+   . since mid 2017 with cbc0f81d, we have been using designated
+     initializers for struct (e.g. "struct t v = { .val = 'a' };").
+
+   . since mid 2017 with 512f41cf, we have been using designated
+     initializers for array (e.g. "int array[10] = { [5] = 2 }").
+
+   . since early 2021 with 765dc168882, we have been using variadic
+     macros, mostly for printf-like trace and debug macros.
+
+   . since late 2021 with 44ba10d6, we have had variables declared in
+     the for loop "for (int i = 0; i < 10; i++)".
+
+   New C99 features that we cannot use yet:
+
+   . %z and %zu as a printf() argument for a size_t (the %z being for
+     the POSIX-specific ssize_t). Instead you should use
+     printf("%"PRIuMAX, (uintmax_t)v).  These days the MSVC version we
+     rely on supports %z, but the C library used by MinGW does not.
+
+   . Shorthand like ".a.b = *c" in struct initializations is known to
+     trip up an older IBM XLC version, use ".a = { .b = *c }" instead.
+     See the 33665d98 (reftable: make assignments portable to AIX xlc
+     v12.01, 2022-03-28).
+
+ - Variables have to be declared at the beginning of the block, before
+   the first statement (i.e. -Wdeclaration-after-statement).  It is
+   encouraged to have a blank line between the end of the declarations
+   and the first statement in the block.
+
+ - NULL pointers shall be written as NULL, not as 0.
+
+ - When declaring pointers, the star sides with the variable
+   name, i.e. "char *string", not "char* string" or
+   "char * string".  This makes it easier to understand code
+   like "char *string, c;".
+
+ - Use whitespace around operators and keywords, but not inside
+   parentheses and not around functions. So:
+
+        while (condition)
+		func(bar + 1);
+
+   and not:
+
+        while( condition )
+		func (bar+1);
+
+ - A binary operator (other than ",") and ternary conditional "?:"
+   have a space on each side of the operator to separate it from its
+   operands.  E.g. "A + 1", not "A+1".
+
+ - A unary operator (other than "." and "->") have no space between it
+   and its operand.  E.g. "(char *)ptr", not "(char *) ptr".
+
+ - Do not explicitly compare an integral value with constant 0 or '\0',
+   or a pointer value with constant NULL.  For instance, to validate that
+   counted array <ptr, cnt> is initialized but has no elements, write:
+
+	if (!ptr || cnt)
+		BUG("empty array expected");
+
+   and not:
+
+	if (ptr == NULL || cnt != 0);
+		BUG("empty array expected");
+
+ - We avoid using braces unnecessarily.  I.e.
+
+	if (bla) {
+		x = 1;
+	}
+
+   is frowned upon. But there are a few exceptions:
+
+	- When the statement extends over a few lines (e.g., a while loop
+	  with an embedded conditional, or a comment). E.g.:
+
+		while (foo) {
+			if (x)
+				one();
+			else
+				two();
+		}
+
+		if (foo) {
+			/*
+			 * This one requires some explanation,
+			 * so we're better off with braces to make
+			 * it obvious that the indentation is correct.
+			 */
+			doit();
+		}
+
+	- When there are multiple arms to a conditional and some of them
+	  require braces, enclose even a single line block in braces for
+	  consistency. E.g.:
+
+		if (foo) {
+			doit();
+		} else {
+			one();
+			two();
+			three();
+		}
+
+ - We try to avoid assignments in the condition of an "if" statement.
+
+ - Try to make your code understandable.  You may put comments
+   in, but comments invariably tend to stale out when the code
+   they were describing changes.  Often splitting a function
+   into two makes the intention of the code much clearer.
+
+ - Multi-line comments include their delimiters on separate lines from
+   the text.  E.g.
+
+	/*
+	 * A very long
+	 * multi-line comment.
+	 */
+
+   Note however that a comment that explains a translatable string to
+   translators uses a convention of starting with a magic token
+   "TRANSLATORS: ", e.g.
+
+	/*
+	 * TRANSLATORS: here is a comment that explains the string to
+	 * be translated, that follows immediately after it.
+	 */
+	_("Here is a translatable string explained by the above.");
+
+ - Double negation is often harder to understand than no negation
+   at all.
+
+ - There are two schools of thought when it comes to comparison,
+   especially inside a loop. Some people prefer to have the less stable
+   value on the left hand side and the more stable value on the right hand
+   side, e.g. if you have a loop that counts variable i down to the
+   lower bound,
+
+	while (i > lower_bound) {
+		do something;
+		i--;
+	}
+
+   Other people prefer to have the textual order of values match the
+   actual order of values in their comparison, so that they can
+   mentally draw a number line from left to right and place these
+   values in order, i.e.
+
+	while (lower_bound < i) {
+		do something;
+		i--;
+	}
+
+   Both are valid, and we use both.  However, the more "stable" the
+   stable side becomes, the more we tend to prefer the former
+   (comparison with a constant, "i > 0", is an extreme example).
+   Just do not mix styles in the same part of the code and mimic
+   existing styles in the neighbourhood.
+
+ - There are two schools of thought when it comes to splitting a long
+   logical line into multiple lines.  Some people push the second and
+   subsequent lines far enough to the right with tabs and align them:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+		span_more_than_a_single_line_of ||
+		the_source_text) {
+                ...
+
+   while other people prefer to align the second and the subsequent
+   lines with the column immediately inside the opening parenthesis,
+   with tabs and spaces, following our "tabstop is always a multiple
+   of 8" convention:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of ||
+	    the_source_text) {
+                ...
+
+   Both are valid, and we use both.  Again, just do not mix styles in
+   the same part of the code and mimic existing styles in the
+   neighbourhood.
+
+ - When splitting a long logical line, some people change line before
+   a binary operator, so that the result looks like a parse tree when
+   you turn your head 90-degrees counterclockwise:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to
+	    || span_more_than_a_single_line_of_the_source_text) {
+
+   while other people prefer to leave the operator at the end of the
+   line:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of_the_source_text) {
+
+   Both are valid, but we tend to use the latter more, unless the
+   expression gets fairly complex, in which case the former tends to
+   be easier to read.  Again, just do not mix styles in the same part
+   of the code and mimic existing styles in the neighbourhood.
+
+ - When splitting a long logical line, with everything else being
+   equal, it is preferable to split after the operator at higher
+   level in the parse tree.  That is, this is more preferable:
+
+	if (a_very_long_variable * that_is_used_in +
+	    a_very_long_expression) {
+		...
+
+   than
+
+	if (a_very_long_variable *
+	    that_is_used_in + a_very_long_expression) {
+		...
+
+ - Some clever tricks, like using the !! operator with arithmetic
+   constructs, can be extremely confusing to others.  Avoid them,
+   unless there is a compelling reason to use them.
+
+ - Use the API.  No, really.  We have a strbuf (variable length
+   string), several arrays with the ALLOC_GROW() macro, a
+   string_list for sorted string lists, a hash map (mapping struct
+   objects) named "struct decorate", amongst other things.
+
+ - When you come up with an API, document its functions and structures
+   in the header file that exposes the API to its callers. Use what is
+   in "strbuf.h" as a model for the appropriate tone and level of
+   detail.
+
+ - The first #include in C files, except in platform specific compat/
+   implementations and sha1dc/, must be <git-compat-util.h>.  This
+   header file insulates other header files and source files from
+   platform differences, like which system header files must be
+   included in what order, and what C preprocessor feature macros must
+   be defined to trigger certain features we expect out of the system.
+   A collorary to this is that C files should not directly include
+   system header files themselves.
+
+   There are some exceptions, because certain group of files that
+   implement an API all have to include the same header file that
+   defines the API and it is convenient to include <git-compat-util.h>
+   there.  Namely:
+
+   - the implementation of the built-in commands in the "builtin/"
+     directory that include "builtin.h" for the cmd_foo() prototype
+     definition,
+
+   - the test helper programs in the "t/helper/" directory that include
+     "t/helper/test-tool.h" for the cmd__foo() prototype definition,
+
+   - the xdiff implementation in the "xdiff/" directory that includes
+     "xdiff/xinclude.h" for the xdiff machinery internals,
+
+   - the unit test programs in "t/unit-tests/" directory that include
+     "t/unit-tests/test-lib.h" that gives them the unit-tests
+     framework, and
+
+   - the source files that implement reftable in the "reftable/"
+     directory that include "reftable/system.h" for the reftable
+     internals,
+
+   are allowed to assume that they do not have to include
+   <git-compat-util.h> themselves, as it is included as the first
+   '#include' in these header files.  These headers must be the first
+   header file to be "#include"d in them, though.
+
+ - A C file must directly include the header files that declare the
+   functions and the types it uses, except for the functions and types
+   that are made available to it by including one of the header files
+   it must include by the previous rule.
+
+ - If you are planning a new command, consider writing it in shell
+   or perl first, so that changes in semantics can be easily
+   changed and discussed.  Many Git commands started out like
+   that, and a few are still scripts.
+
+ - Avoid introducing a new dependency into Git. This means you
+   usually should stay away from scripting languages not already
+   used in the Git core command set (unless your command is clearly
+   separate from it, such as an importer to convert random-scm-X
+   repositories to Git).
+
+ - When we pass <string, length> pair to functions, we should try to
+   pass them in that order.
+
+ - Use Git's gettext wrappers to make the user interface
+   translatable. See "Marking strings for translation" in po/README.
+
+ - Variables and functions local to a given source file should be marked
+   with "static". Variables that are visible to other source files
+   must be declared with "extern" in header files. However, function
+   declarations should not use "extern", as that is already the default.
+
+ - You can launch gdb around your program using the shorthand GIT_DEBUGGER.
+   Run `GIT_DEBUGGER=1 ./bin-wrappers/git foo` to simply use gdb as is, or
+   run `GIT_DEBUGGER="<debugger> <debugger-args>" ./bin-wrappers/git foo` to
+   use your own debugger and arguments. Example: `GIT_DEBUGGER="ddd --gdb"
+   ./bin-wrappers/git log` (See `wrap-for-bin.sh`.)
+
+For Perl programs:
+
+ - Most of the C guidelines above apply.
+
+ - We try to support Perl 5.8.1 and later ("use Perl 5.008001").
+
+ - use strict and use warnings are strongly preferred.
+
+ - Don't overuse statement modifiers unless using them makes the
+   result easier to follow.
+
+	... do something ...
+	do_this() unless (condition);
+        ... do something else ...
+
+   is more readable than:
+
+	... do something ...
+	unless (condition) {
+		do_this();
+	}
+        ... do something else ...
+
+   *only* when the condition is so rare that do_this() will be almost
+   always called.
+
+ - We try to avoid assignments inside "if ()" conditions.
+
+ - Learn and use Git.pm if you need that functionality.
+
+For Python scripts:
+
+ - We follow PEP-8 (https://peps.python.org/pep-0008/).
+
+ - As a minimum, we aim to be compatible with Python 2.7.
+
+ - Where required libraries do not restrict us to Python 2, we try to
+   also be compatible with Python 3.1 and later.
+
+
+Program Output
+
+ We make a distinction between a Git command's primary output and
+ output which is merely chatty feedback (for instance, status
+ messages, running transcript, or progress display), as well as error
+ messages. Roughly speaking, a Git command's primary output is that
+ which one might want to capture to a file or send down a pipe; its
+ chatty output should not interfere with these use-cases.
+
+ As such, primary output should be sent to the standard output stream
+ (stdout), and chatty output should be sent to the standard error
+ stream (stderr). Examples of commands which produce primary output
+ include `git log`, `git show`, and `git branch --list` which generate
+ output on the stdout stream.
+
+ Not all Git commands have primary output; this is often true of
+ commands whose main function is to perform an action. Some action
+ commands are silent, whereas others are chatty. An example of a
+ chatty action commands is `git clone` with its "Cloning into
+ '<path>'..." and "Checking connectivity..." status messages which it
+ sends to the stderr stream.
+
+ Error messages from Git commands should always be sent to the stderr
+ stream.
+
+
+Error Messages
+
+ - Do not end error messages with a full stop.
+
+ - Do not capitalize the first word, only because it is the first word
+   in the message ("unable to open %s", not "Unable to open %s").  But
+   "SHA-3 not supported" is fine, because the reason the first word is
+   capitalized is not because it is at the beginning of the sentence,
+   but because the word would be spelled in capital letters even when
+   it appeared in the middle of the sentence.
+
+ - Say what the error is first ("cannot open %s", not "%s: cannot open")
+
+
+Externally Visible Names
+
+ - For configuration variable names, follow the existing convention:
+
+   . The section name indicates the affected subsystem.
+
+   . The subsection name, if any, indicates which of an unbounded set
+     of things to set the value for.
+
+   . The variable name describes the effect of tweaking this knob.
+
+   The section and variable names that consist of multiple words are
+   formed by concatenating the words without punctuation marks (e.g. `-`),
+   and are broken using bumpyCaps in documentation as a hint to the
+   reader.
+
+   When choosing the variable namespace, do not use variable name for
+   specifying possibly unbounded set of things, most notably anything
+   an end user can freely come up with (e.g. branch names).  Instead,
+   use subsection names or variable values, like the existing variable
+   branch.<name>.description does.
+
+
+Writing Documentation:
+
+ Most (if not all) of the documentation pages are written in the
+ AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+ processed into HTML and manpages (e.g. git.html and git.1 in the
+ same directory).
+
+ The documentation liberally mixes US and UK English (en_US/UK)
+ norms for spelling and grammar, which is somewhat unfortunate.
+ In an ideal world, it would have been better if it consistently
+ used only one and not the other, and we would have picked en_US
+ (if you wish to correct the English of some of the existing
+ documentation, please see the documentation-related advice in the
+ Documentation/SubmittingPatches file).
+
+ In order to ensure the documentation is inclusive, avoid assuming
+ that an unspecified example person is male or female, and think
+ twice before using "he", "him", "she", or "her".  Here are some
+ tips to avoid use of gendered pronouns:
+
+  - Prefer succinctness and matter-of-factly describing functionality
+    in the abstract.  E.g.
+
+     `--short`:: Emit output in the short-format.
+
+    and avoid something like these overly verbose alternatives:
+
+     `--short`:: Use this to emit output in the short-format.
+     `--short`:: You can use this to get output in the short-format.
+     `--short`:: A user who prefers shorter output could....
+     `--short`:: Should a person and/or program want shorter output, he
+                 she/they/it can...
+
+    This practice often eliminates the need to involve human actors in
+    your description, but it is a good practice regardless of the
+    avoidance of gendered pronouns.
+
+  - When it becomes awkward to stick to this style, prefer "you" when
+    addressing the hypothetical user, and possibly "we" when
+    discussing how the program might react to the user.  E.g.
+
+      You can use this option instead of `--xyz`, but we might remove
+      support for it in future versions.
+
+    while keeping in mind that you can probably be less verbose, e.g.
+
+      Use this instead of `--xyz`. This option might be removed in future
+      versions.
+
+  - If you still need to refer to an example person that is
+    third-person singular, you may resort to "singular they" to avoid
+    "he/she/him/her", e.g.
+
+      A contributor asks their upstream to pull from them.
+
+    Note that this sounds ungrammatical and unnatural to those who
+    learned that "they" is only used for third-person plural, e.g.
+    those who learn English as a second language in some parts of the
+    world.
+
+ Every user-visible change should be reflected in the documentation.
+ The same general rule as for code applies -- imitate the existing
+ conventions.
+
+
+Markup:
+
+ Literal parts (e.g. use of command-line options, command names,
+ branch names, URLs, pathnames (files and directories), configuration and
+ environment variables) must be typeset as verbatim (i.e. wrapped with
+ backticks):
+   `--pretty=oneline`
+   `git rev-list`
+   `remote.pushDefault`
+   `http://git.example.com`
+   `.git/config`
+   `GIT_DIR`
+   `HEAD`
+   `umask`(2)
+
+ An environment variable must be prefixed with "$" only when referring to its
+ value and not when referring to the variable itself, in this case there is
+ nothing to add except the backticks:
+   `GIT_DIR` is specified
+   `$GIT_DIR/hooks/pre-receive`
+
+ Word phrases enclosed in `backtick characters` are rendered literally
+ and will not be further expanded. The use of `backticks` to achieve the
+ previous rule means that literal examples should not use AsciiDoc
+ escapes.
+   Correct:
+      `--pretty=oneline`
+   Incorrect:
+      `\--pretty=oneline`
+
+ Placeholders are spelled in lowercase and enclosed in
+ angle brackets surrounded by underscores:
+   _<file>_
+   _<commit>_
+
+ If a placeholder has multiple words, they are separated by dashes:
+   _<new-branch-name>_
+   _<template-directory>_
+
+ A placeholder is not enclosed in backticks, as it is not a literal.
+
+ When needed, use a distinctive identifier for placeholders, usually
+ made of a qualification and a type:
+   _<git-dir>_
+   _<key-id>_
+
+ When literal and placeholders are mixed, each markup is applied for
+ each sub-entity. If they are stuck, a special markup, called
+ unconstrained formatting is required.
+ Unconstrained formating for placeholders is __<like-this>__
+ Unconstrained formatting for literal formatting is ++like this++
+   `--jobs` _<n>_
+   ++--sort=++__<key>__
+   __<directory>__++/.git++
+   ++remote.++__<name>__++.mirror++
+
+ caveat: ++ unconstrained format is not verbatim and may expand
+ content. Use Asciidoc escapes inside them.
+
+Synopsis Syntax
+
+ Syntax grammar is formatted neither as literal nor as placeholder.
+
+ A few commented examples follow to provide reference when writing or
+ modifying command usage strings and synopsis sections in the manual
+ pages:
+
+ Possibility of multiple occurrences is indicated by three dots:
+   _<file>_...
+   (One or more of <file>.)
+
+ Optional parts are enclosed in square brackets:
+   [_<file>_...]
+   (Zero or more of <file>.)
+
+   ++--exec-path++[++=++__<path>__]
+   (Option with an optional argument.  Note that the "=" is inside the
+   brackets.)
+
+   [_<patch>_...]
+   (Zero or more of <patch>.  Note that the dots are inside, not
+   outside the brackets.)
+
+ Multiple alternatives are indicated with vertical bars:
+   [`-q` | `--quiet`]
+   [`--utf8` | `--no-utf8`]
+
+ Use spacing around "|" token(s), but not immediately after opening or
+ before closing a [] or () pair:
+   Do: [`-q` | `--quiet`]
+   Don't: [`-q`|`--quiet`]
+
+ Don't use spacing around "|" tokens when they're used to separate the
+ alternate arguments of an option:
+    Do: ++--track++[++=++(`direct`|`inherit`)]`
+    Don't: ++--track++[++=++(`direct` | `inherit`)]
+
+ Parentheses are used for grouping:
+   [(_<rev>_ | _<range>_)...]
+   (Any number of either <rev> or <range>.  Parens are needed to make
+   it clear that "..." pertains to both <rev> and <range>.)
+
+   [(`-p` _<parent>_)...]
+   (Any number of option -p, each with one <parent> argument.)
+
+   `git remote set-head` _<name>_ (`-a` | `-d` | _<branch>_)
+   (One and only one of "-a", "-d" or "<branch>" _must_ (no square
+   brackets) be provided.)
+
+ And a somewhat more contrived example:
+   `--diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]`
+   Here "=" is outside the brackets, because "--diff-filter=" is a
+   valid usage.  "*" has its own pair of brackets, because it can
+   (optionally) be specified only when one or more of the letters is
+   also provided.
+
+  A note on notation:
+   Use 'git' (all lowercase) when talking about commands i.e. something
+   the user would type into a shell and use 'Git' (uppercase first letter)
+   when talking about the version control system and its properties.
+
+ If some place in the documentation needs to typeset a command usage
+ example with inline substitutions, it is fine to use +monospaced and
+ inline substituted text+ instead of `monospaced literal text`, and with
+ the former, the part that should not get substituted must be
+ quoted/escaped.
diff --git a/external/docs/asciidoc/ce20a0533295750b94bd23a9cb5c67430f8503ba b/external/docs/asciidoc/ce20a0533295750b94bd23a9cb5c67430f8503ba
new file mode 100644
index 0000000000..f4137c68ff
--- /dev/null
+++ b/external/docs/asciidoc/ce20a0533295750b94bd23a9cb5c67430f8503ba
@@ -0,0 +1,372 @@
+Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, three rough rules are:
+
+ - Most importantly, we never say "It's in POSIX; we'll happily
+   ignore your needs should your system not conform to it."
+   We live in the real world.
+
+ - However, we often say "Let's stay away from that construct,
+   it's not even in POSIX".
+
+ - In spite of the above two rules, we sometimes say "Although
+   this is not in POSIX, it (is so convenient | makes the code
+   much more readable | has other good characteristics) and
+   practically all the platforms we care about support it, so
+   let's use it".
+
+   Again, we live in the real world, and it is sometimes a
+   judgement call, the decision based more on real world
+   constraints people face than what the paper standard says.
+
+Make your code readable and sensible, and don't try to be clever.
+
+As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the _local_
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn't match the overall style of existing code).
+
+But if you must have a list of rules, here they are.
+
+For shell scripts specifically (not exhaustive):
+
+ - We use tabs for indentation.
+
+ - Case arms are indented at the same depth as case and esac lines.
+
+ - Redirection operators should be written with space before, but no
+   space after them.  In other words, write 'echo test >"$file"'
+   instead of 'echo test> $file' or 'echo test > $file'.  Note that
+   even though it is not required by POSIX to double-quote the
+   redirection target in a variable (as shown above), our code does so
+   because some versions of bash issue a warning without the quotes.
+
+ - We prefer $( ... ) for command substitution; unlike ``, it
+   properly nests.  It should have been the way Bourne spelled
+   it from day one, but unfortunately isn't.
+
+ - If you want to find out if a command is available on the user's
+   $PATH, you should use 'type <command>', instead of 'which <command>'.
+   The output of 'which' is not machine parseable and its exit code
+   is not reliable across platforms.
+
+ - We use POSIX compliant parameter substitutions and avoid bashisms;
+   namely:
+
+   - We use ${parameter-word} and its [-=?+] siblings, and their
+     colon'ed "unset or null" form.
+
+   - We use ${parameter#word} and its [#%] siblings, and their
+     doubled "longest matching" form.
+
+   - No "Substring Expansion" ${parameter:offset:length}.
+
+   - No shell arrays.
+
+   - No strlen ${#parameter}.
+
+   - No pattern replacement ${parameter/pattern/string}.
+
+ - We use Arithmetic Expansion $(( ... )).
+
+ - Inside Arithmetic Expansion, spell shell variables with $ in front
+   of them, as some shells do not grok $((x)) while accepting $(($x))
+   just fine (e.g. dash older than 0.5.4).
+
+ - We do not use Process Substitution <(list) or >(list).
+
+ - Do not write control structures on a single line with semicolon.
+   "then" should be on the next line for if statements, and "do"
+   should be on the next line for "while" and "for".
+
+ - We prefer "test" over "[ ... ]".
+
+ - We do not write the noiseword "function" in front of shell
+   functions.
+
+ - We prefer a space between the function name and the parentheses. The
+   opening "{" should also be on the same line.
+   E.g.: my_function () {
+
+ - As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+   [::], [==], or [..]) for portability.
+
+   - We do not use \{m,n\};
+
+   - We do not use -E;
+
+   - We do not use ? or + (which are \{0,1\} and \{1,\}
+     respectively in BRE) but that goes without saying as these
+     are ERE elements not BRE (note that \? and \+ are not even part
+     of BRE -- making them accessible from BRE is a GNU extension).
+
+ - Use Git's gettext wrappers in git-sh-i18n to make the user
+   interface translatable. See "Marking strings for translation" in
+   po/README.
+
+For C programs:
+
+ - We use tabs to indent, and interpret tabs as taking up to
+   8 spaces.
+
+ - We try to keep to at most 80 characters per line.
+
+ - We try to support a wide range of C compilers to compile Git with,
+   including old ones. That means that you should not use C99
+   initializers, even if a lot of compilers grok it.
+
+ - Variables have to be declared at the beginning of the block.
+
+ - NULL pointers shall be written as NULL, not as 0.
+
+ - When declaring pointers, the star sides with the variable
+   name, i.e. "char *string", not "char* string" or
+   "char * string".  This makes it easier to understand code
+   like "char *string, c;".
+
+ - Use whitespace around operators and keywords, but not inside
+   parentheses and not around functions. So:
+
+        while (condition)
+		func(bar + 1);
+
+   and not:
+
+        while( condition )
+		func (bar+1);
+
+ - We avoid using braces unnecessarily.  I.e.
+
+	if (bla) {
+		x = 1;
+	}
+
+   is frowned upon.  A gray area is when the statement extends
+   over a few lines, and/or you have a lengthy comment atop of
+   it.  Also, like in the Linux kernel, if there is a long list
+   of "else if" statements, it can make sense to add braces to
+   single line blocks.
+
+ - We try to avoid assignments inside if().
+
+ - Try to make your code understandable.  You may put comments
+   in, but comments invariably tend to stale out when the code
+   they were describing changes.  Often splitting a function
+   into two makes the intention of the code much clearer.
+
+ - Multi-line comments include their delimiters on separate lines from
+   the text.  E.g.
+
+	/*
+	 * A very long
+	 * multi-line comment.
+	 */
+
+   Note however that a comment that explains a translatable string to
+   translators uses a convention of starting with a magic token
+   "TRANSLATORS: " immediately after the opening delimiter, even when
+   it spans multiple lines.  We do not add an asterisk at the beginning
+   of each line, either.  E.g.
+
+	/* TRANSLATORS: here is a comment that explains the string
+	   to be translated, that follows immediately after it */
+	_("Here is a translatable string explained by the above.");
+
+ - Double negation is often harder to understand than no negation
+   at all.
+
+ - Some clever tricks, like using the !! operator with arithmetic
+   constructs, can be extremely confusing to others.  Avoid them,
+   unless there is a compelling reason to use them.
+
+ - Use the API.  No, really.  We have a strbuf (variable length
+   string), several arrays with the ALLOC_GROW() macro, a
+   string_list for sorted string lists, a hash map (mapping struct
+   objects) named "struct decorate", amongst other things.
+
+ - When you come up with an API, document it.
+
+ - The first #include in C files, except in platform specific
+   compat/ implementations, should be git-compat-util.h or another
+   header file that includes it, such as cache.h or builtin.h.
+
+ - If you are planning a new command, consider writing it in shell
+   or perl first, so that changes in semantics can be easily
+   changed and discussed.  Many Git commands started out like
+   that, and a few are still scripts.
+
+ - Avoid introducing a new dependency into Git. This means you
+   usually should stay away from scripting languages not already
+   used in the Git core command set (unless your command is clearly
+   separate from it, such as an importer to convert random-scm-X
+   repositories to Git).
+
+ - When we pass <string, length> pair to functions, we should try to
+   pass them in that order.
+
+ - Use Git's gettext wrappers to make the user interface
+   translatable. See "Marking strings for translation" in po/README.
+
+For Perl programs:
+
+ - Most of the C guidelines above apply.
+
+ - We try to support Perl 5.8 and later ("use Perl 5.008").
+
+ - use strict and use warnings are strongly preferred.
+
+ - Don't overuse statement modifiers unless using them makes the
+   result easier to follow.
+
+	... do something ...
+	do_this() unless (condition);
+        ... do something else ...
+
+   is more readable than:
+
+	... do something ...
+	unless (condition) {
+		do_this();
+	}
+        ... do something else ...
+
+   *only* when the condition is so rare that do_this() will be almost
+   always called.
+
+ - We try to avoid assignments inside "if ()" conditions.
+
+ - Learn and use Git.pm if you need that functionality.
+
+ - For Emacs, it's useful to put the following in
+   GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode:
+
+    ;; note the first part is useful for C editing, too
+    ((nil . ((indent-tabs-mode . t)
+                  (tab-width . 8)
+                  (fill-column . 80)))
+     (cperl-mode . ((cperl-indent-level . 8)
+                    (cperl-extra-newline-before-brace . nil)
+                    (cperl-merge-trailing-else . t))))
+
+For Python scripts:
+
+ - We follow PEP-8 (http://www.python.org/dev/peps/pep-0008/).
+
+ - As a minimum, we aim to be compatible with Python 2.6 and 2.7.
+
+ - Where required libraries do not restrict us to Python 2, we try to
+   also be compatible with Python 3.1 and later.
+
+ - When you must differentiate between Unicode literals and byte string
+   literals, it is OK to use the 'b' prefix.  Even though the Python
+   documentation for version 2.6 does not mention this prefix, it has
+   been supported since version 2.6.0.
+
+Error Messages
+
+ - Do not end error messages with a full stop.
+
+ - Do not capitalize ("unable to open %s", not "Unable to open %s")
+
+ - Say what the error is first ("cannot open %s", not "%s: cannot open")
+
+
+Writing Documentation:
+
+ Most (if not all) of the documentation pages are written in the
+ AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+ processed into HTML and manpages (e.g. git.html and git.1 in the
+ same directory).
+
+ The documentation liberally mixes US and UK English (en_US/UK)
+ norms for spelling and grammar, which is somewhat unfortunate.
+ In an ideal world, it would have been better if it consistently
+ used only one and not the other, and we would have picked en_US
+ (if you wish to correct the English of some of the existing
+ documentation, please see the documentation-related advice in the
+ Documentation/SubmittingPatches file).
+
+ Every user-visible change should be reflected in the documentation.
+ The same general rule as for code applies -- imitate the existing
+ conventions.
+
+ A few commented examples follow to provide reference when writing or
+ modifying command usage strings and synopsis sections in the manual
+ pages:
+
+ Placeholders are spelled in lowercase and enclosed in angle brackets:
+   <file>
+   --sort=<key>
+   --abbrev[=<n>]
+
+ Possibility of multiple occurrences is indicated by three dots:
+   <file>...
+   (One or more of <file>.)
+
+ Optional parts are enclosed in square brackets:
+   [<extra>]
+   (Zero or one <extra>.)
+
+   --exec-path[=<path>]
+   (Option with an optional argument.  Note that the "=" is inside the
+   brackets.)
+
+   [<patch>...]
+   (Zero or more of <patch>.  Note that the dots are inside, not
+   outside the brackets.)
+
+ Multiple alternatives are indicated with vertical bar:
+   [-q | --quiet]
+   [--utf8 | --no-utf8]
+
+ Parentheses are used for grouping:
+   [(<rev>|<range>)...]
+   (Any number of either <rev> or <range>.  Parens are needed to make
+   it clear that "..." pertains to both <rev> and <range>.)
+
+   [(-p <parent>)...]
+   (Any number of option -p, each with one <parent> argument.)
+
+   git remote set-head <name> (-a | -d | <branch>)
+   (One and only one of "-a", "-d" or "<branch>" _must_ (no square
+   brackets) be provided.)
+
+ And a somewhat more contrived example:
+   --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+   Here "=" is outside the brackets, because "--diff-filter=" is a
+   valid usage.  "*" has its own pair of brackets, because it can
+   (optionally) be specified only when one or more of the letters is
+   also provided.
+
+  A note on notation:
+   Use 'git' (all lowercase) when talking about commands i.e. something
+   the user would type into a shell and use 'Git' (uppercase first letter)
+   when talking about the version control system and its properties.
+
+ A few commented examples follow to provide reference when writing or
+ modifying paragraphs or option/command explanations that contain options
+ or commands:
+
+ Literal examples (e.g. use of command-line options, command names, and
+ configuration variables) are typeset in monospace, and if you can use
+ `backticks around word phrases`, do so.
+   `--pretty=oneline`
+   `git rev-list`
+   `remote.pushdefault`
+
+ Word phrases enclosed in `backtick characters` are rendered literally
+ and will not be further expanded. The use of `backticks` to achieve the
+ previous rule means that literal examples should not use AsciiDoc
+ escapes.
+   Correct:
+      `--pretty=oneline`
+   Incorrect:
+      `\--pretty=oneline`
+
+ If some place in the documentation needs to typeset a command usage
+ example with inline substitutions, it is fine to use +monospaced and
+ inline substituted text+ instead of `monospaced literal text`, and with
+ the former, the part that should not get substituted must be
+ quoted/escaped.
diff --git a/external/docs/asciidoc/d2d2e94cbec5178624611283429cb5f21861ff74 b/external/docs/asciidoc/d2d2e94cbec5178624611283429cb5f21861ff74
new file mode 100644
index 0000000000..112770a9da
--- /dev/null
+++ b/external/docs/asciidoc/d2d2e94cbec5178624611283429cb5f21861ff74
@@ -0,0 +1,155 @@
+= Upcoming breaking changes
+
+The Git project aims to ensure backwards compatibility to the best extent
+possible. Minor releases will not break backwards compatibility unless there is
+a very strong reason to do so, like for example a security vulnerability.
+
+Regardless of that, due to the age of the Git project, it is only natural to
+accumulate a backlog of backwards-incompatible changes that will eventually be
+required to keep the project aligned with a changing world. These changes fall
+into several categories:
+
+* Changes to long established defaults.
+* Concepts that have been replaced with a superior design.
+* Concepts, commands, configuration or options that have been lacking in major
+  ways and that cannot be fixed and which will thus be removed without any
+  replacement.
+
+Explicitly not included in this list are fixes to minor bugs that may cause a
+change in user-visible behavior.
+
+The Git project irregularly releases breaking versions that deliberately break
+backwards compatibility with older versions. This is done to ensure that Git
+remains relevant, safe and maintainable going forward. The release cadence of
+breaking versions is typically measured in multiple years. We had the following
+major breaking releases in the past:
+
+* Git 1.6.0, released in August 2008.
+* Git 2.0, released in May 2014.
+
+We use <major>.<minor> release numbers these days, starting from Git 2.0. For
+future releases, our plan is to increment <major> in the release number when we
+make the next breaking release. Before Git 2.0, the release numbers were
+1.<major>.<minor> with the intention to increment <major> for "usual" breaking
+releases, reserving the jump to Git 2.0 for really large backward-compatibility
+breaking changes.
+
+The intent of this document is to track upcoming deprecations for future
+breaking releases. Furthermore, this document also tracks what will _not_ be
+deprecated. This is done such that the outcome of discussions document both
+when the discussion favors deprecation, but also when it rejects a deprecation.
+
+Items should have a clear summary of the reasons why we do or do not want to
+make the described change that can be easily understood without having to read
+the mailing list discussions. If there are alternatives to the changed feature,
+those alternatives should be pointed out to our users.
+
+All items should be accompanied by references to relevant mailing list threads
+where the deprecation was discussed. These references use message-IDs, which
+can visited via
+
+  https://lore.kernel.org/git/$message_id/
+
+to see the message and its surrounding discussion. Such a reference is there to
+make it easier for you to find how the project reached consensus on the
+described item back then.
+
+This is a living document as the environment surrounding the project changes
+over time. If circumstances change, an earlier decision to deprecate or change
+something may need to be revisited from time to time. So do not take items on
+this list to mean "it is settled, do not waste our time bringing it up again".
+
+== Git 3.0
+
+The following subsections document upcoming breaking changes for Git 3.0. There
+is no planned release date for this breaking version yet.
+
+Proposed changes and removals only include items which are "ready" to be done.
+In other words, this is not supposed to be a wishlist of features that should
+be changed to or replaced in case the alternative was implemented already.
+
+=== Changes
+
+* The default hash function for new repositories will be changed from "sha1"
+  to "sha256". SHA-1 has been deprecated by NIST in 2011 and is nowadays
+  recommended against in FIPS 140-2 and similar certifications. Furthermore,
+  there are practical attacks on SHA-1 that weaken its cryptographic properties:
++
+  ** The SHAppening (2015). The first demonstration of a practical attack
+     against SHA-1 with 2^57 operations.
+  ** SHAttered (2017). Generation of two valid PDF files with 2^63 operations.
+  ** Birthday-Near-Collision (2019). This attack allows for chosen prefix
+     attacks with 2^68 operations.
+  ** Shambles (2020). This attack allows for chosen prefix attacks with 2^63
+     operations.
++
+While we have protections in place against known attacks, it is expected
+that more attacks against SHA-1 will be found by future research. Paired
+with the ever-growing capability of hardware, it is only a matter of time
+before SHA-1 will be considered broken completely. We want to be prepared
+and will thus change the default hash algorithm to "sha256" for newly
+initialized repositories.
++
+An important requirement for this change is that the ecosystem is ready to
+support the "sha256" object format. This includes popular Git libraries,
+applications and forges.
++
+There is no plan to deprecate the "sha1" object format at this point in time.
++
+Cf. <2f5de416-04ba-c23d-1e0b-83bb655829a7@zombino.com>,
+<20170223155046.e7nxivfwqqoprsqj@LykOS.localdomain>,
+<CA+EOSBncr=4a4d8n9xS4FNehyebpmX8JiUwCsXD47EQDE+DiUQ@mail.gmail.com>.
+
+=== Removals
+
+* Support for grafting commits has long been superseded by git-replace(1).
+  Grafts are inferior to replacement refs:
++
+  ** Grafts are a local-only mechanism and cannot be shared across
+     repositories.
+  ** Grafts can lead to hard-to-diagnose problems when transferring objects
+     between repositories.
++
+The grafting mechanism has been marked as outdated since e650d0643b (docs: mark
+info/grafts as outdated, 2014-03-05) and will be removed.
++
+Cf. <20140304174806.GA11561@sigill.intra.peff.net>.
+
+* The git-pack-redundant(1) command can be used to remove redundant pack files.
+  The subcommand is unusably slow and the reason why nobody reports it as a
+  performance bug is suspected to be the absence of users. We have nominated
+  the command for removal and have started to emit a user-visible warning in
+  c3b58472be (pack-redundant: gauge the usage before proposing its removal,
+  2020-08-25) whenever the command is executed.
++
+So far there was a single complaint about somebody still using the command, but
+that complaint did not cause us to reverse course. On the contrary, we have
+doubled down on the deprecation and starting with 4406522b76 (pack-redundant:
+escalate deprecation warning to an error, 2023-03-23), the command dies unless
+the user passes the `--i-still-use-this` option.
++
+There have not been any subsequent complaints, so this command will finally be
+removed.
++
+Cf. <xmqq1rjuz6n3.fsf_-_@gitster.c.googlers.com>,
+    <CAKvOHKAFXQwt4D8yUCCkf_TQL79mYaJ=KAKhtpDNTvHJFuX1NA@mail.gmail.com>,
+    <20230323204047.GA9290@coredump.intra.peff.net>,
+
+== Superseded features that will not be deprecated
+
+Some features have gained newer replacements that aim to improve the design in
+certain ways. The fact that there is a replacement does not automatically mean
+that the old way of doing things will eventually be removed. This section tracks
+those features with newer alternatives.
+
+* The features git-checkout(1) offers are covered by the pair of commands
+  git-restore(1) and git-switch(1). Because the use of git-checkout(1) is still
+  widespread, and it is not expected that this will change anytime soon, all
+  three commands will stay.
++
+This decision may get revisited in case we ever figure out that there are
+almost no users of any of the commands anymore.
++
+Cf. <xmqqttjazwwa.fsf@gitster.g>,
+<xmqqleeubork.fsf@gitster.g>,
+<112b6568912a6de6672bf5592c3a718e@manjaro.org>.
diff --git a/external/docs/asciidoc/d3b4cbca6a79491fc719c451995a3667cc68b397 b/external/docs/asciidoc/d3b4cbca6a79491fc719c451995a3667cc68b397
new file mode 100644
index 0000000000..894546dd75
--- /dev/null
+++ b/external/docs/asciidoc/d3b4cbca6a79491fc719c451995a3667cc68b397
@@ -0,0 +1,512 @@
+Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, three rough rules are:
+
+ - Most importantly, we never say "It's in POSIX; we'll happily
+   ignore your needs should your system not conform to it."
+   We live in the real world.
+
+ - However, we often say "Let's stay away from that construct,
+   it's not even in POSIX".
+
+ - In spite of the above two rules, we sometimes say "Although
+   this is not in POSIX, it (is so convenient | makes the code
+   much more readable | has other good characteristics) and
+   practically all the platforms we care about support it, so
+   let's use it".
+
+   Again, we live in the real world, and it is sometimes a
+   judgement call, the decision based more on real world
+   constraints people face than what the paper standard says.
+
+ - Fixing style violations while working on a real change as a
+   preparatory clean-up step is good, but otherwise avoid useless code
+   churn for the sake of conforming to the style.
+
+   "Once it _is_ in the tree, it's not really worth the patch noise to
+   go and fix it up."
+   Cf. http://article.gmane.org/gmane.linux.kernel/943020
+
+Make your code readable and sensible, and don't try to be clever.
+
+As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the _local_
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn't match the overall style of existing code).
+
+But if you must have a list of rules, here they are.
+
+For shell scripts specifically (not exhaustive):
+
+ - We use tabs for indentation.
+
+ - Case arms are indented at the same depth as case and esac lines,
+   like this:
+
+	case "$variable" in
+	pattern1)
+		do this
+		;;
+	pattern2)
+		do that
+		;;
+	esac
+
+ - Redirection operators should be written with space before, but no
+   space after them.  In other words, write 'echo test >"$file"'
+   instead of 'echo test> $file' or 'echo test > $file'.  Note that
+   even though it is not required by POSIX to double-quote the
+   redirection target in a variable (as shown above), our code does so
+   because some versions of bash issue a warning without the quotes.
+
+	(incorrect)
+	cat hello > world < universe
+	echo hello >$world
+
+	(correct)
+	cat hello >world <universe
+	echo hello >"$world"
+
+ - We prefer $( ... ) for command substitution; unlike ``, it
+   properly nests.  It should have been the way Bourne spelled
+   it from day one, but unfortunately isn't.
+
+ - If you want to find out if a command is available on the user's
+   $PATH, you should use 'type <command>', instead of 'which <command>'.
+   The output of 'which' is not machine parseable and its exit code
+   is not reliable across platforms.
+
+ - We use POSIX compliant parameter substitutions and avoid bashisms;
+   namely:
+
+   - We use ${parameter-word} and its [-=?+] siblings, and their
+     colon'ed "unset or null" form.
+
+   - We use ${parameter#word} and its [#%] siblings, and their
+     doubled "longest matching" form.
+
+   - No "Substring Expansion" ${parameter:offset:length}.
+
+   - No shell arrays.
+
+   - No strlen ${#parameter}.
+
+   - No pattern replacement ${parameter/pattern/string}.
+
+ - We use Arithmetic Expansion $(( ... )).
+
+ - Inside Arithmetic Expansion, spell shell variables with $ in front
+   of them, as some shells do not grok $((x)) while accepting $(($x))
+   just fine (e.g. dash older than 0.5.4).
+
+ - We do not use Process Substitution <(list) or >(list).
+
+ - Do not write control structures on a single line with semicolon.
+   "then" should be on the next line for if statements, and "do"
+   should be on the next line for "while" and "for".
+
+	(incorrect)
+	if test -f hello; then
+		do this
+	fi
+
+	(correct)
+	if test -f hello
+	then
+		do this
+	fi
+
+ - We prefer "test" over "[ ... ]".
+
+ - We do not write the noiseword "function" in front of shell
+   functions.
+
+ - We prefer a space between the function name and the parentheses,
+   and no space inside the parentheses. The opening "{" should also
+   be on the same line.
+
+	(incorrect)
+	my_function(){
+		...
+
+	(correct)
+	my_function () {
+		...
+
+ - As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+   [::], [==], or [..]) for portability.
+
+   - We do not use \{m,n\};
+
+   - We do not use -E;
+
+   - We do not use ? or + (which are \{0,1\} and \{1,\}
+     respectively in BRE) but that goes without saying as these
+     are ERE elements not BRE (note that \? and \+ are not even part
+     of BRE -- making them accessible from BRE is a GNU extension).
+
+ - Use Git's gettext wrappers in git-sh-i18n to make the user
+   interface translatable. See "Marking strings for translation" in
+   po/README.
+
+ - We do not write our "test" command with "-a" and "-o" and use "&&"
+   or "||" to concatenate multiple "test" commands instead, because
+   the use of "-a/-o" is often error-prone.  E.g.
+
+     test -n "$x" -a "$a" = "$b"
+
+   is buggy and breaks when $x is "=", but
+
+     test -n "$x" && test "$a" = "$b"
+
+   does not have such a problem.
+
+
+For C programs:
+
+ - We use tabs to indent, and interpret tabs as taking up to
+   8 spaces.
+
+ - We try to keep to at most 80 characters per line.
+
+ - We try to support a wide range of C compilers to compile Git with,
+   including old ones. That means that you should not use C99
+   initializers, even if a lot of compilers grok it.
+
+ - Variables have to be declared at the beginning of the block.
+
+ - NULL pointers shall be written as NULL, not as 0.
+
+ - When declaring pointers, the star sides with the variable
+   name, i.e. "char *string", not "char* string" or
+   "char * string".  This makes it easier to understand code
+   like "char *string, c;".
+
+ - Use whitespace around operators and keywords, but not inside
+   parentheses and not around functions. So:
+
+        while (condition)
+		func(bar + 1);
+
+   and not:
+
+        while( condition )
+		func (bar+1);
+
+ - We avoid using braces unnecessarily.  I.e.
+
+	if (bla) {
+		x = 1;
+	}
+
+   is frowned upon.  A gray area is when the statement extends
+   over a few lines, and/or you have a lengthy comment atop of
+   it.  Also, like in the Linux kernel, if there is a long list
+   of "else if" statements, it can make sense to add braces to
+   single line blocks.
+
+ - We try to avoid assignments in the condition of an "if" statement.
+
+ - Try to make your code understandable.  You may put comments
+   in, but comments invariably tend to stale out when the code
+   they were describing changes.  Often splitting a function
+   into two makes the intention of the code much clearer.
+
+ - Multi-line comments include their delimiters on separate lines from
+   the text.  E.g.
+
+	/*
+	 * A very long
+	 * multi-line comment.
+	 */
+
+   Note however that a comment that explains a translatable string to
+   translators uses a convention of starting with a magic token
+   "TRANSLATORS: " immediately after the opening delimiter, even when
+   it spans multiple lines.  We do not add an asterisk at the beginning
+   of each line, either.  E.g.
+
+	/* TRANSLATORS: here is a comment that explains the string
+	   to be translated, that follows immediately after it */
+	_("Here is a translatable string explained by the above.");
+
+ - Double negation is often harder to understand than no negation
+   at all.
+
+ - There are two schools of thought when it comes to comparison,
+   especially inside a loop. Some people prefer to have the less stable
+   value on the left hand side and the more stable value on the right hand
+   side, e.g. if you have a loop that counts variable i down to the
+   lower bound,
+
+	while (i > lower_bound) {
+		do something;
+		i--;
+	}
+
+   Other people prefer to have the textual order of values match the
+   actual order of values in their comparison, so that they can
+   mentally draw a number line from left to right and place these
+   values in order, i.e.
+
+	while (lower_bound < i) {
+		do something;
+		i--;
+	}
+
+   Both are valid, and we use both.  However, the more "stable" the
+   stable side becomes, the more we tend to prefer the former
+   (comparison with a constant, "i > 0", is an extreme example).
+   Just do not mix styles in the same part of the code and mimic
+   existing styles in the neighbourhood.
+
+ - There are two schools of thought when it comes to splitting a long
+   logical line into multiple lines.  Some people push the second and
+   subsequent lines far enough to the right with tabs and align them:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+		span_more_than_a_single_line_of ||
+		the_source_text) {
+                ...
+
+   while other people prefer to align the second and the subsequent
+   lines with the column immediately inside the opening parenthesis,
+   with tabs and spaces, following our "tabstop is always a multiple
+   of 8" convention:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of ||
+	    the_source_text) {
+                ...
+
+   Both are valid, and we use both.  Again, just do not mix styles in
+   the same part of the code and mimic existing styles in the
+   neighbourhood.
+
+ - When splitting a long logical line, some people change line before
+   a binary operator, so that the result looks like a parse tree when
+   you turn your head 90-degrees counterclockwise:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to
+	    || span_more_than_a_single_line_of_the_source_text) {
+
+   while other people prefer to leave the operator at the end of the
+   line:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of_the_source_text) {
+
+   Both are valid, but we tend to use the latter more, unless the
+   expression gets fairly complex, in which case the former tends to
+   be easier to read.  Again, just do not mix styles in the same part
+   of the code and mimic existing styles in the neighbourhood.
+
+ - When splitting a long logical line, with everything else being
+   equal, it is preferable to split after the operator at higher
+   level in the parse tree.  That is, this is more preferable:
+
+	if (a_very_long_variable * that_is_used_in +
+	    a_very_long_expression) {
+		...
+
+   than
+
+	if (a_very_long_variable *
+	    that_is_used_in + a_very_long_expression) {
+		...
+
+ - Some clever tricks, like using the !! operator with arithmetic
+   constructs, can be extremely confusing to others.  Avoid them,
+   unless there is a compelling reason to use them.
+
+ - Use the API.  No, really.  We have a strbuf (variable length
+   string), several arrays with the ALLOC_GROW() macro, a
+   string_list for sorted string lists, a hash map (mapping struct
+   objects) named "struct decorate", amongst other things.
+
+ - When you come up with an API, document it.
+
+ - The first #include in C files, except in platform specific
+   compat/ implementations, should be git-compat-util.h or another
+   header file that includes it, such as cache.h or builtin.h.
+
+ - If you are planning a new command, consider writing it in shell
+   or perl first, so that changes in semantics can be easily
+   changed and discussed.  Many Git commands started out like
+   that, and a few are still scripts.
+
+ - Avoid introducing a new dependency into Git. This means you
+   usually should stay away from scripting languages not already
+   used in the Git core command set (unless your command is clearly
+   separate from it, such as an importer to convert random-scm-X
+   repositories to Git).
+
+ - When we pass <string, length> pair to functions, we should try to
+   pass them in that order.
+
+ - Use Git's gettext wrappers to make the user interface
+   translatable. See "Marking strings for translation" in po/README.
+
+For Perl programs:
+
+ - Most of the C guidelines above apply.
+
+ - We try to support Perl 5.8 and later ("use Perl 5.008").
+
+ - use strict and use warnings are strongly preferred.
+
+ - Don't overuse statement modifiers unless using them makes the
+   result easier to follow.
+
+	... do something ...
+	do_this() unless (condition);
+        ... do something else ...
+
+   is more readable than:
+
+	... do something ...
+	unless (condition) {
+		do_this();
+	}
+        ... do something else ...
+
+   *only* when the condition is so rare that do_this() will be almost
+   always called.
+
+ - We try to avoid assignments inside "if ()" conditions.
+
+ - Learn and use Git.pm if you need that functionality.
+
+ - For Emacs, it's useful to put the following in
+   GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode:
+
+    ;; note the first part is useful for C editing, too
+    ((nil . ((indent-tabs-mode . t)
+                  (tab-width . 8)
+                  (fill-column . 80)))
+     (cperl-mode . ((cperl-indent-level . 8)
+                    (cperl-extra-newline-before-brace . nil)
+                    (cperl-merge-trailing-else . t))))
+
+For Python scripts:
+
+ - We follow PEP-8 (http://www.python.org/dev/peps/pep-0008/).
+
+ - As a minimum, we aim to be compatible with Python 2.6 and 2.7.
+
+ - Where required libraries do not restrict us to Python 2, we try to
+   also be compatible with Python 3.1 and later.
+
+ - When you must differentiate between Unicode literals and byte string
+   literals, it is OK to use the 'b' prefix.  Even though the Python
+   documentation for version 2.6 does not mention this prefix, it has
+   been supported since version 2.6.0.
+
+Error Messages
+
+ - Do not end error messages with a full stop.
+
+ - Do not capitalize ("unable to open %s", not "Unable to open %s")
+
+ - Say what the error is first ("cannot open %s", not "%s: cannot open")
+
+
+Writing Documentation:
+
+ Most (if not all) of the documentation pages are written in the
+ AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+ processed into HTML and manpages (e.g. git.html and git.1 in the
+ same directory).
+
+ The documentation liberally mixes US and UK English (en_US/UK)
+ norms for spelling and grammar, which is somewhat unfortunate.
+ In an ideal world, it would have been better if it consistently
+ used only one and not the other, and we would have picked en_US
+ (if you wish to correct the English of some of the existing
+ documentation, please see the documentation-related advice in the
+ Documentation/SubmittingPatches file).
+
+ Every user-visible change should be reflected in the documentation.
+ The same general rule as for code applies -- imitate the existing
+ conventions.
+
+ A few commented examples follow to provide reference when writing or
+ modifying command usage strings and synopsis sections in the manual
+ pages:
+
+ Placeholders are spelled in lowercase and enclosed in angle brackets:
+   <file>
+   --sort=<key>
+   --abbrev[=<n>]
+
+ Possibility of multiple occurrences is indicated by three dots:
+   <file>...
+   (One or more of <file>.)
+
+ Optional parts are enclosed in square brackets:
+   [<extra>]
+   (Zero or one <extra>.)
+
+   --exec-path[=<path>]
+   (Option with an optional argument.  Note that the "=" is inside the
+   brackets.)
+
+   [<patch>...]
+   (Zero or more of <patch>.  Note that the dots are inside, not
+   outside the brackets.)
+
+ Multiple alternatives are indicated with vertical bar:
+   [-q | --quiet]
+   [--utf8 | --no-utf8]
+
+ Parentheses are used for grouping:
+   [(<rev>|<range>)...]
+   (Any number of either <rev> or <range>.  Parens are needed to make
+   it clear that "..." pertains to both <rev> and <range>.)
+
+   [(-p <parent>)...]
+   (Any number of option -p, each with one <parent> argument.)
+
+   git remote set-head <name> (-a | -d | <branch>)
+   (One and only one of "-a", "-d" or "<branch>" _must_ (no square
+   brackets) be provided.)
+
+ And a somewhat more contrived example:
+   --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+   Here "=" is outside the brackets, because "--diff-filter=" is a
+   valid usage.  "*" has its own pair of brackets, because it can
+   (optionally) be specified only when one or more of the letters is
+   also provided.
+
+  A note on notation:
+   Use 'git' (all lowercase) when talking about commands i.e. something
+   the user would type into a shell and use 'Git' (uppercase first letter)
+   when talking about the version control system and its properties.
+
+ A few commented examples follow to provide reference when writing or
+ modifying paragraphs or option/command explanations that contain options
+ or commands:
+
+ Literal examples (e.g. use of command-line options, command names, and
+ configuration variables) are typeset in monospace, and if you can use
+ `backticks around word phrases`, do so.
+   `--pretty=oneline`
+   `git rev-list`
+   `remote.pushdefault`
+
+ Word phrases enclosed in `backtick characters` are rendered literally
+ and will not be further expanded. The use of `backticks` to achieve the
+ previous rule means that literal examples should not use AsciiDoc
+ escapes.
+   Correct:
+      `--pretty=oneline`
+   Incorrect:
+      `\--pretty=oneline`
+
+ If some place in the documentation needs to typeset a command usage
+ example with inline substitutions, it is fine to use +monospaced and
+ inline substituted text+ instead of `monospaced literal text`, and with
+ the former, the part that should not get substituted must be
+ quoted/escaped.
diff --git a/external/docs/asciidoc/d49c40b5a0969c8f9c2b9ff6cc204e92af030f8e b/external/docs/asciidoc/d49c40b5a0969c8f9c2b9ff6cc204e92af030f8e
new file mode 100644
index 0000000000..578587a471
--- /dev/null
+++ b/external/docs/asciidoc/d49c40b5a0969c8f9c2b9ff6cc204e92af030f8e
@@ -0,0 +1,758 @@
+Like other projects, we also have some guidelines for our code.  For
+Git in general, a few rough rules are:
+
+ - Most importantly, we never say "It's in POSIX; we'll happily
+   ignore your needs should your system not conform to it."
+   We live in the real world.
+
+ - However, we often say "Let's stay away from that construct,
+   it's not even in POSIX".
+
+ - In spite of the above two rules, we sometimes say "Although
+   this is not in POSIX, it (is so convenient | makes the code
+   much more readable | has other good characteristics) and
+   practically all the platforms we care about support it, so
+   let's use it".
+
+   Again, we live in the real world, and it is sometimes a
+   judgement call, the decision based more on real world
+   constraints people face than what the paper standard says.
+
+ - Fixing style violations while working on a real change as a
+   preparatory clean-up step is good, but otherwise avoid useless code
+   churn for the sake of conforming to the style.
+
+   "Once it _is_ in the tree, it's not really worth the patch noise to
+   go and fix it up."
+   Cf. https://lore.kernel.org/all/20100126160632.3bdbe172.akpm@linux-foundation.org/
+
+ - Log messages to explain your changes are as important as the
+   changes themselves.  Clearly written code and in-code comments
+   explain how the code works and what is assumed from the surrounding
+   context.  The log messages explain what the changes wanted to
+   achieve and why the changes were necessary (more on this in the
+   accompanying SubmittingPatches document).
+
+Make your code readable and sensible, and don't try to be clever.
+
+As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the _local_
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code are expected to match the style the surrounding code already
+uses (even if it doesn't match the overall style of existing code).
+
+But if you must have a list of rules, here are some language
+specific ones. Note that Documentation/ToolsForGit.txt document
+has a collection of tips to help you use some external tools
+to conform to these guidelines.
+
+For shell scripts specifically (not exhaustive):
+
+ - We use tabs for indentation.
+
+ - Case arms are indented at the same depth as case and esac lines,
+   like this:
+
+	case "$variable" in
+	pattern1)
+		do this
+		;;
+	pattern2)
+		do that
+		;;
+	esac
+
+ - Redirection operators should be written with space before, but no
+   space after them.  In other words, write 'echo test >"$file"'
+   instead of 'echo test> $file' or 'echo test > $file'.  Note that
+   even though it is not required by POSIX to double-quote the
+   redirection target in a variable (as shown above), our code does so
+   because some versions of bash issue a warning without the quotes.
+
+	(incorrect)
+	cat hello > world < universe
+	echo hello >$world
+
+	(correct)
+	cat hello >world <universe
+	echo hello >"$world"
+
+ - We prefer $( ... ) for command substitution; unlike ``, it
+   properly nests.  It should have been the way Bourne spelled
+   it from day one, but unfortunately isn't.
+
+ - If you want to find out if a command is available on the user's
+   $PATH, you should use 'type <command>', instead of 'which <command>'.
+   The output of 'which' is not machine parsable and its exit code
+   is not reliable across platforms.
+
+ - We use POSIX compliant parameter substitutions and avoid bashisms;
+   namely:
+
+   - We use ${parameter-word} and its [-=?+] siblings, and their
+     colon'ed "unset or null" form.
+
+   - We use ${parameter#word} and its [#%] siblings, and their
+     doubled "longest matching" form.
+
+   - No "Substring Expansion" ${parameter:offset:length}.
+
+   - No shell arrays.
+
+   - No pattern replacement ${parameter/pattern/string}.
+
+ - We use Arithmetic Expansion $(( ... )).
+
+ - We do not use Process Substitution <(list) or >(list).
+
+ - Do not write control structures on a single line with semicolon.
+   "then" should be on the next line for if statements, and "do"
+   should be on the next line for "while" and "for".
+
+	(incorrect)
+	if test -f hello; then
+		do this
+	fi
+
+	(correct)
+	if test -f hello
+	then
+		do this
+	fi
+
+ - If a command sequence joined with && or || or | spans multiple
+   lines, put each command on a separate line and put && and || and |
+   operators at the end of each line, rather than the start. This
+   means you don't need to use \ to join lines, since the above
+   operators imply the sequence isn't finished.
+
+	(incorrect)
+	grep blob verify_pack_result \
+	| awk -f print_1.awk \
+	| sort >actual &&
+	...
+
+	(correct)
+	grep blob verify_pack_result |
+	awk -f print_1.awk |
+	sort >actual &&
+	...
+
+ - We prefer "test" over "[ ... ]".
+
+ - We do not write the noiseword "function" in front of shell
+   functions.
+
+ - We prefer a space between the function name and the parentheses,
+   and no space inside the parentheses. The opening "{" should also
+   be on the same line.
+
+	(incorrect)
+	my_function(){
+		...
+
+	(correct)
+	my_function () {
+		...
+
+ - As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+   [::], [==], or [..]) for portability.
+
+   - We do not use \{m,n\};
+
+   - We do not use ? or + (which are \{0,1\} and \{1,\}
+     respectively in BRE) but that goes without saying as these
+     are ERE elements not BRE (note that \? and \+ are not even part
+     of BRE -- making them accessible from BRE is a GNU extension).
+
+ - Use Git's gettext wrappers in git-sh-i18n to make the user
+   interface translatable. See "Marking strings for translation" in
+   po/README.
+
+ - We do not write our "test" command with "-a" and "-o" and use "&&"
+   or "||" to concatenate multiple "test" commands instead, because
+   the use of "-a/-o" is often error-prone.  E.g.
+
+     test -n "$x" -a "$a" = "$b"
+
+   is buggy and breaks when $x is "=", but
+
+     test -n "$x" && test "$a" = "$b"
+
+   does not have such a problem.
+
+ - Even though "local" is not part of POSIX, we make heavy use of it
+   in our test suite.  We do not use it in scripted Porcelains, and
+   hopefully nobody starts using "local" before they are reimplemented
+   in C ;-)
+
+ - Use octal escape sequences (e.g. "\302\242"), not hexadecimal (e.g.
+   "\xc2\xa2") in printf format strings, since hexadecimal escape
+   sequences are not portable.
+
+
+For C programs:
+
+ - We use tabs to indent, and interpret tabs as taking up to
+   8 spaces.
+
+ - We try to keep to at most 80 characters per line.
+
+ - As a Git developer we assume you have a reasonably modern compiler
+   and we recommend you to enable the DEVELOPER makefile knob to
+   ensure your patch is clear of all compiler warnings we care about,
+   by e.g. "echo DEVELOPER=1 >>config.mak".
+
+ - We try to support a wide range of C compilers to compile Git with,
+   including old ones.  As of Git v2.35.0 Git requires C99 (we check
+   "__STDC_VERSION__"). You should not use features from a newer C
+   standard, even if your compiler groks them.
+
+   New C99 features have been phased in gradually, if something's new
+   in C99 but not used yet don't assume that it's safe to use, some
+   compilers we target have only partial support for it. These are
+   considered safe to use:
+
+   . since around 2007 with 2b6854c863a, we have been using
+     initializer elements which are not computable at load time. E.g.:
+
+	const char *args[] = {"constant", variable, NULL};
+
+   . since early 2012 with e1327023ea, we have been using an enum
+     definition whose last element is followed by a comma.  This, like
+     an array initializer that ends with a trailing comma, can be used
+     to reduce the patch noise when adding a new identifier at the end.
+
+   . since mid 2017 with cbc0f81d, we have been using designated
+     initializers for struct (e.g. "struct t v = { .val = 'a' };").
+
+   . since mid 2017 with 512f41cf, we have been using designated
+     initializers for array (e.g. "int array[10] = { [5] = 2 }").
+
+   . since early 2021 with 765dc168882, we have been using variadic
+     macros, mostly for printf-like trace and debug macros.
+
+   . since late 2021 with 44ba10d6, we have had variables declared in
+     the for loop "for (int i = 0; i < 10; i++)".
+
+   New C99 features that we cannot use yet:
+
+   . %z and %zu as a printf() argument for a size_t (the %z being for
+     the POSIX-specific ssize_t). Instead you should use
+     printf("%"PRIuMAX, (uintmax_t)v).  These days the MSVC version we
+     rely on supports %z, but the C library used by MinGW does not.
+
+   . Shorthand like ".a.b = *c" in struct initializations is known to
+     trip up an older IBM XLC version, use ".a = { .b = *c }" instead.
+     See the 33665d98 (reftable: make assignments portable to AIX xlc
+     v12.01, 2022-03-28).
+
+ - Variables have to be declared at the beginning of the block, before
+   the first statement (i.e. -Wdeclaration-after-statement).
+
+ - NULL pointers shall be written as NULL, not as 0.
+
+ - When declaring pointers, the star sides with the variable
+   name, i.e. "char *string", not "char* string" or
+   "char * string".  This makes it easier to understand code
+   like "char *string, c;".
+
+ - Use whitespace around operators and keywords, but not inside
+   parentheses and not around functions. So:
+
+        while (condition)
+		func(bar + 1);
+
+   and not:
+
+        while( condition )
+		func (bar+1);
+
+ - Do not explicitly compare an integral value with constant 0 or '\0',
+   or a pointer value with constant NULL.  For instance, to validate that
+   counted array <ptr, cnt> is initialized but has no elements, write:
+
+	if (!ptr || cnt)
+		BUG("empty array expected");
+
+   and not:
+
+	if (ptr == NULL || cnt != 0);
+		BUG("empty array expected");
+
+ - We avoid using braces unnecessarily.  I.e.
+
+	if (bla) {
+		x = 1;
+	}
+
+   is frowned upon. But there are a few exceptions:
+
+	- When the statement extends over a few lines (e.g., a while loop
+	  with an embedded conditional, or a comment). E.g.:
+
+		while (foo) {
+			if (x)
+				one();
+			else
+				two();
+		}
+
+		if (foo) {
+			/*
+			 * This one requires some explanation,
+			 * so we're better off with braces to make
+			 * it obvious that the indentation is correct.
+			 */
+			doit();
+		}
+
+	- When there are multiple arms to a conditional and some of them
+	  require braces, enclose even a single line block in braces for
+	  consistency. E.g.:
+
+		if (foo) {
+			doit();
+		} else {
+			one();
+			two();
+			three();
+		}
+
+ - We try to avoid assignments in the condition of an "if" statement.
+
+ - Try to make your code understandable.  You may put comments
+   in, but comments invariably tend to stale out when the code
+   they were describing changes.  Often splitting a function
+   into two makes the intention of the code much clearer.
+
+ - Multi-line comments include their delimiters on separate lines from
+   the text.  E.g.
+
+	/*
+	 * A very long
+	 * multi-line comment.
+	 */
+
+   Note however that a comment that explains a translatable string to
+   translators uses a convention of starting with a magic token
+   "TRANSLATORS: ", e.g.
+
+	/*
+	 * TRANSLATORS: here is a comment that explains the string to
+	 * be translated, that follows immediately after it.
+	 */
+	_("Here is a translatable string explained by the above.");
+
+ - Double negation is often harder to understand than no negation
+   at all.
+
+ - There are two schools of thought when it comes to comparison,
+   especially inside a loop. Some people prefer to have the less stable
+   value on the left hand side and the more stable value on the right hand
+   side, e.g. if you have a loop that counts variable i down to the
+   lower bound,
+
+	while (i > lower_bound) {
+		do something;
+		i--;
+	}
+
+   Other people prefer to have the textual order of values match the
+   actual order of values in their comparison, so that they can
+   mentally draw a number line from left to right and place these
+   values in order, i.e.
+
+	while (lower_bound < i) {
+		do something;
+		i--;
+	}
+
+   Both are valid, and we use both.  However, the more "stable" the
+   stable side becomes, the more we tend to prefer the former
+   (comparison with a constant, "i > 0", is an extreme example).
+   Just do not mix styles in the same part of the code and mimic
+   existing styles in the neighbourhood.
+
+ - There are two schools of thought when it comes to splitting a long
+   logical line into multiple lines.  Some people push the second and
+   subsequent lines far enough to the right with tabs and align them:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+		span_more_than_a_single_line_of ||
+		the_source_text) {
+                ...
+
+   while other people prefer to align the second and the subsequent
+   lines with the column immediately inside the opening parenthesis,
+   with tabs and spaces, following our "tabstop is always a multiple
+   of 8" convention:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of ||
+	    the_source_text) {
+                ...
+
+   Both are valid, and we use both.  Again, just do not mix styles in
+   the same part of the code and mimic existing styles in the
+   neighbourhood.
+
+ - When splitting a long logical line, some people change line before
+   a binary operator, so that the result looks like a parse tree when
+   you turn your head 90-degrees counterclockwise:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to
+	    || span_more_than_a_single_line_of_the_source_text) {
+
+   while other people prefer to leave the operator at the end of the
+   line:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of_the_source_text) {
+
+   Both are valid, but we tend to use the latter more, unless the
+   expression gets fairly complex, in which case the former tends to
+   be easier to read.  Again, just do not mix styles in the same part
+   of the code and mimic existing styles in the neighbourhood.
+
+ - When splitting a long logical line, with everything else being
+   equal, it is preferable to split after the operator at higher
+   level in the parse tree.  That is, this is more preferable:
+
+	if (a_very_long_variable * that_is_used_in +
+	    a_very_long_expression) {
+		...
+
+   than
+
+	if (a_very_long_variable *
+	    that_is_used_in + a_very_long_expression) {
+		...
+
+ - Some clever tricks, like using the !! operator with arithmetic
+   constructs, can be extremely confusing to others.  Avoid them,
+   unless there is a compelling reason to use them.
+
+ - Use the API.  No, really.  We have a strbuf (variable length
+   string), several arrays with the ALLOC_GROW() macro, a
+   string_list for sorted string lists, a hash map (mapping struct
+   objects) named "struct decorate", amongst other things.
+
+ - When you come up with an API, document its functions and structures
+   in the header file that exposes the API to its callers. Use what is
+   in "strbuf.h" as a model for the appropriate tone and level of
+   detail.
+
+ - The first #include in C files, except in platform specific compat/
+   implementations and sha1dc/, must be either "git-compat-util.h" or
+   one of the approved headers that includes it first for you.  (The
+   approved headers currently include "builtin.h",
+   "t/helper/test-tool.h", "xdiff/xinclude.h", or
+   "reftable/system.h".)  You do not have to include more than one of
+   these.
+
+ - A C file must directly include the header files that declare the
+   functions and the types it uses, except for the functions and types
+   that are made available to it by including one of the header files
+   it must include by the previous rule.
+
+ - If you are planning a new command, consider writing it in shell
+   or perl first, so that changes in semantics can be easily
+   changed and discussed.  Many Git commands started out like
+   that, and a few are still scripts.
+
+ - Avoid introducing a new dependency into Git. This means you
+   usually should stay away from scripting languages not already
+   used in the Git core command set (unless your command is clearly
+   separate from it, such as an importer to convert random-scm-X
+   repositories to Git).
+
+ - When we pass <string, length> pair to functions, we should try to
+   pass them in that order.
+
+ - Use Git's gettext wrappers to make the user interface
+   translatable. See "Marking strings for translation" in po/README.
+
+ - Variables and functions local to a given source file should be marked
+   with "static". Variables that are visible to other source files
+   must be declared with "extern" in header files. However, function
+   declarations should not use "extern", as that is already the default.
+
+ - You can launch gdb around your program using the shorthand GIT_DEBUGGER.
+   Run `GIT_DEBUGGER=1 ./bin-wrappers/git foo` to simply use gdb as is, or
+   run `GIT_DEBUGGER="<debugger> <debugger-args>" ./bin-wrappers/git foo` to
+   use your own debugger and arguments. Example: `GIT_DEBUGGER="ddd --gdb"
+   ./bin-wrappers/git log` (See `wrap-for-bin.sh`.)
+
+For Perl programs:
+
+ - Most of the C guidelines above apply.
+
+ - We try to support Perl 5.8.1 and later ("use Perl 5.008001").
+
+ - use strict and use warnings are strongly preferred.
+
+ - Don't overuse statement modifiers unless using them makes the
+   result easier to follow.
+
+	... do something ...
+	do_this() unless (condition);
+        ... do something else ...
+
+   is more readable than:
+
+	... do something ...
+	unless (condition) {
+		do_this();
+	}
+        ... do something else ...
+
+   *only* when the condition is so rare that do_this() will be almost
+   always called.
+
+ - We try to avoid assignments inside "if ()" conditions.
+
+ - Learn and use Git.pm if you need that functionality.
+
+For Python scripts:
+
+ - We follow PEP-8 (https://peps.python.org/pep-0008/).
+
+ - As a minimum, we aim to be compatible with Python 2.7.
+
+ - Where required libraries do not restrict us to Python 2, we try to
+   also be compatible with Python 3.1 and later.
+
+
+Program Output
+
+ We make a distinction between a Git command's primary output and
+ output which is merely chatty feedback (for instance, status
+ messages, running transcript, or progress display), as well as error
+ messages. Roughly speaking, a Git command's primary output is that
+ which one might want to capture to a file or send down a pipe; its
+ chatty output should not interfere with these use-cases.
+
+ As such, primary output should be sent to the standard output stream
+ (stdout), and chatty output should be sent to the standard error
+ stream (stderr). Examples of commands which produce primary output
+ include `git log`, `git show`, and `git branch --list` which generate
+ output on the stdout stream.
+
+ Not all Git commands have primary output; this is often true of
+ commands whose main function is to perform an action. Some action
+ commands are silent, whereas others are chatty. An example of a
+ chatty action commands is `git clone` with its "Cloning into
+ '<path>'..." and "Checking connectivity..." status messages which it
+ sends to the stderr stream.
+
+ Error messages from Git commands should always be sent to the stderr
+ stream.
+
+
+Error Messages
+
+ - Do not end error messages with a full stop.
+
+ - Do not capitalize the first word, only because it is the first word
+   in the message ("unable to open %s", not "Unable to open %s").  But
+   "SHA-3 not supported" is fine, because the reason the first word is
+   capitalized is not because it is at the beginning of the sentence,
+   but because the word would be spelled in capital letters even when
+   it appeared in the middle of the sentence.
+
+ - Say what the error is first ("cannot open %s", not "%s: cannot open")
+
+
+Externally Visible Names
+
+ - For configuration variable names, follow the existing convention:
+
+   . The section name indicates the affected subsystem.
+
+   . The subsection name, if any, indicates which of an unbounded set
+     of things to set the value for.
+
+   . The variable name describes the effect of tweaking this knob.
+
+   The section and variable names that consist of multiple words are
+   formed by concatenating the words without punctuation marks (e.g. `-`),
+   and are broken using bumpyCaps in documentation as a hint to the
+   reader.
+
+   When choosing the variable namespace, do not use variable name for
+   specifying possibly unbounded set of things, most notably anything
+   an end user can freely come up with (e.g. branch names).  Instead,
+   use subsection names or variable values, like the existing variable
+   branch.<name>.description does.
+
+
+Writing Documentation:
+
+ Most (if not all) of the documentation pages are written in the
+ AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+ processed into HTML and manpages (e.g. git.html and git.1 in the
+ same directory).
+
+ The documentation liberally mixes US and UK English (en_US/UK)
+ norms for spelling and grammar, which is somewhat unfortunate.
+ In an ideal world, it would have been better if it consistently
+ used only one and not the other, and we would have picked en_US
+ (if you wish to correct the English of some of the existing
+ documentation, please see the documentation-related advice in the
+ Documentation/SubmittingPatches file).
+
+ In order to ensure the documentation is inclusive, avoid assuming
+ that an unspecified example person is male or female, and think
+ twice before using "he", "him", "she", or "her".  Here are some
+ tips to avoid use of gendered pronouns:
+
+  - Prefer succinctness and matter-of-factly describing functionality
+    in the abstract.  E.g.
+
+     --short:: Emit output in the short-format.
+
+    and avoid something like these overly verbose alternatives:
+
+     --short:: Use this to emit output in the short-format.
+     --short:: You can use this to get output in the short-format.
+     --short:: A user who prefers shorter output could....
+     --short:: Should a person and/or program want shorter output, he
+               she/they/it can...
+
+    This practice often eliminates the need to involve human actors in
+    your description, but it is a good practice regardless of the
+    avoidance of gendered pronouns.
+
+  - When it becomes awkward to stick to this style, prefer "you" when
+    addressing the hypothetical user, and possibly "we" when
+    discussing how the program might react to the user.  E.g.
+
+      You can use this option instead of --xyz, but we might remove
+      support for it in future versions.
+
+    while keeping in mind that you can probably be less verbose, e.g.
+
+      Use this instead of --xyz. This option might be removed in future
+      versions.
+
+  - If you still need to refer to an example person that is
+    third-person singular, you may resort to "singular they" to avoid
+    "he/she/him/her", e.g.
+
+      A contributor asks their upstream to pull from them.
+
+    Note that this sounds ungrammatical and unnatural to those who
+    learned that "they" is only used for third-person plural, e.g.
+    those who learn English as a second language in some parts of the
+    world.
+
+ Every user-visible change should be reflected in the documentation.
+ The same general rule as for code applies -- imitate the existing
+ conventions.
+
+ A few commented examples follow to provide reference when writing or
+ modifying command usage strings and synopsis sections in the manual
+ pages:
+
+ Placeholders are spelled in lowercase and enclosed in angle brackets:
+   <file>
+   --sort=<key>
+   --abbrev[=<n>]
+
+ If a placeholder has multiple words, they are separated by dashes:
+   <new-branch-name>
+   --template=<template-directory>
+
+ Possibility of multiple occurrences is indicated by three dots:
+   <file>...
+   (One or more of <file>.)
+
+ Optional parts are enclosed in square brackets:
+   [<file>...]
+   (Zero or more of <file>.)
+
+   --exec-path[=<path>]
+   (Option with an optional argument.  Note that the "=" is inside the
+   brackets.)
+
+   [<patch>...]
+   (Zero or more of <patch>.  Note that the dots are inside, not
+   outside the brackets.)
+
+ Multiple alternatives are indicated with vertical bars:
+   [-q | --quiet]
+   [--utf8 | --no-utf8]
+
+ Use spacing around "|" token(s), but not immediately after opening or
+ before closing a [] or () pair:
+   Do: [-q | --quiet]
+   Don't: [-q|--quiet]
+
+ Don't use spacing around "|" tokens when they're used to separate the
+ alternate arguments of an option:
+    Do: --track[=(direct|inherit)]
+    Don't: --track[=(direct | inherit)]
+
+ Parentheses are used for grouping:
+   [(<rev> | <range>)...]
+   (Any number of either <rev> or <range>.  Parens are needed to make
+   it clear that "..." pertains to both <rev> and <range>.)
+
+   [(-p <parent>)...]
+   (Any number of option -p, each with one <parent> argument.)
+
+   git remote set-head <name> (-a | -d | <branch>)
+   (One and only one of "-a", "-d" or "<branch>" _must_ (no square
+   brackets) be provided.)
+
+ And a somewhat more contrived example:
+   --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+   Here "=" is outside the brackets, because "--diff-filter=" is a
+   valid usage.  "*" has its own pair of brackets, because it can
+   (optionally) be specified only when one or more of the letters is
+   also provided.
+
+  A note on notation:
+   Use 'git' (all lowercase) when talking about commands i.e. something
+   the user would type into a shell and use 'Git' (uppercase first letter)
+   when talking about the version control system and its properties.
+
+ A few commented examples follow to provide reference when writing or
+ modifying paragraphs or option/command explanations that contain options
+ or commands:
+
+ Literal examples (e.g. use of command-line options, command names,
+ branch names, URLs, pathnames (files and directories), configuration and
+ environment variables) must be typeset in monospace (i.e. wrapped with
+ backticks):
+   `--pretty=oneline`
+   `git rev-list`
+   `remote.pushDefault`
+   `http://git.example.com`
+   `.git/config`
+   `GIT_DIR`
+   `HEAD`
+
+ An environment variable must be prefixed with "$" only when referring to its
+ value and not when referring to the variable itself, in this case there is
+ nothing to add except the backticks:
+   `GIT_DIR` is specified
+   `$GIT_DIR/hooks/pre-receive`
+
+ Word phrases enclosed in `backtick characters` are rendered literally
+ and will not be further expanded. The use of `backticks` to achieve the
+ previous rule means that literal examples should not use AsciiDoc
+ escapes.
+   Correct:
+      `--pretty=oneline`
+   Incorrect:
+      `\--pretty=oneline`
+
+ If some place in the documentation needs to typeset a command usage
+ example with inline substitutions, it is fine to use +monospaced and
+ inline substituted text+ instead of `monospaced literal text`, and with
+ the former, the part that should not get substituted must be
+ quoted/escaped.
diff --git a/external/docs/asciidoc/d7fc919fc1b767d7ef6d2ca2c8f2b227c63d6df0 b/external/docs/asciidoc/d7fc919fc1b767d7ef6d2ca2c8f2b227c63d6df0
new file mode 100644
index 0000000000..65af8d82ce
--- /dev/null
+++ b/external/docs/asciidoc/d7fc919fc1b767d7ef6d2ca2c8f2b227c63d6df0
@@ -0,0 +1,758 @@
+Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, a few rough rules are:
+
+ - Most importantly, we never say "It's in POSIX; we'll happily
+   ignore your needs should your system not conform to it."
+   We live in the real world.
+
+ - However, we often say "Let's stay away from that construct,
+   it's not even in POSIX".
+
+ - In spite of the above two rules, we sometimes say "Although
+   this is not in POSIX, it (is so convenient | makes the code
+   much more readable | has other good characteristics) and
+   practically all the platforms we care about support it, so
+   let's use it".
+
+   Again, we live in the real world, and it is sometimes a
+   judgement call, the decision based more on real world
+   constraints people face than what the paper standard says.
+
+ - Fixing style violations while working on a real change as a
+   preparatory clean-up step is good, but otherwise avoid useless code
+   churn for the sake of conforming to the style.
+
+   "Once it _is_ in the tree, it's not really worth the patch noise to
+   go and fix it up."
+   Cf. http://lkml.iu.edu/hypermail/linux/kernel/1001.3/01069.html
+
+ - Log messages to explain your changes are as important as the
+   changes themselves.  Clearly written code and in-code comments
+   explain how the code works and what is assumed from the surrounding
+   context.  The log messages explain what the changes wanted to
+   achieve and why the changes were necessary (more on this in the
+   accompanying SubmittingPatches document).
+
+Make your code readable and sensible, and don't try to be clever.
+
+As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the _local_
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn't match the overall style of existing code).
+
+But if you must have a list of rules, here are some language
+specific ones. Note that Documentation/ToolsForGit.txt document
+has a collection of tips to help you use some external tools
+to conform to these guidelines.
+
+For shell scripts specifically (not exhaustive):
+
+ - We use tabs for indentation.
+
+ - Case arms are indented at the same depth as case and esac lines,
+   like this:
+
+	case "$variable" in
+	pattern1)
+		do this
+		;;
+	pattern2)
+		do that
+		;;
+	esac
+
+ - Redirection operators should be written with space before, but no
+   space after them.  In other words, write 'echo test >"$file"'
+   instead of 'echo test> $file' or 'echo test > $file'.  Note that
+   even though it is not required by POSIX to double-quote the
+   redirection target in a variable (as shown above), our code does so
+   because some versions of bash issue a warning without the quotes.
+
+	(incorrect)
+	cat hello > world < universe
+	echo hello >$world
+
+	(correct)
+	cat hello >world <universe
+	echo hello >"$world"
+
+ - We prefer $( ... ) for command substitution; unlike ``, it
+   properly nests.  It should have been the way Bourne spelled
+   it from day one, but unfortunately isn't.
+
+ - If you want to find out if a command is available on the user's
+   $PATH, you should use 'type <command>', instead of 'which <command>'.
+   The output of 'which' is not machine parsable and its exit code
+   is not reliable across platforms.
+
+ - We use POSIX compliant parameter substitutions and avoid bashisms;
+   namely:
+
+   - We use ${parameter-word} and its [-=?+] siblings, and their
+     colon'ed "unset or null" form.
+
+   - We use ${parameter#word} and its [#%] siblings, and their
+     doubled "longest matching" form.
+
+   - No "Substring Expansion" ${parameter:offset:length}.
+
+   - No shell arrays.
+
+   - No pattern replacement ${parameter/pattern/string}.
+
+ - We use Arithmetic Expansion $(( ... )).
+
+ - We do not use Process Substitution <(list) or >(list).
+
+ - Do not write control structures on a single line with semicolon.
+   "then" should be on the next line for if statements, and "do"
+   should be on the next line for "while" and "for".
+
+	(incorrect)
+	if test -f hello; then
+		do this
+	fi
+
+	(correct)
+	if test -f hello
+	then
+		do this
+	fi
+
+ - If a command sequence joined with && or || or | spans multiple
+   lines, put each command on a separate line and put && and || and |
+   operators at the end of each line, rather than the start. This
+   means you don't need to use \ to join lines, since the above
+   operators imply the sequence isn't finished.
+
+	(incorrect)
+	grep blob verify_pack_result \
+	| awk -f print_1.awk \
+	| sort >actual &&
+	...
+
+	(correct)
+	grep blob verify_pack_result |
+	awk -f print_1.awk |
+	sort >actual &&
+	...
+
+ - We prefer "test" over "[ ... ]".
+
+ - We do not write the noiseword "function" in front of shell
+   functions.
+
+ - We prefer a space between the function name and the parentheses,
+   and no space inside the parentheses. The opening "{" should also
+   be on the same line.
+
+	(incorrect)
+	my_function(){
+		...
+
+	(correct)
+	my_function () {
+		...
+
+ - As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+   [::], [==], or [..]) for portability.
+
+   - We do not use \{m,n\};
+
+   - We do not use ? or + (which are \{0,1\} and \{1,\}
+     respectively in BRE) but that goes without saying as these
+     are ERE elements not BRE (note that \? and \+ are not even part
+     of BRE -- making them accessible from BRE is a GNU extension).
+
+ - Use Git's gettext wrappers in git-sh-i18n to make the user
+   interface translatable. See "Marking strings for translation" in
+   po/README.
+
+ - We do not write our "test" command with "-a" and "-o" and use "&&"
+   or "||" to concatenate multiple "test" commands instead, because
+   the use of "-a/-o" is often error-prone.  E.g.
+
+     test -n "$x" -a "$a" = "$b"
+
+   is buggy and breaks when $x is "=", but
+
+     test -n "$x" && test "$a" = "$b"
+
+   does not have such a problem.
+
+ - Even though "local" is not part of POSIX, we make heavy use of it
+   in our test suite.  We do not use it in scripted Porcelains, and
+   hopefully nobody starts using "local" before they are reimplemented
+   in C ;-)
+
+ - Use octal escape sequences (e.g. "\302\242"), not hexadecimal (e.g.
+   "\xc2\xa2") in printf format strings, since hexadecimal escape
+   sequences are not portable.
+
+
+For C programs:
+
+ - We use tabs to indent, and interpret tabs as taking up to
+   8 spaces.
+
+ - We try to keep to at most 80 characters per line.
+
+ - As a Git developer we assume you have a reasonably modern compiler
+   and we recommend you to enable the DEVELOPER makefile knob to
+   ensure your patch is clear of all compiler warnings we care about,
+   by e.g. "echo DEVELOPER=1 >>config.mak".
+
+ - We try to support a wide range of C compilers to compile Git with,
+   including old ones.  As of Git v2.35.0 Git requires C99 (we check
+   "__STDC_VERSION__"). You should not use features from a newer C
+   standard, even if your compiler groks them.
+
+   New C99 features have been phased in gradually, if something's new
+   in C99 but not used yet don't assume that it's safe to use, some
+   compilers we target have only partial support for it. These are
+   considered safe to use:
+
+   . since around 2007 with 2b6854c863a, we have been using
+     initializer elements which are not computable at load time. E.g.:
+
+	const char *args[] = {"constant", variable, NULL};
+
+   . since early 2012 with e1327023ea, we have been using an enum
+     definition whose last element is followed by a comma.  This, like
+     an array initializer that ends with a trailing comma, can be used
+     to reduce the patch noise when adding a new identifier at the end.
+
+   . since mid 2017 with cbc0f81d, we have been using designated
+     initializers for struct (e.g. "struct t v = { .val = 'a' };").
+
+   . since mid 2017 with 512f41cf, we have been using designated
+     initializers for array (e.g. "int array[10] = { [5] = 2 }").
+
+   . since early 2021 with 765dc168882, we have been using variadic
+     macros, mostly for printf-like trace and debug macros.
+
+   . since late 2021 with 44ba10d6, we have had variables declared in
+     the for loop "for (int i = 0; i < 10; i++)".
+
+   New C99 features that we cannot use yet:
+
+   . %z and %zu as a printf() argument for a size_t (the %z being for
+     the POSIX-specific ssize_t). Instead you should use
+     printf("%"PRIuMAX, (uintmax_t)v).  These days the MSVC version we
+     rely on supports %z, but the C library used by MinGW does not.
+
+   . Shorthand like ".a.b = *c" in struct initializations is known to
+     trip up an older IBM XLC version, use ".a = { .b = *c }" instead.
+     See the 33665d98 (reftable: make assignments portable to AIX xlc
+     v12.01, 2022-03-28).
+
+ - Variables have to be declared at the beginning of the block, before
+   the first statement (i.e. -Wdeclaration-after-statement).
+
+ - NULL pointers shall be written as NULL, not as 0.
+
+ - When declaring pointers, the star sides with the variable
+   name, i.e. "char *string", not "char* string" or
+   "char * string".  This makes it easier to understand code
+   like "char *string, c;".
+
+ - Use whitespace around operators and keywords, but not inside
+   parentheses and not around functions. So:
+
+        while (condition)
+		func(bar + 1);
+
+   and not:
+
+        while( condition )
+		func (bar+1);
+
+ - Do not explicitly compare an integral value with constant 0 or '\0',
+   or a pointer value with constant NULL.  For instance, to validate that
+   counted array <ptr, cnt> is initialized but has no elements, write:
+
+	if (!ptr || cnt)
+		BUG("empty array expected");
+
+   and not:
+
+	if (ptr == NULL || cnt != 0);
+		BUG("empty array expected");
+
+ - We avoid using braces unnecessarily.  I.e.
+
+	if (bla) {
+		x = 1;
+	}
+
+   is frowned upon. But there are a few exceptions:
+
+	- When the statement extends over a few lines (e.g., a while loop
+	  with an embedded conditional, or a comment). E.g.:
+
+		while (foo) {
+			if (x)
+				one();
+			else
+				two();
+		}
+
+		if (foo) {
+			/*
+			 * This one requires some explanation,
+			 * so we're better off with braces to make
+			 * it obvious that the indentation is correct.
+			 */
+			doit();
+		}
+
+	- When there are multiple arms to a conditional and some of them
+	  require braces, enclose even a single line block in braces for
+	  consistency. E.g.:
+
+		if (foo) {
+			doit();
+		} else {
+			one();
+			two();
+			three();
+		}
+
+ - We try to avoid assignments in the condition of an "if" statement.
+
+ - Try to make your code understandable.  You may put comments
+   in, but comments invariably tend to stale out when the code
+   they were describing changes.  Often splitting a function
+   into two makes the intention of the code much clearer.
+
+ - Multi-line comments include their delimiters on separate lines from
+   the text.  E.g.
+
+	/*
+	 * A very long
+	 * multi-line comment.
+	 */
+
+   Note however that a comment that explains a translatable string to
+   translators uses a convention of starting with a magic token
+   "TRANSLATORS: ", e.g.
+
+	/*
+	 * TRANSLATORS: here is a comment that explains the string to
+	 * be translated, that follows immediately after it.
+	 */
+	_("Here is a translatable string explained by the above.");
+
+ - Double negation is often harder to understand than no negation
+   at all.
+
+ - There are two schools of thought when it comes to comparison,
+   especially inside a loop. Some people prefer to have the less stable
+   value on the left hand side and the more stable value on the right hand
+   side, e.g. if you have a loop that counts variable i down to the
+   lower bound,
+
+	while (i > lower_bound) {
+		do something;
+		i--;
+	}
+
+   Other people prefer to have the textual order of values match the
+   actual order of values in their comparison, so that they can
+   mentally draw a number line from left to right and place these
+   values in order, i.e.
+
+	while (lower_bound < i) {
+		do something;
+		i--;
+	}
+
+   Both are valid, and we use both.  However, the more "stable" the
+   stable side becomes, the more we tend to prefer the former
+   (comparison with a constant, "i > 0", is an extreme example).
+   Just do not mix styles in the same part of the code and mimic
+   existing styles in the neighbourhood.
+
+ - There are two schools of thought when it comes to splitting a long
+   logical line into multiple lines.  Some people push the second and
+   subsequent lines far enough to the right with tabs and align them:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+		span_more_than_a_single_line_of ||
+		the_source_text) {
+                ...
+
+   while other people prefer to align the second and the subsequent
+   lines with the column immediately inside the opening parenthesis,
+   with tabs and spaces, following our "tabstop is always a multiple
+   of 8" convention:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of ||
+	    the_source_text) {
+                ...
+
+   Both are valid, and we use both.  Again, just do not mix styles in
+   the same part of the code and mimic existing styles in the
+   neighbourhood.
+
+ - When splitting a long logical line, some people change line before
+   a binary operator, so that the result looks like a parse tree when
+   you turn your head 90-degrees counterclockwise:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to
+	    || span_more_than_a_single_line_of_the_source_text) {
+
+   while other people prefer to leave the operator at the end of the
+   line:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of_the_source_text) {
+
+   Both are valid, but we tend to use the latter more, unless the
+   expression gets fairly complex, in which case the former tends to
+   be easier to read.  Again, just do not mix styles in the same part
+   of the code and mimic existing styles in the neighbourhood.
+
+ - When splitting a long logical line, with everything else being
+   equal, it is preferable to split after the operator at higher
+   level in the parse tree.  That is, this is more preferable:
+
+	if (a_very_long_variable * that_is_used_in +
+	    a_very_long_expression) {
+		...
+
+   than
+
+	if (a_very_long_variable *
+	    that_is_used_in + a_very_long_expression) {
+		...
+
+ - Some clever tricks, like using the !! operator with arithmetic
+   constructs, can be extremely confusing to others.  Avoid them,
+   unless there is a compelling reason to use them.
+
+ - Use the API.  No, really.  We have a strbuf (variable length
+   string), several arrays with the ALLOC_GROW() macro, a
+   string_list for sorted string lists, a hash map (mapping struct
+   objects) named "struct decorate", amongst other things.
+
+ - When you come up with an API, document its functions and structures
+   in the header file that exposes the API to its callers. Use what is
+   in "strbuf.h" as a model for the appropriate tone and level of
+   detail.
+
+ - The first #include in C files, except in platform specific compat/
+   implementations and sha1dc/, must be either "git-compat-util.h" or
+   one of the approved headers that includes it first for you.  (The
+   approved headers currently include "builtin.h",
+   "t/helper/test-tool.h", "xdiff/xinclude.h", or
+   "reftable/system.h").  You do not have to include more than one of
+   these.
+
+ - A C file must directly include the header files that declare the
+   functions and the types it uses, except for the functions and types
+   that are made available to it by including one of the header files
+   it must include by the previous rule.
+
+ - If you are planning a new command, consider writing it in shell
+   or perl first, so that changes in semantics can be easily
+   changed and discussed.  Many Git commands started out like
+   that, and a few are still scripts.
+
+ - Avoid introducing a new dependency into Git. This means you
+   usually should stay away from scripting languages not already
+   used in the Git core command set (unless your command is clearly
+   separate from it, such as an importer to convert random-scm-X
+   repositories to Git).
+
+ - When we pass <string, length> pair to functions, we should try to
+   pass them in that order.
+
+ - Use Git's gettext wrappers to make the user interface
+   translatable. See "Marking strings for translation" in po/README.
+
+ - Variables and functions local to a given source file should be marked
+   with "static". Variables that are visible to other source files
+   must be declared with "extern" in header files. However, function
+   declarations should not use "extern", as that is already the default.
+
+ - You can launch gdb around your program using the shorthand GIT_DEBUGGER.
+   Run `GIT_DEBUGGER=1 ./bin-wrappers/git foo` to simply use gdb as is, or
+   run `GIT_DEBUGGER="<debugger> <debugger-args>" ./bin-wrappers/git foo` to
+   use your own debugger and arguments. Example: `GIT_DEBUGGER="ddd --gdb"
+   ./bin-wrappers/git log` (See `wrap-for-bin.sh`.)
+
+For Perl programs:
+
+ - Most of the C guidelines above apply.
+
+ - We try to support Perl 5.8 and later ("use Perl 5.008").
+
+ - use strict and use warnings are strongly preferred.
+
+ - Don't overuse statement modifiers unless using them makes the
+   result easier to follow.
+
+	... do something ...
+	do_this() unless (condition);
+        ... do something else ...
+
+   is more readable than:
+
+	... do something ...
+	unless (condition) {
+		do_this();
+	}
+        ... do something else ...
+
+   *only* when the condition is so rare that do_this() will be almost
+   always called.
+
+ - We try to avoid assignments inside "if ()" conditions.
+
+ - Learn and use Git.pm if you need that functionality.
+
+For Python scripts:
+
+ - We follow PEP-8 (http://www.python.org/dev/peps/pep-0008/).
+
+ - As a minimum, we aim to be compatible with Python 2.7.
+
+ - Where required libraries do not restrict us to Python 2, we try to
+   also be compatible with Python 3.1 and later.
+
+
+Program Output
+
+ We make a distinction between a Git command's primary output and
+ output which is merely chatty feedback (for instance, status
+ messages, running transcript, or progress display), as well as error
+ messages. Roughly speaking, a Git command's primary output is that
+ which one might want to capture to a file or send down a pipe; its
+ chatty output should not interfere with these use-cases.
+
+ As such, primary output should be sent to the standard output stream
+ (stdout), and chatty output should be sent to the standard error
+ stream (stderr). Examples of commands which produce primary output
+ include `git log`, `git show`, and `git branch --list` which generate
+ output on the stdout stream.
+
+ Not all Git commands have primary output; this is often true of
+ commands whose main function is to perform an action. Some action
+ commands are silent, whereas others are chatty. An example of a
+ chatty action commands is `git clone` with its "Cloning into
+ '<path>'..." and "Checking connectivity..." status messages which it
+ sends to the stderr stream.
+
+ Error messages from Git commands should always be sent to the stderr
+ stream.
+
+
+Error Messages
+
+ - Do not end error messages with a full stop.
+
+ - Do not capitalize the first word, only because it is the first word
+   in the message ("unable to open %s", not "Unable to open %s").  But
+   "SHA-3 not supported" is fine, because the reason the first word is
+   capitalized is not because it is at the beginning of the sentence,
+   but because the word would be spelled in capital letters even when
+   it appeared in the middle of the sentence.
+
+ - Say what the error is first ("cannot open %s", not "%s: cannot open")
+
+
+Externally Visible Names
+
+ - For configuration variable names, follow the existing convention:
+
+   . The section name indicates the affected subsystem.
+
+   . The subsection name, if any, indicates which of an unbounded set
+     of things to set the value for.
+
+   . The variable name describes the effect of tweaking this knob.
+
+   The section and variable names that consist of multiple words are
+   formed by concatenating the words without punctuations (e.g. `-`),
+   and are broken using bumpyCaps in documentation as a hint to the
+   reader.
+
+   When choosing the variable namespace, do not use variable name for
+   specifying possibly unbounded set of things, most notably anything
+   an end user can freely come up with (e.g. branch names).  Instead,
+   use subsection names or variable values, like the existing variable
+   branch.<name>.description does.
+
+
+Writing Documentation:
+
+ Most (if not all) of the documentation pages are written in the
+ AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+ processed into HTML and manpages (e.g. git.html and git.1 in the
+ same directory).
+
+ The documentation liberally mixes US and UK English (en_US/UK)
+ norms for spelling and grammar, which is somewhat unfortunate.
+ In an ideal world, it would have been better if it consistently
+ used only one and not the other, and we would have picked en_US
+ (if you wish to correct the English of some of the existing
+ documentation, please see the documentation-related advice in the
+ Documentation/SubmittingPatches file).
+
+ In order to ensure the documentation is inclusive, avoid assuming
+ that an unspecified example person is male or female, and think
+ twice before using "he", "him", "she", or "her".  Here are some
+ tips to avoid use of gendered pronouns:
+
+  - Prefer succinctness and matter-of-factly describing functionality
+    in the abstract.  E.g.
+
+     --short:: Emit output in the short-format.
+
+    and avoid something like these overly verbose alternatives:
+
+     --short:: Use this to emit output in the short-format.
+     --short:: You can use this to get output in the short-format.
+     --short:: A user who prefers shorter output could....
+     --short:: Should a person and/or program want shorter output, he
+               she/they/it can...
+
+    This practice often eliminates the need to involve human actors in
+    your description, but it is a good practice regardless of the
+    avoidance of gendered pronouns.
+
+  - When it becomes awkward to stick to this style, prefer "you" when
+    addressing the hypothetical user, and possibly "we" when
+    discussing how the program might react to the user.  E.g.
+
+      You can use this option instead of --xyz, but we might remove
+      support for it in future versions.
+
+    while keeping in mind that you can probably be less verbose, e.g.
+
+      Use this instead of --xyz. This option might be removed in future
+      versions.
+
+  - If you still need to refer to an example person that is
+    third-person singular, you may resort to "singular they" to avoid
+    "he/she/him/her", e.g.
+
+      A contributor asks their upstream to pull from them.
+
+    Note that this sounds ungrammatical and unnatural to those who
+    learned that "they" is only used for third-person plural, e.g.
+    those who learn English as a second language in some parts of the
+    world.
+
+ Every user-visible change should be reflected in the documentation.
+ The same general rule as for code applies -- imitate the existing
+ conventions.
+
+ A few commented examples follow to provide reference when writing or
+ modifying command usage strings and synopsis sections in the manual
+ pages:
+
+ Placeholders are spelled in lowercase and enclosed in angle brackets:
+   <file>
+   --sort=<key>
+   --abbrev[=<n>]
+
+ If a placeholder has multiple words, they are separated by dashes:
+   <new-branch-name>
+   --template=<template-directory>
+
+ Possibility of multiple occurrences is indicated by three dots:
+   <file>...
+   (One or more of <file>.)
+
+ Optional parts are enclosed in square brackets:
+   [<file>...]
+   (Zero or more of <file>.)
+
+   --exec-path[=<path>]
+   (Option with an optional argument.  Note that the "=" is inside the
+   brackets.)
+
+   [<patch>...]
+   (Zero or more of <patch>.  Note that the dots are inside, not
+   outside the brackets.)
+
+ Multiple alternatives are indicated with vertical bars:
+   [-q | --quiet]
+   [--utf8 | --no-utf8]
+
+ Use spacing around "|" token(s), but not immediately after opening or
+ before closing a [] or () pair:
+   Do: [-q | --quiet]
+   Don't: [-q|--quiet]
+
+ Don't use spacing around "|" tokens when they're used to separate the
+ alternate arguments of an option:
+    Do: --track[=(direct|inherit)]
+    Don't: --track[=(direct | inherit)]
+
+ Parentheses are used for grouping:
+   [(<rev> | <range>)...]
+   (Any number of either <rev> or <range>.  Parens are needed to make
+   it clear that "..." pertains to both <rev> and <range>.)
+
+   [(-p <parent>)...]
+   (Any number of option -p, each with one <parent> argument.)
+
+   git remote set-head <name> (-a | -d | <branch>)
+   (One and only one of "-a", "-d" or "<branch>" _must_ (no square
+   brackets) be provided.)
+
+ And a somewhat more contrived example:
+   --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+   Here "=" is outside the brackets, because "--diff-filter=" is a
+   valid usage.  "*" has its own pair of brackets, because it can
+   (optionally) be specified only when one or more of the letters is
+   also provided.
+
+  A note on notation:
+   Use 'git' (all lowercase) when talking about commands i.e. something
+   the user would type into a shell and use 'Git' (uppercase first letter)
+   when talking about the version control system and its properties.
+
+ A few commented examples follow to provide reference when writing or
+ modifying paragraphs or option/command explanations that contain options
+ or commands:
+
+ Literal examples (e.g. use of command-line options, command names,
+ branch names, URLs, pathnames (files and directories), configuration and
+ environment variables) must be typeset in monospace (i.e. wrapped with
+ backticks):
+   `--pretty=oneline`
+   `git rev-list`
+   `remote.pushDefault`
+   `http://git.example.com`
+   `.git/config`
+   `GIT_DIR`
+   `HEAD`
+
+ An environment variable must be prefixed with "$" only when referring to its
+ value and not when referring to the variable itself, in this case there is
+ nothing to add except the backticks:
+   `GIT_DIR` is specified
+   `$GIT_DIR/hooks/pre-receive`
+
+ Word phrases enclosed in `backtick characters` are rendered literally
+ and will not be further expanded. The use of `backticks` to achieve the
+ previous rule means that literal examples should not use AsciiDoc
+ escapes.
+   Correct:
+      `--pretty=oneline`
+   Incorrect:
+      `\--pretty=oneline`
+
+ If some place in the documentation needs to typeset a command usage
+ example with inline substitutions, it is fine to use +monospaced and
+ inline substituted text+ instead of `monospaced literal text`, and with
+ the former, the part that should not get substituted must be
+ quoted/escaped.
diff --git a/external/docs/asciidoc/dcf07e945fc4ac4874475bace3a886d8ddc2064b b/external/docs/asciidoc/dcf07e945fc4ac4874475bace3a886d8ddc2064b
new file mode 100644
index 0000000000..1d95a142b2
--- /dev/null
+++ b/external/docs/asciidoc/dcf07e945fc4ac4874475bace3a886d8ddc2064b
@@ -0,0 +1,742 @@
+Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, a few rough rules are:
+
+ - Most importantly, we never say "It's in POSIX; we'll happily
+   ignore your needs should your system not conform to it."
+   We live in the real world.
+
+ - However, we often say "Let's stay away from that construct,
+   it's not even in POSIX".
+
+ - In spite of the above two rules, we sometimes say "Although
+   this is not in POSIX, it (is so convenient | makes the code
+   much more readable | has other good characteristics) and
+   practically all the platforms we care about support it, so
+   let's use it".
+
+   Again, we live in the real world, and it is sometimes a
+   judgement call, the decision based more on real world
+   constraints people face than what the paper standard says.
+
+ - Fixing style violations while working on a real change as a
+   preparatory clean-up step is good, but otherwise avoid useless code
+   churn for the sake of conforming to the style.
+
+   "Once it _is_ in the tree, it's not really worth the patch noise to
+   go and fix it up."
+   Cf. http://lkml.iu.edu/hypermail/linux/kernel/1001.3/01069.html
+
+ - Log messages to explain your changes are as important as the
+   changes themselves.  Clearly written code and in-code comments
+   explain how the code works and what is assumed from the surrounding
+   context.  The log messages explain what the changes wanted to
+   achieve and why the changes were necessary (more on this in the
+   accompanying SubmittingPatches document).
+
+Make your code readable and sensible, and don't try to be clever.
+
+As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the _local_
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn't match the overall style of existing code).
+
+But if you must have a list of rules, here are some language
+specific ones. Note that Documentation/ToolsForGit.txt document
+has a collection of tips to help you use some external tools
+to conform to these guidelines.
+
+For shell scripts specifically (not exhaustive):
+
+ - We use tabs for indentation.
+
+ - Case arms are indented at the same depth as case and esac lines,
+   like this:
+
+	case "$variable" in
+	pattern1)
+		do this
+		;;
+	pattern2)
+		do that
+		;;
+	esac
+
+ - Redirection operators should be written with space before, but no
+   space after them.  In other words, write 'echo test >"$file"'
+   instead of 'echo test> $file' or 'echo test > $file'.  Note that
+   even though it is not required by POSIX to double-quote the
+   redirection target in a variable (as shown above), our code does so
+   because some versions of bash issue a warning without the quotes.
+
+	(incorrect)
+	cat hello > world < universe
+	echo hello >$world
+
+	(correct)
+	cat hello >world <universe
+	echo hello >"$world"
+
+ - We prefer $( ... ) for command substitution; unlike ``, it
+   properly nests.  It should have been the way Bourne spelled
+   it from day one, but unfortunately isn't.
+
+ - If you want to find out if a command is available on the user's
+   $PATH, you should use 'type <command>', instead of 'which <command>'.
+   The output of 'which' is not machine parsable and its exit code
+   is not reliable across platforms.
+
+ - We use POSIX compliant parameter substitutions and avoid bashisms;
+   namely:
+
+   - We use ${parameter-word} and its [-=?+] siblings, and their
+     colon'ed "unset or null" form.
+
+   - We use ${parameter#word} and its [#%] siblings, and their
+     doubled "longest matching" form.
+
+   - No "Substring Expansion" ${parameter:offset:length}.
+
+   - No shell arrays.
+
+   - No pattern replacement ${parameter/pattern/string}.
+
+ - We use Arithmetic Expansion $(( ... )).
+
+ - We do not use Process Substitution <(list) or >(list).
+
+ - Do not write control structures on a single line with semicolon.
+   "then" should be on the next line for if statements, and "do"
+   should be on the next line for "while" and "for".
+
+	(incorrect)
+	if test -f hello; then
+		do this
+	fi
+
+	(correct)
+	if test -f hello
+	then
+		do this
+	fi
+
+ - If a command sequence joined with && or || or | spans multiple
+   lines, put each command on a separate line and put && and || and |
+   operators at the end of each line, rather than the start. This
+   means you don't need to use \ to join lines, since the above
+   operators imply the sequence isn't finished.
+
+	(incorrect)
+	grep blob verify_pack_result \
+	| awk -f print_1.awk \
+	| sort >actual &&
+	...
+
+	(correct)
+	grep blob verify_pack_result |
+	awk -f print_1.awk |
+	sort >actual &&
+	...
+
+ - We prefer "test" over "[ ... ]".
+
+ - We do not write the noiseword "function" in front of shell
+   functions.
+
+ - We prefer a space between the function name and the parentheses,
+   and no space inside the parentheses. The opening "{" should also
+   be on the same line.
+
+	(incorrect)
+	my_function(){
+		...
+
+	(correct)
+	my_function () {
+		...
+
+ - As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+   [::], [==], or [..]) for portability.
+
+   - We do not use \{m,n\};
+
+   - We do not use -E;
+
+   - We do not use ? or + (which are \{0,1\} and \{1,\}
+     respectively in BRE) but that goes without saying as these
+     are ERE elements not BRE (note that \? and \+ are not even part
+     of BRE -- making them accessible from BRE is a GNU extension).
+
+ - Use Git's gettext wrappers in git-sh-i18n to make the user
+   interface translatable. See "Marking strings for translation" in
+   po/README.
+
+ - We do not write our "test" command with "-a" and "-o" and use "&&"
+   or "||" to concatenate multiple "test" commands instead, because
+   the use of "-a/-o" is often error-prone.  E.g.
+
+     test -n "$x" -a "$a" = "$b"
+
+   is buggy and breaks when $x is "=", but
+
+     test -n "$x" && test "$a" = "$b"
+
+   does not have such a problem.
+
+ - Even though "local" is not part of POSIX, we make heavy use of it
+   in our test suite.  We do not use it in scripted Porcelains, and
+   hopefully nobody starts using "local" before they are reimplemented
+   in C ;-)
+
+
+For C programs:
+
+ - We use tabs to indent, and interpret tabs as taking up to
+   8 spaces.
+
+ - We try to keep to at most 80 characters per line.
+
+ - As a Git developer we assume you have a reasonably modern compiler
+   and we recommend you to enable the DEVELOPER makefile knob to
+   ensure your patch is clear of all compiler warnings we care about,
+   by e.g. "echo DEVELOPER=1 >>config.mak".
+
+ - We try to support a wide range of C compilers to compile Git with,
+   including old ones.  As of Git v2.35.0 Git requires C99 (we check
+   "__STDC_VERSION__"). You should not use features from a newer C
+   standard, even if your compiler groks them.
+
+   New C99 features have been phased in gradually, if something's new
+   in C99 but not used yet don't assume that it's safe to use, some
+   compilers we target have only partial support for it. These are
+   considered safe to use:
+
+   . since around 2007 with 2b6854c863a, we have been using
+     initializer elements which are not computable at load time. E.g.:
+
+	const char *args[] = {"constant", variable, NULL};
+
+   . since early 2012 with e1327023ea, we have been using an enum
+     definition whose last element is followed by a comma.  This, like
+     an array initializer that ends with a trailing comma, can be used
+     to reduce the patch noise when adding a new identifier at the end.
+
+   . since mid 2017 with cbc0f81d, we have been using designated
+     initializers for struct (e.g. "struct t v = { .val = 'a' };").
+
+   . since mid 2017 with 512f41cf, we have been using designated
+     initializers for array (e.g. "int array[10] = { [5] = 2 }").
+
+   . since early 2021 with 765dc168882, we have been using variadic
+     macros, mostly for printf-like trace and debug macros.
+
+   . since late 2021 with 44ba10d6, we have had variables declared in
+     the for loop "for (int i = 0; i < 10; i++)".
+
+   New C99 features that we cannot use yet:
+
+   . %z and %zu as a printf() argument for a size_t (the %z being for
+     the POSIX-specific ssize_t). Instead you should use
+     printf("%"PRIuMAX, (uintmax_t)v).  These days the MSVC version we
+     rely on supports %z, but the C library used by MinGW does not.
+
+   . Shorthand like ".a.b = *c" in struct initializations is known to
+     trip up an older IBM XLC version, use ".a = { .b = *c }" instead.
+     See the 33665d98 (reftable: make assignments portable to AIX xlc
+     v12.01, 2022-03-28).
+
+ - Variables have to be declared at the beginning of the block, before
+   the first statement (i.e. -Wdeclaration-after-statement).
+
+ - NULL pointers shall be written as NULL, not as 0.
+
+ - When declaring pointers, the star sides with the variable
+   name, i.e. "char *string", not "char* string" or
+   "char * string".  This makes it easier to understand code
+   like "char *string, c;".
+
+ - Use whitespace around operators and keywords, but not inside
+   parentheses and not around functions. So:
+
+        while (condition)
+		func(bar + 1);
+
+   and not:
+
+        while( condition )
+		func (bar+1);
+
+ - Do not explicitly compare an integral value with constant 0 or '\0',
+   or a pointer value with constant NULL.  For instance, to validate that
+   counted array <ptr, cnt> is initialized but has no elements, write:
+
+	if (!ptr || cnt)
+		BUG("empty array expected");
+
+   and not:
+
+	if (ptr == NULL || cnt != 0);
+		BUG("empty array expected");
+
+ - We avoid using braces unnecessarily.  I.e.
+
+	if (bla) {
+		x = 1;
+	}
+
+   is frowned upon. But there are a few exceptions:
+
+	- When the statement extends over a few lines (e.g., a while loop
+	  with an embedded conditional, or a comment). E.g.:
+
+		while (foo) {
+			if (x)
+				one();
+			else
+				two();
+		}
+
+		if (foo) {
+			/*
+			 * This one requires some explanation,
+			 * so we're better off with braces to make
+			 * it obvious that the indentation is correct.
+			 */
+			doit();
+		}
+
+	- When there are multiple arms to a conditional and some of them
+	  require braces, enclose even a single line block in braces for
+	  consistency. E.g.:
+
+		if (foo) {
+			doit();
+		} else {
+			one();
+			two();
+			three();
+		}
+
+ - We try to avoid assignments in the condition of an "if" statement.
+
+ - Try to make your code understandable.  You may put comments
+   in, but comments invariably tend to stale out when the code
+   they were describing changes.  Often splitting a function
+   into two makes the intention of the code much clearer.
+
+ - Multi-line comments include their delimiters on separate lines from
+   the text.  E.g.
+
+	/*
+	 * A very long
+	 * multi-line comment.
+	 */
+
+   Note however that a comment that explains a translatable string to
+   translators uses a convention of starting with a magic token
+   "TRANSLATORS: ", e.g.
+
+	/*
+	 * TRANSLATORS: here is a comment that explains the string to
+	 * be translated, that follows immediately after it.
+	 */
+	_("Here is a translatable string explained by the above.");
+
+ - Double negation is often harder to understand than no negation
+   at all.
+
+ - There are two schools of thought when it comes to comparison,
+   especially inside a loop. Some people prefer to have the less stable
+   value on the left hand side and the more stable value on the right hand
+   side, e.g. if you have a loop that counts variable i down to the
+   lower bound,
+
+	while (i > lower_bound) {
+		do something;
+		i--;
+	}
+
+   Other people prefer to have the textual order of values match the
+   actual order of values in their comparison, so that they can
+   mentally draw a number line from left to right and place these
+   values in order, i.e.
+
+	while (lower_bound < i) {
+		do something;
+		i--;
+	}
+
+   Both are valid, and we use both.  However, the more "stable" the
+   stable side becomes, the more we tend to prefer the former
+   (comparison with a constant, "i > 0", is an extreme example).
+   Just do not mix styles in the same part of the code and mimic
+   existing styles in the neighbourhood.
+
+ - There are two schools of thought when it comes to splitting a long
+   logical line into multiple lines.  Some people push the second and
+   subsequent lines far enough to the right with tabs and align them:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+		span_more_than_a_single_line_of ||
+		the_source_text) {
+                ...
+
+   while other people prefer to align the second and the subsequent
+   lines with the column immediately inside the opening parenthesis,
+   with tabs and spaces, following our "tabstop is always a multiple
+   of 8" convention:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of ||
+	    the_source_text) {
+                ...
+
+   Both are valid, and we use both.  Again, just do not mix styles in
+   the same part of the code and mimic existing styles in the
+   neighbourhood.
+
+ - When splitting a long logical line, some people change line before
+   a binary operator, so that the result looks like a parse tree when
+   you turn your head 90-degrees counterclockwise:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to
+	    || span_more_than_a_single_line_of_the_source_text) {
+
+   while other people prefer to leave the operator at the end of the
+   line:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of_the_source_text) {
+
+   Both are valid, but we tend to use the latter more, unless the
+   expression gets fairly complex, in which case the former tends to
+   be easier to read.  Again, just do not mix styles in the same part
+   of the code and mimic existing styles in the neighbourhood.
+
+ - When splitting a long logical line, with everything else being
+   equal, it is preferable to split after the operator at higher
+   level in the parse tree.  That is, this is more preferable:
+
+	if (a_very_long_variable * that_is_used_in +
+	    a_very_long_expression) {
+		...
+
+   than
+
+	if (a_very_long_variable *
+	    that_is_used_in + a_very_long_expression) {
+		...
+
+ - Some clever tricks, like using the !! operator with arithmetic
+   constructs, can be extremely confusing to others.  Avoid them,
+   unless there is a compelling reason to use them.
+
+ - Use the API.  No, really.  We have a strbuf (variable length
+   string), several arrays with the ALLOC_GROW() macro, a
+   string_list for sorted string lists, a hash map (mapping struct
+   objects) named "struct decorate", amongst other things.
+
+ - When you come up with an API, document its functions and structures
+   in the header file that exposes the API to its callers. Use what is
+   in "strbuf.h" as a model for the appropriate tone and level of
+   detail.
+
+ - The first #include in C files, except in platform specific compat/
+   implementations, must be either "git-compat-util.h", "cache.h" or
+   "builtin.h".  You do not have to include more than one of these.
+
+ - A C file must directly include the header files that declare the
+   functions and the types it uses, except for the functions and types
+   that are made available to it by including one of the header files
+   it must include by the previous rule.
+
+ - If you are planning a new command, consider writing it in shell
+   or perl first, so that changes in semantics can be easily
+   changed and discussed.  Many Git commands started out like
+   that, and a few are still scripts.
+
+ - Avoid introducing a new dependency into Git. This means you
+   usually should stay away from scripting languages not already
+   used in the Git core command set (unless your command is clearly
+   separate from it, such as an importer to convert random-scm-X
+   repositories to Git).
+
+ - When we pass <string, length> pair to functions, we should try to
+   pass them in that order.
+
+ - Use Git's gettext wrappers to make the user interface
+   translatable. See "Marking strings for translation" in po/README.
+
+ - Variables and functions local to a given source file should be marked
+   with "static". Variables that are visible to other source files
+   must be declared with "extern" in header files. However, function
+   declarations should not use "extern", as that is already the default.
+
+ - You can launch gdb around your program using the shorthand GIT_DEBUGGER.
+   Run `GIT_DEBUGGER=1 ./bin-wrappers/git foo` to simply use gdb as is, or
+   run `GIT_DEBUGGER="<debugger> <debugger-args>" ./bin-wrappers/git foo` to
+   use your own debugger and arguments. Example: `GIT_DEBUGGER="ddd --gdb"
+   ./bin-wrappers/git log` (See `wrap-for-bin.sh`.)
+
+For Perl programs:
+
+ - Most of the C guidelines above apply.
+
+ - We try to support Perl 5.8 and later ("use Perl 5.008").
+
+ - use strict and use warnings are strongly preferred.
+
+ - Don't overuse statement modifiers unless using them makes the
+   result easier to follow.
+
+	... do something ...
+	do_this() unless (condition);
+        ... do something else ...
+
+   is more readable than:
+
+	... do something ...
+	unless (condition) {
+		do_this();
+	}
+        ... do something else ...
+
+   *only* when the condition is so rare that do_this() will be almost
+   always called.
+
+ - We try to avoid assignments inside "if ()" conditions.
+
+ - Learn and use Git.pm if you need that functionality.
+
+For Python scripts:
+
+ - We follow PEP-8 (http://www.python.org/dev/peps/pep-0008/).
+
+ - As a minimum, we aim to be compatible with Python 2.7.
+
+ - Where required libraries do not restrict us to Python 2, we try to
+   also be compatible with Python 3.1 and later.
+
+
+Program Output
+
+ We make a distinction between a Git command's primary output and
+ output which is merely chatty feedback (for instance, status
+ messages, running transcript, or progress display), as well as error
+ messages. Roughly speaking, a Git command's primary output is that
+ which one might want to capture to a file or send down a pipe; its
+ chatty output should not interfere with these use-cases.
+
+ As such, primary output should be sent to the standard output stream
+ (stdout), and chatty output should be sent to the standard error
+ stream (stderr). Examples of commands which produce primary output
+ include `git log`, `git show`, and `git branch --list` which generate
+ output on the stdout stream.
+
+ Not all Git commands have primary output; this is often true of
+ commands whose main function is to perform an action. Some action
+ commands are silent, whereas others are chatty. An example of a
+ chatty action commands is `git clone` with its "Cloning into
+ '<path>'..." and "Checking connectivity..." status messages which it
+ sends to the stderr stream.
+
+ Error messages from Git commands should always be sent to the stderr
+ stream.
+
+
+Error Messages
+
+ - Do not end error messages with a full stop.
+
+ - Do not capitalize the first word, only because it is the first word
+   in the message ("unable to open %s", not "Unable to open %s").  But
+   "SHA-3 not supported" is fine, because the reason the first word is
+   capitalized is not because it is at the beginning of the sentence,
+   but because the word would be spelled in capital letters even when
+   it appeared in the middle of the sentence.
+
+ - Say what the error is first ("cannot open %s", not "%s: cannot open")
+
+
+Externally Visible Names
+
+ - For configuration variable names, follow the existing convention:
+
+   . The section name indicates the affected subsystem.
+
+   . The subsection name, if any, indicates which of an unbounded set
+     of things to set the value for.
+
+   . The variable name describes the effect of tweaking this knob.
+
+   The section and variable names that consist of multiple words are
+   formed by concatenating the words without punctuations (e.g. `-`),
+   and are broken using bumpyCaps in documentation as a hint to the
+   reader.
+
+   When choosing the variable namespace, do not use variable name for
+   specifying possibly unbounded set of things, most notably anything
+   an end user can freely come up with (e.g. branch names).  Instead,
+   use subsection names or variable values, like the existing variable
+   branch.<name>.description does.
+
+
+Writing Documentation:
+
+ Most (if not all) of the documentation pages are written in the
+ AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+ processed into HTML and manpages (e.g. git.html and git.1 in the
+ same directory).
+
+ The documentation liberally mixes US and UK English (en_US/UK)
+ norms for spelling and grammar, which is somewhat unfortunate.
+ In an ideal world, it would have been better if it consistently
+ used only one and not the other, and we would have picked en_US
+ (if you wish to correct the English of some of the existing
+ documentation, please see the documentation-related advice in the
+ Documentation/SubmittingPatches file).
+
+ In order to ensure the documentation is inclusive, avoid assuming
+ that an unspecified example person is male or female, and think
+ twice before using "he", "him", "she", or "her".  Here are some
+ tips to avoid use of gendered pronouns:
+
+  - Prefer succinctness and matter-of-factly describing functionality
+    in the abstract.  E.g.
+
+     --short:: Emit output in the short-format.
+
+    and avoid something like these overly verbose alternatives:
+
+     --short:: Use this to emit output in the short-format.
+     --short:: You can use this to get output in the short-format.
+     --short:: A user who prefers shorter output could....
+     --short:: Should a person and/or program want shorter output, he
+               she/they/it can...
+
+    This practice often eliminates the need to involve human actors in
+    your description, but it is a good practice regardless of the
+    avoidance of gendered pronouns.
+
+  - When it becomes awkward to stick to this style, prefer "you" when
+    addressing the hypothetical user, and possibly "we" when
+    discussing how the program might react to the user.  E.g.
+
+      You can use this option instead of --xyz, but we might remove
+      support for it in future versions.
+
+    while keeping in mind that you can probably be less verbose, e.g.
+
+      Use this instead of --xyz. This option might be removed in future
+      versions.
+
+  - If you still need to refer to an example person that is
+    third-person singular, you may resort to "singular they" to avoid
+    "he/she/him/her", e.g.
+
+      A contributor asks their upstream to pull from them.
+
+    Note that this sounds ungrammatical and unnatural to those who
+    learned that "they" is only used for third-person plural, e.g.
+    those who learn English as a second language in some parts of the
+    world.
+
+ Every user-visible change should be reflected in the documentation.
+ The same general rule as for code applies -- imitate the existing
+ conventions.
+
+ A few commented examples follow to provide reference when writing or
+ modifying command usage strings and synopsis sections in the manual
+ pages:
+
+ Placeholders are spelled in lowercase and enclosed in angle brackets:
+   <file>
+   --sort=<key>
+   --abbrev[=<n>]
+
+ If a placeholder has multiple words, they are separated by dashes:
+   <new-branch-name>
+   --template=<template-directory>
+
+ Possibility of multiple occurrences is indicated by three dots:
+   <file>...
+   (One or more of <file>.)
+
+ Optional parts are enclosed in square brackets:
+   [<extra>]
+   (Zero or one <extra>.)
+
+   --exec-path[=<path>]
+   (Option with an optional argument.  Note that the "=" is inside the
+   brackets.)
+
+   [<patch>...]
+   (Zero or more of <patch>.  Note that the dots are inside, not
+   outside the brackets.)
+
+ Multiple alternatives are indicated with vertical bars:
+   [-q | --quiet]
+   [--utf8 | --no-utf8]
+
+ Parentheses are used for grouping:
+   [(<rev> | <range>)...]
+   (Any number of either <rev> or <range>.  Parens are needed to make
+   it clear that "..." pertains to both <rev> and <range>.)
+
+   [(-p <parent>)...]
+   (Any number of option -p, each with one <parent> argument.)
+
+   git remote set-head <name> (-a | -d | <branch>)
+   (One and only one of "-a", "-d" or "<branch>" _must_ (no square
+   brackets) be provided.)
+
+ And a somewhat more contrived example:
+   --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+   Here "=" is outside the brackets, because "--diff-filter=" is a
+   valid usage.  "*" has its own pair of brackets, because it can
+   (optionally) be specified only when one or more of the letters is
+   also provided.
+
+  A note on notation:
+   Use 'git' (all lowercase) when talking about commands i.e. something
+   the user would type into a shell and use 'Git' (uppercase first letter)
+   when talking about the version control system and its properties.
+
+ A few commented examples follow to provide reference when writing or
+ modifying paragraphs or option/command explanations that contain options
+ or commands:
+
+ Literal examples (e.g. use of command-line options, command names,
+ branch names, URLs, pathnames (files and directories), configuration and
+ environment variables) must be typeset in monospace (i.e. wrapped with
+ backticks):
+   `--pretty=oneline`
+   `git rev-list`
+   `remote.pushDefault`
+   `http://git.example.com`
+   `.git/config`
+   `GIT_DIR`
+   `HEAD`
+
+ An environment variable must be prefixed with "$" only when referring to its
+ value and not when referring to the variable itself, in this case there is
+ nothing to add except the backticks:
+   `GIT_DIR` is specified
+   `$GIT_DIR/hooks/pre-receive`
+
+ Word phrases enclosed in `backtick characters` are rendered literally
+ and will not be further expanded. The use of `backticks` to achieve the
+ previous rule means that literal examples should not use AsciiDoc
+ escapes.
+   Correct:
+      `--pretty=oneline`
+   Incorrect:
+      `\--pretty=oneline`
+
+ If some place in the documentation needs to typeset a command usage
+ example with inline substitutions, it is fine to use +monospaced and
+ inline substituted text+ instead of `monospaced literal text`, and with
+ the former, the part that should not get substituted must be
+ quoted/escaped.
diff --git a/external/docs/asciidoc/ed8d63cdf8567e70f4d62c88daca3133a9142b79 b/external/docs/asciidoc/ed8d63cdf8567e70f4d62c88daca3133a9142b79
new file mode 100644
index 0000000000..27acff86db
--- /dev/null
+++ b/external/docs/asciidoc/ed8d63cdf8567e70f4d62c88daca3133a9142b79
@@ -0,0 +1,174 @@
+= Upcoming breaking changes
+
+The Git project aims to ensure backwards compatibility to the best extent
+possible. Minor releases will not break backwards compatibility unless there is
+a very strong reason to do so, like for example a security vulnerability.
+
+Regardless of that, due to the age of the Git project, it is only natural to
+accumulate a backlog of backwards-incompatible changes that will eventually be
+required to keep the project aligned with a changing world. These changes fall
+into several categories:
+
+* Changes to long established defaults.
+* Concepts that have been replaced with a superior design.
+* Concepts, commands, configuration or options that have been lacking in major
+  ways and that cannot be fixed and which will thus be removed without any
+  replacement.
+
+Explicitly not included in this list are fixes to minor bugs that may cause a
+change in user-visible behavior.
+
+The Git project irregularly releases breaking versions that deliberately break
+backwards compatibility with older versions. This is done to ensure that Git
+remains relevant, safe and maintainable going forward. The release cadence of
+breaking versions is typically measured in multiple years. We had the following
+major breaking releases in the past:
+
+* Git 1.6.0, released in August 2008.
+* Git 2.0, released in May 2014.
+
+We use <major>.<minor> release numbers these days, starting from Git 2.0. For
+future releases, our plan is to increment <major> in the release number when we
+make the next breaking release. Before Git 2.0, the release numbers were
+1.<major>.<minor> with the intention to increment <major> for "usual" breaking
+releases, reserving the jump to Git 2.0 for really large backward-compatibility
+breaking changes.
+
+The intent of this document is to track upcoming deprecations for future
+breaking releases. Furthermore, this document also tracks what will _not_ be
+deprecated. This is done such that the outcome of discussions document both
+when the discussion favors deprecation, but also when it rejects a deprecation.
+
+Items should have a clear summary of the reasons why we do or do not want to
+make the described change that can be easily understood without having to read
+the mailing list discussions. If there are alternatives to the changed feature,
+those alternatives should be pointed out to our users.
+
+All items should be accompanied by references to relevant mailing list threads
+where the deprecation was discussed. These references use message-IDs, which
+can visited via
+
+  https://lore.kernel.org/git/$message_id/
+
+to see the message and its surrounding discussion. Such a reference is there to
+make it easier for you to find how the project reached consensus on the
+described item back then.
+
+This is a living document as the environment surrounding the project changes
+over time. If circumstances change, an earlier decision to deprecate or change
+something may need to be revisited from time to time. So do not take items on
+this list to mean "it is settled, do not waste our time bringing it up again".
+
+== Procedure
+
+Discussing the desire to make breaking changes, declaring that breaking
+changes are made at a certain version boundary, and recording these
+decisions in this document, are necessary but not sufficient.
+Because such changes are expected to be numerous, and the design and
+implementation of them are expected to span over time, they have to
+be deployable trivially at such a version boundary.
+
+The breaking changes MUST be guarded with the a compile-time switch,
+WITH_BREAKING_CHANGES, to help this process.  When built with it,
+the resulting Git binary together with its documentation would
+behave as if these breaking changes slated for the next big version
+boundary are already in effect.  We may also want to have a CI job
+or two to exercise the work-in-progress version of Git with these
+breaking changes.
+
+
+== Git 3.0
+
+The following subsections document upcoming breaking changes for Git 3.0. There
+is no planned release date for this breaking version yet.  The early
+adopter configuration used for changes for this release is `feature.git3`.
+
+Proposed changes and removals only include items which are "ready" to be done.
+In other words, this is not supposed to be a wishlist of features that should
+be changed to or replaced in case the alternative was implemented already.
+
+=== Changes
+
+* The default hash function for new repositories will be changed from "sha1"
+  to "sha256". SHA-1 has been deprecated by NIST in 2011 and is nowadays
+  recommended against in FIPS 140-2 and similar certifications. Furthermore,
+  there are practical attacks on SHA-1 that weaken its cryptographic properties:
++
+  ** The SHAppening (2015). The first demonstration of a practical attack
+     against SHA-1 with 2^57 operations.
+  ** SHAttered (2017). Generation of two valid PDF files with 2^63 operations.
+  ** Birthday-Near-Collision (2019). This attack allows for chosen prefix
+     attacks with 2^68 operations.
+  ** Shambles (2020). This attack allows for chosen prefix attacks with 2^63
+     operations.
++
+While we have protections in place against known attacks, it is expected
+that more attacks against SHA-1 will be found by future research. Paired
+with the ever-growing capability of hardware, it is only a matter of time
+before SHA-1 will be considered broken completely. We want to be prepared
+and will thus change the default hash algorithm to "sha256" for newly
+initialized repositories.
++
+An important requirement for this change is that the ecosystem is ready to
+support the "sha256" object format. This includes popular Git libraries,
+applications and forges.
++
+There is no plan to deprecate the "sha1" object format at this point in time.
++
+Cf. <2f5de416-04ba-c23d-1e0b-83bb655829a7@zombino.com>,
+<20170223155046.e7nxivfwqqoprsqj@LykOS.localdomain>,
+<CA+EOSBncr=4a4d8n9xS4FNehyebpmX8JiUwCsXD47EQDE+DiUQ@mail.gmail.com>.
+
+=== Removals
+
+* Support for grafting commits has long been superseded by git-replace(1).
+  Grafts are inferior to replacement refs:
++
+  ** Grafts are a local-only mechanism and cannot be shared across
+     repositories.
+  ** Grafts can lead to hard-to-diagnose problems when transferring objects
+     between repositories.
++
+The grafting mechanism has been marked as outdated since e650d0643b (docs: mark
+info/grafts as outdated, 2014-03-05) and will be removed.
++
+Cf. <20140304174806.GA11561@sigill.intra.peff.net>.
+
+* The git-pack-redundant(1) command can be used to remove redundant pack files.
+  The subcommand is unusably slow and the reason why nobody reports it as a
+  performance bug is suspected to be the absence of users. We have nominated
+  the command for removal and have started to emit a user-visible warning in
+  c3b58472be (pack-redundant: gauge the usage before proposing its removal,
+  2020-08-25) whenever the command is executed.
++
+So far there was a single complaint about somebody still using the command, but
+that complaint did not cause us to reverse course. On the contrary, we have
+doubled down on the deprecation and starting with 4406522b76 (pack-redundant:
+escalate deprecation warning to an error, 2023-03-23), the command dies unless
+the user passes the `--i-still-use-this` option.
++
+There have not been any subsequent complaints, so this command will finally be
+removed.
++
+Cf. <xmqq1rjuz6n3.fsf_-_@gitster.c.googlers.com>,
+    <CAKvOHKAFXQwt4D8yUCCkf_TQL79mYaJ=KAKhtpDNTvHJFuX1NA@mail.gmail.com>,
+    <20230323204047.GA9290@coredump.intra.peff.net>,
+
+== Superseded features that will not be deprecated
+
+Some features have gained newer replacements that aim to improve the design in
+certain ways. The fact that there is a replacement does not automatically mean
+that the old way of doing things will eventually be removed. This section tracks
+those features with newer alternatives.
+
+* The features git-checkout(1) offers are covered by the pair of commands
+  git-restore(1) and git-switch(1). Because the use of git-checkout(1) is still
+  widespread, and it is not expected that this will change anytime soon, all
+  three commands will stay.
++
+This decision may get revisited in case we ever figure out that there are
+almost no users of any of the commands anymore.
++
+Cf. <xmqqttjazwwa.fsf@gitster.g>,
+<xmqqleeubork.fsf@gitster.g>,
+<112b6568912a6de6672bf5592c3a718e@manjaro.org>.
diff --git a/external/docs/asciidoc/f2b007745ffc33a055f437faa3f0ba54ceab087e b/external/docs/asciidoc/f2b007745ffc33a055f437faa3f0ba54ceab087e
new file mode 100644
index 0000000000..f45db5b727
--- /dev/null
+++ b/external/docs/asciidoc/f2b007745ffc33a055f437faa3f0ba54ceab087e
@@ -0,0 +1,639 @@
+Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, a few rough rules are:
+
+ - Most importantly, we never say "It's in POSIX; we'll happily
+   ignore your needs should your system not conform to it."
+   We live in the real world.
+
+ - However, we often say "Let's stay away from that construct,
+   it's not even in POSIX".
+
+ - In spite of the above two rules, we sometimes say "Although
+   this is not in POSIX, it (is so convenient | makes the code
+   much more readable | has other good characteristics) and
+   practically all the platforms we care about support it, so
+   let's use it".
+
+   Again, we live in the real world, and it is sometimes a
+   judgement call, the decision based more on real world
+   constraints people face than what the paper standard says.
+
+ - Fixing style violations while working on a real change as a
+   preparatory clean-up step is good, but otherwise avoid useless code
+   churn for the sake of conforming to the style.
+
+   "Once it _is_ in the tree, it's not really worth the patch noise to
+   go and fix it up."
+   Cf. http://lkml.iu.edu/hypermail/linux/kernel/1001.3/01069.html
+
+Make your code readable and sensible, and don't try to be clever.
+
+As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the _local_
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn't match the overall style of existing code).
+
+But if you must have a list of rules, here they are.
+
+For shell scripts specifically (not exhaustive):
+
+ - We use tabs for indentation.
+
+ - Case arms are indented at the same depth as case and esac lines,
+   like this:
+
+	case "$variable" in
+	pattern1)
+		do this
+		;;
+	pattern2)
+		do that
+		;;
+	esac
+
+ - Redirection operators should be written with space before, but no
+   space after them.  In other words, write 'echo test >"$file"'
+   instead of 'echo test> $file' or 'echo test > $file'.  Note that
+   even though it is not required by POSIX to double-quote the
+   redirection target in a variable (as shown above), our code does so
+   because some versions of bash issue a warning without the quotes.
+
+	(incorrect)
+	cat hello > world < universe
+	echo hello >$world
+
+	(correct)
+	cat hello >world <universe
+	echo hello >"$world"
+
+ - We prefer $( ... ) for command substitution; unlike ``, it
+   properly nests.  It should have been the way Bourne spelled
+   it from day one, but unfortunately isn't.
+
+ - If you want to find out if a command is available on the user's
+   $PATH, you should use 'type <command>', instead of 'which <command>'.
+   The output of 'which' is not machine parseable and its exit code
+   is not reliable across platforms.
+
+ - We use POSIX compliant parameter substitutions and avoid bashisms;
+   namely:
+
+   - We use ${parameter-word} and its [-=?+] siblings, and their
+     colon'ed "unset or null" form.
+
+   - We use ${parameter#word} and its [#%] siblings, and their
+     doubled "longest matching" form.
+
+   - No "Substring Expansion" ${parameter:offset:length}.
+
+   - No shell arrays.
+
+   - No strlen ${#parameter}.
+
+   - No pattern replacement ${parameter/pattern/string}.
+
+ - We use Arithmetic Expansion $(( ... )).
+
+ - Inside Arithmetic Expansion, spell shell variables with $ in front
+   of them, as some shells do not grok $((x)) while accepting $(($x))
+   just fine (e.g. dash older than 0.5.4).
+
+ - We do not use Process Substitution <(list) or >(list).
+
+ - Do not write control structures on a single line with semicolon.
+   "then" should be on the next line for if statements, and "do"
+   should be on the next line for "while" and "for".
+
+	(incorrect)
+	if test -f hello; then
+		do this
+	fi
+
+	(correct)
+	if test -f hello
+	then
+		do this
+	fi
+
+ - If a command sequence joined with && or || or | spans multiple
+   lines, put each command on a separate line and put && and || and |
+   operators at the end of each line, rather than the start. This
+   means you don't need to use \ to join lines, since the above
+   operators imply the sequence isn't finished.
+
+	(incorrect)
+	grep blob verify_pack_result \
+	| awk -f print_1.awk \
+	| sort >actual &&
+	...
+
+	(correct)
+	grep blob verify_pack_result |
+	awk -f print_1.awk |
+	sort >actual &&
+	...
+
+ - We prefer "test" over "[ ... ]".
+
+ - We do not write the noiseword "function" in front of shell
+   functions.
+
+ - We prefer a space between the function name and the parentheses,
+   and no space inside the parentheses. The opening "{" should also
+   be on the same line.
+
+	(incorrect)
+	my_function(){
+		...
+
+	(correct)
+	my_function () {
+		...
+
+ - As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+   [::], [==], or [..]) for portability.
+
+   - We do not use \{m,n\};
+
+   - We do not use -E;
+
+   - We do not use ? or + (which are \{0,1\} and \{1,\}
+     respectively in BRE) but that goes without saying as these
+     are ERE elements not BRE (note that \? and \+ are not even part
+     of BRE -- making them accessible from BRE is a GNU extension).
+
+ - Use Git's gettext wrappers in git-sh-i18n to make the user
+   interface translatable. See "Marking strings for translation" in
+   po/README.
+
+ - We do not write our "test" command with "-a" and "-o" and use "&&"
+   or "||" to concatenate multiple "test" commands instead, because
+   the use of "-a/-o" is often error-prone.  E.g.
+
+     test -n "$x" -a "$a" = "$b"
+
+   is buggy and breaks when $x is "=", but
+
+     test -n "$x" && test "$a" = "$b"
+
+   does not have such a problem.
+
+
+For C programs:
+
+ - We use tabs to indent, and interpret tabs as taking up to
+   8 spaces.
+
+ - We try to keep to at most 80 characters per line.
+
+ - As a Git developer we assume you have a reasonably modern compiler
+   and we recommend you to enable the DEVELOPER makefile knob to
+   ensure your patch is clear of all compiler warnings we care about,
+   by e.g. "echo DEVELOPER=1 >>config.mak".
+
+ - We try to support a wide range of C compilers to compile Git with,
+   including old ones.  You should not use features from newer C
+   standard, even if your compiler groks them.
+
+   There are a few exceptions to this guideline:
+
+   . since early 2012 with e1327023ea, we have been using an enum
+     definition whose last element is followed by a comma.  This, like
+     an array initializer that ends with a trailing comma, can be used
+     to reduce the patch noise when adding a new identifer at the end.
+
+   . since mid 2017 with cbc0f81d, we have been using designated
+     initializers for struct (e.g. "struct t v = { .val = 'a' };").
+
+   . since mid 2017 with 512f41cf, we have been using designated
+     initializers for array (e.g. "int array[10] = { [5] = 2 }").
+
+   These used to be forbidden, but we have not heard any breakage
+   report, and they are assumed to be safe.
+
+ - Variables have to be declared at the beginning of the block, before
+   the first statement (i.e. -Wdeclaration-after-statement).
+
+ - Declaring a variable in the for loop "for (int i = 0; i < 10; i++)"
+   is still not allowed in this codebase.
+
+ - NULL pointers shall be written as NULL, not as 0.
+
+ - When declaring pointers, the star sides with the variable
+   name, i.e. "char *string", not "char* string" or
+   "char * string".  This makes it easier to understand code
+   like "char *string, c;".
+
+ - Use whitespace around operators and keywords, but not inside
+   parentheses and not around functions. So:
+
+        while (condition)
+		func(bar + 1);
+
+   and not:
+
+        while( condition )
+		func (bar+1);
+
+ - We avoid using braces unnecessarily.  I.e.
+
+	if (bla) {
+		x = 1;
+	}
+
+   is frowned upon. But there are a few exceptions:
+
+	- When the statement extends over a few lines (e.g., a while loop
+	  with an embedded conditional, or a comment). E.g.:
+
+		while (foo) {
+			if (x)
+				one();
+			else
+				two();
+		}
+
+		if (foo) {
+			/*
+			 * This one requires some explanation,
+			 * so we're better off with braces to make
+			 * it obvious that the indentation is correct.
+			 */
+			doit();
+		}
+
+	- When there are multiple arms to a conditional and some of them
+	  require braces, enclose even a single line block in braces for
+	  consistency. E.g.:
+
+		if (foo) {
+			doit();
+		} else {
+			one();
+			two();
+			three();
+		}
+
+ - We try to avoid assignments in the condition of an "if" statement.
+
+ - Try to make your code understandable.  You may put comments
+   in, but comments invariably tend to stale out when the code
+   they were describing changes.  Often splitting a function
+   into two makes the intention of the code much clearer.
+
+ - Multi-line comments include their delimiters on separate lines from
+   the text.  E.g.
+
+	/*
+	 * A very long
+	 * multi-line comment.
+	 */
+
+   Note however that a comment that explains a translatable string to
+   translators uses a convention of starting with a magic token
+   "TRANSLATORS: ", e.g.
+
+	/*
+	 * TRANSLATORS: here is a comment that explains the string to
+	 * be translated, that follows immediately after it.
+	 */
+	_("Here is a translatable string explained by the above.");
+
+ - Double negation is often harder to understand than no negation
+   at all.
+
+ - There are two schools of thought when it comes to comparison,
+   especially inside a loop. Some people prefer to have the less stable
+   value on the left hand side and the more stable value on the right hand
+   side, e.g. if you have a loop that counts variable i down to the
+   lower bound,
+
+	while (i > lower_bound) {
+		do something;
+		i--;
+	}
+
+   Other people prefer to have the textual order of values match the
+   actual order of values in their comparison, so that they can
+   mentally draw a number line from left to right and place these
+   values in order, i.e.
+
+	while (lower_bound < i) {
+		do something;
+		i--;
+	}
+
+   Both are valid, and we use both.  However, the more "stable" the
+   stable side becomes, the more we tend to prefer the former
+   (comparison with a constant, "i > 0", is an extreme example).
+   Just do not mix styles in the same part of the code and mimic
+   existing styles in the neighbourhood.
+
+ - There are two schools of thought when it comes to splitting a long
+   logical line into multiple lines.  Some people push the second and
+   subsequent lines far enough to the right with tabs and align them:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+		span_more_than_a_single_line_of ||
+		the_source_text) {
+                ...
+
+   while other people prefer to align the second and the subsequent
+   lines with the column immediately inside the opening parenthesis,
+   with tabs and spaces, following our "tabstop is always a multiple
+   of 8" convention:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of ||
+	    the_source_text) {
+                ...
+
+   Both are valid, and we use both.  Again, just do not mix styles in
+   the same part of the code and mimic existing styles in the
+   neighbourhood.
+
+ - When splitting a long logical line, some people change line before
+   a binary operator, so that the result looks like a parse tree when
+   you turn your head 90-degrees counterclockwise:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to
+	    || span_more_than_a_single_line_of_the_source_text) {
+
+   while other people prefer to leave the operator at the end of the
+   line:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of_the_source_text) {
+
+   Both are valid, but we tend to use the latter more, unless the
+   expression gets fairly complex, in which case the former tends to
+   be easier to read.  Again, just do not mix styles in the same part
+   of the code and mimic existing styles in the neighbourhood.
+
+ - When splitting a long logical line, with everything else being
+   equal, it is preferable to split after the operator at higher
+   level in the parse tree.  That is, this is more preferable:
+
+	if (a_very_long_variable * that_is_used_in +
+	    a_very_long_expression) {
+		...
+
+   than
+
+	if (a_very_long_variable *
+	    that_is_used_in + a_very_long_expression) {
+		...
+
+ - Some clever tricks, like using the !! operator with arithmetic
+   constructs, can be extremely confusing to others.  Avoid them,
+   unless there is a compelling reason to use them.
+
+ - Use the API.  No, really.  We have a strbuf (variable length
+   string), several arrays with the ALLOC_GROW() macro, a
+   string_list for sorted string lists, a hash map (mapping struct
+   objects) named "struct decorate", amongst other things.
+
+ - When you come up with an API, document its functions and structures
+   in the header file that exposes the API to its callers. Use what is
+   in "strbuf.h" as a model for the appropriate tone and level of
+   detail.
+
+ - The first #include in C files, except in platform specific compat/
+   implementations, must be either "git-compat-util.h", "cache.h" or
+   "builtin.h".  You do not have to include more than one of these.
+
+ - A C file must directly include the header files that declare the
+   functions and the types it uses, except for the functions and types
+   that are made available to it by including one of the header files
+   it must include by the previous rule.
+
+ - If you are planning a new command, consider writing it in shell
+   or perl first, so that changes in semantics can be easily
+   changed and discussed.  Many Git commands started out like
+   that, and a few are still scripts.
+
+ - Avoid introducing a new dependency into Git. This means you
+   usually should stay away from scripting languages not already
+   used in the Git core command set (unless your command is clearly
+   separate from it, such as an importer to convert random-scm-X
+   repositories to Git).
+
+ - When we pass <string, length> pair to functions, we should try to
+   pass them in that order.
+
+ - Use Git's gettext wrappers to make the user interface
+   translatable. See "Marking strings for translation" in po/README.
+
+ - Variables and functions local to a given source file should be marked
+   with "static". Variables that are visible to other source files
+   must be declared with "extern" in header files. However, function
+   declarations should not use "extern", as that is already the default.
+
+ - You can launch gdb around your program using the shorthand GIT_DEBUGGER.
+   Run `GIT_DEBUGGER=1 ./bin-wrappers/git foo` to simply use gdb as is, or
+   run `GIT_DEBUGGER="<debugger> <debugger-args>" ./bin-wrappers/git foo` to
+   use your own debugger and arguments. Example: `GIT_DEBUGGER="ddd --gdb"
+   ./bin-wrappers/git log` (See `wrap-for-bin.sh`.)
+
+For Perl programs:
+
+ - Most of the C guidelines above apply.
+
+ - We try to support Perl 5.8 and later ("use Perl 5.008").
+
+ - use strict and use warnings are strongly preferred.
+
+ - Don't overuse statement modifiers unless using them makes the
+   result easier to follow.
+
+	... do something ...
+	do_this() unless (condition);
+        ... do something else ...
+
+   is more readable than:
+
+	... do something ...
+	unless (condition) {
+		do_this();
+	}
+        ... do something else ...
+
+   *only* when the condition is so rare that do_this() will be almost
+   always called.
+
+ - We try to avoid assignments inside "if ()" conditions.
+
+ - Learn and use Git.pm if you need that functionality.
+
+ - For Emacs, it's useful to put the following in
+   GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode:
+
+    ;; note the first part is useful for C editing, too
+    ((nil . ((indent-tabs-mode . t)
+                  (tab-width . 8)
+                  (fill-column . 80)))
+     (cperl-mode . ((cperl-indent-level . 8)
+                    (cperl-extra-newline-before-brace . nil)
+                    (cperl-merge-trailing-else . t))))
+
+For Python scripts:
+
+ - We follow PEP-8 (http://www.python.org/dev/peps/pep-0008/).
+
+ - As a minimum, we aim to be compatible with Python 2.6 and 2.7.
+
+ - Where required libraries do not restrict us to Python 2, we try to
+   also be compatible with Python 3.1 and later.
+
+ - When you must differentiate between Unicode literals and byte string
+   literals, it is OK to use the 'b' prefix.  Even though the Python
+   documentation for version 2.6 does not mention this prefix, it has
+   been supported since version 2.6.0.
+
+Error Messages
+
+ - Do not end error messages with a full stop.
+
+ - Do not capitalize ("unable to open %s", not "Unable to open %s")
+
+ - Say what the error is first ("cannot open %s", not "%s: cannot open")
+
+
+Externally Visible Names
+
+ - For configuration variable names, follow the existing convention:
+
+   . The section name indicates the affected subsystem.
+
+   . The subsection name, if any, indicates which of an unbounded set
+     of things to set the value for.
+
+   . The variable name describes the effect of tweaking this knob.
+
+   The section and variable names that consist of multiple words are
+   formed by concatenating the words without punctuations (e.g. `-`),
+   and are broken using bumpyCaps in documentation as a hint to the
+   reader.
+
+   When choosing the variable namespace, do not use variable name for
+   specifying possibly unbounded set of things, most notably anything
+   an end user can freely come up with (e.g. branch names).  Instead,
+   use subsection names or variable values, like the existing variable
+   branch.<name>.description does.
+
+
+Writing Documentation:
+
+ Most (if not all) of the documentation pages are written in the
+ AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+ processed into HTML and manpages (e.g. git.html and git.1 in the
+ same directory).
+
+ The documentation liberally mixes US and UK English (en_US/UK)
+ norms for spelling and grammar, which is somewhat unfortunate.
+ In an ideal world, it would have been better if it consistently
+ used only one and not the other, and we would have picked en_US
+ (if you wish to correct the English of some of the existing
+ documentation, please see the documentation-related advice in the
+ Documentation/SubmittingPatches file).
+
+ Every user-visible change should be reflected in the documentation.
+ The same general rule as for code applies -- imitate the existing
+ conventions.
+
+ A few commented examples follow to provide reference when writing or
+ modifying command usage strings and synopsis sections in the manual
+ pages:
+
+ Placeholders are spelled in lowercase and enclosed in angle brackets:
+   <file>
+   --sort=<key>
+   --abbrev[=<n>]
+
+ If a placeholder has multiple words, they are separated by dashes:
+   <new-branch-name>
+   --template=<template-directory>
+
+ Possibility of multiple occurrences is indicated by three dots:
+   <file>...
+   (One or more of <file>.)
+
+ Optional parts are enclosed in square brackets:
+   [<extra>]
+   (Zero or one <extra>.)
+
+   --exec-path[=<path>]
+   (Option with an optional argument.  Note that the "=" is inside the
+   brackets.)
+
+   [<patch>...]
+   (Zero or more of <patch>.  Note that the dots are inside, not
+   outside the brackets.)
+
+ Multiple alternatives are indicated with vertical bars:
+   [-q | --quiet]
+   [--utf8 | --no-utf8]
+
+ Parentheses are used for grouping:
+   [(<rev> | <range>)...]
+   (Any number of either <rev> or <range>.  Parens are needed to make
+   it clear that "..." pertains to both <rev> and <range>.)
+
+   [(-p <parent>)...]
+   (Any number of option -p, each with one <parent> argument.)
+
+   git remote set-head <name> (-a | -d | <branch>)
+   (One and only one of "-a", "-d" or "<branch>" _must_ (no square
+   brackets) be provided.)
+
+ And a somewhat more contrived example:
+   --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+   Here "=" is outside the brackets, because "--diff-filter=" is a
+   valid usage.  "*" has its own pair of brackets, because it can
+   (optionally) be specified only when one or more of the letters is
+   also provided.
+
+  A note on notation:
+   Use 'git' (all lowercase) when talking about commands i.e. something
+   the user would type into a shell and use 'Git' (uppercase first letter)
+   when talking about the version control system and its properties.
+
+ A few commented examples follow to provide reference when writing or
+ modifying paragraphs or option/command explanations that contain options
+ or commands:
+
+ Literal examples (e.g. use of command-line options, command names,
+ branch names, URLs, pathnames (files and directories), configuration and
+ environment variables) must be typeset in monospace (i.e. wrapped with
+ backticks):
+   `--pretty=oneline`
+   `git rev-list`
+   `remote.pushDefault`
+   `http://git.example.com`
+   `.git/config`
+   `GIT_DIR`
+   `HEAD`
+
+ An environment variable must be prefixed with "$" only when referring to its
+ value and not when referring to the variable itself, in this case there is
+ nothing to add except the backticks:
+   `GIT_DIR` is specified
+   `$GIT_DIR/hooks/pre-receive`
+
+ Word phrases enclosed in `backtick characters` are rendered literally
+ and will not be further expanded. The use of `backticks` to achieve the
+ previous rule means that literal examples should not use AsciiDoc
+ escapes.
+   Correct:
+      `--pretty=oneline`
+   Incorrect:
+      `\--pretty=oneline`
+
+ If some place in the documentation needs to typeset a command usage
+ example with inline substitutions, it is fine to use +monospaced and
+ inline substituted text+ instead of `monospaced literal text`, and with
+ the former, the part that should not get substituted must be
+ quoted/escaped.
diff --git a/external/docs/asciidoc/f485f9b050c77bb17365499faca70a6e985afbf9 b/external/docs/asciidoc/f485f9b050c77bb17365499faca70a6e985afbf9
new file mode 100644
index 0000000000..9d5c27807a
--- /dev/null
+++ b/external/docs/asciidoc/f485f9b050c77bb17365499faca70a6e985afbf9
@@ -0,0 +1,750 @@
+Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, a few rough rules are:
+
+ - Most importantly, we never say "It's in POSIX; we'll happily
+   ignore your needs should your system not conform to it."
+   We live in the real world.
+
+ - However, we often say "Let's stay away from that construct,
+   it's not even in POSIX".
+
+ - In spite of the above two rules, we sometimes say "Although
+   this is not in POSIX, it (is so convenient | makes the code
+   much more readable | has other good characteristics) and
+   practically all the platforms we care about support it, so
+   let's use it".
+
+   Again, we live in the real world, and it is sometimes a
+   judgement call, the decision based more on real world
+   constraints people face than what the paper standard says.
+
+ - Fixing style violations while working on a real change as a
+   preparatory clean-up step is good, but otherwise avoid useless code
+   churn for the sake of conforming to the style.
+
+   "Once it _is_ in the tree, it's not really worth the patch noise to
+   go and fix it up."
+   Cf. http://lkml.iu.edu/hypermail/linux/kernel/1001.3/01069.html
+
+ - Log messages to explain your changes are as important as the
+   changes themselves.  Clearly written code and in-code comments
+   explain how the code works and what is assumed from the surrounding
+   context.  The log messages explain what the changes wanted to
+   achieve and why the changes were necessary (more on this in the
+   accompanying SubmittingPatches document).
+
+Make your code readable and sensible, and don't try to be clever.
+
+As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the _local_
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn't match the overall style of existing code).
+
+But if you must have a list of rules, here are some language
+specific ones. Note that Documentation/ToolsForGit.txt document
+has a collection of tips to help you use some external tools
+to conform to these guidelines.
+
+For shell scripts specifically (not exhaustive):
+
+ - We use tabs for indentation.
+
+ - Case arms are indented at the same depth as case and esac lines,
+   like this:
+
+	case "$variable" in
+	pattern1)
+		do this
+		;;
+	pattern2)
+		do that
+		;;
+	esac
+
+ - Redirection operators should be written with space before, but no
+   space after them.  In other words, write 'echo test >"$file"'
+   instead of 'echo test> $file' or 'echo test > $file'.  Note that
+   even though it is not required by POSIX to double-quote the
+   redirection target in a variable (as shown above), our code does so
+   because some versions of bash issue a warning without the quotes.
+
+	(incorrect)
+	cat hello > world < universe
+	echo hello >$world
+
+	(correct)
+	cat hello >world <universe
+	echo hello >"$world"
+
+ - We prefer $( ... ) for command substitution; unlike ``, it
+   properly nests.  It should have been the way Bourne spelled
+   it from day one, but unfortunately isn't.
+
+ - If you want to find out if a command is available on the user's
+   $PATH, you should use 'type <command>', instead of 'which <command>'.
+   The output of 'which' is not machine parsable and its exit code
+   is not reliable across platforms.
+
+ - We use POSIX compliant parameter substitutions and avoid bashisms;
+   namely:
+
+   - We use ${parameter-word} and its [-=?+] siblings, and their
+     colon'ed "unset or null" form.
+
+   - We use ${parameter#word} and its [#%] siblings, and their
+     doubled "longest matching" form.
+
+   - No "Substring Expansion" ${parameter:offset:length}.
+
+   - No shell arrays.
+
+   - No pattern replacement ${parameter/pattern/string}.
+
+ - We use Arithmetic Expansion $(( ... )).
+
+ - We do not use Process Substitution <(list) or >(list).
+
+ - Do not write control structures on a single line with semicolon.
+   "then" should be on the next line for if statements, and "do"
+   should be on the next line for "while" and "for".
+
+	(incorrect)
+	if test -f hello; then
+		do this
+	fi
+
+	(correct)
+	if test -f hello
+	then
+		do this
+	fi
+
+ - If a command sequence joined with && or || or | spans multiple
+   lines, put each command on a separate line and put && and || and |
+   operators at the end of each line, rather than the start. This
+   means you don't need to use \ to join lines, since the above
+   operators imply the sequence isn't finished.
+
+	(incorrect)
+	grep blob verify_pack_result \
+	| awk -f print_1.awk \
+	| sort >actual &&
+	...
+
+	(correct)
+	grep blob verify_pack_result |
+	awk -f print_1.awk |
+	sort >actual &&
+	...
+
+ - We prefer "test" over "[ ... ]".
+
+ - We do not write the noiseword "function" in front of shell
+   functions.
+
+ - We prefer a space between the function name and the parentheses,
+   and no space inside the parentheses. The opening "{" should also
+   be on the same line.
+
+	(incorrect)
+	my_function(){
+		...
+
+	(correct)
+	my_function () {
+		...
+
+ - As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+   [::], [==], or [..]) for portability.
+
+   - We do not use \{m,n\};
+
+   - We do not use ? or + (which are \{0,1\} and \{1,\}
+     respectively in BRE) but that goes without saying as these
+     are ERE elements not BRE (note that \? and \+ are not even part
+     of BRE -- making them accessible from BRE is a GNU extension).
+
+ - Use Git's gettext wrappers in git-sh-i18n to make the user
+   interface translatable. See "Marking strings for translation" in
+   po/README.
+
+ - We do not write our "test" command with "-a" and "-o" and use "&&"
+   or "||" to concatenate multiple "test" commands instead, because
+   the use of "-a/-o" is often error-prone.  E.g.
+
+     test -n "$x" -a "$a" = "$b"
+
+   is buggy and breaks when $x is "=", but
+
+     test -n "$x" && test "$a" = "$b"
+
+   does not have such a problem.
+
+ - Even though "local" is not part of POSIX, we make heavy use of it
+   in our test suite.  We do not use it in scripted Porcelains, and
+   hopefully nobody starts using "local" before they are reimplemented
+   in C ;-)
+
+
+For C programs:
+
+ - We use tabs to indent, and interpret tabs as taking up to
+   8 spaces.
+
+ - We try to keep to at most 80 characters per line.
+
+ - As a Git developer we assume you have a reasonably modern compiler
+   and we recommend you to enable the DEVELOPER makefile knob to
+   ensure your patch is clear of all compiler warnings we care about,
+   by e.g. "echo DEVELOPER=1 >>config.mak".
+
+ - We try to support a wide range of C compilers to compile Git with,
+   including old ones.  As of Git v2.35.0 Git requires C99 (we check
+   "__STDC_VERSION__"). You should not use features from a newer C
+   standard, even if your compiler groks them.
+
+   New C99 features have been phased in gradually, if something's new
+   in C99 but not used yet don't assume that it's safe to use, some
+   compilers we target have only partial support for it. These are
+   considered safe to use:
+
+   . since around 2007 with 2b6854c863a, we have been using
+     initializer elements which are not computable at load time. E.g.:
+
+	const char *args[] = {"constant", variable, NULL};
+
+   . since early 2012 with e1327023ea, we have been using an enum
+     definition whose last element is followed by a comma.  This, like
+     an array initializer that ends with a trailing comma, can be used
+     to reduce the patch noise when adding a new identifier at the end.
+
+   . since mid 2017 with cbc0f81d, we have been using designated
+     initializers for struct (e.g. "struct t v = { .val = 'a' };").
+
+   . since mid 2017 with 512f41cf, we have been using designated
+     initializers for array (e.g. "int array[10] = { [5] = 2 }").
+
+   . since early 2021 with 765dc168882, we have been using variadic
+     macros, mostly for printf-like trace and debug macros.
+
+   . since late 2021 with 44ba10d6, we have had variables declared in
+     the for loop "for (int i = 0; i < 10; i++)".
+
+   New C99 features that we cannot use yet:
+
+   . %z and %zu as a printf() argument for a size_t (the %z being for
+     the POSIX-specific ssize_t). Instead you should use
+     printf("%"PRIuMAX, (uintmax_t)v).  These days the MSVC version we
+     rely on supports %z, but the C library used by MinGW does not.
+
+   . Shorthand like ".a.b = *c" in struct initializations is known to
+     trip up an older IBM XLC version, use ".a = { .b = *c }" instead.
+     See the 33665d98 (reftable: make assignments portable to AIX xlc
+     v12.01, 2022-03-28).
+
+ - Variables have to be declared at the beginning of the block, before
+   the first statement (i.e. -Wdeclaration-after-statement).
+
+ - NULL pointers shall be written as NULL, not as 0.
+
+ - When declaring pointers, the star sides with the variable
+   name, i.e. "char *string", not "char* string" or
+   "char * string".  This makes it easier to understand code
+   like "char *string, c;".
+
+ - Use whitespace around operators and keywords, but not inside
+   parentheses and not around functions. So:
+
+        while (condition)
+		func(bar + 1);
+
+   and not:
+
+        while( condition )
+		func (bar+1);
+
+ - Do not explicitly compare an integral value with constant 0 or '\0',
+   or a pointer value with constant NULL.  For instance, to validate that
+   counted array <ptr, cnt> is initialized but has no elements, write:
+
+	if (!ptr || cnt)
+		BUG("empty array expected");
+
+   and not:
+
+	if (ptr == NULL || cnt != 0);
+		BUG("empty array expected");
+
+ - We avoid using braces unnecessarily.  I.e.
+
+	if (bla) {
+		x = 1;
+	}
+
+   is frowned upon. But there are a few exceptions:
+
+	- When the statement extends over a few lines (e.g., a while loop
+	  with an embedded conditional, or a comment). E.g.:
+
+		while (foo) {
+			if (x)
+				one();
+			else
+				two();
+		}
+
+		if (foo) {
+			/*
+			 * This one requires some explanation,
+			 * so we're better off with braces to make
+			 * it obvious that the indentation is correct.
+			 */
+			doit();
+		}
+
+	- When there are multiple arms to a conditional and some of them
+	  require braces, enclose even a single line block in braces for
+	  consistency. E.g.:
+
+		if (foo) {
+			doit();
+		} else {
+			one();
+			two();
+			three();
+		}
+
+ - We try to avoid assignments in the condition of an "if" statement.
+
+ - Try to make your code understandable.  You may put comments
+   in, but comments invariably tend to stale out when the code
+   they were describing changes.  Often splitting a function
+   into two makes the intention of the code much clearer.
+
+ - Multi-line comments include their delimiters on separate lines from
+   the text.  E.g.
+
+	/*
+	 * A very long
+	 * multi-line comment.
+	 */
+
+   Note however that a comment that explains a translatable string to
+   translators uses a convention of starting with a magic token
+   "TRANSLATORS: ", e.g.
+
+	/*
+	 * TRANSLATORS: here is a comment that explains the string to
+	 * be translated, that follows immediately after it.
+	 */
+	_("Here is a translatable string explained by the above.");
+
+ - Double negation is often harder to understand than no negation
+   at all.
+
+ - There are two schools of thought when it comes to comparison,
+   especially inside a loop. Some people prefer to have the less stable
+   value on the left hand side and the more stable value on the right hand
+   side, e.g. if you have a loop that counts variable i down to the
+   lower bound,
+
+	while (i > lower_bound) {
+		do something;
+		i--;
+	}
+
+   Other people prefer to have the textual order of values match the
+   actual order of values in their comparison, so that they can
+   mentally draw a number line from left to right and place these
+   values in order, i.e.
+
+	while (lower_bound < i) {
+		do something;
+		i--;
+	}
+
+   Both are valid, and we use both.  However, the more "stable" the
+   stable side becomes, the more we tend to prefer the former
+   (comparison with a constant, "i > 0", is an extreme example).
+   Just do not mix styles in the same part of the code and mimic
+   existing styles in the neighbourhood.
+
+ - There are two schools of thought when it comes to splitting a long
+   logical line into multiple lines.  Some people push the second and
+   subsequent lines far enough to the right with tabs and align them:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+		span_more_than_a_single_line_of ||
+		the_source_text) {
+                ...
+
+   while other people prefer to align the second and the subsequent
+   lines with the column immediately inside the opening parenthesis,
+   with tabs and spaces, following our "tabstop is always a multiple
+   of 8" convention:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of ||
+	    the_source_text) {
+                ...
+
+   Both are valid, and we use both.  Again, just do not mix styles in
+   the same part of the code and mimic existing styles in the
+   neighbourhood.
+
+ - When splitting a long logical line, some people change line before
+   a binary operator, so that the result looks like a parse tree when
+   you turn your head 90-degrees counterclockwise:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to
+	    || span_more_than_a_single_line_of_the_source_text) {
+
+   while other people prefer to leave the operator at the end of the
+   line:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of_the_source_text) {
+
+   Both are valid, but we tend to use the latter more, unless the
+   expression gets fairly complex, in which case the former tends to
+   be easier to read.  Again, just do not mix styles in the same part
+   of the code and mimic existing styles in the neighbourhood.
+
+ - When splitting a long logical line, with everything else being
+   equal, it is preferable to split after the operator at higher
+   level in the parse tree.  That is, this is more preferable:
+
+	if (a_very_long_variable * that_is_used_in +
+	    a_very_long_expression) {
+		...
+
+   than
+
+	if (a_very_long_variable *
+	    that_is_used_in + a_very_long_expression) {
+		...
+
+ - Some clever tricks, like using the !! operator with arithmetic
+   constructs, can be extremely confusing to others.  Avoid them,
+   unless there is a compelling reason to use them.
+
+ - Use the API.  No, really.  We have a strbuf (variable length
+   string), several arrays with the ALLOC_GROW() macro, a
+   string_list for sorted string lists, a hash map (mapping struct
+   objects) named "struct decorate", amongst other things.
+
+ - When you come up with an API, document its functions and structures
+   in the header file that exposes the API to its callers. Use what is
+   in "strbuf.h" as a model for the appropriate tone and level of
+   detail.
+
+ - The first #include in C files, except in platform specific compat/
+   implementations, must be either "git-compat-util.h", "cache.h" or
+   "builtin.h".  You do not have to include more than one of these.
+
+ - A C file must directly include the header files that declare the
+   functions and the types it uses, except for the functions and types
+   that are made available to it by including one of the header files
+   it must include by the previous rule.
+
+ - If you are planning a new command, consider writing it in shell
+   or perl first, so that changes in semantics can be easily
+   changed and discussed.  Many Git commands started out like
+   that, and a few are still scripts.
+
+ - Avoid introducing a new dependency into Git. This means you
+   usually should stay away from scripting languages not already
+   used in the Git core command set (unless your command is clearly
+   separate from it, such as an importer to convert random-scm-X
+   repositories to Git).
+
+ - When we pass <string, length> pair to functions, we should try to
+   pass them in that order.
+
+ - Use Git's gettext wrappers to make the user interface
+   translatable. See "Marking strings for translation" in po/README.
+
+ - Variables and functions local to a given source file should be marked
+   with "static". Variables that are visible to other source files
+   must be declared with "extern" in header files. However, function
+   declarations should not use "extern", as that is already the default.
+
+ - You can launch gdb around your program using the shorthand GIT_DEBUGGER.
+   Run `GIT_DEBUGGER=1 ./bin-wrappers/git foo` to simply use gdb as is, or
+   run `GIT_DEBUGGER="<debugger> <debugger-args>" ./bin-wrappers/git foo` to
+   use your own debugger and arguments. Example: `GIT_DEBUGGER="ddd --gdb"
+   ./bin-wrappers/git log` (See `wrap-for-bin.sh`.)
+
+For Perl programs:
+
+ - Most of the C guidelines above apply.
+
+ - We try to support Perl 5.8 and later ("use Perl 5.008").
+
+ - use strict and use warnings are strongly preferred.
+
+ - Don't overuse statement modifiers unless using them makes the
+   result easier to follow.
+
+	... do something ...
+	do_this() unless (condition);
+        ... do something else ...
+
+   is more readable than:
+
+	... do something ...
+	unless (condition) {
+		do_this();
+	}
+        ... do something else ...
+
+   *only* when the condition is so rare that do_this() will be almost
+   always called.
+
+ - We try to avoid assignments inside "if ()" conditions.
+
+ - Learn and use Git.pm if you need that functionality.
+
+For Python scripts:
+
+ - We follow PEP-8 (http://www.python.org/dev/peps/pep-0008/).
+
+ - As a minimum, we aim to be compatible with Python 2.7.
+
+ - Where required libraries do not restrict us to Python 2, we try to
+   also be compatible with Python 3.1 and later.
+
+
+Program Output
+
+ We make a distinction between a Git command's primary output and
+ output which is merely chatty feedback (for instance, status
+ messages, running transcript, or progress display), as well as error
+ messages. Roughly speaking, a Git command's primary output is that
+ which one might want to capture to a file or send down a pipe; its
+ chatty output should not interfere with these use-cases.
+
+ As such, primary output should be sent to the standard output stream
+ (stdout), and chatty output should be sent to the standard error
+ stream (stderr). Examples of commands which produce primary output
+ include `git log`, `git show`, and `git branch --list` which generate
+ output on the stdout stream.
+
+ Not all Git commands have primary output; this is often true of
+ commands whose main function is to perform an action. Some action
+ commands are silent, whereas others are chatty. An example of a
+ chatty action commands is `git clone` with its "Cloning into
+ '<path>'..." and "Checking connectivity..." status messages which it
+ sends to the stderr stream.
+
+ Error messages from Git commands should always be sent to the stderr
+ stream.
+
+
+Error Messages
+
+ - Do not end error messages with a full stop.
+
+ - Do not capitalize the first word, only because it is the first word
+   in the message ("unable to open %s", not "Unable to open %s").  But
+   "SHA-3 not supported" is fine, because the reason the first word is
+   capitalized is not because it is at the beginning of the sentence,
+   but because the word would be spelled in capital letters even when
+   it appeared in the middle of the sentence.
+
+ - Say what the error is first ("cannot open %s", not "%s: cannot open")
+
+
+Externally Visible Names
+
+ - For configuration variable names, follow the existing convention:
+
+   . The section name indicates the affected subsystem.
+
+   . The subsection name, if any, indicates which of an unbounded set
+     of things to set the value for.
+
+   . The variable name describes the effect of tweaking this knob.
+
+   The section and variable names that consist of multiple words are
+   formed by concatenating the words without punctuations (e.g. `-`),
+   and are broken using bumpyCaps in documentation as a hint to the
+   reader.
+
+   When choosing the variable namespace, do not use variable name for
+   specifying possibly unbounded set of things, most notably anything
+   an end user can freely come up with (e.g. branch names).  Instead,
+   use subsection names or variable values, like the existing variable
+   branch.<name>.description does.
+
+
+Writing Documentation:
+
+ Most (if not all) of the documentation pages are written in the
+ AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+ processed into HTML and manpages (e.g. git.html and git.1 in the
+ same directory).
+
+ The documentation liberally mixes US and UK English (en_US/UK)
+ norms for spelling and grammar, which is somewhat unfortunate.
+ In an ideal world, it would have been better if it consistently
+ used only one and not the other, and we would have picked en_US
+ (if you wish to correct the English of some of the existing
+ documentation, please see the documentation-related advice in the
+ Documentation/SubmittingPatches file).
+
+ In order to ensure the documentation is inclusive, avoid assuming
+ that an unspecified example person is male or female, and think
+ twice before using "he", "him", "she", or "her".  Here are some
+ tips to avoid use of gendered pronouns:
+
+  - Prefer succinctness and matter-of-factly describing functionality
+    in the abstract.  E.g.
+
+     --short:: Emit output in the short-format.
+
+    and avoid something like these overly verbose alternatives:
+
+     --short:: Use this to emit output in the short-format.
+     --short:: You can use this to get output in the short-format.
+     --short:: A user who prefers shorter output could....
+     --short:: Should a person and/or program want shorter output, he
+               she/they/it can...
+
+    This practice often eliminates the need to involve human actors in
+    your description, but it is a good practice regardless of the
+    avoidance of gendered pronouns.
+
+  - When it becomes awkward to stick to this style, prefer "you" when
+    addressing the hypothetical user, and possibly "we" when
+    discussing how the program might react to the user.  E.g.
+
+      You can use this option instead of --xyz, but we might remove
+      support for it in future versions.
+
+    while keeping in mind that you can probably be less verbose, e.g.
+
+      Use this instead of --xyz. This option might be removed in future
+      versions.
+
+  - If you still need to refer to an example person that is
+    third-person singular, you may resort to "singular they" to avoid
+    "he/she/him/her", e.g.
+
+      A contributor asks their upstream to pull from them.
+
+    Note that this sounds ungrammatical and unnatural to those who
+    learned that "they" is only used for third-person plural, e.g.
+    those who learn English as a second language in some parts of the
+    world.
+
+ Every user-visible change should be reflected in the documentation.
+ The same general rule as for code applies -- imitate the existing
+ conventions.
+
+ A few commented examples follow to provide reference when writing or
+ modifying command usage strings and synopsis sections in the manual
+ pages:
+
+ Placeholders are spelled in lowercase and enclosed in angle brackets:
+   <file>
+   --sort=<key>
+   --abbrev[=<n>]
+
+ If a placeholder has multiple words, they are separated by dashes:
+   <new-branch-name>
+   --template=<template-directory>
+
+ Possibility of multiple occurrences is indicated by three dots:
+   <file>...
+   (One or more of <file>.)
+
+ Optional parts are enclosed in square brackets:
+   [<file>...]
+   (Zero or more of <file>.)
+
+   --exec-path[=<path>]
+   (Option with an optional argument.  Note that the "=" is inside the
+   brackets.)
+
+   [<patch>...]
+   (Zero or more of <patch>.  Note that the dots are inside, not
+   outside the brackets.)
+
+ Multiple alternatives are indicated with vertical bars:
+   [-q | --quiet]
+   [--utf8 | --no-utf8]
+
+ Use spacing around "|" token(s), but not immediately after opening or
+ before closing a [] or () pair:
+   Do: [-q | --quiet]
+   Don't: [-q|--quiet]
+
+ Don't use spacing around "|" tokens when they're used to seperate the
+ alternate arguments of an option:
+    Do: --track[=(direct|inherit)]
+    Don't: --track[=(direct | inherit)]
+
+ Parentheses are used for grouping:
+   [(<rev> | <range>)...]
+   (Any number of either <rev> or <range>.  Parens are needed to make
+   it clear that "..." pertains to both <rev> and <range>.)
+
+   [(-p <parent>)...]
+   (Any number of option -p, each with one <parent> argument.)
+
+   git remote set-head <name> (-a | -d | <branch>)
+   (One and only one of "-a", "-d" or "<branch>" _must_ (no square
+   brackets) be provided.)
+
+ And a somewhat more contrived example:
+   --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+   Here "=" is outside the brackets, because "--diff-filter=" is a
+   valid usage.  "*" has its own pair of brackets, because it can
+   (optionally) be specified only when one or more of the letters is
+   also provided.
+
+  A note on notation:
+   Use 'git' (all lowercase) when talking about commands i.e. something
+   the user would type into a shell and use 'Git' (uppercase first letter)
+   when talking about the version control system and its properties.
+
+ A few commented examples follow to provide reference when writing or
+ modifying paragraphs or option/command explanations that contain options
+ or commands:
+
+ Literal examples (e.g. use of command-line options, command names,
+ branch names, URLs, pathnames (files and directories), configuration and
+ environment variables) must be typeset in monospace (i.e. wrapped with
+ backticks):
+   `--pretty=oneline`
+   `git rev-list`
+   `remote.pushDefault`
+   `http://git.example.com`
+   `.git/config`
+   `GIT_DIR`
+   `HEAD`
+
+ An environment variable must be prefixed with "$" only when referring to its
+ value and not when referring to the variable itself, in this case there is
+ nothing to add except the backticks:
+   `GIT_DIR` is specified
+   `$GIT_DIR/hooks/pre-receive`
+
+ Word phrases enclosed in `backtick characters` are rendered literally
+ and will not be further expanded. The use of `backticks` to achieve the
+ previous rule means that literal examples should not use AsciiDoc
+ escapes.
+   Correct:
+      `--pretty=oneline`
+   Incorrect:
+      `\--pretty=oneline`
+
+ If some place in the documentation needs to typeset a command usage
+ example with inline substitutions, it is fine to use +monospaced and
+ inline substituted text+ instead of `monospaced literal text`, and with
+ the former, the part that should not get substituted must be
+ quoted/escaped.
diff --git a/external/docs/asciidoc/f8255c58b0b03311a6d37ae461d44e7522c08491 b/external/docs/asciidoc/f8255c58b0b03311a6d37ae461d44e7522c08491
new file mode 100644
index 0000000000..8dddb50a9d
--- /dev/null
+++ b/external/docs/asciidoc/f8255c58b0b03311a6d37ae461d44e7522c08491
@@ -0,0 +1,592 @@
+Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, a few rough rules are:
+
+ - Most importantly, we never say "It's in POSIX; we'll happily
+   ignore your needs should your system not conform to it."
+   We live in the real world.
+
+ - However, we often say "Let's stay away from that construct,
+   it's not even in POSIX".
+
+ - In spite of the above two rules, we sometimes say "Although
+   this is not in POSIX, it (is so convenient | makes the code
+   much more readable | has other good characteristics) and
+   practically all the platforms we care about support it, so
+   let's use it".
+
+   Again, we live in the real world, and it is sometimes a
+   judgement call, the decision based more on real world
+   constraints people face than what the paper standard says.
+
+ - Fixing style violations while working on a real change as a
+   preparatory clean-up step is good, but otherwise avoid useless code
+   churn for the sake of conforming to the style.
+
+   "Once it _is_ in the tree, it's not really worth the patch noise to
+   go and fix it up."
+   Cf. http://lkml.iu.edu/hypermail/linux/kernel/1001.3/01069.html
+
+Make your code readable and sensible, and don't try to be clever.
+
+As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the _local_
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn't match the overall style of existing code).
+
+But if you must have a list of rules, here they are.
+
+For shell scripts specifically (not exhaustive):
+
+ - We use tabs for indentation.
+
+ - Case arms are indented at the same depth as case and esac lines,
+   like this:
+
+	case "$variable" in
+	pattern1)
+		do this
+		;;
+	pattern2)
+		do that
+		;;
+	esac
+
+ - Redirection operators should be written with space before, but no
+   space after them.  In other words, write 'echo test >"$file"'
+   instead of 'echo test> $file' or 'echo test > $file'.  Note that
+   even though it is not required by POSIX to double-quote the
+   redirection target in a variable (as shown above), our code does so
+   because some versions of bash issue a warning without the quotes.
+
+	(incorrect)
+	cat hello > world < universe
+	echo hello >$world
+
+	(correct)
+	cat hello >world <universe
+	echo hello >"$world"
+
+ - We prefer $( ... ) for command substitution; unlike ``, it
+   properly nests.  It should have been the way Bourne spelled
+   it from day one, but unfortunately isn't.
+
+ - If you want to find out if a command is available on the user's
+   $PATH, you should use 'type <command>', instead of 'which <command>'.
+   The output of 'which' is not machine parseable and its exit code
+   is not reliable across platforms.
+
+ - We use POSIX compliant parameter substitutions and avoid bashisms;
+   namely:
+
+   - We use ${parameter-word} and its [-=?+] siblings, and their
+     colon'ed "unset or null" form.
+
+   - We use ${parameter#word} and its [#%] siblings, and their
+     doubled "longest matching" form.
+
+   - No "Substring Expansion" ${parameter:offset:length}.
+
+   - No shell arrays.
+
+   - No strlen ${#parameter}.
+
+   - No pattern replacement ${parameter/pattern/string}.
+
+ - We use Arithmetic Expansion $(( ... )).
+
+ - Inside Arithmetic Expansion, spell shell variables with $ in front
+   of them, as some shells do not grok $((x)) while accepting $(($x))
+   just fine (e.g. dash older than 0.5.4).
+
+ - We do not use Process Substitution <(list) or >(list).
+
+ - Do not write control structures on a single line with semicolon.
+   "then" should be on the next line for if statements, and "do"
+   should be on the next line for "while" and "for".
+
+	(incorrect)
+	if test -f hello; then
+		do this
+	fi
+
+	(correct)
+	if test -f hello
+	then
+		do this
+	fi
+
+ - We prefer "test" over "[ ... ]".
+
+ - We do not write the noiseword "function" in front of shell
+   functions.
+
+ - We prefer a space between the function name and the parentheses,
+   and no space inside the parentheses. The opening "{" should also
+   be on the same line.
+
+	(incorrect)
+	my_function(){
+		...
+
+	(correct)
+	my_function () {
+		...
+
+ - As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+   [::], [==], or [..]) for portability.
+
+   - We do not use \{m,n\};
+
+   - We do not use -E;
+
+   - We do not use ? or + (which are \{0,1\} and \{1,\}
+     respectively in BRE) but that goes without saying as these
+     are ERE elements not BRE (note that \? and \+ are not even part
+     of BRE -- making them accessible from BRE is a GNU extension).
+
+ - Use Git's gettext wrappers in git-sh-i18n to make the user
+   interface translatable. See "Marking strings for translation" in
+   po/README.
+
+ - We do not write our "test" command with "-a" and "-o" and use "&&"
+   or "||" to concatenate multiple "test" commands instead, because
+   the use of "-a/-o" is often error-prone.  E.g.
+
+     test -n "$x" -a "$a" = "$b"
+
+   is buggy and breaks when $x is "=", but
+
+     test -n "$x" && test "$a" = "$b"
+
+   does not have such a problem.
+
+
+For C programs:
+
+ - We use tabs to indent, and interpret tabs as taking up to
+   8 spaces.
+
+ - We try to keep to at most 80 characters per line.
+
+ - As a Git developer we assume you have a reasonably modern compiler
+   and we recommend you to enable the DEVELOPER makefile knob to
+   ensure your patch is clear of all compiler warnings we care about,
+   by e.g. "echo DEVELOPER=1 >>config.mak".
+
+ - We try to support a wide range of C compilers to compile Git with,
+   including old ones. That means that you should not use C99
+   initializers, even if a lot of compilers grok it.
+
+ - Variables have to be declared at the beginning of the block.
+
+ - NULL pointers shall be written as NULL, not as 0.
+
+ - When declaring pointers, the star sides with the variable
+   name, i.e. "char *string", not "char* string" or
+   "char * string".  This makes it easier to understand code
+   like "char *string, c;".
+
+ - Use whitespace around operators and keywords, but not inside
+   parentheses and not around functions. So:
+
+        while (condition)
+		func(bar + 1);
+
+   and not:
+
+        while( condition )
+		func (bar+1);
+
+ - We avoid using braces unnecessarily.  I.e.
+
+	if (bla) {
+		x = 1;
+	}
+
+   is frowned upon. But there are a few exceptions:
+
+	- When the statement extends over a few lines (e.g., a while loop
+	  with an embedded conditional, or a comment). E.g.:
+
+		while (foo) {
+			if (x)
+				one();
+			else
+				two();
+		}
+
+		if (foo) {
+			/*
+			 * This one requires some explanation,
+			 * so we're better off with braces to make
+			 * it obvious that the indentation is correct.
+			 */
+			doit();
+		}
+
+	- When there are multiple arms to a conditional and some of them
+	  require braces, enclose even a single line block in braces for
+	  consistency. E.g.:
+
+		if (foo) {
+			doit();
+		} else {
+			one();
+			two();
+			three();
+		}
+
+ - We try to avoid assignments in the condition of an "if" statement.
+
+ - Try to make your code understandable.  You may put comments
+   in, but comments invariably tend to stale out when the code
+   they were describing changes.  Often splitting a function
+   into two makes the intention of the code much clearer.
+
+ - Multi-line comments include their delimiters on separate lines from
+   the text.  E.g.
+
+	/*
+	 * A very long
+	 * multi-line comment.
+	 */
+
+   Note however that a comment that explains a translatable string to
+   translators uses a convention of starting with a magic token
+   "TRANSLATORS: ", e.g.
+
+	/*
+	 * TRANSLATORS: here is a comment that explains the string to
+	 * be translated, that follows immediately after it.
+	 */
+	_("Here is a translatable string explained by the above.");
+
+ - Double negation is often harder to understand than no negation
+   at all.
+
+ - There are two schools of thought when it comes to comparison,
+   especially inside a loop. Some people prefer to have the less stable
+   value on the left hand side and the more stable value on the right hand
+   side, e.g. if you have a loop that counts variable i down to the
+   lower bound,
+
+	while (i > lower_bound) {
+		do something;
+		i--;
+	}
+
+   Other people prefer to have the textual order of values match the
+   actual order of values in their comparison, so that they can
+   mentally draw a number line from left to right and place these
+   values in order, i.e.
+
+	while (lower_bound < i) {
+		do something;
+		i--;
+	}
+
+   Both are valid, and we use both.  However, the more "stable" the
+   stable side becomes, the more we tend to prefer the former
+   (comparison with a constant, "i > 0", is an extreme example).
+   Just do not mix styles in the same part of the code and mimic
+   existing styles in the neighbourhood.
+
+ - There are two schools of thought when it comes to splitting a long
+   logical line into multiple lines.  Some people push the second and
+   subsequent lines far enough to the right with tabs and align them:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+		span_more_than_a_single_line_of ||
+		the_source_text) {
+                ...
+
+   while other people prefer to align the second and the subsequent
+   lines with the column immediately inside the opening parenthesis,
+   with tabs and spaces, following our "tabstop is always a multiple
+   of 8" convention:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of ||
+	    the_source_text) {
+                ...
+
+   Both are valid, and we use both.  Again, just do not mix styles in
+   the same part of the code and mimic existing styles in the
+   neighbourhood.
+
+ - When splitting a long logical line, some people change line before
+   a binary operator, so that the result looks like a parse tree when
+   you turn your head 90-degrees counterclockwise:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to
+	    || span_more_than_a_single_line_of_the_source_text) {
+
+   while other people prefer to leave the operator at the end of the
+   line:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of_the_source_text) {
+
+   Both are valid, but we tend to use the latter more, unless the
+   expression gets fairly complex, in which case the former tends to
+   be easier to read.  Again, just do not mix styles in the same part
+   of the code and mimic existing styles in the neighbourhood.
+
+ - When splitting a long logical line, with everything else being
+   equal, it is preferable to split after the operator at higher
+   level in the parse tree.  That is, this is more preferable:
+
+	if (a_very_long_variable * that_is_used_in +
+	    a_very_long_expression) {
+		...
+
+   than
+
+	if (a_very_long_variable *
+	    that_is_used_in + a_very_long_expression) {
+		...
+
+ - Some clever tricks, like using the !! operator with arithmetic
+   constructs, can be extremely confusing to others.  Avoid them,
+   unless there is a compelling reason to use them.
+
+ - Use the API.  No, really.  We have a strbuf (variable length
+   string), several arrays with the ALLOC_GROW() macro, a
+   string_list for sorted string lists, a hash map (mapping struct
+   objects) named "struct decorate", amongst other things.
+
+ - When you come up with an API, document its functions and structures
+   in the header file that exposes the API to its callers. Use what is
+   in "strbuf.h" as a model for the appropriate tone and level of
+   detail.
+
+ - The first #include in C files, except in platform specific compat/
+   implementations, must be either "git-compat-util.h", "cache.h" or
+   "builtin.h".  You do not have to include more than one of these.
+
+ - A C file must directly include the header files that declare the
+   functions and the types it uses, except for the functions and types
+   that are made available to it by including one of the header files
+   it must include by the previous rule.
+
+ - If you are planning a new command, consider writing it in shell
+   or perl first, so that changes in semantics can be easily
+   changed and discussed.  Many Git commands started out like
+   that, and a few are still scripts.
+
+ - Avoid introducing a new dependency into Git. This means you
+   usually should stay away from scripting languages not already
+   used in the Git core command set (unless your command is clearly
+   separate from it, such as an importer to convert random-scm-X
+   repositories to Git).
+
+ - When we pass <string, length> pair to functions, we should try to
+   pass them in that order.
+
+ - Use Git's gettext wrappers to make the user interface
+   translatable. See "Marking strings for translation" in po/README.
+
+ - Variables and functions local to a given source file should be marked
+   with "static". Variables that are visible to other source files
+   must be declared with "extern" in header files. However, function
+   declarations should not use "extern", as that is already the default.
+
+For Perl programs:
+
+ - Most of the C guidelines above apply.
+
+ - We try to support Perl 5.8 and later ("use Perl 5.008").
+
+ - use strict and use warnings are strongly preferred.
+
+ - Don't overuse statement modifiers unless using them makes the
+   result easier to follow.
+
+	... do something ...
+	do_this() unless (condition);
+        ... do something else ...
+
+   is more readable than:
+
+	... do something ...
+	unless (condition) {
+		do_this();
+	}
+        ... do something else ...
+
+   *only* when the condition is so rare that do_this() will be almost
+   always called.
+
+ - We try to avoid assignments inside "if ()" conditions.
+
+ - Learn and use Git.pm if you need that functionality.
+
+ - For Emacs, it's useful to put the following in
+   GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode:
+
+    ;; note the first part is useful for C editing, too
+    ((nil . ((indent-tabs-mode . t)
+                  (tab-width . 8)
+                  (fill-column . 80)))
+     (cperl-mode . ((cperl-indent-level . 8)
+                    (cperl-extra-newline-before-brace . nil)
+                    (cperl-merge-trailing-else . t))))
+
+For Python scripts:
+
+ - We follow PEP-8 (http://www.python.org/dev/peps/pep-0008/).
+
+ - As a minimum, we aim to be compatible with Python 2.6 and 2.7.
+
+ - Where required libraries do not restrict us to Python 2, we try to
+   also be compatible with Python 3.1 and later.
+
+ - When you must differentiate between Unicode literals and byte string
+   literals, it is OK to use the 'b' prefix.  Even though the Python
+   documentation for version 2.6 does not mention this prefix, it has
+   been supported since version 2.6.0.
+
+Error Messages
+
+ - Do not end error messages with a full stop.
+
+ - Do not capitalize ("unable to open %s", not "Unable to open %s")
+
+ - Say what the error is first ("cannot open %s", not "%s: cannot open")
+
+
+Externally Visible Names
+
+ - For configuration variable names, follow the existing convention:
+
+   . The section name indicates the affected subsystem.
+
+   . The subsection name, if any, indicates which of an unbounded set
+     of things to set the value for.
+
+   . The variable name describes the effect of tweaking this knob.
+
+   The section and variable names that consist of multiple words are
+   formed by concatenating the words without punctuations (e.g. `-`),
+   and are broken using bumpyCaps in documentation as a hint to the
+   reader.
+
+   When choosing the variable namespace, do not use variable name for
+   specifying possibly unbounded set of things, most notably anything
+   an end user can freely come up with (e.g. branch names).  Instead,
+   use subsection names or variable values, like the existing variable
+   branch.<name>.description does.
+
+
+Writing Documentation:
+
+ Most (if not all) of the documentation pages are written in the
+ AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+ processed into HTML and manpages (e.g. git.html and git.1 in the
+ same directory).
+
+ The documentation liberally mixes US and UK English (en_US/UK)
+ norms for spelling and grammar, which is somewhat unfortunate.
+ In an ideal world, it would have been better if it consistently
+ used only one and not the other, and we would have picked en_US
+ (if you wish to correct the English of some of the existing
+ documentation, please see the documentation-related advice in the
+ Documentation/SubmittingPatches file).
+
+ Every user-visible change should be reflected in the documentation.
+ The same general rule as for code applies -- imitate the existing
+ conventions.
+
+ A few commented examples follow to provide reference when writing or
+ modifying command usage strings and synopsis sections in the manual
+ pages:
+
+ Placeholders are spelled in lowercase and enclosed in angle brackets:
+   <file>
+   --sort=<key>
+   --abbrev[=<n>]
+
+ If a placeholder has multiple words, they are separated by dashes:
+   <new-branch-name>
+   --template=<template-directory>
+
+ Possibility of multiple occurrences is indicated by three dots:
+   <file>...
+   (One or more of <file>.)
+
+ Optional parts are enclosed in square brackets:
+   [<extra>]
+   (Zero or one <extra>.)
+
+   --exec-path[=<path>]
+   (Option with an optional argument.  Note that the "=" is inside the
+   brackets.)
+
+   [<patch>...]
+   (Zero or more of <patch>.  Note that the dots are inside, not
+   outside the brackets.)
+
+ Multiple alternatives are indicated with vertical bars:
+   [-q | --quiet]
+   [--utf8 | --no-utf8]
+
+ Parentheses are used for grouping:
+   [(<rev> | <range>)...]
+   (Any number of either <rev> or <range>.  Parens are needed to make
+   it clear that "..." pertains to both <rev> and <range>.)
+
+   [(-p <parent>)...]
+   (Any number of option -p, each with one <parent> argument.)
+
+   git remote set-head <name> (-a | -d | <branch>)
+   (One and only one of "-a", "-d" or "<branch>" _must_ (no square
+   brackets) be provided.)
+
+ And a somewhat more contrived example:
+   --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+   Here "=" is outside the brackets, because "--diff-filter=" is a
+   valid usage.  "*" has its own pair of brackets, because it can
+   (optionally) be specified only when one or more of the letters is
+   also provided.
+
+  A note on notation:
+   Use 'git' (all lowercase) when talking about commands i.e. something
+   the user would type into a shell and use 'Git' (uppercase first letter)
+   when talking about the version control system and its properties.
+
+ A few commented examples follow to provide reference when writing or
+ modifying paragraphs or option/command explanations that contain options
+ or commands:
+
+ Literal examples (e.g. use of command-line options, command names,
+ branch names, configuration and environment variables) must be
+ typeset in monospace (i.e. wrapped with backticks):
+   `--pretty=oneline`
+   `git rev-list`
+   `remote.pushDefault`
+   `GIT_DIR`
+   `HEAD`
+
+ An environment variable must be prefixed with "$" only when referring to its
+ value and not when referring to the variable itself, in this case there is
+ nothing to add except the backticks:
+   `GIT_DIR` is specified
+   `$GIT_DIR/hooks/pre-receive`
+
+ Word phrases enclosed in `backtick characters` are rendered literally
+ and will not be further expanded. The use of `backticks` to achieve the
+ previous rule means that literal examples should not use AsciiDoc
+ escapes.
+   Correct:
+      `--pretty=oneline`
+   Incorrect:
+      `\--pretty=oneline`
+
+ If some place in the documentation needs to typeset a command usage
+ example with inline substitutions, it is fine to use +monospaced and
+ inline substituted text+ instead of `monospaced literal text`, and with
+ the former, the part that should not get substituted must be
+ quoted/escaped.
diff --git a/external/docs/asciidoc/ff290873af26a1047e859571a8e319da8570a23c b/external/docs/asciidoc/ff290873af26a1047e859571a8e319da8570a23c
new file mode 100644
index 0000000000..2dd35bd1b8
--- /dev/null
+++ b/external/docs/asciidoc/ff290873af26a1047e859571a8e319da8570a23c
@@ -0,0 +1,535 @@
+Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, a few rough rules are:
+
+ - Most importantly, we never say "It's in POSIX; we'll happily
+   ignore your needs should your system not conform to it."
+   We live in the real world.
+
+ - However, we often say "Let's stay away from that construct,
+   it's not even in POSIX".
+
+ - In spite of the above two rules, we sometimes say "Although
+   this is not in POSIX, it (is so convenient | makes the code
+   much more readable | has other good characteristics) and
+   practically all the platforms we care about support it, so
+   let's use it".
+
+   Again, we live in the real world, and it is sometimes a
+   judgement call, the decision based more on real world
+   constraints people face than what the paper standard says.
+
+ - Fixing style violations while working on a real change as a
+   preparatory clean-up step is good, but otherwise avoid useless code
+   churn for the sake of conforming to the style.
+
+   "Once it _is_ in the tree, it's not really worth the patch noise to
+   go and fix it up."
+   Cf. http://article.gmane.org/gmane.linux.kernel/943020
+
+Make your code readable and sensible, and don't try to be clever.
+
+As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the _local_
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn't match the overall style of existing code).
+
+But if you must have a list of rules, here they are.
+
+For shell scripts specifically (not exhaustive):
+
+ - We use tabs for indentation.
+
+ - Case arms are indented at the same depth as case and esac lines,
+   like this:
+
+	case "$variable" in
+	pattern1)
+		do this
+		;;
+	pattern2)
+		do that
+		;;
+	esac
+
+ - Redirection operators should be written with space before, but no
+   space after them.  In other words, write 'echo test >"$file"'
+   instead of 'echo test> $file' or 'echo test > $file'.  Note that
+   even though it is not required by POSIX to double-quote the
+   redirection target in a variable (as shown above), our code does so
+   because some versions of bash issue a warning without the quotes.
+
+	(incorrect)
+	cat hello > world < universe
+	echo hello >$world
+
+	(correct)
+	cat hello >world <universe
+	echo hello >"$world"
+
+ - We prefer $( ... ) for command substitution; unlike ``, it
+   properly nests.  It should have been the way Bourne spelled
+   it from day one, but unfortunately isn't.
+
+ - If you want to find out if a command is available on the user's
+   $PATH, you should use 'type <command>', instead of 'which <command>'.
+   The output of 'which' is not machine parseable and its exit code
+   is not reliable across platforms.
+
+ - We use POSIX compliant parameter substitutions and avoid bashisms;
+   namely:
+
+   - We use ${parameter-word} and its [-=?+] siblings, and their
+     colon'ed "unset or null" form.
+
+   - We use ${parameter#word} and its [#%] siblings, and their
+     doubled "longest matching" form.
+
+   - No "Substring Expansion" ${parameter:offset:length}.
+
+   - No shell arrays.
+
+   - No strlen ${#parameter}.
+
+   - No pattern replacement ${parameter/pattern/string}.
+
+ - We use Arithmetic Expansion $(( ... )).
+
+ - Inside Arithmetic Expansion, spell shell variables with $ in front
+   of them, as some shells do not grok $((x)) while accepting $(($x))
+   just fine (e.g. dash older than 0.5.4).
+
+ - We do not use Process Substitution <(list) or >(list).
+
+ - Do not write control structures on a single line with semicolon.
+   "then" should be on the next line for if statements, and "do"
+   should be on the next line for "while" and "for".
+
+	(incorrect)
+	if test -f hello; then
+		do this
+	fi
+
+	(correct)
+	if test -f hello
+	then
+		do this
+	fi
+
+ - We prefer "test" over "[ ... ]".
+
+ - We do not write the noiseword "function" in front of shell
+   functions.
+
+ - We prefer a space between the function name and the parentheses,
+   and no space inside the parentheses. The opening "{" should also
+   be on the same line.
+
+	(incorrect)
+	my_function(){
+		...
+
+	(correct)
+	my_function () {
+		...
+
+ - As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+   [::], [==], or [..]) for portability.
+
+   - We do not use \{m,n\};
+
+   - We do not use -E;
+
+   - We do not use ? or + (which are \{0,1\} and \{1,\}
+     respectively in BRE) but that goes without saying as these
+     are ERE elements not BRE (note that \? and \+ are not even part
+     of BRE -- making them accessible from BRE is a GNU extension).
+
+ - Use Git's gettext wrappers in git-sh-i18n to make the user
+   interface translatable. See "Marking strings for translation" in
+   po/README.
+
+ - We do not write our "test" command with "-a" and "-o" and use "&&"
+   or "||" to concatenate multiple "test" commands instead, because
+   the use of "-a/-o" is often error-prone.  E.g.
+
+     test -n "$x" -a "$a" = "$b"
+
+   is buggy and breaks when $x is "=", but
+
+     test -n "$x" && test "$a" = "$b"
+
+   does not have such a problem.
+
+
+For C programs:
+
+ - We use tabs to indent, and interpret tabs as taking up to
+   8 spaces.
+
+ - We try to keep to at most 80 characters per line.
+
+ - We try to support a wide range of C compilers to compile Git with,
+   including old ones. That means that you should not use C99
+   initializers, even if a lot of compilers grok it.
+
+ - Variables have to be declared at the beginning of the block.
+
+ - NULL pointers shall be written as NULL, not as 0.
+
+ - When declaring pointers, the star sides with the variable
+   name, i.e. "char *string", not "char* string" or
+   "char * string".  This makes it easier to understand code
+   like "char *string, c;".
+
+ - Use whitespace around operators and keywords, but not inside
+   parentheses and not around functions. So:
+
+        while (condition)
+		func(bar + 1);
+
+   and not:
+
+        while( condition )
+		func (bar+1);
+
+ - We avoid using braces unnecessarily.  I.e.
+
+	if (bla) {
+		x = 1;
+	}
+
+   is frowned upon.  A gray area is when the statement extends
+   over a few lines, and/or you have a lengthy comment atop of
+   it.  Also, like in the Linux kernel, if there is a long list
+   of "else if" statements, it can make sense to add braces to
+   single line blocks.
+
+ - We try to avoid assignments in the condition of an "if" statement.
+
+ - Try to make your code understandable.  You may put comments
+   in, but comments invariably tend to stale out when the code
+   they were describing changes.  Often splitting a function
+   into two makes the intention of the code much clearer.
+
+ - Multi-line comments include their delimiters on separate lines from
+   the text.  E.g.
+
+	/*
+	 * A very long
+	 * multi-line comment.
+	 */
+
+   Note however that a comment that explains a translatable string to
+   translators uses a convention of starting with a magic token
+   "TRANSLATORS: " immediately after the opening delimiter, even when
+   it spans multiple lines.  We do not add an asterisk at the beginning
+   of each line, either.  E.g.
+
+	/* TRANSLATORS: here is a comment that explains the string
+	   to be translated, that follows immediately after it */
+	_("Here is a translatable string explained by the above.");
+
+ - Double negation is often harder to understand than no negation
+   at all.
+
+ - There are two schools of thought when it comes to comparison,
+   especially inside a loop. Some people prefer to have the less stable
+   value on the left hand side and the more stable value on the right hand
+   side, e.g. if you have a loop that counts variable i down to the
+   lower bound,
+
+	while (i > lower_bound) {
+		do something;
+		i--;
+	}
+
+   Other people prefer to have the textual order of values match the
+   actual order of values in their comparison, so that they can
+   mentally draw a number line from left to right and place these
+   values in order, i.e.
+
+	while (lower_bound < i) {
+		do something;
+		i--;
+	}
+
+   Both are valid, and we use both.  However, the more "stable" the
+   stable side becomes, the more we tend to prefer the former
+   (comparison with a constant, "i > 0", is an extreme example).
+   Just do not mix styles in the same part of the code and mimic
+   existing styles in the neighbourhood.
+
+ - There are two schools of thought when it comes to splitting a long
+   logical line into multiple lines.  Some people push the second and
+   subsequent lines far enough to the right with tabs and align them:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+		span_more_than_a_single_line_of ||
+		the_source_text) {
+                ...
+
+   while other people prefer to align the second and the subsequent
+   lines with the column immediately inside the opening parenthesis,
+   with tabs and spaces, following our "tabstop is always a multiple
+   of 8" convention:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of ||
+	    the_source_text) {
+                ...
+
+   Both are valid, and we use both.  Again, just do not mix styles in
+   the same part of the code and mimic existing styles in the
+   neighbourhood.
+
+ - When splitting a long logical line, some people change line before
+   a binary operator, so that the result looks like a parse tree when
+   you turn your head 90-degrees counterclockwise:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to
+	    || span_more_than_a_single_line_of_the_source_text) {
+
+   while other people prefer to leave the operator at the end of the
+   line:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of_the_source_text) {
+
+   Both are valid, but we tend to use the latter more, unless the
+   expression gets fairly complex, in which case the former tends to
+   be easier to read.  Again, just do not mix styles in the same part
+   of the code and mimic existing styles in the neighbourhood.
+
+ - When splitting a long logical line, with everything else being
+   equal, it is preferable to split after the operator at higher
+   level in the parse tree.  That is, this is more preferable:
+
+	if (a_very_long_variable * that_is_used_in +
+	    a_very_long_expression) {
+		...
+
+   than
+
+	if (a_very_long_variable *
+	    that_is_used_in + a_very_long_expression) {
+		...
+
+ - Some clever tricks, like using the !! operator with arithmetic
+   constructs, can be extremely confusing to others.  Avoid them,
+   unless there is a compelling reason to use them.
+
+ - Use the API.  No, really.  We have a strbuf (variable length
+   string), several arrays with the ALLOC_GROW() macro, a
+   string_list for sorted string lists, a hash map (mapping struct
+   objects) named "struct decorate", amongst other things.
+
+ - When you come up with an API, document it.
+
+ - The first #include in C files, except in platform specific
+   compat/ implementations, should be git-compat-util.h or another
+   header file that includes it, such as cache.h or builtin.h.
+
+ - If you are planning a new command, consider writing it in shell
+   or perl first, so that changes in semantics can be easily
+   changed and discussed.  Many Git commands started out like
+   that, and a few are still scripts.
+
+ - Avoid introducing a new dependency into Git. This means you
+   usually should stay away from scripting languages not already
+   used in the Git core command set (unless your command is clearly
+   separate from it, such as an importer to convert random-scm-X
+   repositories to Git).
+
+ - When we pass <string, length> pair to functions, we should try to
+   pass them in that order.
+
+ - Use Git's gettext wrappers to make the user interface
+   translatable. See "Marking strings for translation" in po/README.
+
+For Perl programs:
+
+ - Most of the C guidelines above apply.
+
+ - We try to support Perl 5.8 and later ("use Perl 5.008").
+
+ - use strict and use warnings are strongly preferred.
+
+ - Don't overuse statement modifiers unless using them makes the
+   result easier to follow.
+
+	... do something ...
+	do_this() unless (condition);
+        ... do something else ...
+
+   is more readable than:
+
+	... do something ...
+	unless (condition) {
+		do_this();
+	}
+        ... do something else ...
+
+   *only* when the condition is so rare that do_this() will be almost
+   always called.
+
+ - We try to avoid assignments inside "if ()" conditions.
+
+ - Learn and use Git.pm if you need that functionality.
+
+ - For Emacs, it's useful to put the following in
+   GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode:
+
+    ;; note the first part is useful for C editing, too
+    ((nil . ((indent-tabs-mode . t)
+                  (tab-width . 8)
+                  (fill-column . 80)))
+     (cperl-mode . ((cperl-indent-level . 8)
+                    (cperl-extra-newline-before-brace . nil)
+                    (cperl-merge-trailing-else . t))))
+
+For Python scripts:
+
+ - We follow PEP-8 (http://www.python.org/dev/peps/pep-0008/).
+
+ - As a minimum, we aim to be compatible with Python 2.6 and 2.7.
+
+ - Where required libraries do not restrict us to Python 2, we try to
+   also be compatible with Python 3.1 and later.
+
+ - When you must differentiate between Unicode literals and byte string
+   literals, it is OK to use the 'b' prefix.  Even though the Python
+   documentation for version 2.6 does not mention this prefix, it has
+   been supported since version 2.6.0.
+
+Error Messages
+
+ - Do not end error messages with a full stop.
+
+ - Do not capitalize ("unable to open %s", not "Unable to open %s")
+
+ - Say what the error is first ("cannot open %s", not "%s: cannot open")
+
+
+Externally Visible Names
+
+ - For configuration variable names, follow the existing convention:
+
+   . The section name indicates the affected subsystem.
+
+   . The subsection name, if any, indicates which of an unbounded set
+     of things to set the value for.
+
+   . The variable name describes the effect of tweaking this knob.
+
+   The section and variable names that consist of multiple words are
+   formed by concatenating the words without punctuations (e.g. `-`),
+   and are broken using bumpyCaps in documentation as a hint to the
+   reader.
+
+   When choosing the variable namespace, do not use variable name for
+   specifying possibly unbounded set of things, most notably anything
+   an end user can freely come up with (e.g. branch names).  Instead,
+   use subsection names or variable values, like the existing variable
+   branch.<name>.description does.
+
+
+Writing Documentation:
+
+ Most (if not all) of the documentation pages are written in the
+ AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+ processed into HTML and manpages (e.g. git.html and git.1 in the
+ same directory).
+
+ The documentation liberally mixes US and UK English (en_US/UK)
+ norms for spelling and grammar, which is somewhat unfortunate.
+ In an ideal world, it would have been better if it consistently
+ used only one and not the other, and we would have picked en_US
+ (if you wish to correct the English of some of the existing
+ documentation, please see the documentation-related advice in the
+ Documentation/SubmittingPatches file).
+
+ Every user-visible change should be reflected in the documentation.
+ The same general rule as for code applies -- imitate the existing
+ conventions.
+
+ A few commented examples follow to provide reference when writing or
+ modifying command usage strings and synopsis sections in the manual
+ pages:
+
+ Placeholders are spelled in lowercase and enclosed in angle brackets:
+   <file>
+   --sort=<key>
+   --abbrev[=<n>]
+
+ Possibility of multiple occurrences is indicated by three dots:
+   <file>...
+   (One or more of <file>.)
+
+ Optional parts are enclosed in square brackets:
+   [<extra>]
+   (Zero or one <extra>.)
+
+   --exec-path[=<path>]
+   (Option with an optional argument.  Note that the "=" is inside the
+   brackets.)
+
+   [<patch>...]
+   (Zero or more of <patch>.  Note that the dots are inside, not
+   outside the brackets.)
+
+ Multiple alternatives are indicated with vertical bar:
+   [-q | --quiet]
+   [--utf8 | --no-utf8]
+
+ Parentheses are used for grouping:
+   [(<rev>|<range>)...]
+   (Any number of either <rev> or <range>.  Parens are needed to make
+   it clear that "..." pertains to both <rev> and <range>.)
+
+   [(-p <parent>)...]
+   (Any number of option -p, each with one <parent> argument.)
+
+   git remote set-head <name> (-a | -d | <branch>)
+   (One and only one of "-a", "-d" or "<branch>" _must_ (no square
+   brackets) be provided.)
+
+ And a somewhat more contrived example:
+   --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+   Here "=" is outside the brackets, because "--diff-filter=" is a
+   valid usage.  "*" has its own pair of brackets, because it can
+   (optionally) be specified only when one or more of the letters is
+   also provided.
+
+  A note on notation:
+   Use 'git' (all lowercase) when talking about commands i.e. something
+   the user would type into a shell and use 'Git' (uppercase first letter)
+   when talking about the version control system and its properties.
+
+ A few commented examples follow to provide reference when writing or
+ modifying paragraphs or option/command explanations that contain options
+ or commands:
+
+ Literal examples (e.g. use of command-line options, command names, and
+ configuration variables) are typeset in monospace, and if you can use
+ `backticks around word phrases`, do so.
+   `--pretty=oneline`
+   `git rev-list`
+   `remote.pushdefault`
+
+ Word phrases enclosed in `backtick characters` are rendered literally
+ and will not be further expanded. The use of `backticks` to achieve the
+ previous rule means that literal examples should not use AsciiDoc
+ escapes.
+   Correct:
+      `--pretty=oneline`
+   Incorrect:
+      `\--pretty=oneline`
+
+ If some place in the documentation needs to typeset a command usage
+ example with inline substitutions, it is fine to use +monospaced and
+ inline substituted text+ instead of `monospaced literal text`, and with
+ the former, the part that should not get substituted must be
+ quoted/escaped.
diff --git a/external/docs/asciidoc/ff51a5c73ef7c16162ab8672c3649e5fd1f93607 b/external/docs/asciidoc/ff51a5c73ef7c16162ab8672c3649e5fd1f93607
new file mode 100644
index 0000000000..1d92b2da03
--- /dev/null
+++ b/external/docs/asciidoc/ff51a5c73ef7c16162ab8672c3649e5fd1f93607
@@ -0,0 +1,827 @@
+Like other projects, we also have some guidelines for our code.  For
+Git in general, a few rough rules are:
+
+ - Most importantly, we never say "It's in POSIX; we'll happily
+   ignore your needs should your system not conform to it."
+   We live in the real world.
+
+ - However, we often say "Let's stay away from that construct,
+   it's not even in POSIX".
+
+ - In spite of the above two rules, we sometimes say "Although
+   this is not in POSIX, it (is so convenient | makes the code
+   much more readable | has other good characteristics) and
+   practically all the platforms we care about support it, so
+   let's use it".
+
+   Again, we live in the real world, and it is sometimes a
+   judgement call, the decision based more on real world
+   constraints people face than what the paper standard says.
+
+ - Fixing style violations while working on a real change as a
+   preparatory clean-up step is good, but otherwise avoid useless code
+   churn for the sake of conforming to the style.
+
+   "Once it _is_ in the tree, it's not really worth the patch noise to
+   go and fix it up."
+   Cf. https://lore.kernel.org/all/20100126160632.3bdbe172.akpm@linux-foundation.org/
+
+ - Log messages to explain your changes are as important as the
+   changes themselves.  Clearly written code and in-code comments
+   explain how the code works and what is assumed from the surrounding
+   context.  The log messages explain what the changes wanted to
+   achieve and why the changes were necessary (more on this in the
+   accompanying SubmittingPatches document).
+
+Make your code readable and sensible, and don't try to be clever.
+
+As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the _local_
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code are expected to match the style the surrounding code already
+uses (even if it doesn't match the overall style of existing code).
+
+But if you must have a list of rules, here are some language
+specific ones. Note that Documentation/ToolsForGit.txt document
+has a collection of tips to help you use some external tools
+to conform to these guidelines.
+
+For shell scripts specifically (not exhaustive):
+
+ - We use tabs for indentation.
+
+ - Case arms are indented at the same depth as case and esac lines,
+   like this:
+
+	case "$variable" in
+	pattern1)
+		do this
+		;;
+	pattern2)
+		do that
+		;;
+	esac
+
+ - Redirection operators should be written with space before, but no
+   space after them.  In other words, write 'echo test >"$file"'
+   instead of 'echo test> $file' or 'echo test > $file'.  Note that
+   even though it is not required by POSIX to double-quote the
+   redirection target in a variable (as shown above), our code does so
+   because some versions of bash issue a warning without the quotes.
+
+	(incorrect)
+	cat hello > world < universe
+	echo hello >$world
+
+	(correct)
+	cat hello >world <universe
+	echo hello >"$world"
+
+ - We prefer $( ... ) for command substitution; unlike ``, it
+   properly nests.  It should have been the way Bourne spelled
+   it from day one, but unfortunately isn't.
+
+ - If you want to find out if a command is available on the user's
+   $PATH, you should use 'type <command>', instead of 'which <command>'.
+   The output of 'which' is not machine parsable and its exit code
+   is not reliable across platforms.
+
+ - We use POSIX compliant parameter substitutions and avoid bashisms;
+   namely:
+
+   - We use ${parameter-word} and its [-=?+] siblings, and their
+     colon'ed "unset or null" form.
+
+   - We use ${parameter#word} and its [#%] siblings, and their
+     doubled "longest matching" form.
+
+   - No "Substring Expansion" ${parameter:offset:length}.
+
+   - No shell arrays.
+
+   - No pattern replacement ${parameter/pattern/string}.
+
+ - We use Arithmetic Expansion $(( ... )).
+
+ - We do not use Process Substitution <(list) or >(list).
+
+ - Do not write control structures on a single line with semicolon.
+   "then" should be on the next line for if statements, and "do"
+   should be on the next line for "while" and "for".
+
+	(incorrect)
+	if test -f hello; then
+		do this
+	fi
+
+	(correct)
+	if test -f hello
+	then
+		do this
+	fi
+
+ - If a command sequence joined with && or || or | spans multiple
+   lines, put each command on a separate line and put && and || and |
+   operators at the end of each line, rather than the start. This
+   means you don't need to use \ to join lines, since the above
+   operators imply the sequence isn't finished.
+
+	(incorrect)
+	grep blob verify_pack_result \
+	| awk -f print_1.awk \
+	| sort >actual &&
+	...
+
+	(correct)
+	grep blob verify_pack_result |
+	awk -f print_1.awk |
+	sort >actual &&
+	...
+
+ - We prefer "test" over "[ ... ]".
+
+ - We do not write the noiseword "function" in front of shell
+   functions.
+
+ - We prefer a space between the function name and the parentheses,
+   and no space inside the parentheses. The opening "{" should also
+   be on the same line.
+
+	(incorrect)
+	my_function(){
+		...
+
+	(correct)
+	my_function () {
+		...
+
+ - As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+   [::], [==], or [..]) for portability.
+
+   - We do not use \{m,n\};
+
+   - We do not use ? or + (which are \{0,1\} and \{1,\}
+     respectively in BRE) but that goes without saying as these
+     are ERE elements not BRE (note that \? and \+ are not even part
+     of BRE -- making them accessible from BRE is a GNU extension).
+
+ - Use Git's gettext wrappers in git-sh-i18n to make the user
+   interface translatable. See "Marking strings for translation" in
+   po/README.
+
+ - We do not write our "test" command with "-a" and "-o" and use "&&"
+   or "||" to concatenate multiple "test" commands instead, because
+   the use of "-a/-o" is often error-prone.  E.g.
+
+     test -n "$x" -a "$a" = "$b"
+
+   is buggy and breaks when $x is "=", but
+
+     test -n "$x" && test "$a" = "$b"
+
+   does not have such a problem.
+
+ - Even though "local" is not part of POSIX, we make heavy use of it
+   in our test suite.  We do not use it in scripted Porcelains, and
+   hopefully nobody starts using "local" before they are reimplemented
+   in C ;-)
+
+ - Some versions of shell do not understand "export variable=value",
+   so we write "variable=value" and then "export variable" on two
+   separate lines.
+
+ - Some versions of dash have broken variable assignment when prefixed
+   with "local", "export", and "readonly", in that the value to be
+   assigned goes through field splitting at $IFS unless quoted.
+
+	(incorrect)
+	local variable=$value
+	local variable=$(command args)
+
+	(correct)
+	local variable="$value"
+	local variable="$(command args)"
+
+ - Use octal escape sequences (e.g. "\302\242"), not hexadecimal (e.g.
+   "\xc2\xa2") in printf format strings, since hexadecimal escape
+   sequences are not portable.
+
+
+For C programs:
+
+ - We use tabs to indent, and interpret tabs as taking up to
+   8 spaces.
+
+ - We try to keep to at most 80 characters per line.
+
+ - As a Git developer we assume you have a reasonably modern compiler
+   and we recommend you to enable the DEVELOPER makefile knob to
+   ensure your patch is clear of all compiler warnings we care about,
+   by e.g. "echo DEVELOPER=1 >>config.mak".
+
+ - We try to support a wide range of C compilers to compile Git with,
+   including old ones.  As of Git v2.35.0 Git requires C99 (we check
+   "__STDC_VERSION__"). You should not use features from a newer C
+   standard, even if your compiler groks them.
+
+   New C99 features have been phased in gradually, if something's new
+   in C99 but not used yet don't assume that it's safe to use, some
+   compilers we target have only partial support for it. These are
+   considered safe to use:
+
+   . since around 2007 with 2b6854c863a, we have been using
+     initializer elements which are not computable at load time. E.g.:
+
+	const char *args[] = {"constant", variable, NULL};
+
+   . since early 2012 with e1327023ea, we have been using an enum
+     definition whose last element is followed by a comma.  This, like
+     an array initializer that ends with a trailing comma, can be used
+     to reduce the patch noise when adding a new identifier at the end.
+
+   . since mid 2017 with cbc0f81d, we have been using designated
+     initializers for struct (e.g. "struct t v = { .val = 'a' };").
+
+   . since mid 2017 with 512f41cf, we have been using designated
+     initializers for array (e.g. "int array[10] = { [5] = 2 }").
+
+   . since early 2021 with 765dc168882, we have been using variadic
+     macros, mostly for printf-like trace and debug macros.
+
+   . since late 2021 with 44ba10d6, we have had variables declared in
+     the for loop "for (int i = 0; i < 10; i++)".
+
+   New C99 features that we cannot use yet:
+
+   . %z and %zu as a printf() argument for a size_t (the %z being for
+     the POSIX-specific ssize_t). Instead you should use
+     printf("%"PRIuMAX, (uintmax_t)v).  These days the MSVC version we
+     rely on supports %z, but the C library used by MinGW does not.
+
+   . Shorthand like ".a.b = *c" in struct initializations is known to
+     trip up an older IBM XLC version, use ".a = { .b = *c }" instead.
+     See the 33665d98 (reftable: make assignments portable to AIX xlc
+     v12.01, 2022-03-28).
+
+ - Variables have to be declared at the beginning of the block, before
+   the first statement (i.e. -Wdeclaration-after-statement).
+
+ - NULL pointers shall be written as NULL, not as 0.
+
+ - When declaring pointers, the star sides with the variable
+   name, i.e. "char *string", not "char* string" or
+   "char * string".  This makes it easier to understand code
+   like "char *string, c;".
+
+ - Use whitespace around operators and keywords, but not inside
+   parentheses and not around functions. So:
+
+        while (condition)
+		func(bar + 1);
+
+   and not:
+
+        while( condition )
+		func (bar+1);
+
+ - Do not explicitly compare an integral value with constant 0 or '\0',
+   or a pointer value with constant NULL.  For instance, to validate that
+   counted array <ptr, cnt> is initialized but has no elements, write:
+
+	if (!ptr || cnt)
+		BUG("empty array expected");
+
+   and not:
+
+	if (ptr == NULL || cnt != 0);
+		BUG("empty array expected");
+
+ - We avoid using braces unnecessarily.  I.e.
+
+	if (bla) {
+		x = 1;
+	}
+
+   is frowned upon. But there are a few exceptions:
+
+	- When the statement extends over a few lines (e.g., a while loop
+	  with an embedded conditional, or a comment). E.g.:
+
+		while (foo) {
+			if (x)
+				one();
+			else
+				two();
+		}
+
+		if (foo) {
+			/*
+			 * This one requires some explanation,
+			 * so we're better off with braces to make
+			 * it obvious that the indentation is correct.
+			 */
+			doit();
+		}
+
+	- When there are multiple arms to a conditional and some of them
+	  require braces, enclose even a single line block in braces for
+	  consistency. E.g.:
+
+		if (foo) {
+			doit();
+		} else {
+			one();
+			two();
+			three();
+		}
+
+ - We try to avoid assignments in the condition of an "if" statement.
+
+ - Try to make your code understandable.  You may put comments
+   in, but comments invariably tend to stale out when the code
+   they were describing changes.  Often splitting a function
+   into two makes the intention of the code much clearer.
+
+ - Multi-line comments include their delimiters on separate lines from
+   the text.  E.g.
+
+	/*
+	 * A very long
+	 * multi-line comment.
+	 */
+
+   Note however that a comment that explains a translatable string to
+   translators uses a convention of starting with a magic token
+   "TRANSLATORS: ", e.g.
+
+	/*
+	 * TRANSLATORS: here is a comment that explains the string to
+	 * be translated, that follows immediately after it.
+	 */
+	_("Here is a translatable string explained by the above.");
+
+ - Double negation is often harder to understand than no negation
+   at all.
+
+ - There are two schools of thought when it comes to comparison,
+   especially inside a loop. Some people prefer to have the less stable
+   value on the left hand side and the more stable value on the right hand
+   side, e.g. if you have a loop that counts variable i down to the
+   lower bound,
+
+	while (i > lower_bound) {
+		do something;
+		i--;
+	}
+
+   Other people prefer to have the textual order of values match the
+   actual order of values in their comparison, so that they can
+   mentally draw a number line from left to right and place these
+   values in order, i.e.
+
+	while (lower_bound < i) {
+		do something;
+		i--;
+	}
+
+   Both are valid, and we use both.  However, the more "stable" the
+   stable side becomes, the more we tend to prefer the former
+   (comparison with a constant, "i > 0", is an extreme example).
+   Just do not mix styles in the same part of the code and mimic
+   existing styles in the neighbourhood.
+
+ - There are two schools of thought when it comes to splitting a long
+   logical line into multiple lines.  Some people push the second and
+   subsequent lines far enough to the right with tabs and align them:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+		span_more_than_a_single_line_of ||
+		the_source_text) {
+                ...
+
+   while other people prefer to align the second and the subsequent
+   lines with the column immediately inside the opening parenthesis,
+   with tabs and spaces, following our "tabstop is always a multiple
+   of 8" convention:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of ||
+	    the_source_text) {
+                ...
+
+   Both are valid, and we use both.  Again, just do not mix styles in
+   the same part of the code and mimic existing styles in the
+   neighbourhood.
+
+ - When splitting a long logical line, some people change line before
+   a binary operator, so that the result looks like a parse tree when
+   you turn your head 90-degrees counterclockwise:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to
+	    || span_more_than_a_single_line_of_the_source_text) {
+
+   while other people prefer to leave the operator at the end of the
+   line:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of_the_source_text) {
+
+   Both are valid, but we tend to use the latter more, unless the
+   expression gets fairly complex, in which case the former tends to
+   be easier to read.  Again, just do not mix styles in the same part
+   of the code and mimic existing styles in the neighbourhood.
+
+ - When splitting a long logical line, with everything else being
+   equal, it is preferable to split after the operator at higher
+   level in the parse tree.  That is, this is more preferable:
+
+	if (a_very_long_variable * that_is_used_in +
+	    a_very_long_expression) {
+		...
+
+   than
+
+	if (a_very_long_variable *
+	    that_is_used_in + a_very_long_expression) {
+		...
+
+ - Some clever tricks, like using the !! operator with arithmetic
+   constructs, can be extremely confusing to others.  Avoid them,
+   unless there is a compelling reason to use them.
+
+ - Use the API.  No, really.  We have a strbuf (variable length
+   string), several arrays with the ALLOC_GROW() macro, a
+   string_list for sorted string lists, a hash map (mapping struct
+   objects) named "struct decorate", amongst other things.
+
+ - When you come up with an API, document its functions and structures
+   in the header file that exposes the API to its callers. Use what is
+   in "strbuf.h" as a model for the appropriate tone and level of
+   detail.
+
+ - The first #include in C files, except in platform specific compat/
+   implementations and sha1dc/, must be <git-compat-util.h>.  This
+   header file insulates other header files and source files from
+   platform differences, like which system header files must be
+   included in what order, and what C preprocessor feature macros must
+   be defined to trigger certain features we expect out of the system.
+   A collorary to this is that C files should not directly include
+   system header files themselves.
+
+   There are some exceptions, because certain group of files that
+   implement an API all have to include the same header file that
+   defines the API and it is convenient to include <git-compat-util.h>
+   there.  Namely:
+
+   - the implementation of the built-in commands in the "builtin/"
+     directory that include "builtin.h" for the cmd_foo() prototype
+     definition,
+
+   - the test helper programs in the "t/helper/" directory that include
+     "t/helper/test-tool.h" for the cmd__foo() prototype definition,
+
+   - the xdiff implementation in the "xdiff/" directory that includes
+     "xdiff/xinclude.h" for the xdiff machinery internals,
+
+   - the unit test programs in "t/unit-tests/" directory that include
+     "t/unit-tests/test-lib.h" that gives them the unit-tests
+     framework, and
+
+   - the source files that implement reftable in the "reftable/"
+     directory that include "reftable/system.h" for the reftable
+     internals,
+
+   are allowed to assume that they do not have to include
+   <git-compat-util.h> themselves, as it is included as the first
+   '#include' in these header files.  These headers must be the first
+   header file to be "#include"d in them, though.
+
+ - A C file must directly include the header files that declare the
+   functions and the types it uses, except for the functions and types
+   that are made available to it by including one of the header files
+   it must include by the previous rule.
+
+ - If you are planning a new command, consider writing it in shell
+   or perl first, so that changes in semantics can be easily
+   changed and discussed.  Many Git commands started out like
+   that, and a few are still scripts.
+
+ - Avoid introducing a new dependency into Git. This means you
+   usually should stay away from scripting languages not already
+   used in the Git core command set (unless your command is clearly
+   separate from it, such as an importer to convert random-scm-X
+   repositories to Git).
+
+ - When we pass <string, length> pair to functions, we should try to
+   pass them in that order.
+
+ - Use Git's gettext wrappers to make the user interface
+   translatable. See "Marking strings for translation" in po/README.
+
+ - Variables and functions local to a given source file should be marked
+   with "static". Variables that are visible to other source files
+   must be declared with "extern" in header files. However, function
+   declarations should not use "extern", as that is already the default.
+
+ - You can launch gdb around your program using the shorthand GIT_DEBUGGER.
+   Run `GIT_DEBUGGER=1 ./bin-wrappers/git foo` to simply use gdb as is, or
+   run `GIT_DEBUGGER="<debugger> <debugger-args>" ./bin-wrappers/git foo` to
+   use your own debugger and arguments. Example: `GIT_DEBUGGER="ddd --gdb"
+   ./bin-wrappers/git log` (See `wrap-for-bin.sh`.)
+
+For Perl programs:
+
+ - Most of the C guidelines above apply.
+
+ - We try to support Perl 5.8.1 and later ("use Perl 5.008001").
+
+ - use strict and use warnings are strongly preferred.
+
+ - Don't overuse statement modifiers unless using them makes the
+   result easier to follow.
+
+	... do something ...
+	do_this() unless (condition);
+        ... do something else ...
+
+   is more readable than:
+
+	... do something ...
+	unless (condition) {
+		do_this();
+	}
+        ... do something else ...
+
+   *only* when the condition is so rare that do_this() will be almost
+   always called.
+
+ - We try to avoid assignments inside "if ()" conditions.
+
+ - Learn and use Git.pm if you need that functionality.
+
+For Python scripts:
+
+ - We follow PEP-8 (https://peps.python.org/pep-0008/).
+
+ - As a minimum, we aim to be compatible with Python 2.7.
+
+ - Where required libraries do not restrict us to Python 2, we try to
+   also be compatible with Python 3.1 and later.
+
+
+Program Output
+
+ We make a distinction between a Git command's primary output and
+ output which is merely chatty feedback (for instance, status
+ messages, running transcript, or progress display), as well as error
+ messages. Roughly speaking, a Git command's primary output is that
+ which one might want to capture to a file or send down a pipe; its
+ chatty output should not interfere with these use-cases.
+
+ As such, primary output should be sent to the standard output stream
+ (stdout), and chatty output should be sent to the standard error
+ stream (stderr). Examples of commands which produce primary output
+ include `git log`, `git show`, and `git branch --list` which generate
+ output on the stdout stream.
+
+ Not all Git commands have primary output; this is often true of
+ commands whose main function is to perform an action. Some action
+ commands are silent, whereas others are chatty. An example of a
+ chatty action commands is `git clone` with its "Cloning into
+ '<path>'..." and "Checking connectivity..." status messages which it
+ sends to the stderr stream.
+
+ Error messages from Git commands should always be sent to the stderr
+ stream.
+
+
+Error Messages
+
+ - Do not end error messages with a full stop.
+
+ - Do not capitalize the first word, only because it is the first word
+   in the message ("unable to open %s", not "Unable to open %s").  But
+   "SHA-3 not supported" is fine, because the reason the first word is
+   capitalized is not because it is at the beginning of the sentence,
+   but because the word would be spelled in capital letters even when
+   it appeared in the middle of the sentence.
+
+ - Say what the error is first ("cannot open %s", not "%s: cannot open")
+
+
+Externally Visible Names
+
+ - For configuration variable names, follow the existing convention:
+
+   . The section name indicates the affected subsystem.
+
+   . The subsection name, if any, indicates which of an unbounded set
+     of things to set the value for.
+
+   . The variable name describes the effect of tweaking this knob.
+
+   The section and variable names that consist of multiple words are
+   formed by concatenating the words without punctuation marks (e.g. `-`),
+   and are broken using bumpyCaps in documentation as a hint to the
+   reader.
+
+   When choosing the variable namespace, do not use variable name for
+   specifying possibly unbounded set of things, most notably anything
+   an end user can freely come up with (e.g. branch names).  Instead,
+   use subsection names or variable values, like the existing variable
+   branch.<name>.description does.
+
+
+Writing Documentation:
+
+ Most (if not all) of the documentation pages are written in the
+ AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+ processed into HTML and manpages (e.g. git.html and git.1 in the
+ same directory).
+
+ The documentation liberally mixes US and UK English (en_US/UK)
+ norms for spelling and grammar, which is somewhat unfortunate.
+ In an ideal world, it would have been better if it consistently
+ used only one and not the other, and we would have picked en_US
+ (if you wish to correct the English of some of the existing
+ documentation, please see the documentation-related advice in the
+ Documentation/SubmittingPatches file).
+
+ In order to ensure the documentation is inclusive, avoid assuming
+ that an unspecified example person is male or female, and think
+ twice before using "he", "him", "she", or "her".  Here are some
+ tips to avoid use of gendered pronouns:
+
+  - Prefer succinctness and matter-of-factly describing functionality
+    in the abstract.  E.g.
+
+     `--short`:: Emit output in the short-format.
+
+    and avoid something like these overly verbose alternatives:
+
+     `--short`:: Use this to emit output in the short-format.
+     `--short`:: You can use this to get output in the short-format.
+     `--short`:: A user who prefers shorter output could....
+     `--short`:: Should a person and/or program want shorter output, he
+                 she/they/it can...
+
+    This practice often eliminates the need to involve human actors in
+    your description, but it is a good practice regardless of the
+    avoidance of gendered pronouns.
+
+  - When it becomes awkward to stick to this style, prefer "you" when
+    addressing the hypothetical user, and possibly "we" when
+    discussing how the program might react to the user.  E.g.
+
+      You can use this option instead of `--xyz`, but we might remove
+      support for it in future versions.
+
+    while keeping in mind that you can probably be less verbose, e.g.
+
+      Use this instead of `--xyz`. This option might be removed in future
+      versions.
+
+  - If you still need to refer to an example person that is
+    third-person singular, you may resort to "singular they" to avoid
+    "he/she/him/her", e.g.
+
+      A contributor asks their upstream to pull from them.
+
+    Note that this sounds ungrammatical and unnatural to those who
+    learned that "they" is only used for third-person plural, e.g.
+    those who learn English as a second language in some parts of the
+    world.
+
+ Every user-visible change should be reflected in the documentation.
+ The same general rule as for code applies -- imitate the existing
+ conventions.
+
+
+Markup:
+
+ Literal parts (e.g. use of command-line options, command names,
+ branch names, URLs, pathnames (files and directories), configuration and
+ environment variables) must be typeset as verbatim (i.e. wrapped with
+ backticks):
+   `--pretty=oneline`
+   `git rev-list`
+   `remote.pushDefault`
+   `http://git.example.com`
+   `.git/config`
+   `GIT_DIR`
+   `HEAD`
+   `umask`(2)
+
+ An environment variable must be prefixed with "$" only when referring to its
+ value and not when referring to the variable itself, in this case there is
+ nothing to add except the backticks:
+   `GIT_DIR` is specified
+   `$GIT_DIR/hooks/pre-receive`
+
+ Word phrases enclosed in `backtick characters` are rendered literally
+ and will not be further expanded. The use of `backticks` to achieve the
+ previous rule means that literal examples should not use AsciiDoc
+ escapes.
+   Correct:
+      `--pretty=oneline`
+   Incorrect:
+      `\--pretty=oneline`
+
+ Placeholders are spelled in lowercase and enclosed in
+ angle brackets surrounded by underscores:
+   _<file>_
+   _<commit>_
+
+ If a placeholder has multiple words, they are separated by dashes:
+   _<new-branch-name>_
+   _<template-directory>_
+
+ A placeholder is not enclosed in backticks, as it is not a literal.
+
+ When needed, use a distinctive identifier for placeholders, usually
+ made of a qualification and a type:
+   _<git-dir>_
+   _<key-id>_
+
+ When literal and placeholders are mixed, each markup is applied for
+ each sub-entity. If they are stuck, a special markup, called
+ unconstrained formatting is required.
+ Unconstrained formating for placeholders is __<like-this>__
+ Unconstrained formatting for literal formatting is ++like this++
+   `--jobs` _<n>_
+   ++--sort=++__<key>__
+   __<directory>__++/.git++
+   ++remote.++__<name>__++.mirror++
+
+ caveat: ++ unconstrained format is not verbatim and may expand
+ content. Use Asciidoc escapes inside them.
+
+Synopsis Syntax
+
+ Syntax grammar is formatted neither as literal nor as placeholder.
+
+ A few commented examples follow to provide reference when writing or
+ modifying command usage strings and synopsis sections in the manual
+ pages:
+
+ Possibility of multiple occurrences is indicated by three dots:
+   _<file>_...
+   (One or more of <file>.)
+
+ Optional parts are enclosed in square brackets:
+   [_<file>_...]
+   (Zero or more of <file>.)
+
+   ++--exec-path++[++=++__<path>__]
+   (Option with an optional argument.  Note that the "=" is inside the
+   brackets.)
+
+   [_<patch>_...]
+   (Zero or more of <patch>.  Note that the dots are inside, not
+   outside the brackets.)
+
+ Multiple alternatives are indicated with vertical bars:
+   [`-q` | `--quiet`]
+   [`--utf8` | `--no-utf8`]
+
+ Use spacing around "|" token(s), but not immediately after opening or
+ before closing a [] or () pair:
+   Do: [`-q` | `--quiet`]
+   Don't: [`-q`|`--quiet`]
+
+ Don't use spacing around "|" tokens when they're used to separate the
+ alternate arguments of an option:
+    Do: ++--track++[++=++(`direct`|`inherit`)]`
+    Don't: ++--track++[++=++(`direct` | `inherit`)]
+
+ Parentheses are used for grouping:
+   [(_<rev>_ | _<range>_)...]
+   (Any number of either <rev> or <range>.  Parens are needed to make
+   it clear that "..." pertains to both <rev> and <range>.)
+
+   [(`-p` _<parent>_)...]
+   (Any number of option -p, each with one <parent> argument.)
+
+   `git remote set-head` _<name>_ (`-a` | `-d` | _<branch>_)
+   (One and only one of "-a", "-d" or "<branch>" _must_ (no square
+   brackets) be provided.)
+
+ And a somewhat more contrived example:
+   `--diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]`
+   Here "=" is outside the brackets, because "--diff-filter=" is a
+   valid usage.  "*" has its own pair of brackets, because it can
+   (optionally) be specified only when one or more of the letters is
+   also provided.
+
+  A note on notation:
+   Use 'git' (all lowercase) when talking about commands i.e. something
+   the user would type into a shell and use 'Git' (uppercase first letter)
+   when talking about the version control system and its properties.
+
+ If some place in the documentation needs to typeset a command usage
+ example with inline substitutions, it is fine to use +monospaced and
+ inline substituted text+ instead of `monospaced literal text`, and with
+ the former, the part that should not get substituted must be
+ quoted/escaped.
diff --git a/external/docs/asciidoc/ff58baf57350f365f22ec5f7ce1e0cf50351359b b/external/docs/asciidoc/ff58baf57350f365f22ec5f7ce1e0cf50351359b
new file mode 100644
index 0000000000..ed4e443a3c
--- /dev/null
+++ b/external/docs/asciidoc/ff58baf57350f365f22ec5f7ce1e0cf50351359b
@@ -0,0 +1,639 @@
+Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, a few rough rules are:
+
+ - Most importantly, we never say "It's in POSIX; we'll happily
+   ignore your needs should your system not conform to it."
+   We live in the real world.
+
+ - However, we often say "Let's stay away from that construct,
+   it's not even in POSIX".
+
+ - In spite of the above two rules, we sometimes say "Although
+   this is not in POSIX, it (is so convenient | makes the code
+   much more readable | has other good characteristics) and
+   practically all the platforms we care about support it, so
+   let's use it".
+
+   Again, we live in the real world, and it is sometimes a
+   judgement call, the decision based more on real world
+   constraints people face than what the paper standard says.
+
+ - Fixing style violations while working on a real change as a
+   preparatory clean-up step is good, but otherwise avoid useless code
+   churn for the sake of conforming to the style.
+
+   "Once it _is_ in the tree, it's not really worth the patch noise to
+   go and fix it up."
+   Cf. http://lkml.iu.edu/hypermail/linux/kernel/1001.3/01069.html
+
+Make your code readable and sensible, and don't try to be clever.
+
+As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the _local_
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn't match the overall style of existing code).
+
+But if you must have a list of rules, here they are.
+
+For shell scripts specifically (not exhaustive):
+
+ - We use tabs for indentation.
+
+ - Case arms are indented at the same depth as case and esac lines,
+   like this:
+
+	case "$variable" in
+	pattern1)
+		do this
+		;;
+	pattern2)
+		do that
+		;;
+	esac
+
+ - Redirection operators should be written with space before, but no
+   space after them.  In other words, write 'echo test >"$file"'
+   instead of 'echo test> $file' or 'echo test > $file'.  Note that
+   even though it is not required by POSIX to double-quote the
+   redirection target in a variable (as shown above), our code does so
+   because some versions of bash issue a warning without the quotes.
+
+	(incorrect)
+	cat hello > world < universe
+	echo hello >$world
+
+	(correct)
+	cat hello >world <universe
+	echo hello >"$world"
+
+ - We prefer $( ... ) for command substitution; unlike ``, it
+   properly nests.  It should have been the way Bourne spelled
+   it from day one, but unfortunately isn't.
+
+ - If you want to find out if a command is available on the user's
+   $PATH, you should use 'type <command>', instead of 'which <command>'.
+   The output of 'which' is not machine parsable and its exit code
+   is not reliable across platforms.
+
+ - We use POSIX compliant parameter substitutions and avoid bashisms;
+   namely:
+
+   - We use ${parameter-word} and its [-=?+] siblings, and their
+     colon'ed "unset or null" form.
+
+   - We use ${parameter#word} and its [#%] siblings, and their
+     doubled "longest matching" form.
+
+   - No "Substring Expansion" ${parameter:offset:length}.
+
+   - No shell arrays.
+
+   - No strlen ${#parameter}.
+
+   - No pattern replacement ${parameter/pattern/string}.
+
+ - We use Arithmetic Expansion $(( ... )).
+
+ - Inside Arithmetic Expansion, spell shell variables with $ in front
+   of them, as some shells do not grok $((x)) while accepting $(($x))
+   just fine (e.g. dash older than 0.5.4).
+
+ - We do not use Process Substitution <(list) or >(list).
+
+ - Do not write control structures on a single line with semicolon.
+   "then" should be on the next line for if statements, and "do"
+   should be on the next line for "while" and "for".
+
+	(incorrect)
+	if test -f hello; then
+		do this
+	fi
+
+	(correct)
+	if test -f hello
+	then
+		do this
+	fi
+
+ - If a command sequence joined with && or || or | spans multiple
+   lines, put each command on a separate line and put && and || and |
+   operators at the end of each line, rather than the start. This
+   means you don't need to use \ to join lines, since the above
+   operators imply the sequence isn't finished.
+
+	(incorrect)
+	grep blob verify_pack_result \
+	| awk -f print_1.awk \
+	| sort >actual &&
+	...
+
+	(correct)
+	grep blob verify_pack_result |
+	awk -f print_1.awk |
+	sort >actual &&
+	...
+
+ - We prefer "test" over "[ ... ]".
+
+ - We do not write the noiseword "function" in front of shell
+   functions.
+
+ - We prefer a space between the function name and the parentheses,
+   and no space inside the parentheses. The opening "{" should also
+   be on the same line.
+
+	(incorrect)
+	my_function(){
+		...
+
+	(correct)
+	my_function () {
+		...
+
+ - As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+   [::], [==], or [..]) for portability.
+
+   - We do not use \{m,n\};
+
+   - We do not use -E;
+
+   - We do not use ? or + (which are \{0,1\} and \{1,\}
+     respectively in BRE) but that goes without saying as these
+     are ERE elements not BRE (note that \? and \+ are not even part
+     of BRE -- making them accessible from BRE is a GNU extension).
+
+ - Use Git's gettext wrappers in git-sh-i18n to make the user
+   interface translatable. See "Marking strings for translation" in
+   po/README.
+
+ - We do not write our "test" command with "-a" and "-o" and use "&&"
+   or "||" to concatenate multiple "test" commands instead, because
+   the use of "-a/-o" is often error-prone.  E.g.
+
+     test -n "$x" -a "$a" = "$b"
+
+   is buggy and breaks when $x is "=", but
+
+     test -n "$x" && test "$a" = "$b"
+
+   does not have such a problem.
+
+
+For C programs:
+
+ - We use tabs to indent, and interpret tabs as taking up to
+   8 spaces.
+
+ - We try to keep to at most 80 characters per line.
+
+ - As a Git developer we assume you have a reasonably modern compiler
+   and we recommend you to enable the DEVELOPER makefile knob to
+   ensure your patch is clear of all compiler warnings we care about,
+   by e.g. "echo DEVELOPER=1 >>config.mak".
+
+ - We try to support a wide range of C compilers to compile Git with,
+   including old ones.  You should not use features from newer C
+   standard, even if your compiler groks them.
+
+   There are a few exceptions to this guideline:
+
+   . since early 2012 with e1327023ea, we have been using an enum
+     definition whose last element is followed by a comma.  This, like
+     an array initializer that ends with a trailing comma, can be used
+     to reduce the patch noise when adding a new identifier at the end.
+
+   . since mid 2017 with cbc0f81d, we have been using designated
+     initializers for struct (e.g. "struct t v = { .val = 'a' };").
+
+   . since mid 2017 with 512f41cf, we have been using designated
+     initializers for array (e.g. "int array[10] = { [5] = 2 }").
+
+   These used to be forbidden, but we have not heard any breakage
+   report, and they are assumed to be safe.
+
+ - Variables have to be declared at the beginning of the block, before
+   the first statement (i.e. -Wdeclaration-after-statement).
+
+ - Declaring a variable in the for loop "for (int i = 0; i < 10; i++)"
+   is still not allowed in this codebase.
+
+ - NULL pointers shall be written as NULL, not as 0.
+
+ - When declaring pointers, the star sides with the variable
+   name, i.e. "char *string", not "char* string" or
+   "char * string".  This makes it easier to understand code
+   like "char *string, c;".
+
+ - Use whitespace around operators and keywords, but not inside
+   parentheses and not around functions. So:
+
+        while (condition)
+		func(bar + 1);
+
+   and not:
+
+        while( condition )
+		func (bar+1);
+
+ - We avoid using braces unnecessarily.  I.e.
+
+	if (bla) {
+		x = 1;
+	}
+
+   is frowned upon. But there are a few exceptions:
+
+	- When the statement extends over a few lines (e.g., a while loop
+	  with an embedded conditional, or a comment). E.g.:
+
+		while (foo) {
+			if (x)
+				one();
+			else
+				two();
+		}
+
+		if (foo) {
+			/*
+			 * This one requires some explanation,
+			 * so we're better off with braces to make
+			 * it obvious that the indentation is correct.
+			 */
+			doit();
+		}
+
+	- When there are multiple arms to a conditional and some of them
+	  require braces, enclose even a single line block in braces for
+	  consistency. E.g.:
+
+		if (foo) {
+			doit();
+		} else {
+			one();
+			two();
+			three();
+		}
+
+ - We try to avoid assignments in the condition of an "if" statement.
+
+ - Try to make your code understandable.  You may put comments
+   in, but comments invariably tend to stale out when the code
+   they were describing changes.  Often splitting a function
+   into two makes the intention of the code much clearer.
+
+ - Multi-line comments include their delimiters on separate lines from
+   the text.  E.g.
+
+	/*
+	 * A very long
+	 * multi-line comment.
+	 */
+
+   Note however that a comment that explains a translatable string to
+   translators uses a convention of starting with a magic token
+   "TRANSLATORS: ", e.g.
+
+	/*
+	 * TRANSLATORS: here is a comment that explains the string to
+	 * be translated, that follows immediately after it.
+	 */
+	_("Here is a translatable string explained by the above.");
+
+ - Double negation is often harder to understand than no negation
+   at all.
+
+ - There are two schools of thought when it comes to comparison,
+   especially inside a loop. Some people prefer to have the less stable
+   value on the left hand side and the more stable value on the right hand
+   side, e.g. if you have a loop that counts variable i down to the
+   lower bound,
+
+	while (i > lower_bound) {
+		do something;
+		i--;
+	}
+
+   Other people prefer to have the textual order of values match the
+   actual order of values in their comparison, so that they can
+   mentally draw a number line from left to right and place these
+   values in order, i.e.
+
+	while (lower_bound < i) {
+		do something;
+		i--;
+	}
+
+   Both are valid, and we use both.  However, the more "stable" the
+   stable side becomes, the more we tend to prefer the former
+   (comparison with a constant, "i > 0", is an extreme example).
+   Just do not mix styles in the same part of the code and mimic
+   existing styles in the neighbourhood.
+
+ - There are two schools of thought when it comes to splitting a long
+   logical line into multiple lines.  Some people push the second and
+   subsequent lines far enough to the right with tabs and align them:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+		span_more_than_a_single_line_of ||
+		the_source_text) {
+                ...
+
+   while other people prefer to align the second and the subsequent
+   lines with the column immediately inside the opening parenthesis,
+   with tabs and spaces, following our "tabstop is always a multiple
+   of 8" convention:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of ||
+	    the_source_text) {
+                ...
+
+   Both are valid, and we use both.  Again, just do not mix styles in
+   the same part of the code and mimic existing styles in the
+   neighbourhood.
+
+ - When splitting a long logical line, some people change line before
+   a binary operator, so that the result looks like a parse tree when
+   you turn your head 90-degrees counterclockwise:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to
+	    || span_more_than_a_single_line_of_the_source_text) {
+
+   while other people prefer to leave the operator at the end of the
+   line:
+
+        if (the_beginning_of_a_very_long_expression_that_has_to ||
+	    span_more_than_a_single_line_of_the_source_text) {
+
+   Both are valid, but we tend to use the latter more, unless the
+   expression gets fairly complex, in which case the former tends to
+   be easier to read.  Again, just do not mix styles in the same part
+   of the code and mimic existing styles in the neighbourhood.
+
+ - When splitting a long logical line, with everything else being
+   equal, it is preferable to split after the operator at higher
+   level in the parse tree.  That is, this is more preferable:
+
+	if (a_very_long_variable * that_is_used_in +
+	    a_very_long_expression) {
+		...
+
+   than
+
+	if (a_very_long_variable *
+	    that_is_used_in + a_very_long_expression) {
+		...
+
+ - Some clever tricks, like using the !! operator with arithmetic
+   constructs, can be extremely confusing to others.  Avoid them,
+   unless there is a compelling reason to use them.
+
+ - Use the API.  No, really.  We have a strbuf (variable length
+   string), several arrays with the ALLOC_GROW() macro, a
+   string_list for sorted string lists, a hash map (mapping struct
+   objects) named "struct decorate", amongst other things.
+
+ - When you come up with an API, document its functions and structures
+   in the header file that exposes the API to its callers. Use what is
+   in "strbuf.h" as a model for the appropriate tone and level of
+   detail.
+
+ - The first #include in C files, except in platform specific compat/
+   implementations, must be either "git-compat-util.h", "cache.h" or
+   "builtin.h".  You do not have to include more than one of these.
+
+ - A C file must directly include the header files that declare the
+   functions and the types it uses, except for the functions and types
+   that are made available to it by including one of the header files
+   it must include by the previous rule.
+
+ - If you are planning a new command, consider writing it in shell
+   or perl first, so that changes in semantics can be easily
+   changed and discussed.  Many Git commands started out like
+   that, and a few are still scripts.
+
+ - Avoid introducing a new dependency into Git. This means you
+   usually should stay away from scripting languages not already
+   used in the Git core command set (unless your command is clearly
+   separate from it, such as an importer to convert random-scm-X
+   repositories to Git).
+
+ - When we pass <string, length> pair to functions, we should try to
+   pass them in that order.
+
+ - Use Git's gettext wrappers to make the user interface
+   translatable. See "Marking strings for translation" in po/README.
+
+ - Variables and functions local to a given source file should be marked
+   with "static". Variables that are visible to other source files
+   must be declared with "extern" in header files. However, function
+   declarations should not use "extern", as that is already the default.
+
+ - You can launch gdb around your program using the shorthand GIT_DEBUGGER.
+   Run `GIT_DEBUGGER=1 ./bin-wrappers/git foo` to simply use gdb as is, or
+   run `GIT_DEBUGGER="<debugger> <debugger-args>" ./bin-wrappers/git foo` to
+   use your own debugger and arguments. Example: `GIT_DEBUGGER="ddd --gdb"
+   ./bin-wrappers/git log` (See `wrap-for-bin.sh`.)
+
+For Perl programs:
+
+ - Most of the C guidelines above apply.
+
+ - We try to support Perl 5.8 and later ("use Perl 5.008").
+
+ - use strict and use warnings are strongly preferred.
+
+ - Don't overuse statement modifiers unless using them makes the
+   result easier to follow.
+
+	... do something ...
+	do_this() unless (condition);
+        ... do something else ...
+
+   is more readable than:
+
+	... do something ...
+	unless (condition) {
+		do_this();
+	}
+        ... do something else ...
+
+   *only* when the condition is so rare that do_this() will be almost
+   always called.
+
+ - We try to avoid assignments inside "if ()" conditions.
+
+ - Learn and use Git.pm if you need that functionality.
+
+ - For Emacs, it's useful to put the following in
+   GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode:
+
+    ;; note the first part is useful for C editing, too
+    ((nil . ((indent-tabs-mode . t)
+                  (tab-width . 8)
+                  (fill-column . 80)))
+     (cperl-mode . ((cperl-indent-level . 8)
+                    (cperl-extra-newline-before-brace . nil)
+                    (cperl-merge-trailing-else . t))))
+
+For Python scripts:
+
+ - We follow PEP-8 (http://www.python.org/dev/peps/pep-0008/).
+
+ - As a minimum, we aim to be compatible with Python 2.6 and 2.7.
+
+ - Where required libraries do not restrict us to Python 2, we try to
+   also be compatible with Python 3.1 and later.
+
+ - When you must differentiate between Unicode literals and byte string
+   literals, it is OK to use the 'b' prefix.  Even though the Python
+   documentation for version 2.6 does not mention this prefix, it has
+   been supported since version 2.6.0.
+
+Error Messages
+
+ - Do not end error messages with a full stop.
+
+ - Do not capitalize ("unable to open %s", not "Unable to open %s")
+
+ - Say what the error is first ("cannot open %s", not "%s: cannot open")
+
+
+Externally Visible Names
+
+ - For configuration variable names, follow the existing convention:
+
+   . The section name indicates the affected subsystem.
+
+   . The subsection name, if any, indicates which of an unbounded set
+     of things to set the value for.
+
+   . The variable name describes the effect of tweaking this knob.
+
+   The section and variable names that consist of multiple words are
+   formed by concatenating the words without punctuations (e.g. `-`),
+   and are broken using bumpyCaps in documentation as a hint to the
+   reader.
+
+   When choosing the variable namespace, do not use variable name for
+   specifying possibly unbounded set of things, most notably anything
+   an end user can freely come up with (e.g. branch names).  Instead,
+   use subsection names or variable values, like the existing variable
+   branch.<name>.description does.
+
+
+Writing Documentation:
+
+ Most (if not all) of the documentation pages are written in the
+ AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+ processed into HTML and manpages (e.g. git.html and git.1 in the
+ same directory).
+
+ The documentation liberally mixes US and UK English (en_US/UK)
+ norms for spelling and grammar, which is somewhat unfortunate.
+ In an ideal world, it would have been better if it consistently
+ used only one and not the other, and we would have picked en_US
+ (if you wish to correct the English of some of the existing
+ documentation, please see the documentation-related advice in the
+ Documentation/SubmittingPatches file).
+
+ Every user-visible change should be reflected in the documentation.
+ The same general rule as for code applies -- imitate the existing
+ conventions.
+
+ A few commented examples follow to provide reference when writing or
+ modifying command usage strings and synopsis sections in the manual
+ pages:
+
+ Placeholders are spelled in lowercase and enclosed in angle brackets:
+   <file>
+   --sort=<key>
+   --abbrev[=<n>]
+
+ If a placeholder has multiple words, they are separated by dashes:
+   <new-branch-name>
+   --template=<template-directory>
+
+ Possibility of multiple occurrences is indicated by three dots:
+   <file>...
+   (One or more of <file>.)
+
+ Optional parts are enclosed in square brackets:
+   [<extra>]
+   (Zero or one <extra>.)
+
+   --exec-path[=<path>]
+   (Option with an optional argument.  Note that the "=" is inside the
+   brackets.)
+
+   [<patch>...]
+   (Zero or more of <patch>.  Note that the dots are inside, not
+   outside the brackets.)
+
+ Multiple alternatives are indicated with vertical bars:
+   [-q | --quiet]
+   [--utf8 | --no-utf8]
+
+ Parentheses are used for grouping:
+   [(<rev> | <range>)...]
+   (Any number of either <rev> or <range>.  Parens are needed to make
+   it clear that "..." pertains to both <rev> and <range>.)
+
+   [(-p <parent>)...]
+   (Any number of option -p, each with one <parent> argument.)
+
+   git remote set-head <name> (-a | -d | <branch>)
+   (One and only one of "-a", "-d" or "<branch>" _must_ (no square
+   brackets) be provided.)
+
+ And a somewhat more contrived example:
+   --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+   Here "=" is outside the brackets, because "--diff-filter=" is a
+   valid usage.  "*" has its own pair of brackets, because it can
+   (optionally) be specified only when one or more of the letters is
+   also provided.
+
+  A note on notation:
+   Use 'git' (all lowercase) when talking about commands i.e. something
+   the user would type into a shell and use 'Git' (uppercase first letter)
+   when talking about the version control system and its properties.
+
+ A few commented examples follow to provide reference when writing or
+ modifying paragraphs or option/command explanations that contain options
+ or commands:
+
+ Literal examples (e.g. use of command-line options, command names,
+ branch names, URLs, pathnames (files and directories), configuration and
+ environment variables) must be typeset in monospace (i.e. wrapped with
+ backticks):
+   `--pretty=oneline`
+   `git rev-list`
+   `remote.pushDefault`
+   `http://git.example.com`
+   `.git/config`
+   `GIT_DIR`
+   `HEAD`
+
+ An environment variable must be prefixed with "$" only when referring to its
+ value and not when referring to the variable itself, in this case there is
+ nothing to add except the backticks:
+   `GIT_DIR` is specified
+   `$GIT_DIR/hooks/pre-receive`
+
+ Word phrases enclosed in `backtick characters` are rendered literally
+ and will not be further expanded. The use of `backticks` to achieve the
+ previous rule means that literal examples should not use AsciiDoc
+ escapes.
+   Correct:
+      `--pretty=oneline`
+   Incorrect:
+      `\--pretty=oneline`
+
+ If some place in the documentation needs to typeset a command usage
+ example with inline substitutions, it is fine to use +monospaced and
+ inline substituted text+ instead of `monospaced literal text`, and with
+ the former, the part that should not get substituted must be
+ quoted/escaped.
diff --git a/external/docs/content/docs/BreakingChanges.html b/external/docs/content/docs/BreakingChanges.html
new file mode 100644
index 0000000000..27fbdd6c24
--- /dev/null
+++ b/external/docs/content/docs/BreakingChanges.html
@@ -0,0 +1,279 @@
+---
+### DO NOT EDIT! Generated by script/update-docs.rb
+
+category: manual
+section: documentation
+subsection: manual
+title: Git - BreakingChanges Documentation
+docname: BreakingChanges
+version: 2.48.0
+latest-changes: 2.48.0
+aliases:
+- "/docs/BreakingChanges/index.html"
+---
+<div id="preamble">
+<div class="sectionbody">
+<div class="paragraph">
+<p>The Git project aims to ensure backwards compatibility to the best extent
+possible. Minor releases will not break backwards compatibility unless there is
+a very strong reason to do so, like for example a security vulnerability.</p>
+</div>
+<div class="paragraph">
+<p>Regardless of that, due to the age of the Git project, it is only natural to
+accumulate a backlog of backwards-incompatible changes that will eventually be
+required to keep the project aligned with a changing world. These changes fall
+into several categories:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Changes to long established defaults.</p>
+</li>
+<li>
+<p>Concepts that have been replaced with a superior design.</p>
+</li>
+<li>
+<p>Concepts, commands, configuration or options that have been lacking in major
+ways and that cannot be fixed and which will thus be removed without any
+replacement.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Explicitly not included in this list are fixes to minor bugs that may cause a
+change in user-visible behavior.</p>
+</div>
+<div class="paragraph">
+<p>The Git project irregularly releases breaking versions that deliberately break
+backwards compatibility with older versions. This is done to ensure that Git
+remains relevant, safe and maintainable going forward. The release cadence of
+breaking versions is typically measured in multiple years. We had the following
+major breaking releases in the past:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Git 1.6.0, released in August 2008.</p>
+</li>
+<li>
+<p>Git 2.0, released in May 2014.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>We use &lt;major&gt;.&lt;minor&gt; release numbers these days, starting from Git 2.0. For
+future releases, our plan is to increment &lt;major&gt; in the release number when we
+make the next breaking release. Before Git 2.0, the release numbers were
+1.&lt;major&gt;.&lt;minor&gt; with the intention to increment &lt;major&gt; for "usual" breaking
+releases, reserving the jump to Git 2.0 for really large backward-compatibility
+breaking changes.</p>
+</div>
+<div class="paragraph">
+<p>The intent of this document is to track upcoming deprecations for future
+breaking releases. Furthermore, this document also tracks what will <em>not</em> be
+deprecated. This is done such that the outcome of discussions document both
+when the discussion favors deprecation, but also when it rejects a deprecation.</p>
+</div>
+<div class="paragraph">
+<p>Items should have a clear summary of the reasons why we do or do not want to
+make the described change that can be easily understood without having to read
+the mailing list discussions. If there are alternatives to the changed feature,
+those alternatives should be pointed out to our users.</p>
+</div>
+<div class="paragraph">
+<p>All items should be accompanied by references to relevant mailing list threads
+where the deprecation was discussed. These references use message-IDs, which
+can visited via</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>https://lore.kernel.org/git/$message_id/</pre>
+</div>
+</div>
+<div class="paragraph">
+<p>to see the message and its surrounding discussion. Such a reference is there to
+make it easier for you to find how the project reached consensus on the
+described item back then.</p>
+</div>
+<div class="paragraph">
+<p>This is a living document as the environment surrounding the project changes
+over time. If circumstances change, an earlier decision to deprecate or change
+something may need to be revisited from time to time. So do not take items on
+this list to mean "it is settled, do not waste our time bringing it up again".</p>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_procedure"><a class="anchor" href="#_procedure"></a>Procedure</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>Discussing the desire to make breaking changes, declaring that breaking
+changes are made at a certain version boundary, and recording these
+decisions in this document, are necessary but not sufficient.
+Because such changes are expected to be numerous, and the design and
+implementation of them are expected to span over time, they have to
+be deployable trivially at such a version boundary.</p>
+</div>
+<div class="paragraph">
+<p>The breaking changes MUST be guarded with the a compile-time switch,
+WITH_BREAKING_CHANGES, to help this process.  When built with it,
+the resulting Git binary together with its documentation would
+behave as if these breaking changes slated for the next big version
+boundary are already in effect.  We may also want to have a CI job
+or two to exercise the work-in-progress version of Git with these
+breaking changes.</p>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_git_3_0"><a class="anchor" href="#_git_3_0"></a>Git 3.0</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>The following subsections document upcoming breaking changes for Git 3.0. There
+is no planned release date for this breaking version yet.  The early
+adopter configuration used for changes for this release is <code>feature.git3</code>.</p>
+</div>
+<div class="paragraph">
+<p>Proposed changes and removals only include items which are "ready" to be done.
+In other words, this is not supposed to be a wishlist of features that should
+be changed to or replaced in case the alternative was implemented already.</p>
+</div>
+<div class="sect2">
+<h3 id="_changes"><a class="anchor" href="#_changes"></a>Changes</h3>
+<div class="ulist">
+<ul>
+<li>
+<p>The default hash function for new repositories will be changed from "sha1"
+to "sha256". SHA-1 has been deprecated by NIST in 2011 and is nowadays
+recommended against in FIPS 140-2 and similar certifications. Furthermore,
+there are practical attacks on SHA-1 that weaken its cryptographic properties:</p>
+<div class="ulist">
+<ul>
+<li>
+<p>The SHAppening (2015). The first demonstration of a practical attack
+against SHA-1 with 2^57 operations.</p>
+</li>
+<li>
+<p>SHAttered (2017). Generation of two valid PDF files with 2^63 operations.</p>
+</li>
+<li>
+<p>Birthday-Near-Collision (2019). This attack allows for chosen prefix
+attacks with 2^68 operations.</p>
+</li>
+<li>
+<p>Shambles (2020). This attack allows for chosen prefix attacks with 2^63
+operations.</p>
+<div class="paragraph">
+<p>While we have protections in place against known attacks, it is expected
+that more attacks against SHA-1 will be found by future research. Paired
+with the ever-growing capability of hardware, it is only a matter of time
+before SHA-1 will be considered broken completely. We want to be prepared
+and will thus change the default hash algorithm to "sha256" for newly
+initialized repositories.</p>
+</div>
+<div class="paragraph">
+<p>An important requirement for this change is that the ecosystem is ready to
+support the "sha256" object format. This includes popular Git libraries,
+applications and forges.</p>
+</div>
+<div class="paragraph">
+<p>There is no plan to deprecate the "sha1" object format at this point in time.</p>
+</div>
+<div class="paragraph">
+<p>Cf. &lt;<a href="mailto:2f5de416-04ba-c23d-1e0b-83bb655829a7@zombino.com">2f5de416-04ba-c23d-1e0b-83bb655829a7@zombino.com</a>&gt;,
+&lt;20170223155046.e7nxivfwqqoprsqj@LykOS.localdomain&gt;,
+&lt;CA+EOSBncr=<a href="mailto:4a4d8n9xS4FNehyebpmX8JiUwCsXD47EQDE+DiUQ@mail.gmail.com">4a4d8n9xS4FNehyebpmX8JiUwCsXD47EQDE+DiUQ@mail.gmail.com</a>&gt;.</p>
+</div>
+</li>
+</ul>
+</div>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_removals"><a class="anchor" href="#_removals"></a>Removals</h3>
+<div class="ulist">
+<ul>
+<li>
+<p>Support for grafting commits has long been superseded by git-replace(1).
+Grafts are inferior to replacement refs:</p>
+<div class="ulist">
+<ul>
+<li>
+<p>Grafts are a local-only mechanism and cannot be shared across
+repositories.</p>
+</li>
+<li>
+<p>Grafts can lead to hard-to-diagnose problems when transferring objects
+between repositories.</p>
+<div class="paragraph">
+<p>The grafting mechanism has been marked as outdated since e650d0643b (docs: mark
+info/grafts as outdated, 2014-03-05) and will be removed.</p>
+</div>
+<div class="paragraph">
+<p>Cf. &lt;<a href="mailto:20140304174806.GA11561@sigill.intra.peff.net">20140304174806.GA11561@sigill.intra.peff.net</a>&gt;.</p>
+</div>
+</li>
+</ul>
+</div>
+</li>
+<li>
+<p>The git-pack-redundant(1) command can be used to remove redundant pack files.
+The subcommand is unusably slow and the reason why nobody reports it as a
+performance bug is suspected to be the absence of users. We have nominated
+the command for removal and have started to emit a user-visible warning in
+c3b58472be (pack-redundant: gauge the usage before proposing its removal,
+2020-08-25) whenever the command is executed.</p>
+<div class="paragraph">
+<p>So far there was a single complaint about somebody still using the command, but
+that complaint did not cause us to reverse course. On the contrary, we have
+doubled down on the deprecation and starting with 4406522b76 (pack-redundant:
+escalate deprecation warning to an error, 2023-03-23), the command dies unless
+the user passes the <code>--i-still-use-this</code> option.</p>
+</div>
+<div class="paragraph">
+<p>There have not been any subsequent complaints, so this command will finally be
+removed.</p>
+</div>
+<div class="paragraph">
+<p>Cf. &lt;<a href="mailto:xmqq1rjuz6n3.fsf_-_@gitster.c.googlers.com">xmqq1rjuz6n3.fsf_-_@gitster.c.googlers.com</a>&gt;,
+    &lt;CAKvOHKAFXQwt4D8yUCCkf_TQL79mYaJ=<a href="mailto:KAKhtpDNTvHJFuX1NA@mail.gmail.com">KAKhtpDNTvHJFuX1NA@mail.gmail.com</a>&gt;,
+    &lt;<a href="mailto:20230323204047.GA9290@coredump.intra.peff.net">20230323204047.GA9290@coredump.intra.peff.net</a>&gt;,</p>
+</div>
+</li>
+</ul>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_superseded_features_that_will_not_be_deprecated"><a class="anchor" href="#_superseded_features_that_will_not_be_deprecated"></a>Superseded features that will not be deprecated</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>Some features have gained newer replacements that aim to improve the design in
+certain ways. The fact that there is a replacement does not automatically mean
+that the old way of doing things will eventually be removed. This section tracks
+those features with newer alternatives.</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>The features git-checkout(1) offers are covered by the pair of commands
+git-restore(1) and git-switch(1). Because the use of git-checkout(1) is still
+widespread, and it is not expected that this will change anytime soon, all
+three commands will stay.</p>
+<div class="paragraph">
+<p>This decision may get revisited in case we ever figure out that there are
+almost no users of any of the commands anymore.</p>
+</div>
+<div class="paragraph">
+<p>Cf. &lt;xmqqttjazwwa.fsf@gitster.g&gt;,
+&lt;xmqqleeubork.fsf@gitster.g&gt;,
+&lt;<a href="mailto:112b6568912a6de6672bf5592c3a718e@manjaro.org">112b6568912a6de6672bf5592c3a718e@manjaro.org</a>&gt;.</p>
+</div>
+</li>
+</ul>
+</div>
+</div>
+</div>
\ No newline at end of file
diff --git a/external/docs/content/docs/BreakingChanges/2.46.0.html b/external/docs/content/docs/BreakingChanges/2.46.0.html
new file mode 100644
index 0000000000..5a9928959d
--- /dev/null
+++ b/external/docs/content/docs/BreakingChanges/2.46.0.html
@@ -0,0 +1,234 @@
+---
+### DO NOT EDIT! Generated by script/update-docs.rb
+
+category: manual
+section: documentation
+subsection: manual
+title: Git - BreakingChanges Documentation
+docname: BreakingChanges
+version: 2.46.0
+aliases:
+- "/docs/BreakingChanges/2.46.0/index.html"
+- "/docs/BreakingChanges/2.46.1/index.html"
+- "/docs/BreakingChanges/2.46.2/index.html"
+- "/docs/BreakingChanges/2.46.3/index.html"
+---
+<div id="preamble">
+<div class="sectionbody">
+<div class="paragraph">
+<p>The Git project aims to ensure backwards compatibility to the best extent
+possible. Minor releases will not break backwards compatibility unless there is
+a very strong reason to do so, like for example a security vulnerability.</p>
+</div>
+<div class="paragraph">
+<p>Regardless of that, due to the age of the Git project, it is only natural to
+accumulate a backlog of backwards-incompatible changes that will eventually be
+required to keep the project aligned with a changing world. These changes fall
+into several categories:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Changes to long established defaults.</p>
+</li>
+<li>
+<p>Concepts that have been replaced with a superior design.</p>
+</li>
+<li>
+<p>Concepts, commands, configuration or options that have been lacking in major
+ways and that cannot be fixed and which will thus be removed without any
+replacement.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Explicitly not included in this list are fixes to minor bugs that may cause a
+change in user-visible behavior.</p>
+</div>
+<div class="paragraph">
+<p>The Git project irregularly releases breaking versions that deliberately break
+backwards compatibility with older versions. This is done to ensure that Git
+remains relevant, safe and maintainable going forward. The release cadence of
+breaking versions is typically measured in multiple years. We had the following
+major breaking releases in the past:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Git 1.6.0, released in August 2008.</p>
+</li>
+<li>
+<p>Git 2.0, released in May 2014.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>We use &lt;major&gt;.&lt;minor&gt; release numbers these days, starting from Git 2.0. For
+future releases, our plan is to increment &lt;major&gt; in the release number when we
+make the next breaking release. Before Git 2.0, the release numbers were
+1.&lt;major&gt;.&lt;minor&gt; with the intention to increment &lt;major&gt; for "usual" breaking
+releases, reserving the jump to Git 2.0 for really large backward-compatibility
+breaking changes.</p>
+</div>
+<div class="paragraph">
+<p>The intent of this document is to track upcoming deprecations for future
+breaking releases. Furthermore, this document also tracks what will <em>not</em> be
+deprecated. This is done such that the outcome of discussions document both
+when the discussion favors deprecation, but also when it rejects a deprecation.</p>
+</div>
+<div class="paragraph">
+<p>Items should have a clear summary of the reasons why we do or do not want to
+make the described change that can be easily understood without having to read
+the mailing list discussions. If there are alternatives to the changed feature,
+those alternatives should be pointed out to our users.</p>
+</div>
+<div class="paragraph">
+<p>All items should be accompanied by references to relevant mailing list threads
+where the deprecation was discussed. These references use message-IDs, which
+can visited via</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>https://lore.kernel.org/git/$message_id/</pre>
+</div>
+</div>
+<div class="paragraph">
+<p>to see the message and its surrounding discussion. Such a reference is there to
+make it easier for you to find how the project reached consensus on the
+described item back then.</p>
+</div>
+<div class="paragraph">
+<p>This is a living document as the environment surrounding the project changes
+over time. If circumstances change, an earlier decision to deprecate or change
+something may need to be revisited from time to time. So do not take items on
+this list to mean "it is settled, do not waste our time bringing it up again".</p>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_git_3_0"><a class="anchor" href="#_git_3_0"></a>Git 3.0</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>The following subsections document upcoming breaking changes for Git 3.0. There
+is no planned release date for this breaking version yet.</p>
+</div>
+<div class="paragraph">
+<p>Proposed changes and removals only include items which are "ready" to be done.
+In other words, this is not supposed to be a wishlist of features that should
+be changed to or replaced in case the alternative was implemented already.</p>
+</div>
+<div class="sect2">
+<h3 id="_changes"><a class="anchor" href="#_changes"></a>Changes</h3>
+<div class="ulist">
+<ul>
+<li>
+<p>The default hash function for new repositories will be changed from "sha1"
+to "sha256". SHA-1 has been deprecated by NIST in 2011 and is nowadays
+recommended against in FIPS 140-2 and similar certifications. Furthermore,
+there are practical attacks on SHA-1 that weaken its cryptographic properties:</p>
+<div class="ulist">
+<ul>
+<li>
+<p>The SHAppening (2015). The first demonstration of a practical attack
+against SHA-1 with 2^57 operations.</p>
+</li>
+<li>
+<p>SHAttered (2017). Generation of two valid PDF files with 2^63 operations.</p>
+</li>
+<li>
+<p>Birthday-Near-Collision (2019). This attack allows for chosen prefix
+attacks with 2^68 operations.</p>
+</li>
+<li>
+<p>Shambles (2020). This attack allows for chosen prefix attacks with 2^63
+operations.</p>
+<div class="paragraph">
+<p>While we have protections in place against known attacks, it is expected
+that more attacks against SHA-1 will be found by future research. Paired
+with the ever-growing capability of hardware, it is only a matter of time
+before SHA-1 will be considered broken completely. We want to be prepared
+and will thus change the default hash algorithm to "sha256" for newly
+initialized repositories.</p>
+</div>
+<div class="paragraph">
+<p>An important requirement for this change is that the ecosystem is ready to
+support the "sha256" object format. This includes popular Git libraries,
+applications and forges.</p>
+</div>
+<div class="paragraph">
+<p>There is no plan to deprecate the "sha1" object format at this point in time.</p>
+</div>
+<div class="paragraph">
+<p>Cf. &lt;<a href="mailto:2f5de416-04ba-c23d-1e0b-83bb655829a7@zombino.com">2f5de416-04ba-c23d-1e0b-83bb655829a7@zombino.com</a>&gt;,
+&lt;20170223155046.e7nxivfwqqoprsqj@LykOS.localdomain&gt;,
+&lt;CA+EOSBncr=<a href="mailto:4a4d8n9xS4FNehyebpmX8JiUwCsXD47EQDE+DiUQ@mail.gmail.com">4a4d8n9xS4FNehyebpmX8JiUwCsXD47EQDE+DiUQ@mail.gmail.com</a>&gt;.</p>
+</div>
+</li>
+</ul>
+</div>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_removals"><a class="anchor" href="#_removals"></a>Removals</h3>
+<div class="ulist">
+<ul>
+<li>
+<p>Support for grafting commits has long been superseded by git-replace(1).
+Grafts are inferior to replacement refs:</p>
+<div class="ulist">
+<ul>
+<li>
+<p>Grafts are a local-only mechanism and cannot be shared across
+repositories.</p>
+</li>
+<li>
+<p>Grafts can lead to hard-to-diagnose problems when transferring objects
+between repositories.</p>
+<div class="paragraph">
+<p>The grafting mechanism has been marked as outdated since e650d0643b (docs: mark
+info/grafts as outdated, 2014-03-05) and will be removed.</p>
+</div>
+<div class="paragraph">
+<p>Cf. &lt;<a href="mailto:20140304174806.GA11561@sigill.intra.peff.net">20140304174806.GA11561@sigill.intra.peff.net</a>&gt;.</p>
+</div>
+</li>
+</ul>
+</div>
+</li>
+</ul>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_superseded_features_that_will_not_be_deprecated"><a class="anchor" href="#_superseded_features_that_will_not_be_deprecated"></a>Superseded features that will not be deprecated</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>Some features have gained newer replacements that aim to improve the design in
+certain ways. The fact that there is a replacement does not automatically mean
+that the old way of doing things will eventually be removed. This section tracks
+those features with newer alternatives.</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>The features git-checkout(1) offers are covered by the pair of commands
+git-restore(1) and git-switch(1). Because the use of git-checkout(1) is still
+widespread, and it is not expected that this will change anytime soon, all
+three commands will stay.</p>
+<div class="paragraph">
+<p>This decision may get revisited in case we ever figure out that there are
+almost no users of any of the commands anymore.</p>
+</div>
+<div class="paragraph">
+<p>Cf. &lt;xmqqttjazwwa.fsf@gitster.g&gt;,
+&lt;xmqqleeubork.fsf@gitster.g&gt;,
+&lt;<a href="mailto:112b6568912a6de6672bf5592c3a718e@manjaro.org">112b6568912a6de6672bf5592c3a718e@manjaro.org</a>&gt;.</p>
+</div>
+</li>
+</ul>
+</div>
+</div>
+</div>
\ No newline at end of file
diff --git a/external/docs/content/docs/BreakingChanges/2.47.0.html b/external/docs/content/docs/BreakingChanges/2.47.0.html
new file mode 100644
index 0000000000..092d687c78
--- /dev/null
+++ b/external/docs/content/docs/BreakingChanges/2.47.0.html
@@ -0,0 +1,257 @@
+---
+### DO NOT EDIT! Generated by script/update-docs.rb
+
+category: manual
+section: documentation
+subsection: manual
+title: Git - BreakingChanges Documentation
+docname: BreakingChanges
+version: 2.47.0
+aliases:
+- "/docs/BreakingChanges/2.47.0/index.html"
+- "/docs/BreakingChanges/2.47.1/index.html"
+- "/docs/BreakingChanges/2.47.2/index.html"
+---
+<div id="preamble">
+<div class="sectionbody">
+<div class="paragraph">
+<p>The Git project aims to ensure backwards compatibility to the best extent
+possible. Minor releases will not break backwards compatibility unless there is
+a very strong reason to do so, like for example a security vulnerability.</p>
+</div>
+<div class="paragraph">
+<p>Regardless of that, due to the age of the Git project, it is only natural to
+accumulate a backlog of backwards-incompatible changes that will eventually be
+required to keep the project aligned with a changing world. These changes fall
+into several categories:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Changes to long established defaults.</p>
+</li>
+<li>
+<p>Concepts that have been replaced with a superior design.</p>
+</li>
+<li>
+<p>Concepts, commands, configuration or options that have been lacking in major
+ways and that cannot be fixed and which will thus be removed without any
+replacement.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Explicitly not included in this list are fixes to minor bugs that may cause a
+change in user-visible behavior.</p>
+</div>
+<div class="paragraph">
+<p>The Git project irregularly releases breaking versions that deliberately break
+backwards compatibility with older versions. This is done to ensure that Git
+remains relevant, safe and maintainable going forward. The release cadence of
+breaking versions is typically measured in multiple years. We had the following
+major breaking releases in the past:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Git 1.6.0, released in August 2008.</p>
+</li>
+<li>
+<p>Git 2.0, released in May 2014.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>We use &lt;major&gt;.&lt;minor&gt; release numbers these days, starting from Git 2.0. For
+future releases, our plan is to increment &lt;major&gt; in the release number when we
+make the next breaking release. Before Git 2.0, the release numbers were
+1.&lt;major&gt;.&lt;minor&gt; with the intention to increment &lt;major&gt; for "usual" breaking
+releases, reserving the jump to Git 2.0 for really large backward-compatibility
+breaking changes.</p>
+</div>
+<div class="paragraph">
+<p>The intent of this document is to track upcoming deprecations for future
+breaking releases. Furthermore, this document also tracks what will <em>not</em> be
+deprecated. This is done such that the outcome of discussions document both
+when the discussion favors deprecation, but also when it rejects a deprecation.</p>
+</div>
+<div class="paragraph">
+<p>Items should have a clear summary of the reasons why we do or do not want to
+make the described change that can be easily understood without having to read
+the mailing list discussions. If there are alternatives to the changed feature,
+those alternatives should be pointed out to our users.</p>
+</div>
+<div class="paragraph">
+<p>All items should be accompanied by references to relevant mailing list threads
+where the deprecation was discussed. These references use message-IDs, which
+can visited via</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>https://lore.kernel.org/git/$message_id/</pre>
+</div>
+</div>
+<div class="paragraph">
+<p>to see the message and its surrounding discussion. Such a reference is there to
+make it easier for you to find how the project reached consensus on the
+described item back then.</p>
+</div>
+<div class="paragraph">
+<p>This is a living document as the environment surrounding the project changes
+over time. If circumstances change, an earlier decision to deprecate or change
+something may need to be revisited from time to time. So do not take items on
+this list to mean "it is settled, do not waste our time bringing it up again".</p>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_git_3_0"><a class="anchor" href="#_git_3_0"></a>Git 3.0</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>The following subsections document upcoming breaking changes for Git 3.0. There
+is no planned release date for this breaking version yet.</p>
+</div>
+<div class="paragraph">
+<p>Proposed changes and removals only include items which are "ready" to be done.
+In other words, this is not supposed to be a wishlist of features that should
+be changed to or replaced in case the alternative was implemented already.</p>
+</div>
+<div class="sect2">
+<h3 id="_changes"><a class="anchor" href="#_changes"></a>Changes</h3>
+<div class="ulist">
+<ul>
+<li>
+<p>The default hash function for new repositories will be changed from "sha1"
+to "sha256". SHA-1 has been deprecated by NIST in 2011 and is nowadays
+recommended against in FIPS 140-2 and similar certifications. Furthermore,
+there are practical attacks on SHA-1 that weaken its cryptographic properties:</p>
+<div class="ulist">
+<ul>
+<li>
+<p>The SHAppening (2015). The first demonstration of a practical attack
+against SHA-1 with 2^57 operations.</p>
+</li>
+<li>
+<p>SHAttered (2017). Generation of two valid PDF files with 2^63 operations.</p>
+</li>
+<li>
+<p>Birthday-Near-Collision (2019). This attack allows for chosen prefix
+attacks with 2^68 operations.</p>
+</li>
+<li>
+<p>Shambles (2020). This attack allows for chosen prefix attacks with 2^63
+operations.</p>
+<div class="paragraph">
+<p>While we have protections in place against known attacks, it is expected
+that more attacks against SHA-1 will be found by future research. Paired
+with the ever-growing capability of hardware, it is only a matter of time
+before SHA-1 will be considered broken completely. We want to be prepared
+and will thus change the default hash algorithm to "sha256" for newly
+initialized repositories.</p>
+</div>
+<div class="paragraph">
+<p>An important requirement for this change is that the ecosystem is ready to
+support the "sha256" object format. This includes popular Git libraries,
+applications and forges.</p>
+</div>
+<div class="paragraph">
+<p>There is no plan to deprecate the "sha1" object format at this point in time.</p>
+</div>
+<div class="paragraph">
+<p>Cf. &lt;<a href="mailto:2f5de416-04ba-c23d-1e0b-83bb655829a7@zombino.com">2f5de416-04ba-c23d-1e0b-83bb655829a7@zombino.com</a>&gt;,
+&lt;20170223155046.e7nxivfwqqoprsqj@LykOS.localdomain&gt;,
+&lt;CA+EOSBncr=<a href="mailto:4a4d8n9xS4FNehyebpmX8JiUwCsXD47EQDE+DiUQ@mail.gmail.com">4a4d8n9xS4FNehyebpmX8JiUwCsXD47EQDE+DiUQ@mail.gmail.com</a>&gt;.</p>
+</div>
+</li>
+</ul>
+</div>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_removals"><a class="anchor" href="#_removals"></a>Removals</h3>
+<div class="ulist">
+<ul>
+<li>
+<p>Support for grafting commits has long been superseded by git-replace(1).
+Grafts are inferior to replacement refs:</p>
+<div class="ulist">
+<ul>
+<li>
+<p>Grafts are a local-only mechanism and cannot be shared across
+repositories.</p>
+</li>
+<li>
+<p>Grafts can lead to hard-to-diagnose problems when transferring objects
+between repositories.</p>
+<div class="paragraph">
+<p>The grafting mechanism has been marked as outdated since e650d0643b (docs: mark
+info/grafts as outdated, 2014-03-05) and will be removed.</p>
+</div>
+<div class="paragraph">
+<p>Cf. &lt;<a href="mailto:20140304174806.GA11561@sigill.intra.peff.net">20140304174806.GA11561@sigill.intra.peff.net</a>&gt;.</p>
+</div>
+</li>
+</ul>
+</div>
+</li>
+<li>
+<p>The git-pack-redundant(1) command can be used to remove redundant pack files.
+The subcommand is unusably slow and the reason why nobody reports it as a
+performance bug is suspected to be the absence of users. We have nominated
+the command for removal and have started to emit a user-visible warning in
+c3b58472be (pack-redundant: gauge the usage before proposing its removal,
+2020-08-25) whenever the command is executed.</p>
+<div class="paragraph">
+<p>So far there was a single complaint about somebody still using the command, but
+that complaint did not cause us to reverse course. On the contrary, we have
+doubled down on the deprecation and starting with 4406522b76 (pack-redundant:
+escalate deprecation warning to an error, 2023-03-23), the command dies unless
+the user passes the <code>--i-still-use-this</code> option.</p>
+</div>
+<div class="paragraph">
+<p>There have not been any subsequent complaints, so this command will finally be
+removed.</p>
+</div>
+<div class="paragraph">
+<p>Cf. &lt;<a href="mailto:xmqq1rjuz6n3.fsf_-_@gitster.c.googlers.com">xmqq1rjuz6n3.fsf_-_@gitster.c.googlers.com</a>&gt;,
+    &lt;CAKvOHKAFXQwt4D8yUCCkf_TQL79mYaJ=<a href="mailto:KAKhtpDNTvHJFuX1NA@mail.gmail.com">KAKhtpDNTvHJFuX1NA@mail.gmail.com</a>&gt;,
+    &lt;<a href="mailto:20230323204047.GA9290@coredump.intra.peff.net">20230323204047.GA9290@coredump.intra.peff.net</a>&gt;,</p>
+</div>
+</li>
+</ul>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_superseded_features_that_will_not_be_deprecated"><a class="anchor" href="#_superseded_features_that_will_not_be_deprecated"></a>Superseded features that will not be deprecated</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>Some features have gained newer replacements that aim to improve the design in
+certain ways. The fact that there is a replacement does not automatically mean
+that the old way of doing things will eventually be removed. This section tracks
+those features with newer alternatives.</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>The features git-checkout(1) offers are covered by the pair of commands
+git-restore(1) and git-switch(1). Because the use of git-checkout(1) is still
+widespread, and it is not expected that this will change anytime soon, all
+three commands will stay.</p>
+<div class="paragraph">
+<p>This decision may get revisited in case we ever figure out that there are
+almost no users of any of the commands anymore.</p>
+</div>
+<div class="paragraph">
+<p>Cf. &lt;xmqqttjazwwa.fsf@gitster.g&gt;,
+&lt;xmqqleeubork.fsf@gitster.g&gt;,
+&lt;<a href="mailto:112b6568912a6de6672bf5592c3a718e@manjaro.org">112b6568912a6de6672bf5592c3a718e@manjaro.org</a>&gt;.</p>
+</div>
+</li>
+</ul>
+</div>
+</div>
+</div>
\ No newline at end of file
diff --git a/external/docs/content/docs/BreakingChanges/2.48.0.html b/external/docs/content/docs/BreakingChanges/2.48.0.html
new file mode 100644
index 0000000000..c0cb8dc9e4
--- /dev/null
+++ b/external/docs/content/docs/BreakingChanges/2.48.0.html
@@ -0,0 +1,279 @@
+---
+### DO NOT EDIT! Generated by script/update-docs.rb
+
+category: manual
+section: documentation
+subsection: manual
+title: Git - BreakingChanges Documentation
+docname: BreakingChanges
+version: 2.48.0
+aliases:
+- "/docs/BreakingChanges/2.48.0/index.html"
+- "/docs/BreakingChanges/2.48.1/index.html"
+---
+<div id="preamble">
+<div class="sectionbody">
+<div class="paragraph">
+<p>The Git project aims to ensure backwards compatibility to the best extent
+possible. Minor releases will not break backwards compatibility unless there is
+a very strong reason to do so, like for example a security vulnerability.</p>
+</div>
+<div class="paragraph">
+<p>Regardless of that, due to the age of the Git project, it is only natural to
+accumulate a backlog of backwards-incompatible changes that will eventually be
+required to keep the project aligned with a changing world. These changes fall
+into several categories:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Changes to long established defaults.</p>
+</li>
+<li>
+<p>Concepts that have been replaced with a superior design.</p>
+</li>
+<li>
+<p>Concepts, commands, configuration or options that have been lacking in major
+ways and that cannot be fixed and which will thus be removed without any
+replacement.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Explicitly not included in this list are fixes to minor bugs that may cause a
+change in user-visible behavior.</p>
+</div>
+<div class="paragraph">
+<p>The Git project irregularly releases breaking versions that deliberately break
+backwards compatibility with older versions. This is done to ensure that Git
+remains relevant, safe and maintainable going forward. The release cadence of
+breaking versions is typically measured in multiple years. We had the following
+major breaking releases in the past:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Git 1.6.0, released in August 2008.</p>
+</li>
+<li>
+<p>Git 2.0, released in May 2014.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>We use &lt;major&gt;.&lt;minor&gt; release numbers these days, starting from Git 2.0. For
+future releases, our plan is to increment &lt;major&gt; in the release number when we
+make the next breaking release. Before Git 2.0, the release numbers were
+1.&lt;major&gt;.&lt;minor&gt; with the intention to increment &lt;major&gt; for "usual" breaking
+releases, reserving the jump to Git 2.0 for really large backward-compatibility
+breaking changes.</p>
+</div>
+<div class="paragraph">
+<p>The intent of this document is to track upcoming deprecations for future
+breaking releases. Furthermore, this document also tracks what will <em>not</em> be
+deprecated. This is done such that the outcome of discussions document both
+when the discussion favors deprecation, but also when it rejects a deprecation.</p>
+</div>
+<div class="paragraph">
+<p>Items should have a clear summary of the reasons why we do or do not want to
+make the described change that can be easily understood without having to read
+the mailing list discussions. If there are alternatives to the changed feature,
+those alternatives should be pointed out to our users.</p>
+</div>
+<div class="paragraph">
+<p>All items should be accompanied by references to relevant mailing list threads
+where the deprecation was discussed. These references use message-IDs, which
+can visited via</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>https://lore.kernel.org/git/$message_id/</pre>
+</div>
+</div>
+<div class="paragraph">
+<p>to see the message and its surrounding discussion. Such a reference is there to
+make it easier for you to find how the project reached consensus on the
+described item back then.</p>
+</div>
+<div class="paragraph">
+<p>This is a living document as the environment surrounding the project changes
+over time. If circumstances change, an earlier decision to deprecate or change
+something may need to be revisited from time to time. So do not take items on
+this list to mean "it is settled, do not waste our time bringing it up again".</p>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_procedure"><a class="anchor" href="#_procedure"></a>Procedure</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>Discussing the desire to make breaking changes, declaring that breaking
+changes are made at a certain version boundary, and recording these
+decisions in this document, are necessary but not sufficient.
+Because such changes are expected to be numerous, and the design and
+implementation of them are expected to span over time, they have to
+be deployable trivially at such a version boundary.</p>
+</div>
+<div class="paragraph">
+<p>The breaking changes MUST be guarded with the a compile-time switch,
+WITH_BREAKING_CHANGES, to help this process.  When built with it,
+the resulting Git binary together with its documentation would
+behave as if these breaking changes slated for the next big version
+boundary are already in effect.  We may also want to have a CI job
+or two to exercise the work-in-progress version of Git with these
+breaking changes.</p>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_git_3_0"><a class="anchor" href="#_git_3_0"></a>Git 3.0</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>The following subsections document upcoming breaking changes for Git 3.0. There
+is no planned release date for this breaking version yet.  The early
+adopter configuration used for changes for this release is <code>feature.git3</code>.</p>
+</div>
+<div class="paragraph">
+<p>Proposed changes and removals only include items which are "ready" to be done.
+In other words, this is not supposed to be a wishlist of features that should
+be changed to or replaced in case the alternative was implemented already.</p>
+</div>
+<div class="sect2">
+<h3 id="_changes"><a class="anchor" href="#_changes"></a>Changes</h3>
+<div class="ulist">
+<ul>
+<li>
+<p>The default hash function for new repositories will be changed from "sha1"
+to "sha256". SHA-1 has been deprecated by NIST in 2011 and is nowadays
+recommended against in FIPS 140-2 and similar certifications. Furthermore,
+there are practical attacks on SHA-1 that weaken its cryptographic properties:</p>
+<div class="ulist">
+<ul>
+<li>
+<p>The SHAppening (2015). The first demonstration of a practical attack
+against SHA-1 with 2^57 operations.</p>
+</li>
+<li>
+<p>SHAttered (2017). Generation of two valid PDF files with 2^63 operations.</p>
+</li>
+<li>
+<p>Birthday-Near-Collision (2019). This attack allows for chosen prefix
+attacks with 2^68 operations.</p>
+</li>
+<li>
+<p>Shambles (2020). This attack allows for chosen prefix attacks with 2^63
+operations.</p>
+<div class="paragraph">
+<p>While we have protections in place against known attacks, it is expected
+that more attacks against SHA-1 will be found by future research. Paired
+with the ever-growing capability of hardware, it is only a matter of time
+before SHA-1 will be considered broken completely. We want to be prepared
+and will thus change the default hash algorithm to "sha256" for newly
+initialized repositories.</p>
+</div>
+<div class="paragraph">
+<p>An important requirement for this change is that the ecosystem is ready to
+support the "sha256" object format. This includes popular Git libraries,
+applications and forges.</p>
+</div>
+<div class="paragraph">
+<p>There is no plan to deprecate the "sha1" object format at this point in time.</p>
+</div>
+<div class="paragraph">
+<p>Cf. &lt;<a href="mailto:2f5de416-04ba-c23d-1e0b-83bb655829a7@zombino.com">2f5de416-04ba-c23d-1e0b-83bb655829a7@zombino.com</a>&gt;,
+&lt;20170223155046.e7nxivfwqqoprsqj@LykOS.localdomain&gt;,
+&lt;CA+EOSBncr=<a href="mailto:4a4d8n9xS4FNehyebpmX8JiUwCsXD47EQDE+DiUQ@mail.gmail.com">4a4d8n9xS4FNehyebpmX8JiUwCsXD47EQDE+DiUQ@mail.gmail.com</a>&gt;.</p>
+</div>
+</li>
+</ul>
+</div>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_removals"><a class="anchor" href="#_removals"></a>Removals</h3>
+<div class="ulist">
+<ul>
+<li>
+<p>Support for grafting commits has long been superseded by git-replace(1).
+Grafts are inferior to replacement refs:</p>
+<div class="ulist">
+<ul>
+<li>
+<p>Grafts are a local-only mechanism and cannot be shared across
+repositories.</p>
+</li>
+<li>
+<p>Grafts can lead to hard-to-diagnose problems when transferring objects
+between repositories.</p>
+<div class="paragraph">
+<p>The grafting mechanism has been marked as outdated since e650d0643b (docs: mark
+info/grafts as outdated, 2014-03-05) and will be removed.</p>
+</div>
+<div class="paragraph">
+<p>Cf. &lt;<a href="mailto:20140304174806.GA11561@sigill.intra.peff.net">20140304174806.GA11561@sigill.intra.peff.net</a>&gt;.</p>
+</div>
+</li>
+</ul>
+</div>
+</li>
+<li>
+<p>The git-pack-redundant(1) command can be used to remove redundant pack files.
+The subcommand is unusably slow and the reason why nobody reports it as a
+performance bug is suspected to be the absence of users. We have nominated
+the command for removal and have started to emit a user-visible warning in
+c3b58472be (pack-redundant: gauge the usage before proposing its removal,
+2020-08-25) whenever the command is executed.</p>
+<div class="paragraph">
+<p>So far there was a single complaint about somebody still using the command, but
+that complaint did not cause us to reverse course. On the contrary, we have
+doubled down on the deprecation and starting with 4406522b76 (pack-redundant:
+escalate deprecation warning to an error, 2023-03-23), the command dies unless
+the user passes the <code>--i-still-use-this</code> option.</p>
+</div>
+<div class="paragraph">
+<p>There have not been any subsequent complaints, so this command will finally be
+removed.</p>
+</div>
+<div class="paragraph">
+<p>Cf. &lt;<a href="mailto:xmqq1rjuz6n3.fsf_-_@gitster.c.googlers.com">xmqq1rjuz6n3.fsf_-_@gitster.c.googlers.com</a>&gt;,
+    &lt;CAKvOHKAFXQwt4D8yUCCkf_TQL79mYaJ=<a href="mailto:KAKhtpDNTvHJFuX1NA@mail.gmail.com">KAKhtpDNTvHJFuX1NA@mail.gmail.com</a>&gt;,
+    &lt;<a href="mailto:20230323204047.GA9290@coredump.intra.peff.net">20230323204047.GA9290@coredump.intra.peff.net</a>&gt;,</p>
+</div>
+</li>
+</ul>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_superseded_features_that_will_not_be_deprecated"><a class="anchor" href="#_superseded_features_that_will_not_be_deprecated"></a>Superseded features that will not be deprecated</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>Some features have gained newer replacements that aim to improve the design in
+certain ways. The fact that there is a replacement does not automatically mean
+that the old way of doing things will eventually be removed. This section tracks
+those features with newer alternatives.</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>The features git-checkout(1) offers are covered by the pair of commands
+git-restore(1) and git-switch(1). Because the use of git-checkout(1) is still
+widespread, and it is not expected that this will change anytime soon, all
+three commands will stay.</p>
+<div class="paragraph">
+<p>This decision may get revisited in case we ever figure out that there are
+almost no users of any of the commands anymore.</p>
+</div>
+<div class="paragraph">
+<p>Cf. &lt;xmqqttjazwwa.fsf@gitster.g&gt;,
+&lt;xmqqleeubork.fsf@gitster.g&gt;,
+&lt;<a href="mailto:112b6568912a6de6672bf5592c3a718e@manjaro.org">112b6568912a6de6672bf5592c3a718e@manjaro.org</a>&gt;.</p>
+</div>
+</li>
+</ul>
+</div>
+</div>
+</div>
\ No newline at end of file
diff --git a/external/docs/content/docs/CodingGuidelines.html b/external/docs/content/docs/CodingGuidelines.html
new file mode 100644
index 0000000000..917ca9b66c
--- /dev/null
+++ b/external/docs/content/docs/CodingGuidelines.html
@@ -0,0 +1,1479 @@
+---
+### DO NOT EDIT! Generated by script/update-docs.rb
+
+category: manual
+section: documentation
+subsection: manual
+title: Git - CodingGuidelines Documentation
+docname: CodingGuidelines
+version: 2.48.0
+latest-changes: 2.48.0
+aliases:
+- "/docs/CodingGuidelines/index.html"
+---
+<div id="preamble">
+<div class="sectionbody">
+<div class="paragraph">
+<p>Like other projects, we also have some guidelines for our code.  For
+Git in general, a few rough rules are:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most importantly, we never say "It&#8217;s in POSIX; we&#8217;ll happily
+ignore your needs should your system not conform to it."
+We live in the real world.</p>
+</li>
+<li>
+<p>However, we often say "Let&#8217;s stay away from that construct,
+it&#8217;s not even in POSIX".</p>
+</li>
+<li>
+<p>In spite of the above two rules, we sometimes say "Although
+this is not in POSIX, it (is so convenient | makes the code
+much more readable | has other good characteristics) and
+practically all the platforms we care about support it, so
+let&#8217;s use it".</p>
+<div class="literalblock">
+<div class="content">
+<pre>Again, we live in the real world, and it is sometimes a
+judgement call, the decision based more on real world
+constraints people face than what the paper standard says.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Fixing style violations while working on a real change as a
+preparatory clean-up step is good, but otherwise avoid useless code
+churn for the sake of conforming to the style.</p>
+<div class="literalblock">
+<div class="content">
+<pre>"Once it _is_ in the tree, it's not really worth the patch noise to
+go and fix it up."
+Cf. https://lore.kernel.org/all/20100126160632.3bdbe172.akpm@linux-foundation.org/</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Log messages to explain your changes are as important as the
+changes themselves.  Clearly written code and in-code comments
+explain how the code works and what is assumed from the surrounding
+context.  The log messages explain what the changes wanted to
+achieve and why the changes were necessary (more on this in the
+accompanying SubmittingPatches document).</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Make your code readable and sensible, and don&#8217;t try to be clever.</p>
+</div>
+<div class="paragraph">
+<p>As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the <em>local</em>
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code are expected to match the style the surrounding code already
+uses (even if it doesn&#8217;t match the overall style of existing code).</p>
+</div>
+<div class="paragraph">
+<p>But if you must have a list of rules, here are some language
+specific ones. Note that Documentation/ToolsForGit.txt document
+has a collection of tips to help you use some external tools
+to conform to these guidelines.</p>
+</div>
+<div class="paragraph">
+<p>For shell scripts specifically (not exhaustive):</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs for indentation.</p>
+</li>
+<li>
+<p>Case arms are indented at the same depth as case and esac lines,
+like this:</p>
+<div class="literalblock">
+<div class="content">
+<pre>case "$variable" in
+pattern1)
+	do this
+	;;
+pattern2)
+	do that
+	;;
+esac</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Redirection operators should be written with space before, but no
+space after them.  In other words, write <em>echo test &gt;"$file"</em>
+instead of <em>echo test&gt; $file</em> or <em>echo test &gt; $file</em>.  Note that
+even though it is not required by POSIX to double-quote the
+redirection target in a variable (as shown above), our code does so
+because some versions of bash issue a warning without the quotes.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+cat hello &gt; world &lt; universe
+echo hello &gt;$world</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+cat hello &gt;world &lt;universe
+echo hello &gt;"$world"</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer $( &#8230;&#8203; ) for command substitution; unlike ``, it
+properly nests.  It should have been the way Bourne spelled
+it from day one, but unfortunately isn&#8217;t.</p>
+</li>
+<li>
+<p>If you want to find out if a command is available on the user&#8217;s
+$PATH, you should use <em>type &lt;command&gt;</em>, instead of <em>which &lt;command&gt;</em>.
+The output of <em>which</em> is not machine parsable and its exit code
+is not reliable across platforms.</p>
+</li>
+<li>
+<p>We use POSIX compliant parameter substitutions and avoid bashisms;
+namely:</p>
+</li>
+<li>
+<p>We use ${parameter-word} and its [-=?+] siblings, and their
+colon&#8217;ed "unset or null" form.</p>
+</li>
+<li>
+<p>We use ${parameter#word} and its [#%] siblings, and their
+doubled "longest matching" form.</p>
+</li>
+<li>
+<p>No "Substring Expansion" ${parameter:offset:length}.</p>
+</li>
+<li>
+<p>No shell arrays.</p>
+</li>
+<li>
+<p>No pattern replacement ${parameter/pattern/string}.</p>
+</li>
+<li>
+<p>We use Arithmetic Expansion $&#8230;&#8203;.</p>
+</li>
+<li>
+<p>We do not use Process Substitution &lt;(list) or &gt;(list).</p>
+</li>
+<li>
+<p>Do not write control structures on a single line with semicolon.
+"then" should be on the next line for if statements, and "do"
+should be on the next line for "while" and "for".</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+if test -f hello; then
+	do this
+fi</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+if test -f hello
+then
+	do this
+fi</pre>
+</div>
+</div>
+</li>
+<li>
+<p>If a command sequence joined with &amp;&amp; or || or | spans multiple
+lines, put each command on a separate line and put &amp;&amp; and || and |
+operators at the end of each line, rather than the start. This
+means you don&#8217;t need to use \ to join lines, since the above
+operators imply the sequence isn&#8217;t finished.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+grep blob verify_pack_result \
+| awk -f print_1.awk \
+| sort &gt;actual &amp;&amp;
+...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+grep blob verify_pack_result |
+awk -f print_1.awk |
+sort &gt;actual &amp;&amp;
+...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer "test" over "[ &#8230;&#8203; ]".</p>
+</li>
+<li>
+<p>We do not write the noiseword "function" in front of shell
+functions.</p>
+</li>
+<li>
+<p>We prefer a space between the function name and the parentheses,
+and no space inside the parentheses. The opening "{" should also
+be on the same line.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+my_function(){
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+my_function () {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+[::], [==], or [..]) for portability.</p>
+</li>
+<li>
+<p>We do not use \{m,n\};</p>
+</li>
+<li>
+<p>We do not use ? or + (which are \{0,1\} and \{1,\}
+respectively in BRE) but that goes without saying as these
+are ERE elements not BRE (note that \? and \+ are not even part
+of BRE&#8201;&#8212;&#8201;making them accessible from BRE is a GNU extension).</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers in git-sh-i18n to make the user
+interface translatable. See "Marking strings for translation" in
+po/README.</p>
+</li>
+<li>
+<p>We do not write our "test" command with "-a" and "-o" and use "&amp;&amp;"
+or "||" to concatenate multiple "test" commands instead, because
+the use of "-a/-o" is often error-prone.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" -a "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is buggy and breaks when $x is "=", but</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" &amp;&amp; test "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>does not have such a problem.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Even though "local" is not part of POSIX, we make heavy use of it
+in our test suite.  We do not use it in scripted Porcelains, and
+hopefully nobody starts using "local" before all shells that matter
+support it (notably, ksh from AT&amp;T Research does not support it yet).</p>
+</li>
+<li>
+<p>Some versions of shell do not understand "export variable=value",
+so we write "variable=value" and then "export variable" on two
+separate lines.</p>
+</li>
+<li>
+<p>Some versions of dash have broken variable assignment when prefixed
+with "local", "export", and "readonly", in that the value to be
+assigned goes through field splitting at $IFS unless quoted.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+local variable=$value
+local variable=$(command args)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+local variable="$value"
+local variable="$(command args)"</pre>
+</div>
+</div>
+</li>
+<li>
+<p>The common construct</p>
+<div class="literalblock">
+<div class="content">
+<pre>VAR=VAL command args</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>to temporarily set and export environment variable VAR only while
+"command args" is running is handy, but this triggers an
+unspecified behaviour according to POSIX when used for a command
+that is not an external command (like shell functions).  Indeed,
+dash 0.5.10.2-6 on Ubuntu 20.04, /bin/sh on FreeBSD 13, and AT&amp;T
+ksh all make a temporary assignment without exporting the variable,
+in such a case.  As it does not work portably across shells, do not
+use this syntax for shell functions.  A common workaround is to do
+an explicit export in a subshell, like so:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+VAR=VAL func args</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+(
+	VAR=VAL &amp;&amp;
+	export VAR &amp;&amp;
+	func args
+)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>but be careful that the effect "func" makes to the variables in the
+current shell will be lost across the subshell boundary.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Use octal escape sequences (e.g. "\302\242"), not hexadecimal (e.g.
+"\xc2\xa2") in printf format strings, since hexadecimal escape
+sequences are not portable.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For C programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs to indent, and interpret tabs as taking up to
+8 spaces.</p>
+</li>
+<li>
+<p>Nested C preprocessor directives are indented after the hash by one
+space per nesting level.</p>
+<div class="literalblock">
+<div class="content">
+<pre>#if FOO
+# include &lt;foo.h&gt;
+# if BAR
+#  include &lt;bar.h&gt;
+# endif
+#endif</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We try to keep to at most 80 characters per line.</p>
+</li>
+<li>
+<p>As a Git developer we assume you have a reasonably modern compiler
+and we recommend you to enable the DEVELOPER makefile knob to
+ensure your patch is clear of all compiler warnings we care about,
+by e.g. "echo DEVELOPER=1 &gt;&gt;config.mak".</p>
+</li>
+<li>
+<p>When using DEVELOPER=1 mode, you may see warnings from the compiler
+like "error: unused parameter <em>foo</em> [-Werror=unused-parameter]",
+which indicates that a function ignores its argument. If the unused
+parameter can&#8217;t be removed (e.g., because the function is used as a
+callback and has to match a certain interface), you can annotate
+the individual parameters with the UNUSED (or MAYBE_UNUSED)
+keyword, like "int foo UNUSED".</p>
+</li>
+<li>
+<p>We try to support a wide range of C compilers to compile Git with,
+including old ones.  As of Git v2.35.0 Git requires C99 (we check
+"<em>STDC_VERSION</em>"). You should not use features from a newer C
+standard, even if your compiler groks them.</p>
+<div class="literalblock">
+<div class="content">
+<pre>New C99 features have been phased in gradually, if something's new
+in C99 but not used yet don't assume that it's safe to use, some
+compilers we target have only partial support for it. These are
+considered safe to use:</pre>
+</div>
+</div>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>since around 2007 with 2b6854c863a, we have been using
+initializer elements which are not computable at load time. E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>const char *args[] = { "constant", variable, NULL };</pre>
+</div>
+</div>
+</li>
+<li>
+<p>since early 2012 with e1327023ea, we have been using an enum
+definition whose last element is followed by a comma.  This, like
+an array initializer that ends with a trailing comma, can be used
+to reduce the patch noise when adding a new identifier at the end.</p>
+</li>
+<li>
+<p>since mid 2017 with cbc0f81d, we have been using designated
+initializers for struct (e.g. "struct t v = { .val = <em>a</em> };").</p>
+</li>
+<li>
+<p>since mid 2017 with 512f41cf, we have been using designated
+initializers for array (e.g. "int array[10] = { [5] = 2 }").</p>
+</li>
+<li>
+<p>since early 2021 with 765dc168882, we have been using variadic
+macros, mostly for printf-like trace and debug macros.</p>
+</li>
+<li>
+<p>since late 2021 with 44ba10d6, we have had variables declared in
+the for loop "for (int i = 0; i &lt; 10; i++)".</p>
+<div class="literalblock">
+<div class="content">
+<pre>New C99 features that we cannot use yet:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>%z and %zu as a printf() argument for a size_t (the %z being for
+the POSIX-specific ssize_t). Instead you should use
+printf("%"PRIuMAX, (uintmax_t)v).  These days the MSVC version we
+rely on supports %z, but the C library used by MinGW does not.</p>
+</li>
+<li>
+<p>Shorthand like ".a.b = *c" in struct initializations is known to
+trip up an older IBM XLC version, use ".a = { .b = *c }" instead.
+See the 33665d98 (reftable: make assignments portable to AIX xlc
+v12.01, 2022-03-28).</p>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>Variables have to be declared at the beginning of the block, before
+the first statement (i.e. -Wdeclaration-after-statement).  It is
+encouraged to have a blank line between the end of the declarations
+and the first statement in the block.</p>
+</li>
+<li>
+<p>NULL pointers shall be written as NULL, not as 0.</p>
+</li>
+<li>
+<p>When declaring pointers, the star sides with the variable
+name, i.e. "char <strong>string", not "char</strong> string" or
+"char * string".  This makes it easier to understand code
+like "char *string, c;".</p>
+</li>
+<li>
+<p>Use whitespace around operators and keywords, but not inside
+parentheses and not around functions. So:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      while (condition)
+func(bar + 1);</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>      while( condition )
+func (bar+1);</pre>
+</div>
+</div>
+</li>
+<li>
+<p>A binary operator (other than ",") and ternary conditional "?:"
+have a space on each side of the operator to separate it from its
+operands.  E.g. "A + 1", not "A+1".</p>
+</li>
+<li>
+<p>A unary operator (other than "." and "&#8594;") have no space between it
+and its operand.  E.g. "(char *)ptr", not "(char *) ptr".</p>
+</li>
+<li>
+<p>Do not explicitly compare an integral value with constant 0 or <em>\0</em>,
+or a pointer value with constant NULL.  For instance, to validate that
+counted array &lt;ptr, cnt&gt; is initialized but has no elements, write:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (!ptr || cnt)
+	BUG("empty array expected");</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (ptr == NULL || cnt != 0);
+	BUG("empty array expected");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We avoid using braces unnecessarily.  I.e.</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (bla) {
+	x = 1;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is frowned upon. But there are a few exceptions:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When the statement extends over a few lines (e.g., a while loop
+with an embedded conditional, or a comment). E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (foo) {
+	if (x)
+		one();
+	else
+		two();
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	/*
+	 * This one requires some explanation,
+	 * so we're better off with braces to make
+	 * it obvious that the indentation is correct.
+	 */
+	doit();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When there are multiple arms to a conditional and some of them
+require braces, enclose even a single line block in braces for
+consistency. E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	doit();
+} else {
+	one();
+	two();
+	three();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments in the condition of an "if" statement.</p>
+</li>
+<li>
+<p>Try to make your code understandable.  You may put comments
+in, but comments invariably tend to stale out when the code
+they were describing changes.  Often splitting a function
+into two makes the intention of the code much clearer.</p>
+</li>
+<li>
+<p>Multi-line comments include their delimiters on separate lines from
+the text.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * A very long
+ * multi-line comment.
+ */</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Note however that a comment that explains a translatable string to
+translators uses a convention of starting with a magic token
+"TRANSLATORS: ", e.g.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * TRANSLATORS: here is a comment that explains the string to
+ * be translated, that follows immediately after it.
+ */
+_("Here is a translatable string explained by the above.");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Double negation is often harder to understand than no negation
+at all.</p>
+</li>
+<li>
+<p>There are two schools of thought when it comes to comparison,
+especially inside a loop. Some people prefer to have the less stable
+value on the left hand side and the more stable value on the right hand
+side, e.g. if you have a loop that counts variable i down to the
+lower bound,</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (i &gt; lower_bound) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Other people prefer to have the textual order of values match the
+actual order of values in their comparison, so that they can
+mentally draw a number line from left to right and place these
+values in order, i.e.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while (lower_bound &lt; i) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  However, the more "stable" the
+stable side becomes, the more we tend to prefer the former
+(comparison with a constant, "i &gt; 0", is an extreme example).
+Just do not mix styles in the same part of the code and mimic
+existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>There are two schools of thought when it comes to splitting a long
+logical line into multiple lines.  Some people push the second and
+subsequent lines far enough to the right with tabs and align them:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+              ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to align the second and the subsequent
+lines with the column immediately inside the opening parenthesis,
+with tabs and spaces, following our "tabstop is always a multiple
+of 8" convention:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+           ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  Again, just do not mix styles in
+the same part of the code and mimic existing styles in the
+neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, some people change line before
+a binary operator, so that the result looks like a parse tree when
+you turn your head 90-degrees counterclockwise:</p>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to
+|| span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to leave the operator at the end of the
+line:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, but we tend to use the latter more, unless the
+expression gets fairly complex, in which case the former tends to
+be easier to read.  Again, just do not mix styles in the same part
+of the code and mimic existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, with everything else being
+equal, it is preferable to split after the operator at higher
+level in the parse tree.  That is, this is more preferable:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable * that_is_used_in +
+    a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>than</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable *
+    that_is_used_in + a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Some clever tricks, like using the !! operator with arithmetic
+constructs, can be extremely confusing to others.  Avoid them,
+unless there is a compelling reason to use them.</p>
+</li>
+<li>
+<p>Use the API.  No, really.  We have a strbuf (variable length
+string), several arrays with the ALLOC_GROW() macro, a
+string_list for sorted string lists, a hash map (mapping struct
+objects) named "struct decorate", amongst other things.</p>
+</li>
+<li>
+<p>When you come up with an API, document its functions and structures
+in the header file that exposes the API to its callers. Use what is
+in "strbuf.h" as a model for the appropriate tone and level of
+detail.</p>
+</li>
+<li>
+<p>The first #include in C files, except in platform specific compat/
+implementations and sha1dc/, must be &lt;git-compat-util.h&gt;.  This
+header file insulates other header files and source files from
+platform differences, like which system header files must be
+included in what order, and what C preprocessor feature macros must
+be defined to trigger certain features we expect out of the system.
+A collorary to this is that C files should not directly include
+system header files themselves.</p>
+<div class="literalblock">
+<div class="content">
+<pre>There are some exceptions, because certain group of files that
+implement an API all have to include the same header file that
+defines the API and it is convenient to include &lt;git-compat-util.h&gt;
+there.  Namely:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>the implementation of the built-in commands in the "builtin/"
+directory that include "builtin.h" for the cmd_foo() prototype
+definition,</p>
+</li>
+<li>
+<p>the test helper programs in the "t/helper/" directory that include
+"t/helper/test-tool.h" for the cmd__foo() prototype definition,</p>
+</li>
+<li>
+<p>the xdiff implementation in the "xdiff/" directory that includes
+"xdiff/xinclude.h" for the xdiff machinery internals,</p>
+</li>
+<li>
+<p>the unit test programs in "t/unit-tests/" directory that include
+"t/unit-tests/test-lib.h" that gives them the unit-tests
+framework, and</p>
+</li>
+<li>
+<p>the source files that implement reftable in the "reftable/"
+directory that include "reftable/system.h" for the reftable
+internals,</p>
+<div class="literalblock">
+<div class="content">
+<pre>are allowed to assume that they do not have to include
+&lt;git-compat-util.h&gt; themselves, as it is included as the first
+'#include' in these header files.  These headers must be the first
+header file to be "#include"d in them, though.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>A C file must directly include the header files that declare the
+functions and the types it uses, except for the functions and types
+that are made available to it by including one of the header files
+it must include by the previous rule.</p>
+</li>
+<li>
+<p>If you are planning a new command, consider writing it in shell
+or perl first, so that changes in semantics can be easily
+changed and discussed.  Many Git commands started out like
+that, and a few are still scripts.</p>
+</li>
+<li>
+<p>Avoid introducing a new dependency into Git. This means you
+usually should stay away from scripting languages not already
+used in the Git core command set (unless your command is clearly
+separate from it, such as an importer to convert random-scm-X
+repositories to Git).</p>
+</li>
+<li>
+<p>When we pass &lt;string, length&gt; pair to functions, we should try to
+pass them in that order.</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers to make the user interface
+translatable. See "Marking strings for translation" in po/README.</p>
+</li>
+<li>
+<p>Variables and functions local to a given source file should be marked
+with "static". Variables that are visible to other source files
+must be declared with "extern" in header files. However, function
+declarations should not use "extern", as that is already the default.</p>
+</li>
+<li>
+<p>You can launch gdb around your program using the shorthand GIT_DEBUGGER.
+Run <code>GIT_DEBUGGER=1 ./bin-wrappers/git foo</code> to simply use gdb as is, or
+run <code>GIT_DEBUGGER="&lt;debugger&gt; &lt;debugger-args&gt;" ./bin-wrappers/git foo</code> to
+use your own debugger and arguments. Example: <code>GIT_DEBUGGER="ddd --gdb"
+./bin-wrappers/git log</code> (See <code>bin-wrappers/wrap-for-bin.sh</code>.)</p>
+</li>
+<li>
+<p>The primary data structure that a subsystem <em>S</em> deals with is called
+<code>struct S</code>. Functions that operate on <code>struct S</code> are named
+<code>S_&lt;verb&gt;()</code> and should generally receive a pointer to <code>struct S</code> as
+first parameter. E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>struct strbuf;</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>void strbuf_add(struct strbuf *buf, ...);</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>void strbuf_reset(struct strbuf *buf);</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is preferred over:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>struct strbuf;</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>void add_string(struct strbuf *buf, ...);</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>void reset_strbuf(struct strbuf *buf);</pre>
+</div>
+</div>
+</li>
+<li>
+<p>There are several common idiomatic names for functions performing
+specific tasks on a structure <code>S</code>:</p>
+</li>
+<li>
+<p><code>S_init()</code> initializes a structure without allocating the
+structure itself.</p>
+</li>
+<li>
+<p><code>S_release()</code> releases a structure&#8217;s contents without freeing the
+structure.</p>
+</li>
+<li>
+<p><code>S_clear()</code> is equivalent to <code>S_release()</code> followed by <code>S_init()</code>
+such that the structure is directly usable after clearing it. When
+<code>S_clear()</code> is provided, <code>S_init()</code> shall not allocate resources
+that need to be released again.</p>
+</li>
+<li>
+<p><code>S_free()</code> releases a structure&#8217;s contents and frees the
+structure.</p>
+</li>
+<li>
+<p>Function names should be clear and descriptive, accurately reflecting
+their purpose or behavior. Arbitrary suffixes that do not add meaningful
+context can lead to confusion, particularly for newcomers to the codebase.</p>
+<div class="literalblock">
+<div class="content">
+<pre>Historically, the '_1' suffix has been used in situations where:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>A function handles one element among a group that requires similar
+processing.</p>
+</li>
+<li>
+<p>A recursive function has been separated from its setup phase.</p>
+<div class="literalblock">
+<div class="content">
+<pre>The '_1' suffix can be used as a concise way to indicate these specific
+cases. However, it is recommended to find a more descriptive name wherever
+possible to improve the readability and maintainability of the code.</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Perl programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most of the C guidelines above apply.</p>
+</li>
+<li>
+<p>We try to support Perl 5.8.1 and later ("use Perl 5.008001").</p>
+</li>
+<li>
+<p>use strict and use warnings are strongly preferred.</p>
+</li>
+<li>
+<p>Don&#8217;t overuse statement modifiers unless using them makes the
+result easier to follow.</p>
+<div class="olist lowerroman">
+<ol class="lowerroman" type="i">
+<li>
+<p>do something &#8230;&#8203;
+do_this() unless (condition);</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>is more readable than:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>do something &#8230;&#8203;
+unless (condition) {
+	do_this();
+}</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>*only* when the condition is so rare that do_this() will be almost
+always called.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments inside "if ()" conditions.</p>
+</li>
+<li>
+<p>Learn and use Git.pm if you need that functionality.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Python scripts:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We follow PEP-8 (<a href="https://peps.python.org/pep-0008/" class="bare">https://peps.python.org/pep-0008/</a>).</p>
+</li>
+<li>
+<p>As a minimum, we aim to be compatible with Python 2.7.</p>
+</li>
+<li>
+<p>Where required libraries do not restrict us to Python 2, we try to
+also be compatible with Python 3.1 and later.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Program Output</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>We make a distinction between a Git command's primary output and
+output which is merely chatty feedback (for instance, status
+messages, running transcript, or progress display), as well as error
+messages. Roughly speaking, a Git command's primary output is that
+which one might want to capture to a file or send down a pipe; its
+chatty output should not interfere with these use-cases.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>As such, primary output should be sent to the standard output stream
+(stdout), and chatty output should be sent to the standard error
+stream (stderr). Examples of commands which produce primary output
+include `git log`, `git show`, and `git branch --list` which generate
+output on the stdout stream.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Not all Git commands have primary output; this is often true of
+commands whose main function is to perform an action. Some action
+commands are silent, whereas others are chatty. An example of a
+chatty action commands is `git clone` with its "Cloning into
+'&lt;path&gt;'..." and "Checking connectivity..." status messages which it
+sends to the stderr stream.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Error messages from Git commands should always be sent to the stderr
+stream.</pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Error Messages</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Do not end a single-sentence error message with a full stop.</p>
+</li>
+<li>
+<p>Do not capitalize the first word, only because it is the first word
+in the message ("unable to open <em>%s</em>", not "Unable to open <em>%s</em>").  But
+"SHA-3 not supported" is fine, because the reason the first word is
+capitalized is not because it is at the beginning of the sentence,
+but because the word would be spelled in capital letters even when
+it appeared in the middle of the sentence.</p>
+</li>
+<li>
+<p>Say what the error is first ("cannot open <em>%s</em>", not "%s: cannot open").</p>
+</li>
+<li>
+<p>Enclose the subject of an error inside a pair of single quotes,
+e.g. <code>die(_("unable to open '%s'"), path)</code>.</p>
+</li>
+<li>
+<p>Unless there is a compelling reason not to, error messages from
+porcelain commands should be marked for translation, e.g.
+<code>die(_("bad revision %s"), revision)</code>.</p>
+</li>
+<li>
+<p>Error messages from the plumbing commands are sometimes meant for
+machine consumption and should not be marked for translation,
+e.g., <code>die("bad revision %s", revision)</code>.</p>
+</li>
+<li>
+<p>BUG("message") are for communicating the specific error to developers,
+thus should not be translated.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Externally Visible Names</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>For configuration variable names, follow the existing convention:</p>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>The section name indicates the affected subsystem.</p>
+</li>
+<li>
+<p>The subsection name, if any, indicates which of an unbounded set
+of things to set the value for.</p>
+</li>
+<li>
+<p>The variable name describes the effect of tweaking this knob.</p>
+<div class="literalblock">
+<div class="content">
+<pre>The section and variable names that consist of multiple words are
+formed by concatenating the words without punctuation marks (e.g. `-`),
+and are broken using bumpyCaps in documentation as a hint to the
+reader.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>When choosing the variable namespace, do not use variable name for
+specifying possibly unbounded set of things, most notably anything
+an end user can freely come up with (e.g. branch names).  Instead,
+use subsection names or variable values, like the existing variable
+branch.&lt;name&gt;.description does.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Writing Documentation:</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Most (if not all) of the documentation pages are written in the
+AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+processed into HTML and manpages (e.g. git.html and git.1 in the
+same directory).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>The documentation liberally mixes US and UK English (en_US/UK)
+norms for spelling and grammar, which is somewhat unfortunate.
+In an ideal world, it would have been better if it consistently
+used only one and not the other, and we would have picked en_US
+(if you wish to correct the English of some of the existing
+documentation, please see the documentation-related advice in the
+Documentation/SubmittingPatches file).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>In order to ensure the documentation is inclusive, avoid assuming
+that an unspecified example person is male or female, and think
+twice before using "he", "him", "she", or "her".  Here are some
+tips to avoid use of gendered pronouns:</pre>
+</div>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Prefer succinctness and matter-of-factly describing functionality
+in the abstract.  E.g.</p>
+<div class="dlist">
+<dl>
+<dt class="hdlist1" id="Documentation/CodingGuidelines-code--shortcode"> <a class="anchor" href="#Documentation/CodingGuidelines-code--shortcode"></a><code>--short</code> </dt>
+<dd>
+<p>Emit output in the short-format.</p>
+<div class="literalblock">
+<div class="content">
+<pre>and avoid something like these overly verbose alternatives:</pre>
+</div>
+</div>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines-code--shortcode-1"> <a class="anchor" href="#Documentation/CodingGuidelines-code--shortcode-1"></a><code>--short</code> </dt>
+<dd>
+<p>Use this to emit output in the short-format.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines-code--shortcode-1-1"> <a class="anchor" href="#Documentation/CodingGuidelines-code--shortcode-1-1"></a><code>--short</code> </dt>
+<dd>
+<p>You can use this to get output in the short-format.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines-code--shortcode-1-1-1"> <a class="anchor" href="#Documentation/CodingGuidelines-code--shortcode-1-1-1"></a><code>--short</code> </dt>
+<dd>
+<p>A user who prefers shorter output could&#8230;&#8203;.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines-code--shortcode-1-1-1-1"> <a class="anchor" href="#Documentation/CodingGuidelines-code--shortcode-1-1-1-1"></a><code>--short</code> </dt>
+<dd>
+<p>Should a person and/or program want shorter output, he
+she/they/it can&#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>This practice often eliminates the need to involve human actors in
+your description, but it is a good practice regardless of the
+avoidance of gendered pronouns.</pre>
+</div>
+</div>
+</dd>
+</dl>
+</div>
+</li>
+<li>
+<p>When it becomes awkward to stick to this style, prefer "you" when
+addressing the hypothetical user, and possibly "we" when
+discussing how the program might react to the user.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>You can use this option instead of `--xyz`, but we might remove
+support for it in future versions.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while keeping in mind that you can probably be less verbose, e.g.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Use this instead of `--xyz`. This option might be removed in future
+versions.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>If you still need to refer to an example person that is
+third-person singular, you may resort to "singular they" to avoid
+"he/she/him/her", e.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>A contributor asks their upstream to pull from them.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Note that this sounds ungrammatical and unnatural to those who
+learned that "they" is only used for third-person plural, e.g.
+those who learn English as a second language in some parts of the
+world.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Every user-visible change should be reflected in the documentation.
+The same general rule as for code applies -- imitate the existing
+conventions.</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Markup:</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Literal parts (e.g. use of command-line options, command names,
+branch names, URLs, pathnames (files and directories), configuration and
+environment variables) must be typeset as verbatim (i.e. wrapped with
+backticks):
+  `--pretty=oneline`
+  `git rev-list`
+  `remote.pushDefault`
+  `http://git.example.com`
+  `.git/config`
+  `GIT_DIR`
+  `HEAD`
+  `umask`(2)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>An environment variable must be prefixed with "$" only when referring to its
+value and not when referring to the variable itself, in this case there is
+nothing to add except the backticks:
+  `GIT_DIR` is specified
+  `$GIT_DIR/hooks/pre-receive`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Word phrases enclosed in `backtick characters` are rendered literally
+and will not be further expanded. The use of `backticks` to achieve the
+previous rule means that literal examples should not use AsciiDoc
+escapes.
+  Correct:
+     `--pretty=oneline`
+  Incorrect:
+     `\--pretty=oneline`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Placeholders are spelled in lowercase and enclosed in
+angle brackets surrounded by underscores:
+  _&lt;file&gt;_
+  _&lt;commit&gt;_</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If a placeholder has multiple words, they are separated by dashes:
+  _&lt;new-branch-name&gt;_
+  _&lt;template-directory&gt;_</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>When needed, use a distinctive identifier for placeholders, usually
+made of a qualification and a type:
+  _&lt;git-dir&gt;_
+  _&lt;key-id&gt;_</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Git's Asciidoc processor has been tailored to treat backticked text
+as complex synopsis. When literal and placeholders are mixed, you can
+use the backtick notation which will take care of correctly typesetting
+the content.
+  `--jobs &lt;n&gt;`
+  `--sort=&lt;key&gt;`
+  `&lt;directory&gt;/.git`
+  `remote.&lt;name&gt;.mirror`
+  `ssh://[&lt;user&gt;@]&lt;host&gt;[:&lt;port&gt;]/&lt;path-to-git-repo&gt;`</pre>
+</div>
+</div>
+<div class="paragraph">
+<p>As a side effect, backquoted placeholders are correctly typeset, but
+this style is not recommended.</p>
+</div>
+<div class="paragraph">
+<p>Synopsis Syntax</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>The synopsis (a paragraph with [synopsis] attribute) is automatically
+formatted by the toolchain and does not need typesetting.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying command usage strings and synopsis sections in the manual
+pages:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Possibility of multiple occurrences is indicated by three dots:
+  &lt;file&gt;...
+  (One or more of &lt;file&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Optional parts are enclosed in square brackets:
+  [&lt;file&gt;...]
+  (Zero or more of &lt;file&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>An optional parameter needs to be typeset with unconstrained pairs
+  [&lt;repository&gt;]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>--exec-path[=&lt;path&gt;]
+(Option with an optional argument.  Note that the "=" is inside the
+brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[&lt;patch&gt;...]
+(Zero or more of &lt;patch&gt;.  Note that the dots are inside, not
+outside the brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Multiple alternatives are indicated with vertical bars:
+  [-q | --quiet]
+  [--utf8 | --no-utf8]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Use spacing around "|" token(s), but not immediately after opening or
+before closing a [] or () pair:
+  Do: [-q | --quiet]
+  Don't: [-q|--quiet]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Don't use spacing around "|" tokens when they're used to separate the
+alternate arguments of an option:
+   Do: --track[=(direct|inherit)]
+   Don't: --track[=(direct | inherit)]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Parentheses are used for grouping:
+  [(&lt;rev&gt;|&lt;range&gt;)...]
+  (Any number of either &lt;rev&gt; or &lt;range&gt;.  Parens are needed to make
+  it clear that "..." pertains to both &lt;rev&gt; and &lt;range&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[(-p &lt;parent&gt;)...]
+(Any number of option -p, each with one &lt;parent&gt; argument.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>git remote set-head &lt;name&gt; (-a|-d|&lt;branch&gt;)
+(One and only one of "-a", "-d" or "&lt;branch&gt;" _must_ (no square
+brackets) be provided.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>And a somewhat more contrived example:
+  --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+  Here "=" is outside the brackets, because "--diff-filter=" is a
+  valid usage.  "*" has its own pair of brackets, because it can
+  (optionally) be specified only when one or more of the letters is
+  also provided.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A note on notation:
+ Use 'git' (all lowercase) when talking about commands i.e. something
+ the user would type into a shell and use 'Git' (uppercase first letter)
+ when talking about the version control system and its properties.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If some place in the documentation needs to typeset a command usage
+example with inline substitutions, it is fine to use +monospaced and
+inline substituted text+ instead of `monospaced literal text`, and with
+the former, the part that should not get substituted must be
+quoted/escaped.</pre>
+</div>
+</div>
+</div>
+</div>
\ No newline at end of file
diff --git a/external/docs/content/docs/CodingGuidelines/2.0.5.html b/external/docs/content/docs/CodingGuidelines/2.0.5.html
new file mode 100644
index 0000000000..7e52001ed0
--- /dev/null
+++ b/external/docs/content/docs/CodingGuidelines/2.0.5.html
@@ -0,0 +1,586 @@
+---
+### DO NOT EDIT! Generated by script/update-docs.rb
+
+category: manual
+section: documentation
+subsection: manual
+title: Git - CodingGuidelines Documentation
+docname: CodingGuidelines
+version: 2.0.5
+aliases:
+- "/docs/CodingGuidelines/2.0.5/index.html"
+---
+<div id="preamble">
+<div class="sectionbody">
+<div class="paragraph">
+<p>Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, three rough rules are:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most importantly, we never say "It&#8217;s in POSIX; we&#8217;ll happily
+ignore your needs should your system not conform to it."
+We live in the real world.</p>
+</li>
+<li>
+<p>However, we often say "Let&#8217;s stay away from that construct,
+it&#8217;s not even in POSIX".</p>
+</li>
+<li>
+<p>In spite of the above two rules, we sometimes say "Although
+this is not in POSIX, it (is so convenient | makes the code
+much more readable | has other good characteristics) and
+practically all the platforms we care about support it, so
+let&#8217;s use it".</p>
+<div class="literalblock">
+<div class="content">
+<pre>Again, we live in the real world, and it is sometimes a
+judgement call, the decision based more on real world
+constraints people face than what the paper standard says.</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Make your code readable and sensible, and don&#8217;t try to be clever.</p>
+</div>
+<div class="paragraph">
+<p>As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the <em>local</em>
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn&#8217;t match the overall style of existing code).</p>
+</div>
+<div class="paragraph">
+<p>But if you must have a list of rules, here they are.</p>
+</div>
+<div class="paragraph">
+<p>For shell scripts specifically (not exhaustive):</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs for indentation.</p>
+</li>
+<li>
+<p>Case arms are indented at the same depth as case and esac lines.</p>
+</li>
+<li>
+<p>Redirection operators should be written with space before, but no
+space after them.  In other words, write <em>echo test &gt;"$file"</em>
+instead of <em>echo test&gt; $file</em> or <em>echo test &gt; $file</em>.  Note that
+even though it is not required by POSIX to double-quote the
+redirection target in a variable (as shown above), our code does so
+because some versions of bash issue a warning without the quotes.</p>
+</li>
+<li>
+<p>We prefer $( &#8230;&#8203; ) for command substitution; unlike ``, it
+properly nests.  It should have been the way Bourne spelled
+it from day one, but unfortunately isn&#8217;t.</p>
+</li>
+<li>
+<p>If you want to find out if a command is available on the user&#8217;s
+$PATH, you should use <em>type &lt;command&gt;</em>, instead of <em>which &lt;command&gt;</em>.
+The output of <em>which</em> is not machine parseable and its exit code
+is not reliable across platforms.</p>
+</li>
+<li>
+<p>We use POSIX compliant parameter substitutions and avoid bashisms;
+namely:</p>
+</li>
+<li>
+<p>We use ${parameter-word} and its [-=?+] siblings, and their
+colon&#8217;ed "unset or null" form.</p>
+</li>
+<li>
+<p>We use ${parameter#word} and its [#%] siblings, and their
+doubled "longest matching" form.</p>
+</li>
+<li>
+<p>No "Substring Expansion" ${parameter:offset:length}.</p>
+</li>
+<li>
+<p>No shell arrays.</p>
+</li>
+<li>
+<p>No strlen ${#parameter}.</p>
+</li>
+<li>
+<p>No pattern replacement ${parameter/pattern/string}.</p>
+</li>
+<li>
+<p>We use Arithmetic Expansion $&#8230;&#8203;.</p>
+</li>
+<li>
+<p>Inside Arithmetic Expansion, spell shell variables with $ in front
+of them, as some shells do not grok $x while accepting $$x
+just fine (e.g. dash older than 0.5.4).</p>
+</li>
+<li>
+<p>We do not use Process Substitution &lt;(list) or &gt;(list).</p>
+</li>
+<li>
+<p>Do not write control structures on a single line with semicolon.
+"then" should be on the next line for if statements, and "do"
+should be on the next line for "while" and "for".</p>
+</li>
+<li>
+<p>We prefer "test" over "[ &#8230;&#8203; ]".</p>
+</li>
+<li>
+<p>We do not write the noiseword "function" in front of shell
+functions.</p>
+</li>
+<li>
+<p>We prefer a space between the function name and the parentheses. The
+opening "{" should also be on the same line.
+E.g.: my_function () {</p>
+</li>
+<li>
+<p>As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+[::], [==], or [..]) for portability.</p>
+</li>
+<li>
+<p>We do not use \{m,n\};</p>
+</li>
+<li>
+<p>We do not use -E;</p>
+</li>
+<li>
+<p>We do not use ? or + (which are \{0,1\} and \{1,\}
+respectively in BRE) but that goes without saying as these
+are ERE elements not BRE (note that \? and \+ are not even part
+of BRE&#8201;&#8212;&#8201;making them accessible from BRE is a GNU extension).</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers in git-sh-i18n to make the user
+interface translatable. See "Marking strings for translation" in
+po/README.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For C programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs to indent, and interpret tabs as taking up to
+8 spaces.</p>
+</li>
+<li>
+<p>We try to keep to at most 80 characters per line.</p>
+</li>
+<li>
+<p>We try to support a wide range of C compilers to compile Git with,
+including old ones. That means that you should not use C99
+initializers, even if a lot of compilers grok it.</p>
+</li>
+<li>
+<p>Variables have to be declared at the beginning of the block.</p>
+</li>
+<li>
+<p>NULL pointers shall be written as NULL, not as 0.</p>
+</li>
+<li>
+<p>When declaring pointers, the star sides with the variable
+name, i.e. "char <strong>string", not "char</strong> string" or
+"char * string".  This makes it easier to understand code
+like "char *string, c;".</p>
+</li>
+<li>
+<p>Use whitespace around operators and keywords, but not inside
+parentheses and not around functions. So:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      while (condition)
+func(bar + 1);</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>      while( condition )
+func (bar+1);</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We avoid using braces unnecessarily.  I.e.</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (bla) {
+	x = 1;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is frowned upon.  A gray area is when the statement extends
+over a few lines, and/or you have a lengthy comment atop of
+it.  Also, like in the Linux kernel, if there is a long list
+of "else if" statements, it can make sense to add braces to
+single line blocks.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments inside if().</p>
+</li>
+<li>
+<p>Try to make your code understandable.  You may put comments
+in, but comments invariably tend to stale out when the code
+they were describing changes.  Often splitting a function
+into two makes the intention of the code much clearer.</p>
+</li>
+<li>
+<p>Multi-line comments include their delimiters on separate lines from
+the text.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * A very long
+ * multi-line comment.
+ */</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Note however that a comment that explains a translatable string to
+translators uses a convention of starting with a magic token
+"TRANSLATORS: " immediately after the opening delimiter, even when
+it spans multiple lines.  We do not add an asterisk at the beginning
+of each line, either.  E.g.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>/* TRANSLATORS: here is a comment that explains the string
+   to be translated, that follows immediately after it */
+_("Here is a translatable string explained by the above.");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Double negation is often harder to understand than no negation
+at all.</p>
+</li>
+<li>
+<p>Some clever tricks, like using the !! operator with arithmetic
+constructs, can be extremely confusing to others.  Avoid them,
+unless there is a compelling reason to use them.</p>
+</li>
+<li>
+<p>Use the API.  No, really.  We have a strbuf (variable length
+string), several arrays with the ALLOC_GROW() macro, a
+string_list for sorted string lists, a hash map (mapping struct
+objects) named "struct decorate", amongst other things.</p>
+</li>
+<li>
+<p>When you come up with an API, document it.</p>
+</li>
+<li>
+<p>The first #include in C files, except in platform specific
+compat/ implementations, should be git-compat-util.h or another
+header file that includes it, such as cache.h or builtin.h.</p>
+</li>
+<li>
+<p>If you are planning a new command, consider writing it in shell
+or perl first, so that changes in semantics can be easily
+changed and discussed.  Many Git commands started out like
+that, and a few are still scripts.</p>
+</li>
+<li>
+<p>Avoid introducing a new dependency into Git. This means you
+usually should stay away from scripting languages not already
+used in the Git core command set (unless your command is clearly
+separate from it, such as an importer to convert random-scm-X
+repositories to Git).</p>
+</li>
+<li>
+<p>When we pass &lt;string, length&gt; pair to functions, we should try to
+pass them in that order.</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers to make the user interface
+translatable. See "Marking strings for translation" in po/README.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Perl programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most of the C guidelines above apply.</p>
+</li>
+<li>
+<p>We try to support Perl 5.8 and later ("use Perl 5.008").</p>
+</li>
+<li>
+<p>use strict and use warnings are strongly preferred.</p>
+</li>
+<li>
+<p>Don&#8217;t overuse statement modifiers unless using them makes the
+result easier to follow.</p>
+<div class="olist lowerroman">
+<ol class="lowerroman" type="i">
+<li>
+<p>do something &#8230;&#8203;
+do_this() unless (condition);</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>is more readable than:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>do something &#8230;&#8203;
+unless (condition) {
+	do_this();
+}</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>*only* when the condition is so rare that do_this() will be almost
+always called.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments inside "if ()" conditions.</p>
+</li>
+<li>
+<p>Learn and use Git.pm if you need that functionality.</p>
+</li>
+<li>
+<p>For Emacs, it&#8217;s useful to put the following in
+GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode:</p>
+<div class="literalblock">
+<div class="content">
+<pre>;; note the first part is useful for C editing, too
+((nil . ((indent-tabs-mode . t)
+              (tab-width . 8)
+              (fill-column . 80)))
+ (cperl-mode . ((cperl-indent-level . 8)
+                (cperl-extra-newline-before-brace . nil)
+                (cperl-merge-trailing-else . t))))</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Python scripts:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We follow PEP-8 (<a href="http://www.python.org/dev/peps/pep-0008/" class="bare">http://www.python.org/dev/peps/pep-0008/</a>).</p>
+</li>
+<li>
+<p>As a minimum, we aim to be compatible with Python 2.6 and 2.7.</p>
+</li>
+<li>
+<p>Where required libraries do not restrict us to Python 2, we try to
+also be compatible with Python 3.1 and later.</p>
+</li>
+<li>
+<p>When you must differentiate between Unicode literals and byte string
+literals, it is OK to use the <em>b</em> prefix.  Even though the Python
+documentation for version 2.6 does not mention this prefix, it has
+been supported since version 2.6.0.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Error Messages</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Do not end error messages with a full stop.</p>
+</li>
+<li>
+<p>Do not capitalize ("unable to open %s", not "Unable to open %s")</p>
+</li>
+<li>
+<p>Say what the error is first ("cannot open %s", not "%s: cannot open")</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Writing Documentation:</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Most (if not all) of the documentation pages are written in the
+AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+processed into HTML and manpages (e.g. git.html and git.1 in the
+same directory).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>The documentation liberally mixes US and UK English (en_US/UK)
+norms for spelling and grammar, which is somewhat unfortunate.
+In an ideal world, it would have been better if it consistently
+used only one and not the other, and we would have picked en_US
+(if you wish to correct the English of some of the existing
+documentation, please see the documentation-related advice in the
+Documentation/SubmittingPatches file).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Every user-visible change should be reflected in the documentation.
+The same general rule as for code applies -- imitate the existing
+conventions.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying command usage strings and synopsis sections in the manual
+pages:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Placeholders are spelled in lowercase and enclosed in angle brackets:
+  &lt;file&gt;
+  --sort=&lt;key&gt;
+  --abbrev[=&lt;n&gt;]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Possibility of multiple occurrences is indicated by three dots:
+  &lt;file&gt;...
+  (One or more of &lt;file&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Optional parts are enclosed in square brackets:
+  [&lt;extra&gt;]
+  (Zero or one &lt;extra&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>--exec-path[=&lt;path&gt;]
+(Option with an optional argument.  Note that the "=" is inside the
+brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[&lt;patch&gt;...]
+(Zero or more of &lt;patch&gt;.  Note that the dots are inside, not
+outside the brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Multiple alternatives are indicated with vertical bar:
+  [-q | --quiet]
+  [--utf8 | --no-utf8]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Parentheses are used for grouping:
+  [(&lt;rev&gt;|&lt;range&gt;)...]
+  (Any number of either &lt;rev&gt; or &lt;range&gt;.  Parens are needed to make
+  it clear that "..." pertains to both &lt;rev&gt; and &lt;range&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[(-p &lt;parent&gt;)...]
+(Any number of option -p, each with one &lt;parent&gt; argument.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>git remote set-head &lt;name&gt; (-a | -d | &lt;branch&gt;)
+(One and only one of "-a", "-d" or "&lt;branch&gt;" _must_ (no square
+brackets) be provided.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>And a somewhat more contrived example:
+  --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+  Here "=" is outside the brackets, because "--diff-filter=" is a
+  valid usage.  "*" has its own pair of brackets, because it can
+  (optionally) be specified only when one or more of the letters is
+  also provided.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A note on notation:
+ Use 'git' (all lowercase) when talking about commands i.e. something
+ the user would type into a shell and use 'Git' (uppercase first letter)
+ when talking about the version control system and its properties.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying paragraphs or option/command explanations that contain options
+or commands:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Literal examples (e.g. use of command-line options, command names, and
+configuration variables) are typeset in monospace, and if you can use
+`backticks around word phrases`, do so.
+  `--pretty=oneline`
+  `git rev-list`
+  `remote.pushdefault`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Word phrases enclosed in `backtick characters` are rendered literally
+and will not be further expanded. The use of `backticks` to achieve the
+previous rule means that literal examples should not use AsciiDoc
+escapes.
+  Correct:
+     `--pretty=oneline`
+  Incorrect:
+     `\--pretty=oneline`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If some place in the documentation needs to typeset a command usage
+example with inline substitutions, it is fine to use +monospaced and
+inline substituted text+ instead of `monospaced literal text`, and with
+the former, the part that should not get substituted must be
+quoted/escaped.</pre>
+</div>
+</div>
+</div>
+</div>
\ No newline at end of file
diff --git a/external/docs/content/docs/CodingGuidelines/2.1.4.html b/external/docs/content/docs/CodingGuidelines/2.1.4.html
new file mode 100644
index 0000000000..16f9dc4414
--- /dev/null
+++ b/external/docs/content/docs/CodingGuidelines/2.1.4.html
@@ -0,0 +1,813 @@
+---
+### DO NOT EDIT! Generated by script/update-docs.rb
+
+category: manual
+section: documentation
+subsection: manual
+title: Git - CodingGuidelines Documentation
+docname: CodingGuidelines
+version: 2.1.4
+aliases:
+- "/docs/CodingGuidelines/2.1.4/index.html"
+- "/docs/CodingGuidelines/2.2.3/index.html"
+---
+<div id="preamble">
+<div class="sectionbody">
+<div class="paragraph">
+<p>Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, three rough rules are:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most importantly, we never say "It&#8217;s in POSIX; we&#8217;ll happily
+ignore your needs should your system not conform to it."
+We live in the real world.</p>
+</li>
+<li>
+<p>However, we often say "Let&#8217;s stay away from that construct,
+it&#8217;s not even in POSIX".</p>
+</li>
+<li>
+<p>In spite of the above two rules, we sometimes say "Although
+this is not in POSIX, it (is so convenient | makes the code
+much more readable | has other good characteristics) and
+practically all the platforms we care about support it, so
+let&#8217;s use it".</p>
+<div class="literalblock">
+<div class="content">
+<pre>Again, we live in the real world, and it is sometimes a
+judgement call, the decision based more on real world
+constraints people face than what the paper standard says.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Fixing style violations while working on a real change as a
+preparatory clean-up step is good, but otherwise avoid useless code
+churn for the sake of conforming to the style.</p>
+<div class="literalblock">
+<div class="content">
+<pre>"Once it _is_ in the tree, it's not really worth the patch noise to
+go and fix it up."
+Cf. http://article.gmane.org/gmane.linux.kernel/943020</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Make your code readable and sensible, and don&#8217;t try to be clever.</p>
+</div>
+<div class="paragraph">
+<p>As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the <em>local</em>
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn&#8217;t match the overall style of existing code).</p>
+</div>
+<div class="paragraph">
+<p>But if you must have a list of rules, here they are.</p>
+</div>
+<div class="paragraph">
+<p>For shell scripts specifically (not exhaustive):</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs for indentation.</p>
+</li>
+<li>
+<p>Case arms are indented at the same depth as case and esac lines,
+like this:</p>
+<div class="literalblock">
+<div class="content">
+<pre>case "$variable" in
+pattern1)
+	do this
+	;;
+pattern2)
+	do that
+	;;
+esac</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Redirection operators should be written with space before, but no
+space after them.  In other words, write <em>echo test &gt;"$file"</em>
+instead of <em>echo test&gt; $file</em> or <em>echo test &gt; $file</em>.  Note that
+even though it is not required by POSIX to double-quote the
+redirection target in a variable (as shown above), our code does so
+because some versions of bash issue a warning without the quotes.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+cat hello &gt; world &lt; universe
+echo hello &gt;$world</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+cat hello &gt;world &lt;universe
+echo hello &gt;"$world"</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer $( &#8230;&#8203; ) for command substitution; unlike ``, it
+properly nests.  It should have been the way Bourne spelled
+it from day one, but unfortunately isn&#8217;t.</p>
+</li>
+<li>
+<p>If you want to find out if a command is available on the user&#8217;s
+$PATH, you should use <em>type &lt;command&gt;</em>, instead of <em>which &lt;command&gt;</em>.
+The output of <em>which</em> is not machine parseable and its exit code
+is not reliable across platforms.</p>
+</li>
+<li>
+<p>We use POSIX compliant parameter substitutions and avoid bashisms;
+namely:</p>
+</li>
+<li>
+<p>We use ${parameter-word} and its [-=?+] siblings, and their
+colon&#8217;ed "unset or null" form.</p>
+</li>
+<li>
+<p>We use ${parameter#word} and its [#%] siblings, and their
+doubled "longest matching" form.</p>
+</li>
+<li>
+<p>No "Substring Expansion" ${parameter:offset:length}.</p>
+</li>
+<li>
+<p>No shell arrays.</p>
+</li>
+<li>
+<p>No strlen ${#parameter}.</p>
+</li>
+<li>
+<p>No pattern replacement ${parameter/pattern/string}.</p>
+</li>
+<li>
+<p>We use Arithmetic Expansion $&#8230;&#8203;.</p>
+</li>
+<li>
+<p>Inside Arithmetic Expansion, spell shell variables with $ in front
+of them, as some shells do not grok $x while accepting $$x
+just fine (e.g. dash older than 0.5.4).</p>
+</li>
+<li>
+<p>We do not use Process Substitution &lt;(list) or &gt;(list).</p>
+</li>
+<li>
+<p>Do not write control structures on a single line with semicolon.
+"then" should be on the next line for if statements, and "do"
+should be on the next line for "while" and "for".</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+if test -f hello; then
+	do this
+fi</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+if test -f hello
+then
+	do this
+fi</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer "test" over "[ &#8230;&#8203; ]".</p>
+</li>
+<li>
+<p>We do not write the noiseword "function" in front of shell
+functions.</p>
+</li>
+<li>
+<p>We prefer a space between the function name and the parentheses,
+and no space inside the parentheses. The opening "{" should also
+be on the same line.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+my_function(){
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+my_function () {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+[::], [==], or [..]) for portability.</p>
+</li>
+<li>
+<p>We do not use \{m,n\};</p>
+</li>
+<li>
+<p>We do not use -E;</p>
+</li>
+<li>
+<p>We do not use ? or + (which are \{0,1\} and \{1,\}
+respectively in BRE) but that goes without saying as these
+are ERE elements not BRE (note that \? and \+ are not even part
+of BRE&#8201;&#8212;&#8201;making them accessible from BRE is a GNU extension).</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers in git-sh-i18n to make the user
+interface translatable. See "Marking strings for translation" in
+po/README.</p>
+</li>
+<li>
+<p>We do not write our "test" command with "-a" and "-o" and use "&amp;&amp;"
+or "||" to concatenate multiple "test" commands instead, because
+the use of "-a/-o" is often error-prone.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" -a "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is buggy and breaks when $x is "=", but</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" &amp;&amp; test "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>does not have such a problem.</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For C programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs to indent, and interpret tabs as taking up to
+8 spaces.</p>
+</li>
+<li>
+<p>We try to keep to at most 80 characters per line.</p>
+</li>
+<li>
+<p>We try to support a wide range of C compilers to compile Git with,
+including old ones. That means that you should not use C99
+initializers, even if a lot of compilers grok it.</p>
+</li>
+<li>
+<p>Variables have to be declared at the beginning of the block.</p>
+</li>
+<li>
+<p>NULL pointers shall be written as NULL, not as 0.</p>
+</li>
+<li>
+<p>When declaring pointers, the star sides with the variable
+name, i.e. "char <strong>string", not "char</strong> string" or
+"char * string".  This makes it easier to understand code
+like "char *string, c;".</p>
+</li>
+<li>
+<p>Use whitespace around operators and keywords, but not inside
+parentheses and not around functions. So:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      while (condition)
+func(bar + 1);</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>      while( condition )
+func (bar+1);</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We avoid using braces unnecessarily.  I.e.</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (bla) {
+	x = 1;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is frowned upon.  A gray area is when the statement extends
+over a few lines, and/or you have a lengthy comment atop of
+it.  Also, like in the Linux kernel, if there is a long list
+of "else if" statements, it can make sense to add braces to
+single line blocks.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments in the condition of an "if" statement.</p>
+</li>
+<li>
+<p>Try to make your code understandable.  You may put comments
+in, but comments invariably tend to stale out when the code
+they were describing changes.  Often splitting a function
+into two makes the intention of the code much clearer.</p>
+</li>
+<li>
+<p>Multi-line comments include their delimiters on separate lines from
+the text.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * A very long
+ * multi-line comment.
+ */</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Note however that a comment that explains a translatable string to
+translators uses a convention of starting with a magic token
+"TRANSLATORS: " immediately after the opening delimiter, even when
+it spans multiple lines.  We do not add an asterisk at the beginning
+of each line, either.  E.g.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>/* TRANSLATORS: here is a comment that explains the string
+   to be translated, that follows immediately after it */
+_("Here is a translatable string explained by the above.");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Double negation is often harder to understand than no negation
+at all.</p>
+</li>
+<li>
+<p>There are two schools of thought when it comes to comparison,
+especially inside a loop. Some people prefer to have the less stable
+value on the left hand side and the more stable value on the right hand
+side, e.g. if you have a loop that counts variable i down to the
+lower bound,</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (i &gt; lower_bound) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Other people prefer to have the textual order of values match the
+actual order of values in their comparison, so that they can
+mentally draw a number line from left to right and place these
+values in order, i.e.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while (lower_bound &lt; i) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  However, the more "stable" the
+stable side becomes, the more we tend to prefer the former
+(comparison with a constant, "i &gt; 0", is an extreme example).
+Just do not mix styles in the same part of the code and mimic
+existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>There are two schools of thought when it comes to splitting a long
+logical line into multiple lines.  Some people push the second and
+subsequent lines far enough to the right with tabs and align them:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+              ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to align the second and the subsequent
+lines with the column immediately inside the opening parenthesis,
+with tabs and spaces, following our "tabstop is always a multiple
+of 8" convention:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+           ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  Again, just do not mix styles in
+the same part of the code and mimic existing styles in the
+neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, some people change line before
+a binary operator, so that the result looks like a parse tree when
+you turn your head 90-degrees counterclockwise:</p>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to
+|| span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to leave the operator at the end of the
+line:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, but we tend to use the latter more, unless the
+expression gets fairly complex, in which case the former tends to
+be easier to read.  Again, just do not mix styles in the same part
+of the code and mimic existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, with everything else being
+equal, it is preferable to split after the operator at higher
+level in the parse tree.  That is, this is more preferable:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable * that_is_used_in +
+    a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>than</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable *
+    that_is_used_in + a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Some clever tricks, like using the !! operator with arithmetic
+constructs, can be extremely confusing to others.  Avoid them,
+unless there is a compelling reason to use them.</p>
+</li>
+<li>
+<p>Use the API.  No, really.  We have a strbuf (variable length
+string), several arrays with the ALLOC_GROW() macro, a
+string_list for sorted string lists, a hash map (mapping struct
+objects) named "struct decorate", amongst other things.</p>
+</li>
+<li>
+<p>When you come up with an API, document it.</p>
+</li>
+<li>
+<p>The first #include in C files, except in platform specific
+compat/ implementations, should be git-compat-util.h or another
+header file that includes it, such as cache.h or builtin.h.</p>
+</li>
+<li>
+<p>If you are planning a new command, consider writing it in shell
+or perl first, so that changes in semantics can be easily
+changed and discussed.  Many Git commands started out like
+that, and a few are still scripts.</p>
+</li>
+<li>
+<p>Avoid introducing a new dependency into Git. This means you
+usually should stay away from scripting languages not already
+used in the Git core command set (unless your command is clearly
+separate from it, such as an importer to convert random-scm-X
+repositories to Git).</p>
+</li>
+<li>
+<p>When we pass &lt;string, length&gt; pair to functions, we should try to
+pass them in that order.</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers to make the user interface
+translatable. See "Marking strings for translation" in po/README.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Perl programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most of the C guidelines above apply.</p>
+</li>
+<li>
+<p>We try to support Perl 5.8 and later ("use Perl 5.008").</p>
+</li>
+<li>
+<p>use strict and use warnings are strongly preferred.</p>
+</li>
+<li>
+<p>Don&#8217;t overuse statement modifiers unless using them makes the
+result easier to follow.</p>
+<div class="olist lowerroman">
+<ol class="lowerroman" type="i">
+<li>
+<p>do something &#8230;&#8203;
+do_this() unless (condition);</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>is more readable than:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>do something &#8230;&#8203;
+unless (condition) {
+	do_this();
+}</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>*only* when the condition is so rare that do_this() will be almost
+always called.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments inside "if ()" conditions.</p>
+</li>
+<li>
+<p>Learn and use Git.pm if you need that functionality.</p>
+</li>
+<li>
+<p>For Emacs, it&#8217;s useful to put the following in
+GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode:</p>
+<div class="literalblock">
+<div class="content">
+<pre>;; note the first part is useful for C editing, too
+((nil . ((indent-tabs-mode . t)
+              (tab-width . 8)
+              (fill-column . 80)))
+ (cperl-mode . ((cperl-indent-level . 8)
+                (cperl-extra-newline-before-brace . nil)
+                (cperl-merge-trailing-else . t))))</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Python scripts:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We follow PEP-8 (<a href="http://www.python.org/dev/peps/pep-0008/" class="bare">http://www.python.org/dev/peps/pep-0008/</a>).</p>
+</li>
+<li>
+<p>As a minimum, we aim to be compatible with Python 2.6 and 2.7.</p>
+</li>
+<li>
+<p>Where required libraries do not restrict us to Python 2, we try to
+also be compatible with Python 3.1 and later.</p>
+</li>
+<li>
+<p>When you must differentiate between Unicode literals and byte string
+literals, it is OK to use the <em>b</em> prefix.  Even though the Python
+documentation for version 2.6 does not mention this prefix, it has
+been supported since version 2.6.0.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Error Messages</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Do not end error messages with a full stop.</p>
+</li>
+<li>
+<p>Do not capitalize ("unable to open %s", not "Unable to open %s")</p>
+</li>
+<li>
+<p>Say what the error is first ("cannot open %s", not "%s: cannot open")</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Writing Documentation:</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Most (if not all) of the documentation pages are written in the
+AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+processed into HTML and manpages (e.g. git.html and git.1 in the
+same directory).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>The documentation liberally mixes US and UK English (en_US/UK)
+norms for spelling and grammar, which is somewhat unfortunate.
+In an ideal world, it would have been better if it consistently
+used only one and not the other, and we would have picked en_US
+(if you wish to correct the English of some of the existing
+documentation, please see the documentation-related advice in the
+Documentation/SubmittingPatches file).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Every user-visible change should be reflected in the documentation.
+The same general rule as for code applies -- imitate the existing
+conventions.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying command usage strings and synopsis sections in the manual
+pages:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Placeholders are spelled in lowercase and enclosed in angle brackets:
+  &lt;file&gt;
+  --sort=&lt;key&gt;
+  --abbrev[=&lt;n&gt;]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Possibility of multiple occurrences is indicated by three dots:
+  &lt;file&gt;...
+  (One or more of &lt;file&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Optional parts are enclosed in square brackets:
+  [&lt;extra&gt;]
+  (Zero or one &lt;extra&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>--exec-path[=&lt;path&gt;]
+(Option with an optional argument.  Note that the "=" is inside the
+brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[&lt;patch&gt;...]
+(Zero or more of &lt;patch&gt;.  Note that the dots are inside, not
+outside the brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Multiple alternatives are indicated with vertical bar:
+  [-q | --quiet]
+  [--utf8 | --no-utf8]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Parentheses are used for grouping:
+  [(&lt;rev&gt;|&lt;range&gt;)...]
+  (Any number of either &lt;rev&gt; or &lt;range&gt;.  Parens are needed to make
+  it clear that "..." pertains to both &lt;rev&gt; and &lt;range&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[(-p &lt;parent&gt;)...]
+(Any number of option -p, each with one &lt;parent&gt; argument.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>git remote set-head &lt;name&gt; (-a | -d | &lt;branch&gt;)
+(One and only one of "-a", "-d" or "&lt;branch&gt;" _must_ (no square
+brackets) be provided.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>And a somewhat more contrived example:
+  --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+  Here "=" is outside the brackets, because "--diff-filter=" is a
+  valid usage.  "*" has its own pair of brackets, because it can
+  (optionally) be specified only when one or more of the letters is
+  also provided.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A note on notation:
+ Use 'git' (all lowercase) when talking about commands i.e. something
+ the user would type into a shell and use 'Git' (uppercase first letter)
+ when talking about the version control system and its properties.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying paragraphs or option/command explanations that contain options
+or commands:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Literal examples (e.g. use of command-line options, command names, and
+configuration variables) are typeset in monospace, and if you can use
+`backticks around word phrases`, do so.
+  `--pretty=oneline`
+  `git rev-list`
+  `remote.pushdefault`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Word phrases enclosed in `backtick characters` are rendered literally
+and will not be further expanded. The use of `backticks` to achieve the
+previous rule means that literal examples should not use AsciiDoc
+escapes.
+  Correct:
+     `--pretty=oneline`
+  Incorrect:
+     `\--pretty=oneline`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If some place in the documentation needs to typeset a command usage
+example with inline substitutions, it is fine to use +monospaced and
+inline substituted text+ instead of `monospaced literal text`, and with
+the former, the part that should not get substituted must be
+quoted/escaped.</pre>
+</div>
+</div>
+</div>
+</div>
\ No newline at end of file
diff --git a/external/docs/content/docs/CodingGuidelines/2.11.4.html b/external/docs/content/docs/CodingGuidelines/2.11.4.html
new file mode 100644
index 0000000000..412d0770c8
--- /dev/null
+++ b/external/docs/content/docs/CodingGuidelines/2.11.4.html
@@ -0,0 +1,922 @@
+---
+### DO NOT EDIT! Generated by script/update-docs.rb
+
+category: manual
+section: documentation
+subsection: manual
+title: Git - CodingGuidelines Documentation
+docname: CodingGuidelines
+version: 2.11.4
+aliases:
+- "/docs/CodingGuidelines/2.11.4/index.html"
+- "/docs/CodingGuidelines/2.12.5/index.html"
+---
+<div id="preamble">
+<div class="sectionbody">
+<div class="paragraph">
+<p>Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, a few rough rules are:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most importantly, we never say "It&#8217;s in POSIX; we&#8217;ll happily
+ignore your needs should your system not conform to it."
+We live in the real world.</p>
+</li>
+<li>
+<p>However, we often say "Let&#8217;s stay away from that construct,
+it&#8217;s not even in POSIX".</p>
+</li>
+<li>
+<p>In spite of the above two rules, we sometimes say "Although
+this is not in POSIX, it (is so convenient | makes the code
+much more readable | has other good characteristics) and
+practically all the platforms we care about support it, so
+let&#8217;s use it".</p>
+<div class="literalblock">
+<div class="content">
+<pre>Again, we live in the real world, and it is sometimes a
+judgement call, the decision based more on real world
+constraints people face than what the paper standard says.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Fixing style violations while working on a real change as a
+preparatory clean-up step is good, but otherwise avoid useless code
+churn for the sake of conforming to the style.</p>
+<div class="literalblock">
+<div class="content">
+<pre>"Once it _is_ in the tree, it's not really worth the patch noise to
+go and fix it up."
+Cf. http://article.gmane.org/gmane.linux.kernel/943020</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Make your code readable and sensible, and don&#8217;t try to be clever.</p>
+</div>
+<div class="paragraph">
+<p>As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the <em>local</em>
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn&#8217;t match the overall style of existing code).</p>
+</div>
+<div class="paragraph">
+<p>But if you must have a list of rules, here they are.</p>
+</div>
+<div class="paragraph">
+<p>For shell scripts specifically (not exhaustive):</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs for indentation.</p>
+</li>
+<li>
+<p>Case arms are indented at the same depth as case and esac lines,
+like this:</p>
+<div class="literalblock">
+<div class="content">
+<pre>case "$variable" in
+pattern1)
+	do this
+	;;
+pattern2)
+	do that
+	;;
+esac</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Redirection operators should be written with space before, but no
+space after them.  In other words, write <em>echo test &gt;"$file"</em>
+instead of <em>echo test&gt; $file</em> or <em>echo test &gt; $file</em>.  Note that
+even though it is not required by POSIX to double-quote the
+redirection target in a variable (as shown above), our code does so
+because some versions of bash issue a warning without the quotes.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+cat hello &gt; world &lt; universe
+echo hello &gt;$world</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+cat hello &gt;world &lt;universe
+echo hello &gt;"$world"</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer $( &#8230;&#8203; ) for command substitution; unlike ``, it
+properly nests.  It should have been the way Bourne spelled
+it from day one, but unfortunately isn&#8217;t.</p>
+</li>
+<li>
+<p>If you want to find out if a command is available on the user&#8217;s
+$PATH, you should use <em>type &lt;command&gt;</em>, instead of <em>which &lt;command&gt;</em>.
+The output of <em>which</em> is not machine parseable and its exit code
+is not reliable across platforms.</p>
+</li>
+<li>
+<p>We use POSIX compliant parameter substitutions and avoid bashisms;
+namely:</p>
+</li>
+<li>
+<p>We use ${parameter-word} and its [-=?+] siblings, and their
+colon&#8217;ed "unset or null" form.</p>
+</li>
+<li>
+<p>We use ${parameter#word} and its [#%] siblings, and their
+doubled "longest matching" form.</p>
+</li>
+<li>
+<p>No "Substring Expansion" ${parameter:offset:length}.</p>
+</li>
+<li>
+<p>No shell arrays.</p>
+</li>
+<li>
+<p>No strlen ${#parameter}.</p>
+</li>
+<li>
+<p>No pattern replacement ${parameter/pattern/string}.</p>
+</li>
+<li>
+<p>We use Arithmetic Expansion $&#8230;&#8203;.</p>
+</li>
+<li>
+<p>Inside Arithmetic Expansion, spell shell variables with $ in front
+of them, as some shells do not grok $x while accepting $$x
+just fine (e.g. dash older than 0.5.4).</p>
+</li>
+<li>
+<p>We do not use Process Substitution &lt;(list) or &gt;(list).</p>
+</li>
+<li>
+<p>Do not write control structures on a single line with semicolon.
+"then" should be on the next line for if statements, and "do"
+should be on the next line for "while" and "for".</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+if test -f hello; then
+	do this
+fi</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+if test -f hello
+then
+	do this
+fi</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer "test" over "[ &#8230;&#8203; ]".</p>
+</li>
+<li>
+<p>We do not write the noiseword "function" in front of shell
+functions.</p>
+</li>
+<li>
+<p>We prefer a space between the function name and the parentheses,
+and no space inside the parentheses. The opening "{" should also
+be on the same line.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+my_function(){
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+my_function () {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+[::], [==], or [..]) for portability.</p>
+</li>
+<li>
+<p>We do not use \{m,n\};</p>
+</li>
+<li>
+<p>We do not use -E;</p>
+</li>
+<li>
+<p>We do not use ? or + (which are \{0,1\} and \{1,\}
+respectively in BRE) but that goes without saying as these
+are ERE elements not BRE (note that \? and \+ are not even part
+of BRE&#8201;&#8212;&#8201;making them accessible from BRE is a GNU extension).</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers in git-sh-i18n to make the user
+interface translatable. See "Marking strings for translation" in
+po/README.</p>
+</li>
+<li>
+<p>We do not write our "test" command with "-a" and "-o" and use "&amp;&amp;"
+or "||" to concatenate multiple "test" commands instead, because
+the use of "-a/-o" is often error-prone.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" -a "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is buggy and breaks when $x is "=", but</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" &amp;&amp; test "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>does not have such a problem.</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For C programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs to indent, and interpret tabs as taking up to
+8 spaces.</p>
+</li>
+<li>
+<p>We try to keep to at most 80 characters per line.</p>
+</li>
+<li>
+<p>As a Git developer we assume you have a reasonably modern compiler
+and we recommend you to enable the DEVELOPER makefile knob to
+ensure your patch is clear of all compiler warnings we care about,
+by e.g. "echo DEVELOPER=1 &gt;&gt;config.mak".</p>
+</li>
+<li>
+<p>We try to support a wide range of C compilers to compile Git with,
+including old ones. That means that you should not use C99
+initializers, even if a lot of compilers grok it.</p>
+</li>
+<li>
+<p>Variables have to be declared at the beginning of the block.</p>
+</li>
+<li>
+<p>NULL pointers shall be written as NULL, not as 0.</p>
+</li>
+<li>
+<p>When declaring pointers, the star sides with the variable
+name, i.e. "char <strong>string", not "char</strong> string" or
+"char * string".  This makes it easier to understand code
+like "char *string, c;".</p>
+</li>
+<li>
+<p>Use whitespace around operators and keywords, but not inside
+parentheses and not around functions. So:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      while (condition)
+func(bar + 1);</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>      while( condition )
+func (bar+1);</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We avoid using braces unnecessarily.  I.e.</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (bla) {
+	x = 1;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is frowned upon. But there are a few exceptions:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When the statement extends over a few lines (e.g., a while loop
+with an embedded conditional, or a comment). E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (foo) {
+	if (x)
+		one();
+	else
+		two();
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	/*
+	 * This one requires some explanation,
+	 * so we're better off with braces to make
+	 * it obvious that the indentation is correct.
+	 */
+	doit();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When there are multiple arms to a conditional and some of them
+require braces, enclose even a single line block in braces for
+consistency. E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	doit();
+} else {
+	one();
+	two();
+	three();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments in the condition of an "if" statement.</p>
+</li>
+<li>
+<p>Try to make your code understandable.  You may put comments
+in, but comments invariably tend to stale out when the code
+they were describing changes.  Often splitting a function
+into two makes the intention of the code much clearer.</p>
+</li>
+<li>
+<p>Multi-line comments include their delimiters on separate lines from
+the text.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * A very long
+ * multi-line comment.
+ */</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Note however that a comment that explains a translatable string to
+translators uses a convention of starting with a magic token
+"TRANSLATORS: " immediately after the opening delimiter, even when
+it spans multiple lines.  We do not add an asterisk at the beginning
+of each line, either.  E.g.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>/* TRANSLATORS: here is a comment that explains the string
+   to be translated, that follows immediately after it */
+_("Here is a translatable string explained by the above.");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Double negation is often harder to understand than no negation
+at all.</p>
+</li>
+<li>
+<p>There are two schools of thought when it comes to comparison,
+especially inside a loop. Some people prefer to have the less stable
+value on the left hand side and the more stable value on the right hand
+side, e.g. if you have a loop that counts variable i down to the
+lower bound,</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (i &gt; lower_bound) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Other people prefer to have the textual order of values match the
+actual order of values in their comparison, so that they can
+mentally draw a number line from left to right and place these
+values in order, i.e.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while (lower_bound &lt; i) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  However, the more "stable" the
+stable side becomes, the more we tend to prefer the former
+(comparison with a constant, "i &gt; 0", is an extreme example).
+Just do not mix styles in the same part of the code and mimic
+existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>There are two schools of thought when it comes to splitting a long
+logical line into multiple lines.  Some people push the second and
+subsequent lines far enough to the right with tabs and align them:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+              ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to align the second and the subsequent
+lines with the column immediately inside the opening parenthesis,
+with tabs and spaces, following our "tabstop is always a multiple
+of 8" convention:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+           ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  Again, just do not mix styles in
+the same part of the code and mimic existing styles in the
+neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, some people change line before
+a binary operator, so that the result looks like a parse tree when
+you turn your head 90-degrees counterclockwise:</p>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to
+|| span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to leave the operator at the end of the
+line:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, but we tend to use the latter more, unless the
+expression gets fairly complex, in which case the former tends to
+be easier to read.  Again, just do not mix styles in the same part
+of the code and mimic existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, with everything else being
+equal, it is preferable to split after the operator at higher
+level in the parse tree.  That is, this is more preferable:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable * that_is_used_in +
+    a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>than</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable *
+    that_is_used_in + a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Some clever tricks, like using the !! operator with arithmetic
+constructs, can be extremely confusing to others.  Avoid them,
+unless there is a compelling reason to use them.</p>
+</li>
+<li>
+<p>Use the API.  No, really.  We have a strbuf (variable length
+string), several arrays with the ALLOC_GROW() macro, a
+string_list for sorted string lists, a hash map (mapping struct
+objects) named "struct decorate", amongst other things.</p>
+</li>
+<li>
+<p>When you come up with an API, document it.</p>
+</li>
+<li>
+<p>The first #include in C files, except in platform specific compat/
+implementations, must be either "git-compat-util.h", "cache.h" or
+"builtin.h".  You do not have to include more than one of these.</p>
+</li>
+<li>
+<p>A C file must directly include the header files that declare the
+functions and the types it uses, except for the functions and types
+that are made available to it by including one of the header files
+it must include by the previous rule.</p>
+</li>
+<li>
+<p>If you are planning a new command, consider writing it in shell
+or perl first, so that changes in semantics can be easily
+changed and discussed.  Many Git commands started out like
+that, and a few are still scripts.</p>
+</li>
+<li>
+<p>Avoid introducing a new dependency into Git. This means you
+usually should stay away from scripting languages not already
+used in the Git core command set (unless your command is clearly
+separate from it, such as an importer to convert random-scm-X
+repositories to Git).</p>
+</li>
+<li>
+<p>When we pass &lt;string, length&gt; pair to functions, we should try to
+pass them in that order.</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers to make the user interface
+translatable. See "Marking strings for translation" in po/README.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Perl programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most of the C guidelines above apply.</p>
+</li>
+<li>
+<p>We try to support Perl 5.8 and later ("use Perl 5.008").</p>
+</li>
+<li>
+<p>use strict and use warnings are strongly preferred.</p>
+</li>
+<li>
+<p>Don&#8217;t overuse statement modifiers unless using them makes the
+result easier to follow.</p>
+<div class="olist lowerroman">
+<ol class="lowerroman" type="i">
+<li>
+<p>do something &#8230;&#8203;
+do_this() unless (condition);</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>is more readable than:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>do something &#8230;&#8203;
+unless (condition) {
+	do_this();
+}</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>*only* when the condition is so rare that do_this() will be almost
+always called.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments inside "if ()" conditions.</p>
+</li>
+<li>
+<p>Learn and use Git.pm if you need that functionality.</p>
+</li>
+<li>
+<p>For Emacs, it&#8217;s useful to put the following in
+GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode:</p>
+<div class="literalblock">
+<div class="content">
+<pre>;; note the first part is useful for C editing, too
+((nil . ((indent-tabs-mode . t)
+              (tab-width . 8)
+              (fill-column . 80)))
+ (cperl-mode . ((cperl-indent-level . 8)
+                (cperl-extra-newline-before-brace . nil)
+                (cperl-merge-trailing-else . t))))</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Python scripts:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We follow PEP-8 (<a href="http://www.python.org/dev/peps/pep-0008/" class="bare">http://www.python.org/dev/peps/pep-0008/</a>).</p>
+</li>
+<li>
+<p>As a minimum, we aim to be compatible with Python 2.6 and 2.7.</p>
+</li>
+<li>
+<p>Where required libraries do not restrict us to Python 2, we try to
+also be compatible with Python 3.1 and later.</p>
+</li>
+<li>
+<p>When you must differentiate between Unicode literals and byte string
+literals, it is OK to use the <em>b</em> prefix.  Even though the Python
+documentation for version 2.6 does not mention this prefix, it has
+been supported since version 2.6.0.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Error Messages</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Do not end error messages with a full stop.</p>
+</li>
+<li>
+<p>Do not capitalize ("unable to open %s", not "Unable to open %s")</p>
+</li>
+<li>
+<p>Say what the error is first ("cannot open %s", not "%s: cannot open")</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Externally Visible Names</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>For configuration variable names, follow the existing convention:</p>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>The section name indicates the affected subsystem.</p>
+</li>
+<li>
+<p>The subsection name, if any, indicates which of an unbounded set
+of things to set the value for.</p>
+</li>
+<li>
+<p>The variable name describes the effect of tweaking this knob.</p>
+<div class="literalblock">
+<div class="content">
+<pre>The section and variable names that consist of multiple words are
+formed by concatenating the words without punctuations (e.g. `-`),
+and are broken using bumpyCaps in documentation as a hint to the
+reader.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>When choosing the variable namespace, do not use variable name for
+specifying possibly unbounded set of things, most notably anything
+an end user can freely come up with (e.g. branch names).  Instead,
+use subsection names or variable values, like the existing variable
+branch.&lt;name&gt;.description does.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Writing Documentation:</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Most (if not all) of the documentation pages are written in the
+AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+processed into HTML and manpages (e.g. git.html and git.1 in the
+same directory).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>The documentation liberally mixes US and UK English (en_US/UK)
+norms for spelling and grammar, which is somewhat unfortunate.
+In an ideal world, it would have been better if it consistently
+used only one and not the other, and we would have picked en_US
+(if you wish to correct the English of some of the existing
+documentation, please see the documentation-related advice in the
+Documentation/SubmittingPatches file).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Every user-visible change should be reflected in the documentation.
+The same general rule as for code applies -- imitate the existing
+conventions.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying command usage strings and synopsis sections in the manual
+pages:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Placeholders are spelled in lowercase and enclosed in angle brackets:
+  &lt;file&gt;
+  --sort=&lt;key&gt;
+  --abbrev[=&lt;n&gt;]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If a placeholder has multiple words, they are separated by dashes:
+  &lt;new-branch-name&gt;
+  --template=&lt;template-directory&gt;</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Possibility of multiple occurrences is indicated by three dots:
+  &lt;file&gt;...
+  (One or more of &lt;file&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Optional parts are enclosed in square brackets:
+  [&lt;extra&gt;]
+  (Zero or one &lt;extra&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>--exec-path[=&lt;path&gt;]
+(Option with an optional argument.  Note that the "=" is inside the
+brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[&lt;patch&gt;...]
+(Zero or more of &lt;patch&gt;.  Note that the dots are inside, not
+outside the brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Multiple alternatives are indicated with vertical bars:
+  [-q | --quiet]
+  [--utf8 | --no-utf8]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Parentheses are used for grouping:
+  [(&lt;rev&gt; | &lt;range&gt;)...]
+  (Any number of either &lt;rev&gt; or &lt;range&gt;.  Parens are needed to make
+  it clear that "..." pertains to both &lt;rev&gt; and &lt;range&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[(-p &lt;parent&gt;)...]
+(Any number of option -p, each with one &lt;parent&gt; argument.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>git remote set-head &lt;name&gt; (-a | -d | &lt;branch&gt;)
+(One and only one of "-a", "-d" or "&lt;branch&gt;" _must_ (no square
+brackets) be provided.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>And a somewhat more contrived example:
+  --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+  Here "=" is outside the brackets, because "--diff-filter=" is a
+  valid usage.  "*" has its own pair of brackets, because it can
+  (optionally) be specified only when one or more of the letters is
+  also provided.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A note on notation:
+ Use 'git' (all lowercase) when talking about commands i.e. something
+ the user would type into a shell and use 'Git' (uppercase first letter)
+ when talking about the version control system and its properties.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying paragraphs or option/command explanations that contain options
+or commands:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Literal examples (e.g. use of command-line options, command names,
+branch names, configuration and environment variables) must be
+typeset in monospace (i.e. wrapped with backticks):
+  `--pretty=oneline`
+  `git rev-list`
+  `remote.pushDefault`
+  `GIT_DIR`
+  `HEAD`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>An environment variable must be prefixed with "$" only when referring to its
+value and not when referring to the variable itself, in this case there is
+nothing to add except the backticks:
+  `GIT_DIR` is specified
+  `$GIT_DIR/hooks/pre-receive`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Word phrases enclosed in `backtick characters` are rendered literally
+and will not be further expanded. The use of `backticks` to achieve the
+previous rule means that literal examples should not use AsciiDoc
+escapes.
+  Correct:
+     `--pretty=oneline`
+  Incorrect:
+     `\--pretty=oneline`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If some place in the documentation needs to typeset a command usage
+example with inline substitutions, it is fine to use +monospaced and
+inline substituted text+ instead of `monospaced literal text`, and with
+the former, the part that should not get substituted must be
+quoted/escaped.</pre>
+</div>
+</div>
+</div>
+</div>
\ No newline at end of file
diff --git a/external/docs/content/docs/CodingGuidelines/2.13.7.html b/external/docs/content/docs/CodingGuidelines/2.13.7.html
new file mode 100644
index 0000000000..79994f0870
--- /dev/null
+++ b/external/docs/content/docs/CodingGuidelines/2.13.7.html
@@ -0,0 +1,924 @@
+---
+### DO NOT EDIT! Generated by script/update-docs.rb
+
+category: manual
+section: documentation
+subsection: manual
+title: Git - CodingGuidelines Documentation
+docname: CodingGuidelines
+version: 2.13.7
+aliases:
+- "/docs/CodingGuidelines/2.13.7/index.html"
+- "/docs/CodingGuidelines/2.14.6/index.html"
+- "/docs/CodingGuidelines/2.15.4/index.html"
+- "/docs/CodingGuidelines/2.16.6/index.html"
+---
+<div id="preamble">
+<div class="sectionbody">
+<div class="paragraph">
+<p>Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, a few rough rules are:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most importantly, we never say "It&#8217;s in POSIX; we&#8217;ll happily
+ignore your needs should your system not conform to it."
+We live in the real world.</p>
+</li>
+<li>
+<p>However, we often say "Let&#8217;s stay away from that construct,
+it&#8217;s not even in POSIX".</p>
+</li>
+<li>
+<p>In spite of the above two rules, we sometimes say "Although
+this is not in POSIX, it (is so convenient | makes the code
+much more readable | has other good characteristics) and
+practically all the platforms we care about support it, so
+let&#8217;s use it".</p>
+<div class="literalblock">
+<div class="content">
+<pre>Again, we live in the real world, and it is sometimes a
+judgement call, the decision based more on real world
+constraints people face than what the paper standard says.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Fixing style violations while working on a real change as a
+preparatory clean-up step is good, but otherwise avoid useless code
+churn for the sake of conforming to the style.</p>
+<div class="literalblock">
+<div class="content">
+<pre>"Once it _is_ in the tree, it's not really worth the patch noise to
+go and fix it up."
+Cf. http://lkml.iu.edu/hypermail/linux/kernel/1001.3/01069.html</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Make your code readable and sensible, and don&#8217;t try to be clever.</p>
+</div>
+<div class="paragraph">
+<p>As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the <em>local</em>
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn&#8217;t match the overall style of existing code).</p>
+</div>
+<div class="paragraph">
+<p>But if you must have a list of rules, here they are.</p>
+</div>
+<div class="paragraph">
+<p>For shell scripts specifically (not exhaustive):</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs for indentation.</p>
+</li>
+<li>
+<p>Case arms are indented at the same depth as case and esac lines,
+like this:</p>
+<div class="literalblock">
+<div class="content">
+<pre>case "$variable" in
+pattern1)
+	do this
+	;;
+pattern2)
+	do that
+	;;
+esac</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Redirection operators should be written with space before, but no
+space after them.  In other words, write <em>echo test &gt;"$file"</em>
+instead of <em>echo test&gt; $file</em> or <em>echo test &gt; $file</em>.  Note that
+even though it is not required by POSIX to double-quote the
+redirection target in a variable (as shown above), our code does so
+because some versions of bash issue a warning without the quotes.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+cat hello &gt; world &lt; universe
+echo hello &gt;$world</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+cat hello &gt;world &lt;universe
+echo hello &gt;"$world"</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer $( &#8230;&#8203; ) for command substitution; unlike ``, it
+properly nests.  It should have been the way Bourne spelled
+it from day one, but unfortunately isn&#8217;t.</p>
+</li>
+<li>
+<p>If you want to find out if a command is available on the user&#8217;s
+$PATH, you should use <em>type &lt;command&gt;</em>, instead of <em>which &lt;command&gt;</em>.
+The output of <em>which</em> is not machine parseable and its exit code
+is not reliable across platforms.</p>
+</li>
+<li>
+<p>We use POSIX compliant parameter substitutions and avoid bashisms;
+namely:</p>
+</li>
+<li>
+<p>We use ${parameter-word} and its [-=?+] siblings, and their
+colon&#8217;ed "unset or null" form.</p>
+</li>
+<li>
+<p>We use ${parameter#word} and its [#%] siblings, and their
+doubled "longest matching" form.</p>
+</li>
+<li>
+<p>No "Substring Expansion" ${parameter:offset:length}.</p>
+</li>
+<li>
+<p>No shell arrays.</p>
+</li>
+<li>
+<p>No strlen ${#parameter}.</p>
+</li>
+<li>
+<p>No pattern replacement ${parameter/pattern/string}.</p>
+</li>
+<li>
+<p>We use Arithmetic Expansion $&#8230;&#8203;.</p>
+</li>
+<li>
+<p>Inside Arithmetic Expansion, spell shell variables with $ in front
+of them, as some shells do not grok $x while accepting $$x
+just fine (e.g. dash older than 0.5.4).</p>
+</li>
+<li>
+<p>We do not use Process Substitution &lt;(list) or &gt;(list).</p>
+</li>
+<li>
+<p>Do not write control structures on a single line with semicolon.
+"then" should be on the next line for if statements, and "do"
+should be on the next line for "while" and "for".</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+if test -f hello; then
+	do this
+fi</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+if test -f hello
+then
+	do this
+fi</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer "test" over "[ &#8230;&#8203; ]".</p>
+</li>
+<li>
+<p>We do not write the noiseword "function" in front of shell
+functions.</p>
+</li>
+<li>
+<p>We prefer a space between the function name and the parentheses,
+and no space inside the parentheses. The opening "{" should also
+be on the same line.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+my_function(){
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+my_function () {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+[::], [==], or [..]) for portability.</p>
+</li>
+<li>
+<p>We do not use \{m,n\};</p>
+</li>
+<li>
+<p>We do not use -E;</p>
+</li>
+<li>
+<p>We do not use ? or + (which are \{0,1\} and \{1,\}
+respectively in BRE) but that goes without saying as these
+are ERE elements not BRE (note that \? and \+ are not even part
+of BRE&#8201;&#8212;&#8201;making them accessible from BRE is a GNU extension).</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers in git-sh-i18n to make the user
+interface translatable. See "Marking strings for translation" in
+po/README.</p>
+</li>
+<li>
+<p>We do not write our "test" command with "-a" and "-o" and use "&amp;&amp;"
+or "||" to concatenate multiple "test" commands instead, because
+the use of "-a/-o" is often error-prone.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" -a "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is buggy and breaks when $x is "=", but</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" &amp;&amp; test "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>does not have such a problem.</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For C programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs to indent, and interpret tabs as taking up to
+8 spaces.</p>
+</li>
+<li>
+<p>We try to keep to at most 80 characters per line.</p>
+</li>
+<li>
+<p>As a Git developer we assume you have a reasonably modern compiler
+and we recommend you to enable the DEVELOPER makefile knob to
+ensure your patch is clear of all compiler warnings we care about,
+by e.g. "echo DEVELOPER=1 &gt;&gt;config.mak".</p>
+</li>
+<li>
+<p>We try to support a wide range of C compilers to compile Git with,
+including old ones. That means that you should not use C99
+initializers, even if a lot of compilers grok it.</p>
+</li>
+<li>
+<p>Variables have to be declared at the beginning of the block.</p>
+</li>
+<li>
+<p>NULL pointers shall be written as NULL, not as 0.</p>
+</li>
+<li>
+<p>When declaring pointers, the star sides with the variable
+name, i.e. "char <strong>string", not "char</strong> string" or
+"char * string".  This makes it easier to understand code
+like "char *string, c;".</p>
+</li>
+<li>
+<p>Use whitespace around operators and keywords, but not inside
+parentheses and not around functions. So:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      while (condition)
+func(bar + 1);</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>      while( condition )
+func (bar+1);</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We avoid using braces unnecessarily.  I.e.</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (bla) {
+	x = 1;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is frowned upon. But there are a few exceptions:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When the statement extends over a few lines (e.g., a while loop
+with an embedded conditional, or a comment). E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (foo) {
+	if (x)
+		one();
+	else
+		two();
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	/*
+	 * This one requires some explanation,
+	 * so we're better off with braces to make
+	 * it obvious that the indentation is correct.
+	 */
+	doit();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When there are multiple arms to a conditional and some of them
+require braces, enclose even a single line block in braces for
+consistency. E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	doit();
+} else {
+	one();
+	two();
+	three();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments in the condition of an "if" statement.</p>
+</li>
+<li>
+<p>Try to make your code understandable.  You may put comments
+in, but comments invariably tend to stale out when the code
+they were describing changes.  Often splitting a function
+into two makes the intention of the code much clearer.</p>
+</li>
+<li>
+<p>Multi-line comments include their delimiters on separate lines from
+the text.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * A very long
+ * multi-line comment.
+ */</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Note however that a comment that explains a translatable string to
+translators uses a convention of starting with a magic token
+"TRANSLATORS: ", e.g.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * TRANSLATORS: here is a comment that explains the string to
+ * be translated, that follows immediately after it.
+ */
+_("Here is a translatable string explained by the above.");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Double negation is often harder to understand than no negation
+at all.</p>
+</li>
+<li>
+<p>There are two schools of thought when it comes to comparison,
+especially inside a loop. Some people prefer to have the less stable
+value on the left hand side and the more stable value on the right hand
+side, e.g. if you have a loop that counts variable i down to the
+lower bound,</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (i &gt; lower_bound) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Other people prefer to have the textual order of values match the
+actual order of values in their comparison, so that they can
+mentally draw a number line from left to right and place these
+values in order, i.e.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while (lower_bound &lt; i) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  However, the more "stable" the
+stable side becomes, the more we tend to prefer the former
+(comparison with a constant, "i &gt; 0", is an extreme example).
+Just do not mix styles in the same part of the code and mimic
+existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>There are two schools of thought when it comes to splitting a long
+logical line into multiple lines.  Some people push the second and
+subsequent lines far enough to the right with tabs and align them:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+              ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to align the second and the subsequent
+lines with the column immediately inside the opening parenthesis,
+with tabs and spaces, following our "tabstop is always a multiple
+of 8" convention:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+           ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  Again, just do not mix styles in
+the same part of the code and mimic existing styles in the
+neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, some people change line before
+a binary operator, so that the result looks like a parse tree when
+you turn your head 90-degrees counterclockwise:</p>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to
+|| span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to leave the operator at the end of the
+line:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, but we tend to use the latter more, unless the
+expression gets fairly complex, in which case the former tends to
+be easier to read.  Again, just do not mix styles in the same part
+of the code and mimic existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, with everything else being
+equal, it is preferable to split after the operator at higher
+level in the parse tree.  That is, this is more preferable:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable * that_is_used_in +
+    a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>than</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable *
+    that_is_used_in + a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Some clever tricks, like using the !! operator with arithmetic
+constructs, can be extremely confusing to others.  Avoid them,
+unless there is a compelling reason to use them.</p>
+</li>
+<li>
+<p>Use the API.  No, really.  We have a strbuf (variable length
+string), several arrays with the ALLOC_GROW() macro, a
+string_list for sorted string lists, a hash map (mapping struct
+objects) named "struct decorate", amongst other things.</p>
+</li>
+<li>
+<p>When you come up with an API, document it.</p>
+</li>
+<li>
+<p>The first #include in C files, except in platform specific compat/
+implementations, must be either "git-compat-util.h", "cache.h" or
+"builtin.h".  You do not have to include more than one of these.</p>
+</li>
+<li>
+<p>A C file must directly include the header files that declare the
+functions and the types it uses, except for the functions and types
+that are made available to it by including one of the header files
+it must include by the previous rule.</p>
+</li>
+<li>
+<p>If you are planning a new command, consider writing it in shell
+or perl first, so that changes in semantics can be easily
+changed and discussed.  Many Git commands started out like
+that, and a few are still scripts.</p>
+</li>
+<li>
+<p>Avoid introducing a new dependency into Git. This means you
+usually should stay away from scripting languages not already
+used in the Git core command set (unless your command is clearly
+separate from it, such as an importer to convert random-scm-X
+repositories to Git).</p>
+</li>
+<li>
+<p>When we pass &lt;string, length&gt; pair to functions, we should try to
+pass them in that order.</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers to make the user interface
+translatable. See "Marking strings for translation" in po/README.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Perl programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most of the C guidelines above apply.</p>
+</li>
+<li>
+<p>We try to support Perl 5.8 and later ("use Perl 5.008").</p>
+</li>
+<li>
+<p>use strict and use warnings are strongly preferred.</p>
+</li>
+<li>
+<p>Don&#8217;t overuse statement modifiers unless using them makes the
+result easier to follow.</p>
+<div class="olist lowerroman">
+<ol class="lowerroman" type="i">
+<li>
+<p>do something &#8230;&#8203;
+do_this() unless (condition);</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>is more readable than:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>do something &#8230;&#8203;
+unless (condition) {
+	do_this();
+}</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>*only* when the condition is so rare that do_this() will be almost
+always called.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments inside "if ()" conditions.</p>
+</li>
+<li>
+<p>Learn and use Git.pm if you need that functionality.</p>
+</li>
+<li>
+<p>For Emacs, it&#8217;s useful to put the following in
+GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode:</p>
+<div class="literalblock">
+<div class="content">
+<pre>;; note the first part is useful for C editing, too
+((nil . ((indent-tabs-mode . t)
+              (tab-width . 8)
+              (fill-column . 80)))
+ (cperl-mode . ((cperl-indent-level . 8)
+                (cperl-extra-newline-before-brace . nil)
+                (cperl-merge-trailing-else . t))))</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Python scripts:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We follow PEP-8 (<a href="http://www.python.org/dev/peps/pep-0008/" class="bare">http://www.python.org/dev/peps/pep-0008/</a>).</p>
+</li>
+<li>
+<p>As a minimum, we aim to be compatible with Python 2.6 and 2.7.</p>
+</li>
+<li>
+<p>Where required libraries do not restrict us to Python 2, we try to
+also be compatible with Python 3.1 and later.</p>
+</li>
+<li>
+<p>When you must differentiate between Unicode literals and byte string
+literals, it is OK to use the <em>b</em> prefix.  Even though the Python
+documentation for version 2.6 does not mention this prefix, it has
+been supported since version 2.6.0.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Error Messages</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Do not end error messages with a full stop.</p>
+</li>
+<li>
+<p>Do not capitalize ("unable to open %s", not "Unable to open %s")</p>
+</li>
+<li>
+<p>Say what the error is first ("cannot open %s", not "%s: cannot open")</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Externally Visible Names</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>For configuration variable names, follow the existing convention:</p>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>The section name indicates the affected subsystem.</p>
+</li>
+<li>
+<p>The subsection name, if any, indicates which of an unbounded set
+of things to set the value for.</p>
+</li>
+<li>
+<p>The variable name describes the effect of tweaking this knob.</p>
+<div class="literalblock">
+<div class="content">
+<pre>The section and variable names that consist of multiple words are
+formed by concatenating the words without punctuations (e.g. `-`),
+and are broken using bumpyCaps in documentation as a hint to the
+reader.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>When choosing the variable namespace, do not use variable name for
+specifying possibly unbounded set of things, most notably anything
+an end user can freely come up with (e.g. branch names).  Instead,
+use subsection names or variable values, like the existing variable
+branch.&lt;name&gt;.description does.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Writing Documentation:</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Most (if not all) of the documentation pages are written in the
+AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+processed into HTML and manpages (e.g. git.html and git.1 in the
+same directory).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>The documentation liberally mixes US and UK English (en_US/UK)
+norms for spelling and grammar, which is somewhat unfortunate.
+In an ideal world, it would have been better if it consistently
+used only one and not the other, and we would have picked en_US
+(if you wish to correct the English of some of the existing
+documentation, please see the documentation-related advice in the
+Documentation/SubmittingPatches file).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Every user-visible change should be reflected in the documentation.
+The same general rule as for code applies -- imitate the existing
+conventions.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying command usage strings and synopsis sections in the manual
+pages:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Placeholders are spelled in lowercase and enclosed in angle brackets:
+  &lt;file&gt;
+  --sort=&lt;key&gt;
+  --abbrev[=&lt;n&gt;]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If a placeholder has multiple words, they are separated by dashes:
+  &lt;new-branch-name&gt;
+  --template=&lt;template-directory&gt;</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Possibility of multiple occurrences is indicated by three dots:
+  &lt;file&gt;...
+  (One or more of &lt;file&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Optional parts are enclosed in square brackets:
+  [&lt;extra&gt;]
+  (Zero or one &lt;extra&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>--exec-path[=&lt;path&gt;]
+(Option with an optional argument.  Note that the "=" is inside the
+brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[&lt;patch&gt;...]
+(Zero or more of &lt;patch&gt;.  Note that the dots are inside, not
+outside the brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Multiple alternatives are indicated with vertical bars:
+  [-q | --quiet]
+  [--utf8 | --no-utf8]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Parentheses are used for grouping:
+  [(&lt;rev&gt; | &lt;range&gt;)...]
+  (Any number of either &lt;rev&gt; or &lt;range&gt;.  Parens are needed to make
+  it clear that "..." pertains to both &lt;rev&gt; and &lt;range&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[(-p &lt;parent&gt;)...]
+(Any number of option -p, each with one &lt;parent&gt; argument.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>git remote set-head &lt;name&gt; (-a | -d | &lt;branch&gt;)
+(One and only one of "-a", "-d" or "&lt;branch&gt;" _must_ (no square
+brackets) be provided.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>And a somewhat more contrived example:
+  --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+  Here "=" is outside the brackets, because "--diff-filter=" is a
+  valid usage.  "*" has its own pair of brackets, because it can
+  (optionally) be specified only when one or more of the letters is
+  also provided.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A note on notation:
+ Use 'git' (all lowercase) when talking about commands i.e. something
+ the user would type into a shell and use 'Git' (uppercase first letter)
+ when talking about the version control system and its properties.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying paragraphs or option/command explanations that contain options
+or commands:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Literal examples (e.g. use of command-line options, command names,
+branch names, configuration and environment variables) must be
+typeset in monospace (i.e. wrapped with backticks):
+  `--pretty=oneline`
+  `git rev-list`
+  `remote.pushDefault`
+  `GIT_DIR`
+  `HEAD`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>An environment variable must be prefixed with "$" only when referring to its
+value and not when referring to the variable itself, in this case there is
+nothing to add except the backticks:
+  `GIT_DIR` is specified
+  `$GIT_DIR/hooks/pre-receive`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Word phrases enclosed in `backtick characters` are rendered literally
+and will not be further expanded. The use of `backticks` to achieve the
+previous rule means that literal examples should not use AsciiDoc
+escapes.
+  Correct:
+     `--pretty=oneline`
+  Incorrect:
+     `\--pretty=oneline`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If some place in the documentation needs to typeset a command usage
+example with inline substitutions, it is fine to use +monospaced and
+inline substituted text+ instead of `monospaced literal text`, and with
+the former, the part that should not get substituted must be
+quoted/escaped.</pre>
+</div>
+</div>
+</div>
+</div>
\ No newline at end of file
diff --git a/external/docs/content/docs/CodingGuidelines/2.17.0.html b/external/docs/content/docs/CodingGuidelines/2.17.0.html
new file mode 100644
index 0000000000..b5352e34a3
--- /dev/null
+++ b/external/docs/content/docs/CodingGuidelines/2.17.0.html
@@ -0,0 +1,941 @@
+---
+### DO NOT EDIT! Generated by script/update-docs.rb
+
+category: manual
+section: documentation
+subsection: manual
+title: Git - CodingGuidelines Documentation
+docname: CodingGuidelines
+version: 2.17.0
+aliases:
+- "/docs/CodingGuidelines/2.17.0/index.html"
+- "/docs/CodingGuidelines/2.17.1/index.html"
+- "/docs/CodingGuidelines/2.17.2/index.html"
+- "/docs/CodingGuidelines/2.17.3/index.html"
+- "/docs/CodingGuidelines/2.17.4/index.html"
+- "/docs/CodingGuidelines/2.17.5/index.html"
+- "/docs/CodingGuidelines/2.17.6/index.html"
+- "/docs/CodingGuidelines/2.18.0/index.html"
+- "/docs/CodingGuidelines/2.18.1/index.html"
+- "/docs/CodingGuidelines/2.18.2/index.html"
+- "/docs/CodingGuidelines/2.18.3/index.html"
+- "/docs/CodingGuidelines/2.18.4/index.html"
+- "/docs/CodingGuidelines/2.18.5/index.html"
+- "/docs/CodingGuidelines/2.19.0/index.html"
+- "/docs/CodingGuidelines/2.19.1/index.html"
+---
+<div id="preamble">
+<div class="sectionbody">
+<div class="paragraph">
+<p>Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, a few rough rules are:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most importantly, we never say "It&#8217;s in POSIX; we&#8217;ll happily
+ignore your needs should your system not conform to it."
+We live in the real world.</p>
+</li>
+<li>
+<p>However, we often say "Let&#8217;s stay away from that construct,
+it&#8217;s not even in POSIX".</p>
+</li>
+<li>
+<p>In spite of the above two rules, we sometimes say "Although
+this is not in POSIX, it (is so convenient | makes the code
+much more readable | has other good characteristics) and
+practically all the platforms we care about support it, so
+let&#8217;s use it".</p>
+<div class="literalblock">
+<div class="content">
+<pre>Again, we live in the real world, and it is sometimes a
+judgement call, the decision based more on real world
+constraints people face than what the paper standard says.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Fixing style violations while working on a real change as a
+preparatory clean-up step is good, but otherwise avoid useless code
+churn for the sake of conforming to the style.</p>
+<div class="literalblock">
+<div class="content">
+<pre>"Once it _is_ in the tree, it's not really worth the patch noise to
+go and fix it up."
+Cf. http://lkml.iu.edu/hypermail/linux/kernel/1001.3/01069.html</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Make your code readable and sensible, and don&#8217;t try to be clever.</p>
+</div>
+<div class="paragraph">
+<p>As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the <em>local</em>
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn&#8217;t match the overall style of existing code).</p>
+</div>
+<div class="paragraph">
+<p>But if you must have a list of rules, here they are.</p>
+</div>
+<div class="paragraph">
+<p>For shell scripts specifically (not exhaustive):</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs for indentation.</p>
+</li>
+<li>
+<p>Case arms are indented at the same depth as case and esac lines,
+like this:</p>
+<div class="literalblock">
+<div class="content">
+<pre>case "$variable" in
+pattern1)
+	do this
+	;;
+pattern2)
+	do that
+	;;
+esac</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Redirection operators should be written with space before, but no
+space after them.  In other words, write <em>echo test &gt;"$file"</em>
+instead of <em>echo test&gt; $file</em> or <em>echo test &gt; $file</em>.  Note that
+even though it is not required by POSIX to double-quote the
+redirection target in a variable (as shown above), our code does so
+because some versions of bash issue a warning without the quotes.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+cat hello &gt; world &lt; universe
+echo hello &gt;$world</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+cat hello &gt;world &lt;universe
+echo hello &gt;"$world"</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer $( &#8230;&#8203; ) for command substitution; unlike ``, it
+properly nests.  It should have been the way Bourne spelled
+it from day one, but unfortunately isn&#8217;t.</p>
+</li>
+<li>
+<p>If you want to find out if a command is available on the user&#8217;s
+$PATH, you should use <em>type &lt;command&gt;</em>, instead of <em>which &lt;command&gt;</em>.
+The output of <em>which</em> is not machine parseable and its exit code
+is not reliable across platforms.</p>
+</li>
+<li>
+<p>We use POSIX compliant parameter substitutions and avoid bashisms;
+namely:</p>
+</li>
+<li>
+<p>We use ${parameter-word} and its [-=?+] siblings, and their
+colon&#8217;ed "unset or null" form.</p>
+</li>
+<li>
+<p>We use ${parameter#word} and its [#%] siblings, and their
+doubled "longest matching" form.</p>
+</li>
+<li>
+<p>No "Substring Expansion" ${parameter:offset:length}.</p>
+</li>
+<li>
+<p>No shell arrays.</p>
+</li>
+<li>
+<p>No strlen ${#parameter}.</p>
+</li>
+<li>
+<p>No pattern replacement ${parameter/pattern/string}.</p>
+</li>
+<li>
+<p>We use Arithmetic Expansion $&#8230;&#8203;.</p>
+</li>
+<li>
+<p>Inside Arithmetic Expansion, spell shell variables with $ in front
+of them, as some shells do not grok $x while accepting $$x
+just fine (e.g. dash older than 0.5.4).</p>
+</li>
+<li>
+<p>We do not use Process Substitution &lt;(list) or &gt;(list).</p>
+</li>
+<li>
+<p>Do not write control structures on a single line with semicolon.
+"then" should be on the next line for if statements, and "do"
+should be on the next line for "while" and "for".</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+if test -f hello; then
+	do this
+fi</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+if test -f hello
+then
+	do this
+fi</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer "test" over "[ &#8230;&#8203; ]".</p>
+</li>
+<li>
+<p>We do not write the noiseword "function" in front of shell
+functions.</p>
+</li>
+<li>
+<p>We prefer a space between the function name and the parentheses,
+and no space inside the parentheses. The opening "{" should also
+be on the same line.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+my_function(){
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+my_function () {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+[::], [==], or [..]) for portability.</p>
+</li>
+<li>
+<p>We do not use \{m,n\};</p>
+</li>
+<li>
+<p>We do not use -E;</p>
+</li>
+<li>
+<p>We do not use ? or + (which are \{0,1\} and \{1,\}
+respectively in BRE) but that goes without saying as these
+are ERE elements not BRE (note that \? and \+ are not even part
+of BRE&#8201;&#8212;&#8201;making them accessible from BRE is a GNU extension).</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers in git-sh-i18n to make the user
+interface translatable. See "Marking strings for translation" in
+po/README.</p>
+</li>
+<li>
+<p>We do not write our "test" command with "-a" and "-o" and use "&amp;&amp;"
+or "||" to concatenate multiple "test" commands instead, because
+the use of "-a/-o" is often error-prone.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" -a "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is buggy and breaks when $x is "=", but</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" &amp;&amp; test "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>does not have such a problem.</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For C programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs to indent, and interpret tabs as taking up to
+8 spaces.</p>
+</li>
+<li>
+<p>We try to keep to at most 80 characters per line.</p>
+</li>
+<li>
+<p>As a Git developer we assume you have a reasonably modern compiler
+and we recommend you to enable the DEVELOPER makefile knob to
+ensure your patch is clear of all compiler warnings we care about,
+by e.g. "echo DEVELOPER=1 &gt;&gt;config.mak".</p>
+</li>
+<li>
+<p>We try to support a wide range of C compilers to compile Git with,
+including old ones. That means that you should not use C99
+initializers, even if a lot of compilers grok it.</p>
+</li>
+<li>
+<p>Variables have to be declared at the beginning of the block.</p>
+</li>
+<li>
+<p>NULL pointers shall be written as NULL, not as 0.</p>
+</li>
+<li>
+<p>When declaring pointers, the star sides with the variable
+name, i.e. "char <strong>string", not "char</strong> string" or
+"char * string".  This makes it easier to understand code
+like "char *string, c;".</p>
+</li>
+<li>
+<p>Use whitespace around operators and keywords, but not inside
+parentheses and not around functions. So:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      while (condition)
+func(bar + 1);</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>      while( condition )
+func (bar+1);</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We avoid using braces unnecessarily.  I.e.</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (bla) {
+	x = 1;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is frowned upon. But there are a few exceptions:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When the statement extends over a few lines (e.g., a while loop
+with an embedded conditional, or a comment). E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (foo) {
+	if (x)
+		one();
+	else
+		two();
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	/*
+	 * This one requires some explanation,
+	 * so we're better off with braces to make
+	 * it obvious that the indentation is correct.
+	 */
+	doit();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When there are multiple arms to a conditional and some of them
+require braces, enclose even a single line block in braces for
+consistency. E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	doit();
+} else {
+	one();
+	two();
+	three();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments in the condition of an "if" statement.</p>
+</li>
+<li>
+<p>Try to make your code understandable.  You may put comments
+in, but comments invariably tend to stale out when the code
+they were describing changes.  Often splitting a function
+into two makes the intention of the code much clearer.</p>
+</li>
+<li>
+<p>Multi-line comments include their delimiters on separate lines from
+the text.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * A very long
+ * multi-line comment.
+ */</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Note however that a comment that explains a translatable string to
+translators uses a convention of starting with a magic token
+"TRANSLATORS: ", e.g.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * TRANSLATORS: here is a comment that explains the string to
+ * be translated, that follows immediately after it.
+ */
+_("Here is a translatable string explained by the above.");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Double negation is often harder to understand than no negation
+at all.</p>
+</li>
+<li>
+<p>There are two schools of thought when it comes to comparison,
+especially inside a loop. Some people prefer to have the less stable
+value on the left hand side and the more stable value on the right hand
+side, e.g. if you have a loop that counts variable i down to the
+lower bound,</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (i &gt; lower_bound) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Other people prefer to have the textual order of values match the
+actual order of values in their comparison, so that they can
+mentally draw a number line from left to right and place these
+values in order, i.e.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while (lower_bound &lt; i) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  However, the more "stable" the
+stable side becomes, the more we tend to prefer the former
+(comparison with a constant, "i &gt; 0", is an extreme example).
+Just do not mix styles in the same part of the code and mimic
+existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>There are two schools of thought when it comes to splitting a long
+logical line into multiple lines.  Some people push the second and
+subsequent lines far enough to the right with tabs and align them:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+              ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to align the second and the subsequent
+lines with the column immediately inside the opening parenthesis,
+with tabs and spaces, following our "tabstop is always a multiple
+of 8" convention:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+           ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  Again, just do not mix styles in
+the same part of the code and mimic existing styles in the
+neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, some people change line before
+a binary operator, so that the result looks like a parse tree when
+you turn your head 90-degrees counterclockwise:</p>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to
+|| span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to leave the operator at the end of the
+line:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, but we tend to use the latter more, unless the
+expression gets fairly complex, in which case the former tends to
+be easier to read.  Again, just do not mix styles in the same part
+of the code and mimic existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, with everything else being
+equal, it is preferable to split after the operator at higher
+level in the parse tree.  That is, this is more preferable:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable * that_is_used_in +
+    a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>than</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable *
+    that_is_used_in + a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Some clever tricks, like using the !! operator with arithmetic
+constructs, can be extremely confusing to others.  Avoid them,
+unless there is a compelling reason to use them.</p>
+</li>
+<li>
+<p>Use the API.  No, really.  We have a strbuf (variable length
+string), several arrays with the ALLOC_GROW() macro, a
+string_list for sorted string lists, a hash map (mapping struct
+objects) named "struct decorate", amongst other things.</p>
+</li>
+<li>
+<p>When you come up with an API, document it.</p>
+</li>
+<li>
+<p>The first #include in C files, except in platform specific compat/
+implementations, must be either "git-compat-util.h", "cache.h" or
+"builtin.h".  You do not have to include more than one of these.</p>
+</li>
+<li>
+<p>A C file must directly include the header files that declare the
+functions and the types it uses, except for the functions and types
+that are made available to it by including one of the header files
+it must include by the previous rule.</p>
+</li>
+<li>
+<p>If you are planning a new command, consider writing it in shell
+or perl first, so that changes in semantics can be easily
+changed and discussed.  Many Git commands started out like
+that, and a few are still scripts.</p>
+</li>
+<li>
+<p>Avoid introducing a new dependency into Git. This means you
+usually should stay away from scripting languages not already
+used in the Git core command set (unless your command is clearly
+separate from it, such as an importer to convert random-scm-X
+repositories to Git).</p>
+</li>
+<li>
+<p>When we pass &lt;string, length&gt; pair to functions, we should try to
+pass them in that order.</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers to make the user interface
+translatable. See "Marking strings for translation" in po/README.</p>
+</li>
+<li>
+<p>Variables and functions local to a given source file should be marked
+with "static". Variables that are visible to other source files
+must be declared with "extern" in header files. However, function
+declarations should not use "extern", as that is already the default.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Perl programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most of the C guidelines above apply.</p>
+</li>
+<li>
+<p>We try to support Perl 5.8 and later ("use Perl 5.008").</p>
+</li>
+<li>
+<p>use strict and use warnings are strongly preferred.</p>
+</li>
+<li>
+<p>Don&#8217;t overuse statement modifiers unless using them makes the
+result easier to follow.</p>
+<div class="olist lowerroman">
+<ol class="lowerroman" type="i">
+<li>
+<p>do something &#8230;&#8203;
+do_this() unless (condition);</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>is more readable than:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>do something &#8230;&#8203;
+unless (condition) {
+	do_this();
+}</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>*only* when the condition is so rare that do_this() will be almost
+always called.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments inside "if ()" conditions.</p>
+</li>
+<li>
+<p>Learn and use Git.pm if you need that functionality.</p>
+</li>
+<li>
+<p>For Emacs, it&#8217;s useful to put the following in
+GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode:</p>
+<div class="literalblock">
+<div class="content">
+<pre>;; note the first part is useful for C editing, too
+((nil . ((indent-tabs-mode . t)
+              (tab-width . 8)
+              (fill-column . 80)))
+ (cperl-mode . ((cperl-indent-level . 8)
+                (cperl-extra-newline-before-brace . nil)
+                (cperl-merge-trailing-else . t))))</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Python scripts:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We follow PEP-8 (<a href="http://www.python.org/dev/peps/pep-0008/" class="bare">http://www.python.org/dev/peps/pep-0008/</a>).</p>
+</li>
+<li>
+<p>As a minimum, we aim to be compatible with Python 2.6 and 2.7.</p>
+</li>
+<li>
+<p>Where required libraries do not restrict us to Python 2, we try to
+also be compatible with Python 3.1 and later.</p>
+</li>
+<li>
+<p>When you must differentiate between Unicode literals and byte string
+literals, it is OK to use the <em>b</em> prefix.  Even though the Python
+documentation for version 2.6 does not mention this prefix, it has
+been supported since version 2.6.0.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Error Messages</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Do not end error messages with a full stop.</p>
+</li>
+<li>
+<p>Do not capitalize ("unable to open %s", not "Unable to open %s")</p>
+</li>
+<li>
+<p>Say what the error is first ("cannot open %s", not "%s: cannot open")</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Externally Visible Names</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>For configuration variable names, follow the existing convention:</p>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>The section name indicates the affected subsystem.</p>
+</li>
+<li>
+<p>The subsection name, if any, indicates which of an unbounded set
+of things to set the value for.</p>
+</li>
+<li>
+<p>The variable name describes the effect of tweaking this knob.</p>
+<div class="literalblock">
+<div class="content">
+<pre>The section and variable names that consist of multiple words are
+formed by concatenating the words without punctuations (e.g. `-`),
+and are broken using bumpyCaps in documentation as a hint to the
+reader.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>When choosing the variable namespace, do not use variable name for
+specifying possibly unbounded set of things, most notably anything
+an end user can freely come up with (e.g. branch names).  Instead,
+use subsection names or variable values, like the existing variable
+branch.&lt;name&gt;.description does.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Writing Documentation:</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Most (if not all) of the documentation pages are written in the
+AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+processed into HTML and manpages (e.g. git.html and git.1 in the
+same directory).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>The documentation liberally mixes US and UK English (en_US/UK)
+norms for spelling and grammar, which is somewhat unfortunate.
+In an ideal world, it would have been better if it consistently
+used only one and not the other, and we would have picked en_US
+(if you wish to correct the English of some of the existing
+documentation, please see the documentation-related advice in the
+Documentation/SubmittingPatches file).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Every user-visible change should be reflected in the documentation.
+The same general rule as for code applies -- imitate the existing
+conventions.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying command usage strings and synopsis sections in the manual
+pages:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Placeholders are spelled in lowercase and enclosed in angle brackets:
+  &lt;file&gt;
+  --sort=&lt;key&gt;
+  --abbrev[=&lt;n&gt;]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If a placeholder has multiple words, they are separated by dashes:
+  &lt;new-branch-name&gt;
+  --template=&lt;template-directory&gt;</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Possibility of multiple occurrences is indicated by three dots:
+  &lt;file&gt;...
+  (One or more of &lt;file&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Optional parts are enclosed in square brackets:
+  [&lt;extra&gt;]
+  (Zero or one &lt;extra&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>--exec-path[=&lt;path&gt;]
+(Option with an optional argument.  Note that the "=" is inside the
+brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[&lt;patch&gt;...]
+(Zero or more of &lt;patch&gt;.  Note that the dots are inside, not
+outside the brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Multiple alternatives are indicated with vertical bars:
+  [-q | --quiet]
+  [--utf8 | --no-utf8]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Parentheses are used for grouping:
+  [(&lt;rev&gt; | &lt;range&gt;)...]
+  (Any number of either &lt;rev&gt; or &lt;range&gt;.  Parens are needed to make
+  it clear that "..." pertains to both &lt;rev&gt; and &lt;range&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[(-p &lt;parent&gt;)...]
+(Any number of option -p, each with one &lt;parent&gt; argument.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>git remote set-head &lt;name&gt; (-a | -d | &lt;branch&gt;)
+(One and only one of "-a", "-d" or "&lt;branch&gt;" _must_ (no square
+brackets) be provided.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>And a somewhat more contrived example:
+  --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+  Here "=" is outside the brackets, because "--diff-filter=" is a
+  valid usage.  "*" has its own pair of brackets, because it can
+  (optionally) be specified only when one or more of the letters is
+  also provided.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A note on notation:
+ Use 'git' (all lowercase) when talking about commands i.e. something
+ the user would type into a shell and use 'Git' (uppercase first letter)
+ when talking about the version control system and its properties.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying paragraphs or option/command explanations that contain options
+or commands:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Literal examples (e.g. use of command-line options, command names,
+branch names, configuration and environment variables) must be
+typeset in monospace (i.e. wrapped with backticks):
+  `--pretty=oneline`
+  `git rev-list`
+  `remote.pushDefault`
+  `GIT_DIR`
+  `HEAD`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>An environment variable must be prefixed with "$" only when referring to its
+value and not when referring to the variable itself, in this case there is
+nothing to add except the backticks:
+  `GIT_DIR` is specified
+  `$GIT_DIR/hooks/pre-receive`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Word phrases enclosed in `backtick characters` are rendered literally
+and will not be further expanded. The use of `backticks` to achieve the
+previous rule means that literal examples should not use AsciiDoc
+escapes.
+  Correct:
+     `--pretty=oneline`
+  Incorrect:
+     `\--pretty=oneline`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If some place in the documentation needs to typeset a command usage
+example with inline substitutions, it is fine to use +monospaced and
+inline substituted text+ instead of `monospaced literal text`, and with
+the former, the part that should not get substituted must be
+quoted/escaped.</pre>
+</div>
+</div>
+</div>
+</div>
\ No newline at end of file
diff --git a/external/docs/content/docs/CodingGuidelines/2.19.2.html b/external/docs/content/docs/CodingGuidelines/2.19.2.html
new file mode 100644
index 0000000000..4600ba671f
--- /dev/null
+++ b/external/docs/content/docs/CodingGuidelines/2.19.2.html
@@ -0,0 +1,934 @@
+---
+### DO NOT EDIT! Generated by script/update-docs.rb
+
+category: manual
+section: documentation
+subsection: manual
+title: Git - CodingGuidelines Documentation
+docname: CodingGuidelines
+version: 2.19.2
+aliases:
+- "/docs/CodingGuidelines/2.19.2/index.html"
+- "/docs/CodingGuidelines/2.19.3/index.html"
+- "/docs/CodingGuidelines/2.19.4/index.html"
+- "/docs/CodingGuidelines/2.19.5/index.html"
+- "/docs/CodingGuidelines/2.19.6/index.html"
+---
+<div id="preamble">
+<div class="sectionbody">
+<div class="paragraph">
+<p>Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, a few rough rules are:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most importantly, we never say "It&#8217;s in POSIX; we&#8217;ll happily
+ignore your needs should your system not conform to it."
+We live in the real world.</p>
+</li>
+<li>
+<p>However, we often say "Let&#8217;s stay away from that construct,
+it&#8217;s not even in POSIX".</p>
+</li>
+<li>
+<p>In spite of the above two rules, we sometimes say "Although
+this is not in POSIX, it (is so convenient | makes the code
+much more readable | has other good characteristics) and
+practically all the platforms we care about support it, so
+let&#8217;s use it".</p>
+<div class="literalblock">
+<div class="content">
+<pre>Again, we live in the real world, and it is sometimes a
+judgement call, the decision based more on real world
+constraints people face than what the paper standard says.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Fixing style violations while working on a real change as a
+preparatory clean-up step is good, but otherwise avoid useless code
+churn for the sake of conforming to the style.</p>
+<div class="literalblock">
+<div class="content">
+<pre>"Once it _is_ in the tree, it's not really worth the patch noise to
+go and fix it up."
+Cf. http://lkml.iu.edu/hypermail/linux/kernel/1001.3/01069.html</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Make your code readable and sensible, and don&#8217;t try to be clever.</p>
+</div>
+<div class="paragraph">
+<p>As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the <em>local</em>
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn&#8217;t match the overall style of existing code).</p>
+</div>
+<div class="paragraph">
+<p>But if you must have a list of rules, here they are.</p>
+</div>
+<div class="paragraph">
+<p>For shell scripts specifically (not exhaustive):</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs for indentation.</p>
+</li>
+<li>
+<p>Case arms are indented at the same depth as case and esac lines,
+like this:</p>
+<div class="literalblock">
+<div class="content">
+<pre>case "$variable" in
+pattern1)
+	do this
+	;;
+pattern2)
+	do that
+	;;
+esac</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Redirection operators should be written with space before, but no
+space after them.  In other words, write <em>echo test &gt;"$file"</em>
+instead of <em>echo test&gt; $file</em> or <em>echo test &gt; $file</em>.  Note that
+even though it is not required by POSIX to double-quote the
+redirection target in a variable (as shown above), our code does so
+because some versions of bash issue a warning without the quotes.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+cat hello &gt; world &lt; universe
+echo hello &gt;$world</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+cat hello &gt;world &lt;universe
+echo hello &gt;"$world"</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer $( &#8230;&#8203; ) for command substitution; unlike ``, it
+properly nests.  It should have been the way Bourne spelled
+it from day one, but unfortunately isn&#8217;t.</p>
+</li>
+<li>
+<p>If you want to find out if a command is available on the user&#8217;s
+$PATH, you should use <em>type &lt;command&gt;</em>, instead of <em>which &lt;command&gt;</em>.
+The output of <em>which</em> is not machine parseable and its exit code
+is not reliable across platforms.</p>
+</li>
+<li>
+<p>We use POSIX compliant parameter substitutions and avoid bashisms;
+namely:</p>
+</li>
+<li>
+<p>We use ${parameter-word} and its [-=?+] siblings, and their
+colon&#8217;ed "unset or null" form.</p>
+</li>
+<li>
+<p>We use ${parameter#word} and its [#%] siblings, and their
+doubled "longest matching" form.</p>
+</li>
+<li>
+<p>No "Substring Expansion" ${parameter:offset:length}.</p>
+</li>
+<li>
+<p>No shell arrays.</p>
+</li>
+<li>
+<p>No strlen ${#parameter}.</p>
+</li>
+<li>
+<p>No pattern replacement ${parameter/pattern/string}.</p>
+</li>
+<li>
+<p>We use Arithmetic Expansion $&#8230;&#8203;.</p>
+</li>
+<li>
+<p>Inside Arithmetic Expansion, spell shell variables with $ in front
+of them, as some shells do not grok $x while accepting $$x
+just fine (e.g. dash older than 0.5.4).</p>
+</li>
+<li>
+<p>We do not use Process Substitution &lt;(list) or &gt;(list).</p>
+</li>
+<li>
+<p>Do not write control structures on a single line with semicolon.
+"then" should be on the next line for if statements, and "do"
+should be on the next line for "while" and "for".</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+if test -f hello; then
+	do this
+fi</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+if test -f hello
+then
+	do this
+fi</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer "test" over "[ &#8230;&#8203; ]".</p>
+</li>
+<li>
+<p>We do not write the noiseword "function" in front of shell
+functions.</p>
+</li>
+<li>
+<p>We prefer a space between the function name and the parentheses,
+and no space inside the parentheses. The opening "{" should also
+be on the same line.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+my_function(){
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+my_function () {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+[::], [==], or [..]) for portability.</p>
+</li>
+<li>
+<p>We do not use \{m,n\};</p>
+</li>
+<li>
+<p>We do not use -E;</p>
+</li>
+<li>
+<p>We do not use ? or + (which are \{0,1\} and \{1,\}
+respectively in BRE) but that goes without saying as these
+are ERE elements not BRE (note that \? and \+ are not even part
+of BRE&#8201;&#8212;&#8201;making them accessible from BRE is a GNU extension).</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers in git-sh-i18n to make the user
+interface translatable. See "Marking strings for translation" in
+po/README.</p>
+</li>
+<li>
+<p>We do not write our "test" command with "-a" and "-o" and use "&amp;&amp;"
+or "||" to concatenate multiple "test" commands instead, because
+the use of "-a/-o" is often error-prone.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" -a "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is buggy and breaks when $x is "=", but</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" &amp;&amp; test "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>does not have such a problem.</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For C programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs to indent, and interpret tabs as taking up to
+8 spaces.</p>
+</li>
+<li>
+<p>We try to keep to at most 80 characters per line.</p>
+</li>
+<li>
+<p>As a Git developer we assume you have a reasonably modern compiler
+and we recommend you to enable the DEVELOPER makefile knob to
+ensure your patch is clear of all compiler warnings we care about,
+by e.g. "echo DEVELOPER=1 &gt;&gt;config.mak".</p>
+</li>
+<li>
+<p>We try to support a wide range of C compilers to compile Git with,
+including old ones. That means that you should not use C99
+initializers, even if a lot of compilers grok it.</p>
+</li>
+<li>
+<p>Variables have to be declared at the beginning of the block.</p>
+</li>
+<li>
+<p>NULL pointers shall be written as NULL, not as 0.</p>
+</li>
+<li>
+<p>When declaring pointers, the star sides with the variable
+name, i.e. "char <strong>string", not "char</strong> string" or
+"char * string".  This makes it easier to understand code
+like "char *string, c;".</p>
+</li>
+<li>
+<p>Use whitespace around operators and keywords, but not inside
+parentheses and not around functions. So:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      while (condition)
+func(bar + 1);</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>      while( condition )
+func (bar+1);</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We avoid using braces unnecessarily.  I.e.</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (bla) {
+	x = 1;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is frowned upon. But there are a few exceptions:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When the statement extends over a few lines (e.g., a while loop
+with an embedded conditional, or a comment). E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (foo) {
+	if (x)
+		one();
+	else
+		two();
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	/*
+	 * This one requires some explanation,
+	 * so we're better off with braces to make
+	 * it obvious that the indentation is correct.
+	 */
+	doit();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When there are multiple arms to a conditional and some of them
+require braces, enclose even a single line block in braces for
+consistency. E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	doit();
+} else {
+	one();
+	two();
+	three();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments in the condition of an "if" statement.</p>
+</li>
+<li>
+<p>Try to make your code understandable.  You may put comments
+in, but comments invariably tend to stale out when the code
+they were describing changes.  Often splitting a function
+into two makes the intention of the code much clearer.</p>
+</li>
+<li>
+<p>Multi-line comments include their delimiters on separate lines from
+the text.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * A very long
+ * multi-line comment.
+ */</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Note however that a comment that explains a translatable string to
+translators uses a convention of starting with a magic token
+"TRANSLATORS: ", e.g.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * TRANSLATORS: here is a comment that explains the string to
+ * be translated, that follows immediately after it.
+ */
+_("Here is a translatable string explained by the above.");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Double negation is often harder to understand than no negation
+at all.</p>
+</li>
+<li>
+<p>There are two schools of thought when it comes to comparison,
+especially inside a loop. Some people prefer to have the less stable
+value on the left hand side and the more stable value on the right hand
+side, e.g. if you have a loop that counts variable i down to the
+lower bound,</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (i &gt; lower_bound) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Other people prefer to have the textual order of values match the
+actual order of values in their comparison, so that they can
+mentally draw a number line from left to right and place these
+values in order, i.e.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while (lower_bound &lt; i) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  However, the more "stable" the
+stable side becomes, the more we tend to prefer the former
+(comparison with a constant, "i &gt; 0", is an extreme example).
+Just do not mix styles in the same part of the code and mimic
+existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>There are two schools of thought when it comes to splitting a long
+logical line into multiple lines.  Some people push the second and
+subsequent lines far enough to the right with tabs and align them:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+              ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to align the second and the subsequent
+lines with the column immediately inside the opening parenthesis,
+with tabs and spaces, following our "tabstop is always a multiple
+of 8" convention:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+           ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  Again, just do not mix styles in
+the same part of the code and mimic existing styles in the
+neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, some people change line before
+a binary operator, so that the result looks like a parse tree when
+you turn your head 90-degrees counterclockwise:</p>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to
+|| span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to leave the operator at the end of the
+line:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, but we tend to use the latter more, unless the
+expression gets fairly complex, in which case the former tends to
+be easier to read.  Again, just do not mix styles in the same part
+of the code and mimic existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, with everything else being
+equal, it is preferable to split after the operator at higher
+level in the parse tree.  That is, this is more preferable:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable * that_is_used_in +
+    a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>than</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable *
+    that_is_used_in + a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Some clever tricks, like using the !! operator with arithmetic
+constructs, can be extremely confusing to others.  Avoid them,
+unless there is a compelling reason to use them.</p>
+</li>
+<li>
+<p>Use the API.  No, really.  We have a strbuf (variable length
+string), several arrays with the ALLOC_GROW() macro, a
+string_list for sorted string lists, a hash map (mapping struct
+objects) named "struct decorate", amongst other things.</p>
+</li>
+<li>
+<p>When you come up with an API, document its functions and structures
+in the header file that exposes the API to its callers. Use what is
+in "strbuf.h" as a model for the appropriate tone and level of
+detail.</p>
+</li>
+<li>
+<p>The first #include in C files, except in platform specific compat/
+implementations, must be either "git-compat-util.h", "cache.h" or
+"builtin.h".  You do not have to include more than one of these.</p>
+</li>
+<li>
+<p>A C file must directly include the header files that declare the
+functions and the types it uses, except for the functions and types
+that are made available to it by including one of the header files
+it must include by the previous rule.</p>
+</li>
+<li>
+<p>If you are planning a new command, consider writing it in shell
+or perl first, so that changes in semantics can be easily
+changed and discussed.  Many Git commands started out like
+that, and a few are still scripts.</p>
+</li>
+<li>
+<p>Avoid introducing a new dependency into Git. This means you
+usually should stay away from scripting languages not already
+used in the Git core command set (unless your command is clearly
+separate from it, such as an importer to convert random-scm-X
+repositories to Git).</p>
+</li>
+<li>
+<p>When we pass &lt;string, length&gt; pair to functions, we should try to
+pass them in that order.</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers to make the user interface
+translatable. See "Marking strings for translation" in po/README.</p>
+</li>
+<li>
+<p>Variables and functions local to a given source file should be marked
+with "static". Variables that are visible to other source files
+must be declared with "extern" in header files. However, function
+declarations should not use "extern", as that is already the default.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Perl programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most of the C guidelines above apply.</p>
+</li>
+<li>
+<p>We try to support Perl 5.8 and later ("use Perl 5.008").</p>
+</li>
+<li>
+<p>use strict and use warnings are strongly preferred.</p>
+</li>
+<li>
+<p>Don&#8217;t overuse statement modifiers unless using them makes the
+result easier to follow.</p>
+<div class="olist lowerroman">
+<ol class="lowerroman" type="i">
+<li>
+<p>do something &#8230;&#8203;
+do_this() unless (condition);</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>is more readable than:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>do something &#8230;&#8203;
+unless (condition) {
+	do_this();
+}</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>*only* when the condition is so rare that do_this() will be almost
+always called.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments inside "if ()" conditions.</p>
+</li>
+<li>
+<p>Learn and use Git.pm if you need that functionality.</p>
+</li>
+<li>
+<p>For Emacs, it&#8217;s useful to put the following in
+GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode:</p>
+<div class="literalblock">
+<div class="content">
+<pre>;; note the first part is useful for C editing, too
+((nil . ((indent-tabs-mode . t)
+              (tab-width . 8)
+              (fill-column . 80)))
+ (cperl-mode . ((cperl-indent-level . 8)
+                (cperl-extra-newline-before-brace . nil)
+                (cperl-merge-trailing-else . t))))</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Python scripts:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We follow PEP-8 (<a href="http://www.python.org/dev/peps/pep-0008/" class="bare">http://www.python.org/dev/peps/pep-0008/</a>).</p>
+</li>
+<li>
+<p>As a minimum, we aim to be compatible with Python 2.6 and 2.7.</p>
+</li>
+<li>
+<p>Where required libraries do not restrict us to Python 2, we try to
+also be compatible with Python 3.1 and later.</p>
+</li>
+<li>
+<p>When you must differentiate between Unicode literals and byte string
+literals, it is OK to use the <em>b</em> prefix.  Even though the Python
+documentation for version 2.6 does not mention this prefix, it has
+been supported since version 2.6.0.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Error Messages</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Do not end error messages with a full stop.</p>
+</li>
+<li>
+<p>Do not capitalize ("unable to open %s", not "Unable to open %s")</p>
+</li>
+<li>
+<p>Say what the error is first ("cannot open %s", not "%s: cannot open")</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Externally Visible Names</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>For configuration variable names, follow the existing convention:</p>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>The section name indicates the affected subsystem.</p>
+</li>
+<li>
+<p>The subsection name, if any, indicates which of an unbounded set
+of things to set the value for.</p>
+</li>
+<li>
+<p>The variable name describes the effect of tweaking this knob.</p>
+<div class="literalblock">
+<div class="content">
+<pre>The section and variable names that consist of multiple words are
+formed by concatenating the words without punctuations (e.g. `-`),
+and are broken using bumpyCaps in documentation as a hint to the
+reader.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>When choosing the variable namespace, do not use variable name for
+specifying possibly unbounded set of things, most notably anything
+an end user can freely come up with (e.g. branch names).  Instead,
+use subsection names or variable values, like the existing variable
+branch.&lt;name&gt;.description does.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Writing Documentation:</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Most (if not all) of the documentation pages are written in the
+AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+processed into HTML and manpages (e.g. git.html and git.1 in the
+same directory).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>The documentation liberally mixes US and UK English (en_US/UK)
+norms for spelling and grammar, which is somewhat unfortunate.
+In an ideal world, it would have been better if it consistently
+used only one and not the other, and we would have picked en_US
+(if you wish to correct the English of some of the existing
+documentation, please see the documentation-related advice in the
+Documentation/SubmittingPatches file).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Every user-visible change should be reflected in the documentation.
+The same general rule as for code applies -- imitate the existing
+conventions.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying command usage strings and synopsis sections in the manual
+pages:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Placeholders are spelled in lowercase and enclosed in angle brackets:
+  &lt;file&gt;
+  --sort=&lt;key&gt;
+  --abbrev[=&lt;n&gt;]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If a placeholder has multiple words, they are separated by dashes:
+  &lt;new-branch-name&gt;
+  --template=&lt;template-directory&gt;</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Possibility of multiple occurrences is indicated by three dots:
+  &lt;file&gt;...
+  (One or more of &lt;file&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Optional parts are enclosed in square brackets:
+  [&lt;extra&gt;]
+  (Zero or one &lt;extra&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>--exec-path[=&lt;path&gt;]
+(Option with an optional argument.  Note that the "=" is inside the
+brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[&lt;patch&gt;...]
+(Zero or more of &lt;patch&gt;.  Note that the dots are inside, not
+outside the brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Multiple alternatives are indicated with vertical bars:
+  [-q | --quiet]
+  [--utf8 | --no-utf8]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Parentheses are used for grouping:
+  [(&lt;rev&gt; | &lt;range&gt;)...]
+  (Any number of either &lt;rev&gt; or &lt;range&gt;.  Parens are needed to make
+  it clear that "..." pertains to both &lt;rev&gt; and &lt;range&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[(-p &lt;parent&gt;)...]
+(Any number of option -p, each with one &lt;parent&gt; argument.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>git remote set-head &lt;name&gt; (-a | -d | &lt;branch&gt;)
+(One and only one of "-a", "-d" or "&lt;branch&gt;" _must_ (no square
+brackets) be provided.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>And a somewhat more contrived example:
+  --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+  Here "=" is outside the brackets, because "--diff-filter=" is a
+  valid usage.  "*" has its own pair of brackets, because it can
+  (optionally) be specified only when one or more of the letters is
+  also provided.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A note on notation:
+ Use 'git' (all lowercase) when talking about commands i.e. something
+ the user would type into a shell and use 'Git' (uppercase first letter)
+ when talking about the version control system and its properties.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying paragraphs or option/command explanations that contain options
+or commands:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Literal examples (e.g. use of command-line options, command names,
+branch names, configuration and environment variables) must be
+typeset in monospace (i.e. wrapped with backticks):
+  `--pretty=oneline`
+  `git rev-list`
+  `remote.pushDefault`
+  `GIT_DIR`
+  `HEAD`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>An environment variable must be prefixed with "$" only when referring to its
+value and not when referring to the variable itself, in this case there is
+nothing to add except the backticks:
+  `GIT_DIR` is specified
+  `$GIT_DIR/hooks/pre-receive`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Word phrases enclosed in `backtick characters` are rendered literally
+and will not be further expanded. The use of `backticks` to achieve the
+previous rule means that literal examples should not use AsciiDoc
+escapes.
+  Correct:
+     `--pretty=oneline`
+  Incorrect:
+     `\--pretty=oneline`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If some place in the documentation needs to typeset a command usage
+example with inline substitutions, it is fine to use +monospaced and
+inline substituted text+ instead of `monospaced literal text`, and with
+the former, the part that should not get substituted must be
+quoted/escaped.</pre>
+</div>
+</div>
+</div>
+</div>
\ No newline at end of file
diff --git a/external/docs/content/docs/CodingGuidelines/2.20.0.html b/external/docs/content/docs/CodingGuidelines/2.20.0.html
new file mode 100644
index 0000000000..746736ef28
--- /dev/null
+++ b/external/docs/content/docs/CodingGuidelines/2.20.0.html
@@ -0,0 +1,965 @@
+---
+### DO NOT EDIT! Generated by script/update-docs.rb
+
+category: manual
+section: documentation
+subsection: manual
+title: Git - CodingGuidelines Documentation
+docname: CodingGuidelines
+version: 2.20.0
+aliases:
+- "/docs/CodingGuidelines/2.20.0/index.html"
+- "/docs/CodingGuidelines/2.20.1/index.html"
+- "/docs/CodingGuidelines/2.20.2/index.html"
+- "/docs/CodingGuidelines/2.20.3/index.html"
+- "/docs/CodingGuidelines/2.20.4/index.html"
+- "/docs/CodingGuidelines/2.20.5/index.html"
+- "/docs/CodingGuidelines/2.21.0/index.html"
+- "/docs/CodingGuidelines/2.21.1/index.html"
+- "/docs/CodingGuidelines/2.21.2/index.html"
+- "/docs/CodingGuidelines/2.21.3/index.html"
+- "/docs/CodingGuidelines/2.21.4/index.html"
+---
+<div id="preamble">
+<div class="sectionbody">
+<div class="paragraph">
+<p>Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, a few rough rules are:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most importantly, we never say "It&#8217;s in POSIX; we&#8217;ll happily
+ignore your needs should your system not conform to it."
+We live in the real world.</p>
+</li>
+<li>
+<p>However, we often say "Let&#8217;s stay away from that construct,
+it&#8217;s not even in POSIX".</p>
+</li>
+<li>
+<p>In spite of the above two rules, we sometimes say "Although
+this is not in POSIX, it (is so convenient | makes the code
+much more readable | has other good characteristics) and
+practically all the platforms we care about support it, so
+let&#8217;s use it".</p>
+<div class="literalblock">
+<div class="content">
+<pre>Again, we live in the real world, and it is sometimes a
+judgement call, the decision based more on real world
+constraints people face than what the paper standard says.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Fixing style violations while working on a real change as a
+preparatory clean-up step is good, but otherwise avoid useless code
+churn for the sake of conforming to the style.</p>
+<div class="literalblock">
+<div class="content">
+<pre>"Once it _is_ in the tree, it's not really worth the patch noise to
+go and fix it up."
+Cf. http://lkml.iu.edu/hypermail/linux/kernel/1001.3/01069.html</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Make your code readable and sensible, and don&#8217;t try to be clever.</p>
+</div>
+<div class="paragraph">
+<p>As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the <em>local</em>
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn&#8217;t match the overall style of existing code).</p>
+</div>
+<div class="paragraph">
+<p>But if you must have a list of rules, here they are.</p>
+</div>
+<div class="paragraph">
+<p>For shell scripts specifically (not exhaustive):</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs for indentation.</p>
+</li>
+<li>
+<p>Case arms are indented at the same depth as case and esac lines,
+like this:</p>
+<div class="literalblock">
+<div class="content">
+<pre>case "$variable" in
+pattern1)
+	do this
+	;;
+pattern2)
+	do that
+	;;
+esac</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Redirection operators should be written with space before, but no
+space after them.  In other words, write <em>echo test &gt;"$file"</em>
+instead of <em>echo test&gt; $file</em> or <em>echo test &gt; $file</em>.  Note that
+even though it is not required by POSIX to double-quote the
+redirection target in a variable (as shown above), our code does so
+because some versions of bash issue a warning without the quotes.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+cat hello &gt; world &lt; universe
+echo hello &gt;$world</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+cat hello &gt;world &lt;universe
+echo hello &gt;"$world"</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer $( &#8230;&#8203; ) for command substitution; unlike ``, it
+properly nests.  It should have been the way Bourne spelled
+it from day one, but unfortunately isn&#8217;t.</p>
+</li>
+<li>
+<p>If you want to find out if a command is available on the user&#8217;s
+$PATH, you should use <em>type &lt;command&gt;</em>, instead of <em>which &lt;command&gt;</em>.
+The output of <em>which</em> is not machine parseable and its exit code
+is not reliable across platforms.</p>
+</li>
+<li>
+<p>We use POSIX compliant parameter substitutions and avoid bashisms;
+namely:</p>
+</li>
+<li>
+<p>We use ${parameter-word} and its [-=?+] siblings, and their
+colon&#8217;ed "unset or null" form.</p>
+</li>
+<li>
+<p>We use ${parameter#word} and its [#%] siblings, and their
+doubled "longest matching" form.</p>
+</li>
+<li>
+<p>No "Substring Expansion" ${parameter:offset:length}.</p>
+</li>
+<li>
+<p>No shell arrays.</p>
+</li>
+<li>
+<p>No strlen ${#parameter}.</p>
+</li>
+<li>
+<p>No pattern replacement ${parameter/pattern/string}.</p>
+</li>
+<li>
+<p>We use Arithmetic Expansion $&#8230;&#8203;.</p>
+</li>
+<li>
+<p>Inside Arithmetic Expansion, spell shell variables with $ in front
+of them, as some shells do not grok $x while accepting $$x
+just fine (e.g. dash older than 0.5.4).</p>
+</li>
+<li>
+<p>We do not use Process Substitution &lt;(list) or &gt;(list).</p>
+</li>
+<li>
+<p>Do not write control structures on a single line with semicolon.
+"then" should be on the next line for if statements, and "do"
+should be on the next line for "while" and "for".</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+if test -f hello; then
+	do this
+fi</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+if test -f hello
+then
+	do this
+fi</pre>
+</div>
+</div>
+</li>
+<li>
+<p>If a command sequence joined with &amp;&amp; or || or | spans multiple
+lines, put each command on a separate line and put &amp;&amp; and || and |
+operators at the end of each line, rather than the start. This
+means you don&#8217;t need to use \ to join lines, since the above
+operators imply the sequence isn&#8217;t finished.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+grep blob verify_pack_result \
+| awk -f print_1.awk \
+| sort &gt;actual &amp;&amp;
+...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+grep blob verify_pack_result |
+awk -f print_1.awk |
+sort &gt;actual &amp;&amp;
+...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer "test" over "[ &#8230;&#8203; ]".</p>
+</li>
+<li>
+<p>We do not write the noiseword "function" in front of shell
+functions.</p>
+</li>
+<li>
+<p>We prefer a space between the function name and the parentheses,
+and no space inside the parentheses. The opening "{" should also
+be on the same line.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+my_function(){
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+my_function () {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+[::], [==], or [..]) for portability.</p>
+</li>
+<li>
+<p>We do not use \{m,n\};</p>
+</li>
+<li>
+<p>We do not use -E;</p>
+</li>
+<li>
+<p>We do not use ? or + (which are \{0,1\} and \{1,\}
+respectively in BRE) but that goes without saying as these
+are ERE elements not BRE (note that \? and \+ are not even part
+of BRE&#8201;&#8212;&#8201;making them accessible from BRE is a GNU extension).</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers in git-sh-i18n to make the user
+interface translatable. See "Marking strings for translation" in
+po/README.</p>
+</li>
+<li>
+<p>We do not write our "test" command with "-a" and "-o" and use "&amp;&amp;"
+or "||" to concatenate multiple "test" commands instead, because
+the use of "-a/-o" is often error-prone.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" -a "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is buggy and breaks when $x is "=", but</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" &amp;&amp; test "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>does not have such a problem.</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For C programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs to indent, and interpret tabs as taking up to
+8 spaces.</p>
+</li>
+<li>
+<p>We try to keep to at most 80 characters per line.</p>
+</li>
+<li>
+<p>As a Git developer we assume you have a reasonably modern compiler
+and we recommend you to enable the DEVELOPER makefile knob to
+ensure your patch is clear of all compiler warnings we care about,
+by e.g. "echo DEVELOPER=1 &gt;&gt;config.mak".</p>
+</li>
+<li>
+<p>We try to support a wide range of C compilers to compile Git with,
+including old ones. That means that you should not use C99
+initializers, even if a lot of compilers grok it.</p>
+</li>
+<li>
+<p>Variables have to be declared at the beginning of the block.</p>
+</li>
+<li>
+<p>NULL pointers shall be written as NULL, not as 0.</p>
+</li>
+<li>
+<p>When declaring pointers, the star sides with the variable
+name, i.e. "char <strong>string", not "char</strong> string" or
+"char * string".  This makes it easier to understand code
+like "char *string, c;".</p>
+</li>
+<li>
+<p>Use whitespace around operators and keywords, but not inside
+parentheses and not around functions. So:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      while (condition)
+func(bar + 1);</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>      while( condition )
+func (bar+1);</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We avoid using braces unnecessarily.  I.e.</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (bla) {
+	x = 1;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is frowned upon. But there are a few exceptions:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When the statement extends over a few lines (e.g., a while loop
+with an embedded conditional, or a comment). E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (foo) {
+	if (x)
+		one();
+	else
+		two();
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	/*
+	 * This one requires some explanation,
+	 * so we're better off with braces to make
+	 * it obvious that the indentation is correct.
+	 */
+	doit();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When there are multiple arms to a conditional and some of them
+require braces, enclose even a single line block in braces for
+consistency. E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	doit();
+} else {
+	one();
+	two();
+	three();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments in the condition of an "if" statement.</p>
+</li>
+<li>
+<p>Try to make your code understandable.  You may put comments
+in, but comments invariably tend to stale out when the code
+they were describing changes.  Often splitting a function
+into two makes the intention of the code much clearer.</p>
+</li>
+<li>
+<p>Multi-line comments include their delimiters on separate lines from
+the text.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * A very long
+ * multi-line comment.
+ */</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Note however that a comment that explains a translatable string to
+translators uses a convention of starting with a magic token
+"TRANSLATORS: ", e.g.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * TRANSLATORS: here is a comment that explains the string to
+ * be translated, that follows immediately after it.
+ */
+_("Here is a translatable string explained by the above.");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Double negation is often harder to understand than no negation
+at all.</p>
+</li>
+<li>
+<p>There are two schools of thought when it comes to comparison,
+especially inside a loop. Some people prefer to have the less stable
+value on the left hand side and the more stable value on the right hand
+side, e.g. if you have a loop that counts variable i down to the
+lower bound,</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (i &gt; lower_bound) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Other people prefer to have the textual order of values match the
+actual order of values in their comparison, so that they can
+mentally draw a number line from left to right and place these
+values in order, i.e.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while (lower_bound &lt; i) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  However, the more "stable" the
+stable side becomes, the more we tend to prefer the former
+(comparison with a constant, "i &gt; 0", is an extreme example).
+Just do not mix styles in the same part of the code and mimic
+existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>There are two schools of thought when it comes to splitting a long
+logical line into multiple lines.  Some people push the second and
+subsequent lines far enough to the right with tabs and align them:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+              ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to align the second and the subsequent
+lines with the column immediately inside the opening parenthesis,
+with tabs and spaces, following our "tabstop is always a multiple
+of 8" convention:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+           ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  Again, just do not mix styles in
+the same part of the code and mimic existing styles in the
+neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, some people change line before
+a binary operator, so that the result looks like a parse tree when
+you turn your head 90-degrees counterclockwise:</p>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to
+|| span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to leave the operator at the end of the
+line:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, but we tend to use the latter more, unless the
+expression gets fairly complex, in which case the former tends to
+be easier to read.  Again, just do not mix styles in the same part
+of the code and mimic existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, with everything else being
+equal, it is preferable to split after the operator at higher
+level in the parse tree.  That is, this is more preferable:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable * that_is_used_in +
+    a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>than</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable *
+    that_is_used_in + a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Some clever tricks, like using the !! operator with arithmetic
+constructs, can be extremely confusing to others.  Avoid them,
+unless there is a compelling reason to use them.</p>
+</li>
+<li>
+<p>Use the API.  No, really.  We have a strbuf (variable length
+string), several arrays with the ALLOC_GROW() macro, a
+string_list for sorted string lists, a hash map (mapping struct
+objects) named "struct decorate", amongst other things.</p>
+</li>
+<li>
+<p>When you come up with an API, document its functions and structures
+in the header file that exposes the API to its callers. Use what is
+in "strbuf.h" as a model for the appropriate tone and level of
+detail.</p>
+</li>
+<li>
+<p>The first #include in C files, except in platform specific compat/
+implementations, must be either "git-compat-util.h", "cache.h" or
+"builtin.h".  You do not have to include more than one of these.</p>
+</li>
+<li>
+<p>A C file must directly include the header files that declare the
+functions and the types it uses, except for the functions and types
+that are made available to it by including one of the header files
+it must include by the previous rule.</p>
+</li>
+<li>
+<p>If you are planning a new command, consider writing it in shell
+or perl first, so that changes in semantics can be easily
+changed and discussed.  Many Git commands started out like
+that, and a few are still scripts.</p>
+</li>
+<li>
+<p>Avoid introducing a new dependency into Git. This means you
+usually should stay away from scripting languages not already
+used in the Git core command set (unless your command is clearly
+separate from it, such as an importer to convert random-scm-X
+repositories to Git).</p>
+</li>
+<li>
+<p>When we pass &lt;string, length&gt; pair to functions, we should try to
+pass them in that order.</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers to make the user interface
+translatable. See "Marking strings for translation" in po/README.</p>
+</li>
+<li>
+<p>Variables and functions local to a given source file should be marked
+with "static". Variables that are visible to other source files
+must be declared with "extern" in header files. However, function
+declarations should not use "extern", as that is already the default.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Perl programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most of the C guidelines above apply.</p>
+</li>
+<li>
+<p>We try to support Perl 5.8 and later ("use Perl 5.008").</p>
+</li>
+<li>
+<p>use strict and use warnings are strongly preferred.</p>
+</li>
+<li>
+<p>Don&#8217;t overuse statement modifiers unless using them makes the
+result easier to follow.</p>
+<div class="olist lowerroman">
+<ol class="lowerroman" type="i">
+<li>
+<p>do something &#8230;&#8203;
+do_this() unless (condition);</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>is more readable than:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>do something &#8230;&#8203;
+unless (condition) {
+	do_this();
+}</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>*only* when the condition is so rare that do_this() will be almost
+always called.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments inside "if ()" conditions.</p>
+</li>
+<li>
+<p>Learn and use Git.pm if you need that functionality.</p>
+</li>
+<li>
+<p>For Emacs, it&#8217;s useful to put the following in
+GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode:</p>
+<div class="literalblock">
+<div class="content">
+<pre>;; note the first part is useful for C editing, too
+((nil . ((indent-tabs-mode . t)
+              (tab-width . 8)
+              (fill-column . 80)))
+ (cperl-mode . ((cperl-indent-level . 8)
+                (cperl-extra-newline-before-brace . nil)
+                (cperl-merge-trailing-else . t))))</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Python scripts:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We follow PEP-8 (<a href="http://www.python.org/dev/peps/pep-0008/" class="bare">http://www.python.org/dev/peps/pep-0008/</a>).</p>
+</li>
+<li>
+<p>As a minimum, we aim to be compatible with Python 2.6 and 2.7.</p>
+</li>
+<li>
+<p>Where required libraries do not restrict us to Python 2, we try to
+also be compatible with Python 3.1 and later.</p>
+</li>
+<li>
+<p>When you must differentiate between Unicode literals and byte string
+literals, it is OK to use the <em>b</em> prefix.  Even though the Python
+documentation for version 2.6 does not mention this prefix, it has
+been supported since version 2.6.0.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Error Messages</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Do not end error messages with a full stop.</p>
+</li>
+<li>
+<p>Do not capitalize ("unable to open %s", not "Unable to open %s")</p>
+</li>
+<li>
+<p>Say what the error is first ("cannot open %s", not "%s: cannot open")</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Externally Visible Names</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>For configuration variable names, follow the existing convention:</p>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>The section name indicates the affected subsystem.</p>
+</li>
+<li>
+<p>The subsection name, if any, indicates which of an unbounded set
+of things to set the value for.</p>
+</li>
+<li>
+<p>The variable name describes the effect of tweaking this knob.</p>
+<div class="literalblock">
+<div class="content">
+<pre>The section and variable names that consist of multiple words are
+formed by concatenating the words without punctuations (e.g. `-`),
+and are broken using bumpyCaps in documentation as a hint to the
+reader.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>When choosing the variable namespace, do not use variable name for
+specifying possibly unbounded set of things, most notably anything
+an end user can freely come up with (e.g. branch names).  Instead,
+use subsection names or variable values, like the existing variable
+branch.&lt;name&gt;.description does.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Writing Documentation:</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Most (if not all) of the documentation pages are written in the
+AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+processed into HTML and manpages (e.g. git.html and git.1 in the
+same directory).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>The documentation liberally mixes US and UK English (en_US/UK)
+norms for spelling and grammar, which is somewhat unfortunate.
+In an ideal world, it would have been better if it consistently
+used only one and not the other, and we would have picked en_US
+(if you wish to correct the English of some of the existing
+documentation, please see the documentation-related advice in the
+Documentation/SubmittingPatches file).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Every user-visible change should be reflected in the documentation.
+The same general rule as for code applies -- imitate the existing
+conventions.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying command usage strings and synopsis sections in the manual
+pages:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Placeholders are spelled in lowercase and enclosed in angle brackets:
+  &lt;file&gt;
+  --sort=&lt;key&gt;
+  --abbrev[=&lt;n&gt;]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If a placeholder has multiple words, they are separated by dashes:
+  &lt;new-branch-name&gt;
+  --template=&lt;template-directory&gt;</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Possibility of multiple occurrences is indicated by three dots:
+  &lt;file&gt;...
+  (One or more of &lt;file&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Optional parts are enclosed in square brackets:
+  [&lt;extra&gt;]
+  (Zero or one &lt;extra&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>--exec-path[=&lt;path&gt;]
+(Option with an optional argument.  Note that the "=" is inside the
+brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[&lt;patch&gt;...]
+(Zero or more of &lt;patch&gt;.  Note that the dots are inside, not
+outside the brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Multiple alternatives are indicated with vertical bars:
+  [-q | --quiet]
+  [--utf8 | --no-utf8]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Parentheses are used for grouping:
+  [(&lt;rev&gt; | &lt;range&gt;)...]
+  (Any number of either &lt;rev&gt; or &lt;range&gt;.  Parens are needed to make
+  it clear that "..." pertains to both &lt;rev&gt; and &lt;range&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[(-p &lt;parent&gt;)...]
+(Any number of option -p, each with one &lt;parent&gt; argument.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>git remote set-head &lt;name&gt; (-a | -d | &lt;branch&gt;)
+(One and only one of "-a", "-d" or "&lt;branch&gt;" _must_ (no square
+brackets) be provided.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>And a somewhat more contrived example:
+  --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+  Here "=" is outside the brackets, because "--diff-filter=" is a
+  valid usage.  "*" has its own pair of brackets, because it can
+  (optionally) be specified only when one or more of the letters is
+  also provided.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A note on notation:
+ Use 'git' (all lowercase) when talking about commands i.e. something
+ the user would type into a shell and use 'Git' (uppercase first letter)
+ when talking about the version control system and its properties.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying paragraphs or option/command explanations that contain options
+or commands:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Literal examples (e.g. use of command-line options, command names,
+branch names, configuration and environment variables) must be
+typeset in monospace (i.e. wrapped with backticks):
+  `--pretty=oneline`
+  `git rev-list`
+  `remote.pushDefault`
+  `GIT_DIR`
+  `HEAD`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>An environment variable must be prefixed with "$" only when referring to its
+value and not when referring to the variable itself, in this case there is
+nothing to add except the backticks:
+  `GIT_DIR` is specified
+  `$GIT_DIR/hooks/pre-receive`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Word phrases enclosed in `backtick characters` are rendered literally
+and will not be further expanded. The use of `backticks` to achieve the
+previous rule means that literal examples should not use AsciiDoc
+escapes.
+  Correct:
+     `--pretty=oneline`
+  Incorrect:
+     `\--pretty=oneline`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If some place in the documentation needs to typeset a command usage
+example with inline substitutions, it is fine to use +monospaced and
+inline substituted text+ instead of `monospaced literal text`, and with
+the former, the part that should not get substituted must be
+quoted/escaped.</pre>
+</div>
+</div>
+</div>
+</div>
\ No newline at end of file
diff --git a/external/docs/content/docs/CodingGuidelines/2.22.0.html b/external/docs/content/docs/CodingGuidelines/2.22.0.html
new file mode 100644
index 0000000000..601abe0fb1
--- /dev/null
+++ b/external/docs/content/docs/CodingGuidelines/2.22.0.html
@@ -0,0 +1,958 @@
+---
+### DO NOT EDIT! Generated by script/update-docs.rb
+
+category: manual
+section: documentation
+subsection: manual
+title: Git - CodingGuidelines Documentation
+docname: CodingGuidelines
+version: 2.22.0
+aliases:
+- "/docs/CodingGuidelines/2.22.0/index.html"
+---
+<div id="preamble">
+<div class="sectionbody">
+<div class="paragraph">
+<p>Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, a few rough rules are:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most importantly, we never say "It&#8217;s in POSIX; we&#8217;ll happily
+ignore your needs should your system not conform to it."
+We live in the real world.</p>
+</li>
+<li>
+<p>However, we often say "Let&#8217;s stay away from that construct,
+it&#8217;s not even in POSIX".</p>
+</li>
+<li>
+<p>In spite of the above two rules, we sometimes say "Although
+this is not in POSIX, it (is so convenient | makes the code
+much more readable | has other good characteristics) and
+practically all the platforms we care about support it, so
+let&#8217;s use it".</p>
+<div class="literalblock">
+<div class="content">
+<pre>Again, we live in the real world, and it is sometimes a
+judgement call, the decision based more on real world
+constraints people face than what the paper standard says.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Fixing style violations while working on a real change as a
+preparatory clean-up step is good, but otherwise avoid useless code
+churn for the sake of conforming to the style.</p>
+<div class="literalblock">
+<div class="content">
+<pre>"Once it _is_ in the tree, it's not really worth the patch noise to
+go and fix it up."
+Cf. http://lkml.iu.edu/hypermail/linux/kernel/1001.3/01069.html</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Make your code readable and sensible, and don&#8217;t try to be clever.</p>
+</div>
+<div class="paragraph">
+<p>As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the <em>local</em>
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn&#8217;t match the overall style of existing code).</p>
+</div>
+<div class="paragraph">
+<p>But if you must have a list of rules, here they are.</p>
+</div>
+<div class="paragraph">
+<p>For shell scripts specifically (not exhaustive):</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs for indentation.</p>
+</li>
+<li>
+<p>Case arms are indented at the same depth as case and esac lines,
+like this:</p>
+<div class="literalblock">
+<div class="content">
+<pre>case "$variable" in
+pattern1)
+	do this
+	;;
+pattern2)
+	do that
+	;;
+esac</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Redirection operators should be written with space before, but no
+space after them.  In other words, write <em>echo test &gt;"$file"</em>
+instead of <em>echo test&gt; $file</em> or <em>echo test &gt; $file</em>.  Note that
+even though it is not required by POSIX to double-quote the
+redirection target in a variable (as shown above), our code does so
+because some versions of bash issue a warning without the quotes.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+cat hello &gt; world &lt; universe
+echo hello &gt;$world</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+cat hello &gt;world &lt;universe
+echo hello &gt;"$world"</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer $( &#8230;&#8203; ) for command substitution; unlike ``, it
+properly nests.  It should have been the way Bourne spelled
+it from day one, but unfortunately isn&#8217;t.</p>
+</li>
+<li>
+<p>If you want to find out if a command is available on the user&#8217;s
+$PATH, you should use <em>type &lt;command&gt;</em>, instead of <em>which &lt;command&gt;</em>.
+The output of <em>which</em> is not machine parseable and its exit code
+is not reliable across platforms.</p>
+</li>
+<li>
+<p>We use POSIX compliant parameter substitutions and avoid bashisms;
+namely:</p>
+</li>
+<li>
+<p>We use ${parameter-word} and its [-=?+] siblings, and their
+colon&#8217;ed "unset or null" form.</p>
+</li>
+<li>
+<p>We use ${parameter#word} and its [#%] siblings, and their
+doubled "longest matching" form.</p>
+</li>
+<li>
+<p>No "Substring Expansion" ${parameter:offset:length}.</p>
+</li>
+<li>
+<p>No shell arrays.</p>
+</li>
+<li>
+<p>No strlen ${#parameter}.</p>
+</li>
+<li>
+<p>No pattern replacement ${parameter/pattern/string}.</p>
+</li>
+<li>
+<p>We use Arithmetic Expansion $&#8230;&#8203;.</p>
+</li>
+<li>
+<p>Inside Arithmetic Expansion, spell shell variables with $ in front
+of them, as some shells do not grok $x while accepting $$x
+just fine (e.g. dash older than 0.5.4).</p>
+</li>
+<li>
+<p>We do not use Process Substitution &lt;(list) or &gt;(list).</p>
+</li>
+<li>
+<p>Do not write control structures on a single line with semicolon.
+"then" should be on the next line for if statements, and "do"
+should be on the next line for "while" and "for".</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+if test -f hello; then
+	do this
+fi</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+if test -f hello
+then
+	do this
+fi</pre>
+</div>
+</div>
+</li>
+<li>
+<p>If a command sequence joined with &amp;&amp; or || or | spans multiple
+lines, put each command on a separate line and put &amp;&amp; and || and |
+operators at the end of each line, rather than the start. This
+means you don&#8217;t need to use \ to join lines, since the above
+operators imply the sequence isn&#8217;t finished.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+grep blob verify_pack_result \
+| awk -f print_1.awk \
+| sort &gt;actual &amp;&amp;
+...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+grep blob verify_pack_result |
+awk -f print_1.awk |
+sort &gt;actual &amp;&amp;
+...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer "test" over "[ &#8230;&#8203; ]".</p>
+</li>
+<li>
+<p>We do not write the noiseword "function" in front of shell
+functions.</p>
+</li>
+<li>
+<p>We prefer a space between the function name and the parentheses,
+and no space inside the parentheses. The opening "{" should also
+be on the same line.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+my_function(){
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+my_function () {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+[::], [==], or [..]) for portability.</p>
+</li>
+<li>
+<p>We do not use \{m,n\};</p>
+</li>
+<li>
+<p>We do not use -E;</p>
+</li>
+<li>
+<p>We do not use ? or + (which are \{0,1\} and \{1,\}
+respectively in BRE) but that goes without saying as these
+are ERE elements not BRE (note that \? and \+ are not even part
+of BRE&#8201;&#8212;&#8201;making them accessible from BRE is a GNU extension).</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers in git-sh-i18n to make the user
+interface translatable. See "Marking strings for translation" in
+po/README.</p>
+</li>
+<li>
+<p>We do not write our "test" command with "-a" and "-o" and use "&amp;&amp;"
+or "||" to concatenate multiple "test" commands instead, because
+the use of "-a/-o" is often error-prone.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" -a "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is buggy and breaks when $x is "=", but</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" &amp;&amp; test "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>does not have such a problem.</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For C programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs to indent, and interpret tabs as taking up to
+8 spaces.</p>
+</li>
+<li>
+<p>We try to keep to at most 80 characters per line.</p>
+</li>
+<li>
+<p>As a Git developer we assume you have a reasonably modern compiler
+and we recommend you to enable the DEVELOPER makefile knob to
+ensure your patch is clear of all compiler warnings we care about,
+by e.g. "echo DEVELOPER=1 &gt;&gt;config.mak".</p>
+</li>
+<li>
+<p>We try to support a wide range of C compilers to compile Git with,
+including old ones. That means that you should not use C99
+initializers, even if a lot of compilers grok it.</p>
+</li>
+<li>
+<p>Variables have to be declared at the beginning of the block.</p>
+</li>
+<li>
+<p>NULL pointers shall be written as NULL, not as 0.</p>
+</li>
+<li>
+<p>When declaring pointers, the star sides with the variable
+name, i.e. "char <strong>string", not "char</strong> string" or
+"char * string".  This makes it easier to understand code
+like "char *string, c;".</p>
+</li>
+<li>
+<p>Use whitespace around operators and keywords, but not inside
+parentheses and not around functions. So:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      while (condition)
+func(bar + 1);</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>      while( condition )
+func (bar+1);</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We avoid using braces unnecessarily.  I.e.</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (bla) {
+	x = 1;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is frowned upon. But there are a few exceptions:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When the statement extends over a few lines (e.g., a while loop
+with an embedded conditional, or a comment). E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (foo) {
+	if (x)
+		one();
+	else
+		two();
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	/*
+	 * This one requires some explanation,
+	 * so we're better off with braces to make
+	 * it obvious that the indentation is correct.
+	 */
+	doit();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When there are multiple arms to a conditional and some of them
+require braces, enclose even a single line block in braces for
+consistency. E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	doit();
+} else {
+	one();
+	two();
+	three();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments in the condition of an "if" statement.</p>
+</li>
+<li>
+<p>Try to make your code understandable.  You may put comments
+in, but comments invariably tend to stale out when the code
+they were describing changes.  Often splitting a function
+into two makes the intention of the code much clearer.</p>
+</li>
+<li>
+<p>Multi-line comments include their delimiters on separate lines from
+the text.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * A very long
+ * multi-line comment.
+ */</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Note however that a comment that explains a translatable string to
+translators uses a convention of starting with a magic token
+"TRANSLATORS: ", e.g.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * TRANSLATORS: here is a comment that explains the string to
+ * be translated, that follows immediately after it.
+ */
+_("Here is a translatable string explained by the above.");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Double negation is often harder to understand than no negation
+at all.</p>
+</li>
+<li>
+<p>There are two schools of thought when it comes to comparison,
+especially inside a loop. Some people prefer to have the less stable
+value on the left hand side and the more stable value on the right hand
+side, e.g. if you have a loop that counts variable i down to the
+lower bound,</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (i &gt; lower_bound) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Other people prefer to have the textual order of values match the
+actual order of values in their comparison, so that they can
+mentally draw a number line from left to right and place these
+values in order, i.e.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while (lower_bound &lt; i) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  However, the more "stable" the
+stable side becomes, the more we tend to prefer the former
+(comparison with a constant, "i &gt; 0", is an extreme example).
+Just do not mix styles in the same part of the code and mimic
+existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>There are two schools of thought when it comes to splitting a long
+logical line into multiple lines.  Some people push the second and
+subsequent lines far enough to the right with tabs and align them:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+              ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to align the second and the subsequent
+lines with the column immediately inside the opening parenthesis,
+with tabs and spaces, following our "tabstop is always a multiple
+of 8" convention:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+           ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  Again, just do not mix styles in
+the same part of the code and mimic existing styles in the
+neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, some people change line before
+a binary operator, so that the result looks like a parse tree when
+you turn your head 90-degrees counterclockwise:</p>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to
+|| span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to leave the operator at the end of the
+line:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, but we tend to use the latter more, unless the
+expression gets fairly complex, in which case the former tends to
+be easier to read.  Again, just do not mix styles in the same part
+of the code and mimic existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, with everything else being
+equal, it is preferable to split after the operator at higher
+level in the parse tree.  That is, this is more preferable:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable * that_is_used_in +
+    a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>than</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable *
+    that_is_used_in + a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Some clever tricks, like using the !! operator with arithmetic
+constructs, can be extremely confusing to others.  Avoid them,
+unless there is a compelling reason to use them.</p>
+</li>
+<li>
+<p>Use the API.  No, really.  We have a strbuf (variable length
+string), several arrays with the ALLOC_GROW() macro, a
+string_list for sorted string lists, a hash map (mapping struct
+objects) named "struct decorate", amongst other things.</p>
+</li>
+<li>
+<p>When you come up with an API, document its functions and structures
+in the header file that exposes the API to its callers. Use what is
+in "strbuf.h" as a model for the appropriate tone and level of
+detail.</p>
+</li>
+<li>
+<p>The first #include in C files, except in platform specific compat/
+implementations, must be either "git-compat-util.h", "cache.h" or
+"builtin.h".  You do not have to include more than one of these.</p>
+</li>
+<li>
+<p>A C file must directly include the header files that declare the
+functions and the types it uses, except for the functions and types
+that are made available to it by including one of the header files
+it must include by the previous rule.</p>
+</li>
+<li>
+<p>If you are planning a new command, consider writing it in shell
+or perl first, so that changes in semantics can be easily
+changed and discussed.  Many Git commands started out like
+that, and a few are still scripts.</p>
+</li>
+<li>
+<p>Avoid introducing a new dependency into Git. This means you
+usually should stay away from scripting languages not already
+used in the Git core command set (unless your command is clearly
+separate from it, such as an importer to convert random-scm-X
+repositories to Git).</p>
+</li>
+<li>
+<p>When we pass &lt;string, length&gt; pair to functions, we should try to
+pass them in that order.</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers to make the user interface
+translatable. See "Marking strings for translation" in po/README.</p>
+</li>
+<li>
+<p>Variables and functions local to a given source file should be marked
+with "static". Variables that are visible to other source files
+must be declared with "extern" in header files. However, function
+declarations should not use "extern", as that is already the default.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Perl programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most of the C guidelines above apply.</p>
+</li>
+<li>
+<p>We try to support Perl 5.8 and later ("use Perl 5.008").</p>
+</li>
+<li>
+<p>use strict and use warnings are strongly preferred.</p>
+</li>
+<li>
+<p>Don&#8217;t overuse statement modifiers unless using them makes the
+result easier to follow.</p>
+<div class="olist lowerroman">
+<ol class="lowerroman" type="i">
+<li>
+<p>do something &#8230;&#8203;
+do_this() unless (condition);</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>is more readable than:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>do something &#8230;&#8203;
+unless (condition) {
+	do_this();
+}</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>*only* when the condition is so rare that do_this() will be almost
+always called.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments inside "if ()" conditions.</p>
+</li>
+<li>
+<p>Learn and use Git.pm if you need that functionality.</p>
+</li>
+<li>
+<p>For Emacs, it&#8217;s useful to put the following in
+GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode:</p>
+<div class="literalblock">
+<div class="content">
+<pre>;; note the first part is useful for C editing, too
+((nil . ((indent-tabs-mode . t)
+              (tab-width . 8)
+              (fill-column . 80)))
+ (cperl-mode . ((cperl-indent-level . 8)
+                (cperl-extra-newline-before-brace . nil)
+                (cperl-merge-trailing-else . t))))</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Python scripts:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We follow PEP-8 (<a href="http://www.python.org/dev/peps/pep-0008/" class="bare">http://www.python.org/dev/peps/pep-0008/</a>).</p>
+</li>
+<li>
+<p>As a minimum, we aim to be compatible with Python 2.6 and 2.7.</p>
+</li>
+<li>
+<p>Where required libraries do not restrict us to Python 2, we try to
+also be compatible with Python 3.1 and later.</p>
+</li>
+<li>
+<p>When you must differentiate between Unicode literals and byte string
+literals, it is OK to use the <em>b</em> prefix.  Even though the Python
+documentation for version 2.6 does not mention this prefix, it has
+been supported since version 2.6.0.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Error Messages</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Do not end error messages with a full stop.</p>
+</li>
+<li>
+<p>Do not capitalize ("unable to open %s", not "Unable to open %s")</p>
+</li>
+<li>
+<p>Say what the error is first ("cannot open %s", not "%s: cannot open")</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Externally Visible Names</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>For configuration variable names, follow the existing convention:</p>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>The section name indicates the affected subsystem.</p>
+</li>
+<li>
+<p>The subsection name, if any, indicates which of an unbounded set
+of things to set the value for.</p>
+</li>
+<li>
+<p>The variable name describes the effect of tweaking this knob.</p>
+<div class="literalblock">
+<div class="content">
+<pre>The section and variable names that consist of multiple words are
+formed by concatenating the words without punctuations (e.g. `-`),
+and are broken using bumpyCaps in documentation as a hint to the
+reader.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>When choosing the variable namespace, do not use variable name for
+specifying possibly unbounded set of things, most notably anything
+an end user can freely come up with (e.g. branch names).  Instead,
+use subsection names or variable values, like the existing variable
+branch.&lt;name&gt;.description does.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Writing Documentation:</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Most (if not all) of the documentation pages are written in the
+AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+processed into HTML and manpages (e.g. git.html and git.1 in the
+same directory).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>The documentation liberally mixes US and UK English (en_US/UK)
+norms for spelling and grammar, which is somewhat unfortunate.
+In an ideal world, it would have been better if it consistently
+used only one and not the other, and we would have picked en_US
+(if you wish to correct the English of some of the existing
+documentation, please see the documentation-related advice in the
+Documentation/SubmittingPatches file).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Every user-visible change should be reflected in the documentation.
+The same general rule as for code applies -- imitate the existing
+conventions.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying command usage strings and synopsis sections in the manual
+pages:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Placeholders are spelled in lowercase and enclosed in angle brackets:
+  &lt;file&gt;
+  --sort=&lt;key&gt;
+  --abbrev[=&lt;n&gt;]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If a placeholder has multiple words, they are separated by dashes:
+  &lt;new-branch-name&gt;
+  --template=&lt;template-directory&gt;</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Possibility of multiple occurrences is indicated by three dots:
+  &lt;file&gt;...
+  (One or more of &lt;file&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Optional parts are enclosed in square brackets:
+  [&lt;extra&gt;]
+  (Zero or one &lt;extra&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>--exec-path[=&lt;path&gt;]
+(Option with an optional argument.  Note that the "=" is inside the
+brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[&lt;patch&gt;...]
+(Zero or more of &lt;patch&gt;.  Note that the dots are inside, not
+outside the brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Multiple alternatives are indicated with vertical bars:
+  [-q | --quiet]
+  [--utf8 | --no-utf8]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Parentheses are used for grouping:
+  [(&lt;rev&gt; | &lt;range&gt;)...]
+  (Any number of either &lt;rev&gt; or &lt;range&gt;.  Parens are needed to make
+  it clear that "..." pertains to both &lt;rev&gt; and &lt;range&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[(-p &lt;parent&gt;)...]
+(Any number of option -p, each with one &lt;parent&gt; argument.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>git remote set-head &lt;name&gt; (-a | -d | &lt;branch&gt;)
+(One and only one of "-a", "-d" or "&lt;branch&gt;" _must_ (no square
+brackets) be provided.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>And a somewhat more contrived example:
+  --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+  Here "=" is outside the brackets, because "--diff-filter=" is a
+  valid usage.  "*" has its own pair of brackets, because it can
+  (optionally) be specified only when one or more of the letters is
+  also provided.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A note on notation:
+ Use 'git' (all lowercase) when talking about commands i.e. something
+ the user would type into a shell and use 'Git' (uppercase first letter)
+ when talking about the version control system and its properties.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying paragraphs or option/command explanations that contain options
+or commands:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Literal examples (e.g. use of command-line options, command names,
+branch names, URLs, pathnames (files and directories), configuration and
+environment variables) must be typeset in monospace (i.e. wrapped with
+backticks):
+  `--pretty=oneline`
+  `git rev-list`
+  `remote.pushDefault`
+  `http://git.example.com`
+  `.git/config`
+  `GIT_DIR`
+  `HEAD`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>An environment variable must be prefixed with "$" only when referring to its
+value and not when referring to the variable itself, in this case there is
+nothing to add except the backticks:
+  `GIT_DIR` is specified
+  `$GIT_DIR/hooks/pre-receive`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Word phrases enclosed in `backtick characters` are rendered literally
+and will not be further expanded. The use of `backticks` to achieve the
+previous rule means that literal examples should not use AsciiDoc
+escapes.
+  Correct:
+     `--pretty=oneline`
+  Incorrect:
+     `\--pretty=oneline`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If some place in the documentation needs to typeset a command usage
+example with inline substitutions, it is fine to use +monospaced and
+inline substituted text+ instead of `monospaced literal text`, and with
+the former, the part that should not get substituted must be
+quoted/escaped.</pre>
+</div>
+</div>
+</div>
+</div>
\ No newline at end of file
diff --git a/external/docs/content/docs/CodingGuidelines/2.22.1.html b/external/docs/content/docs/CodingGuidelines/2.22.1.html
new file mode 100644
index 0000000000..aa56188283
--- /dev/null
+++ b/external/docs/content/docs/CodingGuidelines/2.22.1.html
@@ -0,0 +1,1013 @@
+---
+### DO NOT EDIT! Generated by script/update-docs.rb
+
+category: manual
+section: documentation
+subsection: manual
+title: Git - CodingGuidelines Documentation
+docname: CodingGuidelines
+version: 2.22.1
+aliases:
+- "/docs/CodingGuidelines/2.22.1/index.html"
+- "/docs/CodingGuidelines/2.22.2/index.html"
+- "/docs/CodingGuidelines/2.22.3/index.html"
+- "/docs/CodingGuidelines/2.22.4/index.html"
+- "/docs/CodingGuidelines/2.22.5/index.html"
+- "/docs/CodingGuidelines/2.23.0/index.html"
+- "/docs/CodingGuidelines/2.23.1/index.html"
+- "/docs/CodingGuidelines/2.23.2/index.html"
+- "/docs/CodingGuidelines/2.23.3/index.html"
+- "/docs/CodingGuidelines/2.23.4/index.html"
+- "/docs/CodingGuidelines/2.24.0/index.html"
+- "/docs/CodingGuidelines/2.24.1/index.html"
+- "/docs/CodingGuidelines/2.24.2/index.html"
+- "/docs/CodingGuidelines/2.24.3/index.html"
+- "/docs/CodingGuidelines/2.24.4/index.html"
+---
+<div id="preamble">
+<div class="sectionbody">
+<div class="paragraph">
+<p>Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, a few rough rules are:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most importantly, we never say "It&#8217;s in POSIX; we&#8217;ll happily
+ignore your needs should your system not conform to it."
+We live in the real world.</p>
+</li>
+<li>
+<p>However, we often say "Let&#8217;s stay away from that construct,
+it&#8217;s not even in POSIX".</p>
+</li>
+<li>
+<p>In spite of the above two rules, we sometimes say "Although
+this is not in POSIX, it (is so convenient | makes the code
+much more readable | has other good characteristics) and
+practically all the platforms we care about support it, so
+let&#8217;s use it".</p>
+<div class="literalblock">
+<div class="content">
+<pre>Again, we live in the real world, and it is sometimes a
+judgement call, the decision based more on real world
+constraints people face than what the paper standard says.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Fixing style violations while working on a real change as a
+preparatory clean-up step is good, but otherwise avoid useless code
+churn for the sake of conforming to the style.</p>
+<div class="literalblock">
+<div class="content">
+<pre>"Once it _is_ in the tree, it's not really worth the patch noise to
+go and fix it up."
+Cf. http://lkml.iu.edu/hypermail/linux/kernel/1001.3/01069.html</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Make your code readable and sensible, and don&#8217;t try to be clever.</p>
+</div>
+<div class="paragraph">
+<p>As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the <em>local</em>
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn&#8217;t match the overall style of existing code).</p>
+</div>
+<div class="paragraph">
+<p>But if you must have a list of rules, here they are.</p>
+</div>
+<div class="paragraph">
+<p>For shell scripts specifically (not exhaustive):</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs for indentation.</p>
+</li>
+<li>
+<p>Case arms are indented at the same depth as case and esac lines,
+like this:</p>
+<div class="literalblock">
+<div class="content">
+<pre>case "$variable" in
+pattern1)
+	do this
+	;;
+pattern2)
+	do that
+	;;
+esac</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Redirection operators should be written with space before, but no
+space after them.  In other words, write <em>echo test &gt;"$file"</em>
+instead of <em>echo test&gt; $file</em> or <em>echo test &gt; $file</em>.  Note that
+even though it is not required by POSIX to double-quote the
+redirection target in a variable (as shown above), our code does so
+because some versions of bash issue a warning without the quotes.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+cat hello &gt; world &lt; universe
+echo hello &gt;$world</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+cat hello &gt;world &lt;universe
+echo hello &gt;"$world"</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer $( &#8230;&#8203; ) for command substitution; unlike ``, it
+properly nests.  It should have been the way Bourne spelled
+it from day one, but unfortunately isn&#8217;t.</p>
+</li>
+<li>
+<p>If you want to find out if a command is available on the user&#8217;s
+$PATH, you should use <em>type &lt;command&gt;</em>, instead of <em>which &lt;command&gt;</em>.
+The output of <em>which</em> is not machine parseable and its exit code
+is not reliable across platforms.</p>
+</li>
+<li>
+<p>We use POSIX compliant parameter substitutions and avoid bashisms;
+namely:</p>
+</li>
+<li>
+<p>We use ${parameter-word} and its [-=?+] siblings, and their
+colon&#8217;ed "unset or null" form.</p>
+</li>
+<li>
+<p>We use ${parameter#word} and its [#%] siblings, and their
+doubled "longest matching" form.</p>
+</li>
+<li>
+<p>No "Substring Expansion" ${parameter:offset:length}.</p>
+</li>
+<li>
+<p>No shell arrays.</p>
+</li>
+<li>
+<p>No strlen ${#parameter}.</p>
+</li>
+<li>
+<p>No pattern replacement ${parameter/pattern/string}.</p>
+</li>
+<li>
+<p>We use Arithmetic Expansion $&#8230;&#8203;.</p>
+</li>
+<li>
+<p>Inside Arithmetic Expansion, spell shell variables with $ in front
+of them, as some shells do not grok $x while accepting $$x
+just fine (e.g. dash older than 0.5.4).</p>
+</li>
+<li>
+<p>We do not use Process Substitution &lt;(list) or &gt;(list).</p>
+</li>
+<li>
+<p>Do not write control structures on a single line with semicolon.
+"then" should be on the next line for if statements, and "do"
+should be on the next line for "while" and "for".</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+if test -f hello; then
+	do this
+fi</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+if test -f hello
+then
+	do this
+fi</pre>
+</div>
+</div>
+</li>
+<li>
+<p>If a command sequence joined with &amp;&amp; or || or | spans multiple
+lines, put each command on a separate line and put &amp;&amp; and || and |
+operators at the end of each line, rather than the start. This
+means you don&#8217;t need to use \ to join lines, since the above
+operators imply the sequence isn&#8217;t finished.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+grep blob verify_pack_result \
+| awk -f print_1.awk \
+| sort &gt;actual &amp;&amp;
+...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+grep blob verify_pack_result |
+awk -f print_1.awk |
+sort &gt;actual &amp;&amp;
+...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer "test" over "[ &#8230;&#8203; ]".</p>
+</li>
+<li>
+<p>We do not write the noiseword "function" in front of shell
+functions.</p>
+</li>
+<li>
+<p>We prefer a space between the function name and the parentheses,
+and no space inside the parentheses. The opening "{" should also
+be on the same line.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+my_function(){
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+my_function () {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+[::], [==], or [..]) for portability.</p>
+</li>
+<li>
+<p>We do not use \{m,n\};</p>
+</li>
+<li>
+<p>We do not use -E;</p>
+</li>
+<li>
+<p>We do not use ? or + (which are \{0,1\} and \{1,\}
+respectively in BRE) but that goes without saying as these
+are ERE elements not BRE (note that \? and \+ are not even part
+of BRE&#8201;&#8212;&#8201;making them accessible from BRE is a GNU extension).</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers in git-sh-i18n to make the user
+interface translatable. See "Marking strings for translation" in
+po/README.</p>
+</li>
+<li>
+<p>We do not write our "test" command with "-a" and "-o" and use "&amp;&amp;"
+or "||" to concatenate multiple "test" commands instead, because
+the use of "-a/-o" is often error-prone.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" -a "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is buggy and breaks when $x is "=", but</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" &amp;&amp; test "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>does not have such a problem.</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For C programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs to indent, and interpret tabs as taking up to
+8 spaces.</p>
+</li>
+<li>
+<p>We try to keep to at most 80 characters per line.</p>
+</li>
+<li>
+<p>As a Git developer we assume you have a reasonably modern compiler
+and we recommend you to enable the DEVELOPER makefile knob to
+ensure your patch is clear of all compiler warnings we care about,
+by e.g. "echo DEVELOPER=1 &gt;&gt;config.mak".</p>
+</li>
+<li>
+<p>We try to support a wide range of C compilers to compile Git with,
+including old ones.  You should not use features from newer C
+standard, even if your compiler groks them.</p>
+<div class="literalblock">
+<div class="content">
+<pre>There are a few exceptions to this guideline:</pre>
+</div>
+</div>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>since early 2012 with e1327023ea, we have been using an enum
+definition whose last element is followed by a comma.  This, like
+an array initializer that ends with a trailing comma, can be used
+to reduce the patch noise when adding a new identifer at the end.</p>
+</li>
+<li>
+<p>since mid 2017 with cbc0f81d, we have been using designated
+initializers for struct (e.g. "struct t v = { .val = <em>a</em> };").</p>
+</li>
+<li>
+<p>since mid 2017 with 512f41cf, we have been using designated
+initializers for array (e.g. "int array[10] = { [5] = 2 }").</p>
+<div class="literalblock">
+<div class="content">
+<pre>These used to be forbidden, but we have not heard any breakage
+report, and they are assumed to be safe.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>Variables have to be declared at the beginning of the block, before
+the first statement (i.e. -Wdeclaration-after-statement).</p>
+</li>
+<li>
+<p>Declaring a variable in the for loop "for (int i = 0; i &lt; 10; i++)"
+is still not allowed in this codebase.</p>
+</li>
+<li>
+<p>NULL pointers shall be written as NULL, not as 0.</p>
+</li>
+<li>
+<p>When declaring pointers, the star sides with the variable
+name, i.e. "char <strong>string", not "char</strong> string" or
+"char * string".  This makes it easier to understand code
+like "char *string, c;".</p>
+</li>
+<li>
+<p>Use whitespace around operators and keywords, but not inside
+parentheses and not around functions. So:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      while (condition)
+func(bar + 1);</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>      while( condition )
+func (bar+1);</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We avoid using braces unnecessarily.  I.e.</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (bla) {
+	x = 1;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is frowned upon. But there are a few exceptions:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When the statement extends over a few lines (e.g., a while loop
+with an embedded conditional, or a comment). E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (foo) {
+	if (x)
+		one();
+	else
+		two();
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	/*
+	 * This one requires some explanation,
+	 * so we're better off with braces to make
+	 * it obvious that the indentation is correct.
+	 */
+	doit();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When there are multiple arms to a conditional and some of them
+require braces, enclose even a single line block in braces for
+consistency. E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	doit();
+} else {
+	one();
+	two();
+	three();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments in the condition of an "if" statement.</p>
+</li>
+<li>
+<p>Try to make your code understandable.  You may put comments
+in, but comments invariably tend to stale out when the code
+they were describing changes.  Often splitting a function
+into two makes the intention of the code much clearer.</p>
+</li>
+<li>
+<p>Multi-line comments include their delimiters on separate lines from
+the text.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * A very long
+ * multi-line comment.
+ */</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Note however that a comment that explains a translatable string to
+translators uses a convention of starting with a magic token
+"TRANSLATORS: ", e.g.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * TRANSLATORS: here is a comment that explains the string to
+ * be translated, that follows immediately after it.
+ */
+_("Here is a translatable string explained by the above.");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Double negation is often harder to understand than no negation
+at all.</p>
+</li>
+<li>
+<p>There are two schools of thought when it comes to comparison,
+especially inside a loop. Some people prefer to have the less stable
+value on the left hand side and the more stable value on the right hand
+side, e.g. if you have a loop that counts variable i down to the
+lower bound,</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (i &gt; lower_bound) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Other people prefer to have the textual order of values match the
+actual order of values in their comparison, so that they can
+mentally draw a number line from left to right and place these
+values in order, i.e.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while (lower_bound &lt; i) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  However, the more "stable" the
+stable side becomes, the more we tend to prefer the former
+(comparison with a constant, "i &gt; 0", is an extreme example).
+Just do not mix styles in the same part of the code and mimic
+existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>There are two schools of thought when it comes to splitting a long
+logical line into multiple lines.  Some people push the second and
+subsequent lines far enough to the right with tabs and align them:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+              ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to align the second and the subsequent
+lines with the column immediately inside the opening parenthesis,
+with tabs and spaces, following our "tabstop is always a multiple
+of 8" convention:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+           ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  Again, just do not mix styles in
+the same part of the code and mimic existing styles in the
+neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, some people change line before
+a binary operator, so that the result looks like a parse tree when
+you turn your head 90-degrees counterclockwise:</p>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to
+|| span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to leave the operator at the end of the
+line:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, but we tend to use the latter more, unless the
+expression gets fairly complex, in which case the former tends to
+be easier to read.  Again, just do not mix styles in the same part
+of the code and mimic existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, with everything else being
+equal, it is preferable to split after the operator at higher
+level in the parse tree.  That is, this is more preferable:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable * that_is_used_in +
+    a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>than</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable *
+    that_is_used_in + a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Some clever tricks, like using the !! operator with arithmetic
+constructs, can be extremely confusing to others.  Avoid them,
+unless there is a compelling reason to use them.</p>
+</li>
+<li>
+<p>Use the API.  No, really.  We have a strbuf (variable length
+string), several arrays with the ALLOC_GROW() macro, a
+string_list for sorted string lists, a hash map (mapping struct
+objects) named "struct decorate", amongst other things.</p>
+</li>
+<li>
+<p>When you come up with an API, document its functions and structures
+in the header file that exposes the API to its callers. Use what is
+in "strbuf.h" as a model for the appropriate tone and level of
+detail.</p>
+</li>
+<li>
+<p>The first #include in C files, except in platform specific compat/
+implementations, must be either "git-compat-util.h", "cache.h" or
+"builtin.h".  You do not have to include more than one of these.</p>
+</li>
+<li>
+<p>A C file must directly include the header files that declare the
+functions and the types it uses, except for the functions and types
+that are made available to it by including one of the header files
+it must include by the previous rule.</p>
+</li>
+<li>
+<p>If you are planning a new command, consider writing it in shell
+or perl first, so that changes in semantics can be easily
+changed and discussed.  Many Git commands started out like
+that, and a few are still scripts.</p>
+</li>
+<li>
+<p>Avoid introducing a new dependency into Git. This means you
+usually should stay away from scripting languages not already
+used in the Git core command set (unless your command is clearly
+separate from it, such as an importer to convert random-scm-X
+repositories to Git).</p>
+</li>
+<li>
+<p>When we pass &lt;string, length&gt; pair to functions, we should try to
+pass them in that order.</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers to make the user interface
+translatable. See "Marking strings for translation" in po/README.</p>
+</li>
+<li>
+<p>Variables and functions local to a given source file should be marked
+with "static". Variables that are visible to other source files
+must be declared with "extern" in header files. However, function
+declarations should not use "extern", as that is already the default.</p>
+</li>
+<li>
+<p>You can launch gdb around your program using the shorthand GIT_DEBUGGER.
+Run <code>GIT_DEBUGGER=1 ./bin-wrappers/git foo</code> to simply use gdb as is, or
+run <code>GIT_DEBUGGER="&lt;debugger&gt; &lt;debugger-args&gt;" ./bin-wrappers/git foo</code> to
+use your own debugger and arguments. Example: <code>GIT_DEBUGGER="ddd --gdb"
+./bin-wrappers/git log</code> (See <code>wrap-for-bin.sh</code>.)</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Perl programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most of the C guidelines above apply.</p>
+</li>
+<li>
+<p>We try to support Perl 5.8 and later ("use Perl 5.008").</p>
+</li>
+<li>
+<p>use strict and use warnings are strongly preferred.</p>
+</li>
+<li>
+<p>Don&#8217;t overuse statement modifiers unless using them makes the
+result easier to follow.</p>
+<div class="olist lowerroman">
+<ol class="lowerroman" type="i">
+<li>
+<p>do something &#8230;&#8203;
+do_this() unless (condition);</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>is more readable than:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>do something &#8230;&#8203;
+unless (condition) {
+	do_this();
+}</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>*only* when the condition is so rare that do_this() will be almost
+always called.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments inside "if ()" conditions.</p>
+</li>
+<li>
+<p>Learn and use Git.pm if you need that functionality.</p>
+</li>
+<li>
+<p>For Emacs, it&#8217;s useful to put the following in
+GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode:</p>
+<div class="literalblock">
+<div class="content">
+<pre>;; note the first part is useful for C editing, too
+((nil . ((indent-tabs-mode . t)
+              (tab-width . 8)
+              (fill-column . 80)))
+ (cperl-mode . ((cperl-indent-level . 8)
+                (cperl-extra-newline-before-brace . nil)
+                (cperl-merge-trailing-else . t))))</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Python scripts:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We follow PEP-8 (<a href="http://www.python.org/dev/peps/pep-0008/" class="bare">http://www.python.org/dev/peps/pep-0008/</a>).</p>
+</li>
+<li>
+<p>As a minimum, we aim to be compatible with Python 2.6 and 2.7.</p>
+</li>
+<li>
+<p>Where required libraries do not restrict us to Python 2, we try to
+also be compatible with Python 3.1 and later.</p>
+</li>
+<li>
+<p>When you must differentiate between Unicode literals and byte string
+literals, it is OK to use the <em>b</em> prefix.  Even though the Python
+documentation for version 2.6 does not mention this prefix, it has
+been supported since version 2.6.0.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Error Messages</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Do not end error messages with a full stop.</p>
+</li>
+<li>
+<p>Do not capitalize ("unable to open %s", not "Unable to open %s")</p>
+</li>
+<li>
+<p>Say what the error is first ("cannot open %s", not "%s: cannot open")</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Externally Visible Names</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>For configuration variable names, follow the existing convention:</p>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>The section name indicates the affected subsystem.</p>
+</li>
+<li>
+<p>The subsection name, if any, indicates which of an unbounded set
+of things to set the value for.</p>
+</li>
+<li>
+<p>The variable name describes the effect of tweaking this knob.</p>
+<div class="literalblock">
+<div class="content">
+<pre>The section and variable names that consist of multiple words are
+formed by concatenating the words without punctuations (e.g. `-`),
+and are broken using bumpyCaps in documentation as a hint to the
+reader.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>When choosing the variable namespace, do not use variable name for
+specifying possibly unbounded set of things, most notably anything
+an end user can freely come up with (e.g. branch names).  Instead,
+use subsection names or variable values, like the existing variable
+branch.&lt;name&gt;.description does.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Writing Documentation:</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Most (if not all) of the documentation pages are written in the
+AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+processed into HTML and manpages (e.g. git.html and git.1 in the
+same directory).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>The documentation liberally mixes US and UK English (en_US/UK)
+norms for spelling and grammar, which is somewhat unfortunate.
+In an ideal world, it would have been better if it consistently
+used only one and not the other, and we would have picked en_US
+(if you wish to correct the English of some of the existing
+documentation, please see the documentation-related advice in the
+Documentation/SubmittingPatches file).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Every user-visible change should be reflected in the documentation.
+The same general rule as for code applies -- imitate the existing
+conventions.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying command usage strings and synopsis sections in the manual
+pages:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Placeholders are spelled in lowercase and enclosed in angle brackets:
+  &lt;file&gt;
+  --sort=&lt;key&gt;
+  --abbrev[=&lt;n&gt;]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If a placeholder has multiple words, they are separated by dashes:
+  &lt;new-branch-name&gt;
+  --template=&lt;template-directory&gt;</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Possibility of multiple occurrences is indicated by three dots:
+  &lt;file&gt;...
+  (One or more of &lt;file&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Optional parts are enclosed in square brackets:
+  [&lt;extra&gt;]
+  (Zero or one &lt;extra&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>--exec-path[=&lt;path&gt;]
+(Option with an optional argument.  Note that the "=" is inside the
+brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[&lt;patch&gt;...]
+(Zero or more of &lt;patch&gt;.  Note that the dots are inside, not
+outside the brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Multiple alternatives are indicated with vertical bars:
+  [-q | --quiet]
+  [--utf8 | --no-utf8]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Parentheses are used for grouping:
+  [(&lt;rev&gt; | &lt;range&gt;)...]
+  (Any number of either &lt;rev&gt; or &lt;range&gt;.  Parens are needed to make
+  it clear that "..." pertains to both &lt;rev&gt; and &lt;range&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[(-p &lt;parent&gt;)...]
+(Any number of option -p, each with one &lt;parent&gt; argument.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>git remote set-head &lt;name&gt; (-a | -d | &lt;branch&gt;)
+(One and only one of "-a", "-d" or "&lt;branch&gt;" _must_ (no square
+brackets) be provided.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>And a somewhat more contrived example:
+  --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+  Here "=" is outside the brackets, because "--diff-filter=" is a
+  valid usage.  "*" has its own pair of brackets, because it can
+  (optionally) be specified only when one or more of the letters is
+  also provided.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A note on notation:
+ Use 'git' (all lowercase) when talking about commands i.e. something
+ the user would type into a shell and use 'Git' (uppercase first letter)
+ when talking about the version control system and its properties.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying paragraphs or option/command explanations that contain options
+or commands:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Literal examples (e.g. use of command-line options, command names,
+branch names, URLs, pathnames (files and directories), configuration and
+environment variables) must be typeset in monospace (i.e. wrapped with
+backticks):
+  `--pretty=oneline`
+  `git rev-list`
+  `remote.pushDefault`
+  `http://git.example.com`
+  `.git/config`
+  `GIT_DIR`
+  `HEAD`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>An environment variable must be prefixed with "$" only when referring to its
+value and not when referring to the variable itself, in this case there is
+nothing to add except the backticks:
+  `GIT_DIR` is specified
+  `$GIT_DIR/hooks/pre-receive`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Word phrases enclosed in `backtick characters` are rendered literally
+and will not be further expanded. The use of `backticks` to achieve the
+previous rule means that literal examples should not use AsciiDoc
+escapes.
+  Correct:
+     `--pretty=oneline`
+  Incorrect:
+     `\--pretty=oneline`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If some place in the documentation needs to typeset a command usage
+example with inline substitutions, it is fine to use +monospaced and
+inline substituted text+ instead of `monospaced literal text`, and with
+the former, the part that should not get substituted must be
+quoted/escaped.</pre>
+</div>
+</div>
+</div>
+</div>
\ No newline at end of file
diff --git a/external/docs/content/docs/CodingGuidelines/2.25.0.html b/external/docs/content/docs/CodingGuidelines/2.25.0.html
new file mode 100644
index 0000000000..59fa47efee
--- /dev/null
+++ b/external/docs/content/docs/CodingGuidelines/2.25.0.html
@@ -0,0 +1,1008 @@
+---
+### DO NOT EDIT! Generated by script/update-docs.rb
+
+category: manual
+section: documentation
+subsection: manual
+title: Git - CodingGuidelines Documentation
+docname: CodingGuidelines
+version: 2.25.0
+aliases:
+- "/docs/CodingGuidelines/2.25.0/index.html"
+- "/docs/CodingGuidelines/2.25.1/index.html"
+- "/docs/CodingGuidelines/2.25.2/index.html"
+- "/docs/CodingGuidelines/2.25.3/index.html"
+- "/docs/CodingGuidelines/2.25.4/index.html"
+- "/docs/CodingGuidelines/2.25.5/index.html"
+- "/docs/CodingGuidelines/2.26.0/index.html"
+- "/docs/CodingGuidelines/2.26.1/index.html"
+- "/docs/CodingGuidelines/2.26.2/index.html"
+- "/docs/CodingGuidelines/2.26.3/index.html"
+---
+<div id="preamble">
+<div class="sectionbody">
+<div class="paragraph">
+<p>Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, a few rough rules are:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most importantly, we never say "It&#8217;s in POSIX; we&#8217;ll happily
+ignore your needs should your system not conform to it."
+We live in the real world.</p>
+</li>
+<li>
+<p>However, we often say "Let&#8217;s stay away from that construct,
+it&#8217;s not even in POSIX".</p>
+</li>
+<li>
+<p>In spite of the above two rules, we sometimes say "Although
+this is not in POSIX, it (is so convenient | makes the code
+much more readable | has other good characteristics) and
+practically all the platforms we care about support it, so
+let&#8217;s use it".</p>
+<div class="literalblock">
+<div class="content">
+<pre>Again, we live in the real world, and it is sometimes a
+judgement call, the decision based more on real world
+constraints people face than what the paper standard says.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Fixing style violations while working on a real change as a
+preparatory clean-up step is good, but otherwise avoid useless code
+churn for the sake of conforming to the style.</p>
+<div class="literalblock">
+<div class="content">
+<pre>"Once it _is_ in the tree, it's not really worth the patch noise to
+go and fix it up."
+Cf. http://lkml.iu.edu/hypermail/linux/kernel/1001.3/01069.html</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Make your code readable and sensible, and don&#8217;t try to be clever.</p>
+</div>
+<div class="paragraph">
+<p>As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the <em>local</em>
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn&#8217;t match the overall style of existing code).</p>
+</div>
+<div class="paragraph">
+<p>But if you must have a list of rules, here they are.</p>
+</div>
+<div class="paragraph">
+<p>For shell scripts specifically (not exhaustive):</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs for indentation.</p>
+</li>
+<li>
+<p>Case arms are indented at the same depth as case and esac lines,
+like this:</p>
+<div class="literalblock">
+<div class="content">
+<pre>case "$variable" in
+pattern1)
+	do this
+	;;
+pattern2)
+	do that
+	;;
+esac</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Redirection operators should be written with space before, but no
+space after them.  In other words, write <em>echo test &gt;"$file"</em>
+instead of <em>echo test&gt; $file</em> or <em>echo test &gt; $file</em>.  Note that
+even though it is not required by POSIX to double-quote the
+redirection target in a variable (as shown above), our code does so
+because some versions of bash issue a warning without the quotes.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+cat hello &gt; world &lt; universe
+echo hello &gt;$world</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+cat hello &gt;world &lt;universe
+echo hello &gt;"$world"</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer $( &#8230;&#8203; ) for command substitution; unlike ``, it
+properly nests.  It should have been the way Bourne spelled
+it from day one, but unfortunately isn&#8217;t.</p>
+</li>
+<li>
+<p>If you want to find out if a command is available on the user&#8217;s
+$PATH, you should use <em>type &lt;command&gt;</em>, instead of <em>which &lt;command&gt;</em>.
+The output of <em>which</em> is not machine parsable and its exit code
+is not reliable across platforms.</p>
+</li>
+<li>
+<p>We use POSIX compliant parameter substitutions and avoid bashisms;
+namely:</p>
+</li>
+<li>
+<p>We use ${parameter-word} and its [-=?+] siblings, and their
+colon&#8217;ed "unset or null" form.</p>
+</li>
+<li>
+<p>We use ${parameter#word} and its [#%] siblings, and their
+doubled "longest matching" form.</p>
+</li>
+<li>
+<p>No "Substring Expansion" ${parameter:offset:length}.</p>
+</li>
+<li>
+<p>No shell arrays.</p>
+</li>
+<li>
+<p>No strlen ${#parameter}.</p>
+</li>
+<li>
+<p>No pattern replacement ${parameter/pattern/string}.</p>
+</li>
+<li>
+<p>We use Arithmetic Expansion $&#8230;&#8203;.</p>
+</li>
+<li>
+<p>Inside Arithmetic Expansion, spell shell variables with $ in front
+of them, as some shells do not grok $x while accepting $$x
+just fine (e.g. dash older than 0.5.4).</p>
+</li>
+<li>
+<p>We do not use Process Substitution &lt;(list) or &gt;(list).</p>
+</li>
+<li>
+<p>Do not write control structures on a single line with semicolon.
+"then" should be on the next line for if statements, and "do"
+should be on the next line for "while" and "for".</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+if test -f hello; then
+	do this
+fi</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+if test -f hello
+then
+	do this
+fi</pre>
+</div>
+</div>
+</li>
+<li>
+<p>If a command sequence joined with &amp;&amp; or || or | spans multiple
+lines, put each command on a separate line and put &amp;&amp; and || and |
+operators at the end of each line, rather than the start. This
+means you don&#8217;t need to use \ to join lines, since the above
+operators imply the sequence isn&#8217;t finished.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+grep blob verify_pack_result \
+| awk -f print_1.awk \
+| sort &gt;actual &amp;&amp;
+...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+grep blob verify_pack_result |
+awk -f print_1.awk |
+sort &gt;actual &amp;&amp;
+...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer "test" over "[ &#8230;&#8203; ]".</p>
+</li>
+<li>
+<p>We do not write the noiseword "function" in front of shell
+functions.</p>
+</li>
+<li>
+<p>We prefer a space between the function name and the parentheses,
+and no space inside the parentheses. The opening "{" should also
+be on the same line.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+my_function(){
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+my_function () {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+[::], [==], or [..]) for portability.</p>
+</li>
+<li>
+<p>We do not use \{m,n\};</p>
+</li>
+<li>
+<p>We do not use -E;</p>
+</li>
+<li>
+<p>We do not use ? or + (which are \{0,1\} and \{1,\}
+respectively in BRE) but that goes without saying as these
+are ERE elements not BRE (note that \? and \+ are not even part
+of BRE&#8201;&#8212;&#8201;making them accessible from BRE is a GNU extension).</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers in git-sh-i18n to make the user
+interface translatable. See "Marking strings for translation" in
+po/README.</p>
+</li>
+<li>
+<p>We do not write our "test" command with "-a" and "-o" and use "&amp;&amp;"
+or "||" to concatenate multiple "test" commands instead, because
+the use of "-a/-o" is often error-prone.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" -a "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is buggy and breaks when $x is "=", but</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" &amp;&amp; test "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>does not have such a problem.</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For C programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs to indent, and interpret tabs as taking up to
+8 spaces.</p>
+</li>
+<li>
+<p>We try to keep to at most 80 characters per line.</p>
+</li>
+<li>
+<p>As a Git developer we assume you have a reasonably modern compiler
+and we recommend you to enable the DEVELOPER makefile knob to
+ensure your patch is clear of all compiler warnings we care about,
+by e.g. "echo DEVELOPER=1 &gt;&gt;config.mak".</p>
+</li>
+<li>
+<p>We try to support a wide range of C compilers to compile Git with,
+including old ones.  You should not use features from newer C
+standard, even if your compiler groks them.</p>
+<div class="literalblock">
+<div class="content">
+<pre>There are a few exceptions to this guideline:</pre>
+</div>
+</div>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>since early 2012 with e1327023ea, we have been using an enum
+definition whose last element is followed by a comma.  This, like
+an array initializer that ends with a trailing comma, can be used
+to reduce the patch noise when adding a new identifier at the end.</p>
+</li>
+<li>
+<p>since mid 2017 with cbc0f81d, we have been using designated
+initializers for struct (e.g. "struct t v = { .val = <em>a</em> };").</p>
+</li>
+<li>
+<p>since mid 2017 with 512f41cf, we have been using designated
+initializers for array (e.g. "int array[10] = { [5] = 2 }").</p>
+<div class="literalblock">
+<div class="content">
+<pre>These used to be forbidden, but we have not heard any breakage
+report, and they are assumed to be safe.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>Variables have to be declared at the beginning of the block, before
+the first statement (i.e. -Wdeclaration-after-statement).</p>
+</li>
+<li>
+<p>Declaring a variable in the for loop "for (int i = 0; i &lt; 10; i++)"
+is still not allowed in this codebase.</p>
+</li>
+<li>
+<p>NULL pointers shall be written as NULL, not as 0.</p>
+</li>
+<li>
+<p>When declaring pointers, the star sides with the variable
+name, i.e. "char <strong>string", not "char</strong> string" or
+"char * string".  This makes it easier to understand code
+like "char *string, c;".</p>
+</li>
+<li>
+<p>Use whitespace around operators and keywords, but not inside
+parentheses and not around functions. So:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      while (condition)
+func(bar + 1);</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>      while( condition )
+func (bar+1);</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We avoid using braces unnecessarily.  I.e.</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (bla) {
+	x = 1;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is frowned upon. But there are a few exceptions:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When the statement extends over a few lines (e.g., a while loop
+with an embedded conditional, or a comment). E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (foo) {
+	if (x)
+		one();
+	else
+		two();
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	/*
+	 * This one requires some explanation,
+	 * so we're better off with braces to make
+	 * it obvious that the indentation is correct.
+	 */
+	doit();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When there are multiple arms to a conditional and some of them
+require braces, enclose even a single line block in braces for
+consistency. E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	doit();
+} else {
+	one();
+	two();
+	three();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments in the condition of an "if" statement.</p>
+</li>
+<li>
+<p>Try to make your code understandable.  You may put comments
+in, but comments invariably tend to stale out when the code
+they were describing changes.  Often splitting a function
+into two makes the intention of the code much clearer.</p>
+</li>
+<li>
+<p>Multi-line comments include their delimiters on separate lines from
+the text.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * A very long
+ * multi-line comment.
+ */</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Note however that a comment that explains a translatable string to
+translators uses a convention of starting with a magic token
+"TRANSLATORS: ", e.g.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * TRANSLATORS: here is a comment that explains the string to
+ * be translated, that follows immediately after it.
+ */
+_("Here is a translatable string explained by the above.");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Double negation is often harder to understand than no negation
+at all.</p>
+</li>
+<li>
+<p>There are two schools of thought when it comes to comparison,
+especially inside a loop. Some people prefer to have the less stable
+value on the left hand side and the more stable value on the right hand
+side, e.g. if you have a loop that counts variable i down to the
+lower bound,</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (i &gt; lower_bound) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Other people prefer to have the textual order of values match the
+actual order of values in their comparison, so that they can
+mentally draw a number line from left to right and place these
+values in order, i.e.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while (lower_bound &lt; i) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  However, the more "stable" the
+stable side becomes, the more we tend to prefer the former
+(comparison with a constant, "i &gt; 0", is an extreme example).
+Just do not mix styles in the same part of the code and mimic
+existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>There are two schools of thought when it comes to splitting a long
+logical line into multiple lines.  Some people push the second and
+subsequent lines far enough to the right with tabs and align them:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+              ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to align the second and the subsequent
+lines with the column immediately inside the opening parenthesis,
+with tabs and spaces, following our "tabstop is always a multiple
+of 8" convention:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+           ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  Again, just do not mix styles in
+the same part of the code and mimic existing styles in the
+neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, some people change line before
+a binary operator, so that the result looks like a parse tree when
+you turn your head 90-degrees counterclockwise:</p>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to
+|| span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to leave the operator at the end of the
+line:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, but we tend to use the latter more, unless the
+expression gets fairly complex, in which case the former tends to
+be easier to read.  Again, just do not mix styles in the same part
+of the code and mimic existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, with everything else being
+equal, it is preferable to split after the operator at higher
+level in the parse tree.  That is, this is more preferable:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable * that_is_used_in +
+    a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>than</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable *
+    that_is_used_in + a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Some clever tricks, like using the !! operator with arithmetic
+constructs, can be extremely confusing to others.  Avoid them,
+unless there is a compelling reason to use them.</p>
+</li>
+<li>
+<p>Use the API.  No, really.  We have a strbuf (variable length
+string), several arrays with the ALLOC_GROW() macro, a
+string_list for sorted string lists, a hash map (mapping struct
+objects) named "struct decorate", amongst other things.</p>
+</li>
+<li>
+<p>When you come up with an API, document its functions and structures
+in the header file that exposes the API to its callers. Use what is
+in "strbuf.h" as a model for the appropriate tone and level of
+detail.</p>
+</li>
+<li>
+<p>The first #include in C files, except in platform specific compat/
+implementations, must be either "git-compat-util.h", "cache.h" or
+"builtin.h".  You do not have to include more than one of these.</p>
+</li>
+<li>
+<p>A C file must directly include the header files that declare the
+functions and the types it uses, except for the functions and types
+that are made available to it by including one of the header files
+it must include by the previous rule.</p>
+</li>
+<li>
+<p>If you are planning a new command, consider writing it in shell
+or perl first, so that changes in semantics can be easily
+changed and discussed.  Many Git commands started out like
+that, and a few are still scripts.</p>
+</li>
+<li>
+<p>Avoid introducing a new dependency into Git. This means you
+usually should stay away from scripting languages not already
+used in the Git core command set (unless your command is clearly
+separate from it, such as an importer to convert random-scm-X
+repositories to Git).</p>
+</li>
+<li>
+<p>When we pass &lt;string, length&gt; pair to functions, we should try to
+pass them in that order.</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers to make the user interface
+translatable. See "Marking strings for translation" in po/README.</p>
+</li>
+<li>
+<p>Variables and functions local to a given source file should be marked
+with "static". Variables that are visible to other source files
+must be declared with "extern" in header files. However, function
+declarations should not use "extern", as that is already the default.</p>
+</li>
+<li>
+<p>You can launch gdb around your program using the shorthand GIT_DEBUGGER.
+Run <code>GIT_DEBUGGER=1 ./bin-wrappers/git foo</code> to simply use gdb as is, or
+run <code>GIT_DEBUGGER="&lt;debugger&gt; &lt;debugger-args&gt;" ./bin-wrappers/git foo</code> to
+use your own debugger and arguments. Example: <code>GIT_DEBUGGER="ddd --gdb"
+./bin-wrappers/git log</code> (See <code>wrap-for-bin.sh</code>.)</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Perl programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most of the C guidelines above apply.</p>
+</li>
+<li>
+<p>We try to support Perl 5.8 and later ("use Perl 5.008").</p>
+</li>
+<li>
+<p>use strict and use warnings are strongly preferred.</p>
+</li>
+<li>
+<p>Don&#8217;t overuse statement modifiers unless using them makes the
+result easier to follow.</p>
+<div class="olist lowerroman">
+<ol class="lowerroman" type="i">
+<li>
+<p>do something &#8230;&#8203;
+do_this() unless (condition);</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>is more readable than:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>do something &#8230;&#8203;
+unless (condition) {
+	do_this();
+}</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>*only* when the condition is so rare that do_this() will be almost
+always called.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments inside "if ()" conditions.</p>
+</li>
+<li>
+<p>Learn and use Git.pm if you need that functionality.</p>
+</li>
+<li>
+<p>For Emacs, it&#8217;s useful to put the following in
+GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode:</p>
+<div class="literalblock">
+<div class="content">
+<pre>;; note the first part is useful for C editing, too
+((nil . ((indent-tabs-mode . t)
+              (tab-width . 8)
+              (fill-column . 80)))
+ (cperl-mode . ((cperl-indent-level . 8)
+                (cperl-extra-newline-before-brace . nil)
+                (cperl-merge-trailing-else . t))))</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Python scripts:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We follow PEP-8 (<a href="http://www.python.org/dev/peps/pep-0008/" class="bare">http://www.python.org/dev/peps/pep-0008/</a>).</p>
+</li>
+<li>
+<p>As a minimum, we aim to be compatible with Python 2.6 and 2.7.</p>
+</li>
+<li>
+<p>Where required libraries do not restrict us to Python 2, we try to
+also be compatible with Python 3.1 and later.</p>
+</li>
+<li>
+<p>When you must differentiate between Unicode literals and byte string
+literals, it is OK to use the <em>b</em> prefix.  Even though the Python
+documentation for version 2.6 does not mention this prefix, it has
+been supported since version 2.6.0.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Error Messages</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Do not end error messages with a full stop.</p>
+</li>
+<li>
+<p>Do not capitalize ("unable to open %s", not "Unable to open %s")</p>
+</li>
+<li>
+<p>Say what the error is first ("cannot open %s", not "%s: cannot open")</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Externally Visible Names</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>For configuration variable names, follow the existing convention:</p>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>The section name indicates the affected subsystem.</p>
+</li>
+<li>
+<p>The subsection name, if any, indicates which of an unbounded set
+of things to set the value for.</p>
+</li>
+<li>
+<p>The variable name describes the effect of tweaking this knob.</p>
+<div class="literalblock">
+<div class="content">
+<pre>The section and variable names that consist of multiple words are
+formed by concatenating the words without punctuations (e.g. `-`),
+and are broken using bumpyCaps in documentation as a hint to the
+reader.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>When choosing the variable namespace, do not use variable name for
+specifying possibly unbounded set of things, most notably anything
+an end user can freely come up with (e.g. branch names).  Instead,
+use subsection names or variable values, like the existing variable
+branch.&lt;name&gt;.description does.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Writing Documentation:</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Most (if not all) of the documentation pages are written in the
+AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+processed into HTML and manpages (e.g. git.html and git.1 in the
+same directory).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>The documentation liberally mixes US and UK English (en_US/UK)
+norms for spelling and grammar, which is somewhat unfortunate.
+In an ideal world, it would have been better if it consistently
+used only one and not the other, and we would have picked en_US
+(if you wish to correct the English of some of the existing
+documentation, please see the documentation-related advice in the
+Documentation/SubmittingPatches file).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Every user-visible change should be reflected in the documentation.
+The same general rule as for code applies -- imitate the existing
+conventions.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying command usage strings and synopsis sections in the manual
+pages:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Placeholders are spelled in lowercase and enclosed in angle brackets:
+  &lt;file&gt;
+  --sort=&lt;key&gt;
+  --abbrev[=&lt;n&gt;]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If a placeholder has multiple words, they are separated by dashes:
+  &lt;new-branch-name&gt;
+  --template=&lt;template-directory&gt;</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Possibility of multiple occurrences is indicated by three dots:
+  &lt;file&gt;...
+  (One or more of &lt;file&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Optional parts are enclosed in square brackets:
+  [&lt;extra&gt;]
+  (Zero or one &lt;extra&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>--exec-path[=&lt;path&gt;]
+(Option with an optional argument.  Note that the "=" is inside the
+brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[&lt;patch&gt;...]
+(Zero or more of &lt;patch&gt;.  Note that the dots are inside, not
+outside the brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Multiple alternatives are indicated with vertical bars:
+  [-q | --quiet]
+  [--utf8 | --no-utf8]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Parentheses are used for grouping:
+  [(&lt;rev&gt; | &lt;range&gt;)...]
+  (Any number of either &lt;rev&gt; or &lt;range&gt;.  Parens are needed to make
+  it clear that "..." pertains to both &lt;rev&gt; and &lt;range&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[(-p &lt;parent&gt;)...]
+(Any number of option -p, each with one &lt;parent&gt; argument.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>git remote set-head &lt;name&gt; (-a | -d | &lt;branch&gt;)
+(One and only one of "-a", "-d" or "&lt;branch&gt;" _must_ (no square
+brackets) be provided.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>And a somewhat more contrived example:
+  --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+  Here "=" is outside the brackets, because "--diff-filter=" is a
+  valid usage.  "*" has its own pair of brackets, because it can
+  (optionally) be specified only when one or more of the letters is
+  also provided.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A note on notation:
+ Use 'git' (all lowercase) when talking about commands i.e. something
+ the user would type into a shell and use 'Git' (uppercase first letter)
+ when talking about the version control system and its properties.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying paragraphs or option/command explanations that contain options
+or commands:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Literal examples (e.g. use of command-line options, command names,
+branch names, URLs, pathnames (files and directories), configuration and
+environment variables) must be typeset in monospace (i.e. wrapped with
+backticks):
+  `--pretty=oneline`
+  `git rev-list`
+  `remote.pushDefault`
+  `http://git.example.com`
+  `.git/config`
+  `GIT_DIR`
+  `HEAD`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>An environment variable must be prefixed with "$" only when referring to its
+value and not when referring to the variable itself, in this case there is
+nothing to add except the backticks:
+  `GIT_DIR` is specified
+  `$GIT_DIR/hooks/pre-receive`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Word phrases enclosed in `backtick characters` are rendered literally
+and will not be further expanded. The use of `backticks` to achieve the
+previous rule means that literal examples should not use AsciiDoc
+escapes.
+  Correct:
+     `--pretty=oneline`
+  Incorrect:
+     `\--pretty=oneline`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If some place in the documentation needs to typeset a command usage
+example with inline substitutions, it is fine to use +monospaced and
+inline substituted text+ instead of `monospaced literal text`, and with
+the former, the part that should not get substituted must be
+quoted/escaped.</pre>
+</div>
+</div>
+</div>
+</div>
\ No newline at end of file
diff --git a/external/docs/content/docs/CodingGuidelines/2.27.0.html b/external/docs/content/docs/CodingGuidelines/2.27.0.html
new file mode 100644
index 0000000000..0db4b07a05
--- /dev/null
+++ b/external/docs/content/docs/CodingGuidelines/2.27.0.html
@@ -0,0 +1,1014 @@
+---
+### DO NOT EDIT! Generated by script/update-docs.rb
+
+category: manual
+section: documentation
+subsection: manual
+title: Git - CodingGuidelines Documentation
+docname: CodingGuidelines
+version: 2.27.0
+aliases:
+- "/docs/CodingGuidelines/2.27.0/index.html"
+- "/docs/CodingGuidelines/2.27.1/index.html"
+---
+<div id="preamble">
+<div class="sectionbody">
+<div class="paragraph">
+<p>Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, a few rough rules are:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most importantly, we never say "It&#8217;s in POSIX; we&#8217;ll happily
+ignore your needs should your system not conform to it."
+We live in the real world.</p>
+</li>
+<li>
+<p>However, we often say "Let&#8217;s stay away from that construct,
+it&#8217;s not even in POSIX".</p>
+</li>
+<li>
+<p>In spite of the above two rules, we sometimes say "Although
+this is not in POSIX, it (is so convenient | makes the code
+much more readable | has other good characteristics) and
+practically all the platforms we care about support it, so
+let&#8217;s use it".</p>
+<div class="literalblock">
+<div class="content">
+<pre>Again, we live in the real world, and it is sometimes a
+judgement call, the decision based more on real world
+constraints people face than what the paper standard says.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Fixing style violations while working on a real change as a
+preparatory clean-up step is good, but otherwise avoid useless code
+churn for the sake of conforming to the style.</p>
+<div class="literalblock">
+<div class="content">
+<pre>"Once it _is_ in the tree, it's not really worth the patch noise to
+go and fix it up."
+Cf. http://lkml.iu.edu/hypermail/linux/kernel/1001.3/01069.html</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Make your code readable and sensible, and don&#8217;t try to be clever.</p>
+</div>
+<div class="paragraph">
+<p>As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the <em>local</em>
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn&#8217;t match the overall style of existing code).</p>
+</div>
+<div class="paragraph">
+<p>But if you must have a list of rules, here they are.</p>
+</div>
+<div class="paragraph">
+<p>For shell scripts specifically (not exhaustive):</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs for indentation.</p>
+</li>
+<li>
+<p>Case arms are indented at the same depth as case and esac lines,
+like this:</p>
+<div class="literalblock">
+<div class="content">
+<pre>case "$variable" in
+pattern1)
+	do this
+	;;
+pattern2)
+	do that
+	;;
+esac</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Redirection operators should be written with space before, but no
+space after them.  In other words, write <em>echo test &gt;"$file"</em>
+instead of <em>echo test&gt; $file</em> or <em>echo test &gt; $file</em>.  Note that
+even though it is not required by POSIX to double-quote the
+redirection target in a variable (as shown above), our code does so
+because some versions of bash issue a warning without the quotes.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+cat hello &gt; world &lt; universe
+echo hello &gt;$world</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+cat hello &gt;world &lt;universe
+echo hello &gt;"$world"</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer $( &#8230;&#8203; ) for command substitution; unlike ``, it
+properly nests.  It should have been the way Bourne spelled
+it from day one, but unfortunately isn&#8217;t.</p>
+</li>
+<li>
+<p>If you want to find out if a command is available on the user&#8217;s
+$PATH, you should use <em>type &lt;command&gt;</em>, instead of <em>which &lt;command&gt;</em>.
+The output of <em>which</em> is not machine parsable and its exit code
+is not reliable across platforms.</p>
+</li>
+<li>
+<p>We use POSIX compliant parameter substitutions and avoid bashisms;
+namely:</p>
+</li>
+<li>
+<p>We use ${parameter-word} and its [-=?+] siblings, and their
+colon&#8217;ed "unset or null" form.</p>
+</li>
+<li>
+<p>We use ${parameter#word} and its [#%] siblings, and their
+doubled "longest matching" form.</p>
+</li>
+<li>
+<p>No "Substring Expansion" ${parameter:offset:length}.</p>
+</li>
+<li>
+<p>No shell arrays.</p>
+</li>
+<li>
+<p>No pattern replacement ${parameter/pattern/string}.</p>
+</li>
+<li>
+<p>We use Arithmetic Expansion $&#8230;&#8203;.</p>
+</li>
+<li>
+<p>We do not use Process Substitution &lt;(list) or &gt;(list).</p>
+</li>
+<li>
+<p>Do not write control structures on a single line with semicolon.
+"then" should be on the next line for if statements, and "do"
+should be on the next line for "while" and "for".</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+if test -f hello; then
+	do this
+fi</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+if test -f hello
+then
+	do this
+fi</pre>
+</div>
+</div>
+</li>
+<li>
+<p>If a command sequence joined with &amp;&amp; or || or | spans multiple
+lines, put each command on a separate line and put &amp;&amp; and || and |
+operators at the end of each line, rather than the start. This
+means you don&#8217;t need to use \ to join lines, since the above
+operators imply the sequence isn&#8217;t finished.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+grep blob verify_pack_result \
+| awk -f print_1.awk \
+| sort &gt;actual &amp;&amp;
+...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+grep blob verify_pack_result |
+awk -f print_1.awk |
+sort &gt;actual &amp;&amp;
+...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer "test" over "[ &#8230;&#8203; ]".</p>
+</li>
+<li>
+<p>We do not write the noiseword "function" in front of shell
+functions.</p>
+</li>
+<li>
+<p>We prefer a space between the function name and the parentheses,
+and no space inside the parentheses. The opening "{" should also
+be on the same line.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+my_function(){
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+my_function () {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+[::], [==], or [..]) for portability.</p>
+</li>
+<li>
+<p>We do not use \{m,n\};</p>
+</li>
+<li>
+<p>We do not use -E;</p>
+</li>
+<li>
+<p>We do not use ? or + (which are \{0,1\} and \{1,\}
+respectively in BRE) but that goes without saying as these
+are ERE elements not BRE (note that \? and \+ are not even part
+of BRE&#8201;&#8212;&#8201;making them accessible from BRE is a GNU extension).</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers in git-sh-i18n to make the user
+interface translatable. See "Marking strings for translation" in
+po/README.</p>
+</li>
+<li>
+<p>We do not write our "test" command with "-a" and "-o" and use "&amp;&amp;"
+or "||" to concatenate multiple "test" commands instead, because
+the use of "-a/-o" is often error-prone.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" -a "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is buggy and breaks when $x is "=", but</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" &amp;&amp; test "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>does not have such a problem.</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For C programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs to indent, and interpret tabs as taking up to
+8 spaces.</p>
+</li>
+<li>
+<p>We try to keep to at most 80 characters per line.</p>
+</li>
+<li>
+<p>As a Git developer we assume you have a reasonably modern compiler
+and we recommend you to enable the DEVELOPER makefile knob to
+ensure your patch is clear of all compiler warnings we care about,
+by e.g. "echo DEVELOPER=1 &gt;&gt;config.mak".</p>
+</li>
+<li>
+<p>We try to support a wide range of C compilers to compile Git with,
+including old ones.  You should not use features from newer C
+standard, even if your compiler groks them.</p>
+<div class="literalblock">
+<div class="content">
+<pre>There are a few exceptions to this guideline:</pre>
+</div>
+</div>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>since early 2012 with e1327023ea, we have been using an enum
+definition whose last element is followed by a comma.  This, like
+an array initializer that ends with a trailing comma, can be used
+to reduce the patch noise when adding a new identifier at the end.</p>
+</li>
+<li>
+<p>since mid 2017 with cbc0f81d, we have been using designated
+initializers for struct (e.g. "struct t v = { .val = <em>a</em> };").</p>
+</li>
+<li>
+<p>since mid 2017 with 512f41cf, we have been using designated
+initializers for array (e.g. "int array[10] = { [5] = 2 }").</p>
+<div class="literalblock">
+<div class="content">
+<pre>These used to be forbidden, but we have not heard any breakage
+report, and they are assumed to be safe.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>Variables have to be declared at the beginning of the block, before
+the first statement (i.e. -Wdeclaration-after-statement).</p>
+</li>
+<li>
+<p>Declaring a variable in the for loop "for (int i = 0; i &lt; 10; i++)"
+is still not allowed in this codebase.</p>
+</li>
+<li>
+<p>NULL pointers shall be written as NULL, not as 0.</p>
+</li>
+<li>
+<p>When declaring pointers, the star sides with the variable
+name, i.e. "char <strong>string", not "char</strong> string" or
+"char * string".  This makes it easier to understand code
+like "char *string, c;".</p>
+</li>
+<li>
+<p>Use whitespace around operators and keywords, but not inside
+parentheses and not around functions. So:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      while (condition)
+func(bar + 1);</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>      while( condition )
+func (bar+1);</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Do not explicitly compare an integral value with constant 0 or <em>\0</em>,
+or a pointer value with constant NULL.  For instance, to validate that
+counted array &lt;ptr, cnt&gt; is initialized but has no elements, write:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (!ptr || cnt)
+	BUG("empty array expected");</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (ptr == NULL || cnt != 0);
+	BUG("empty array expected");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We avoid using braces unnecessarily.  I.e.</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (bla) {
+	x = 1;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is frowned upon. But there are a few exceptions:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When the statement extends over a few lines (e.g., a while loop
+with an embedded conditional, or a comment). E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (foo) {
+	if (x)
+		one();
+	else
+		two();
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	/*
+	 * This one requires some explanation,
+	 * so we're better off with braces to make
+	 * it obvious that the indentation is correct.
+	 */
+	doit();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When there are multiple arms to a conditional and some of them
+require braces, enclose even a single line block in braces for
+consistency. E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	doit();
+} else {
+	one();
+	two();
+	three();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments in the condition of an "if" statement.</p>
+</li>
+<li>
+<p>Try to make your code understandable.  You may put comments
+in, but comments invariably tend to stale out when the code
+they were describing changes.  Often splitting a function
+into two makes the intention of the code much clearer.</p>
+</li>
+<li>
+<p>Multi-line comments include their delimiters on separate lines from
+the text.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * A very long
+ * multi-line comment.
+ */</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Note however that a comment that explains a translatable string to
+translators uses a convention of starting with a magic token
+"TRANSLATORS: ", e.g.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * TRANSLATORS: here is a comment that explains the string to
+ * be translated, that follows immediately after it.
+ */
+_("Here is a translatable string explained by the above.");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Double negation is often harder to understand than no negation
+at all.</p>
+</li>
+<li>
+<p>There are two schools of thought when it comes to comparison,
+especially inside a loop. Some people prefer to have the less stable
+value on the left hand side and the more stable value on the right hand
+side, e.g. if you have a loop that counts variable i down to the
+lower bound,</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (i &gt; lower_bound) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Other people prefer to have the textual order of values match the
+actual order of values in their comparison, so that they can
+mentally draw a number line from left to right and place these
+values in order, i.e.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while (lower_bound &lt; i) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  However, the more "stable" the
+stable side becomes, the more we tend to prefer the former
+(comparison with a constant, "i &gt; 0", is an extreme example).
+Just do not mix styles in the same part of the code and mimic
+existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>There are two schools of thought when it comes to splitting a long
+logical line into multiple lines.  Some people push the second and
+subsequent lines far enough to the right with tabs and align them:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+              ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to align the second and the subsequent
+lines with the column immediately inside the opening parenthesis,
+with tabs and spaces, following our "tabstop is always a multiple
+of 8" convention:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+           ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  Again, just do not mix styles in
+the same part of the code and mimic existing styles in the
+neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, some people change line before
+a binary operator, so that the result looks like a parse tree when
+you turn your head 90-degrees counterclockwise:</p>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to
+|| span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to leave the operator at the end of the
+line:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, but we tend to use the latter more, unless the
+expression gets fairly complex, in which case the former tends to
+be easier to read.  Again, just do not mix styles in the same part
+of the code and mimic existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, with everything else being
+equal, it is preferable to split after the operator at higher
+level in the parse tree.  That is, this is more preferable:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable * that_is_used_in +
+    a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>than</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable *
+    that_is_used_in + a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Some clever tricks, like using the !! operator with arithmetic
+constructs, can be extremely confusing to others.  Avoid them,
+unless there is a compelling reason to use them.</p>
+</li>
+<li>
+<p>Use the API.  No, really.  We have a strbuf (variable length
+string), several arrays with the ALLOC_GROW() macro, a
+string_list for sorted string lists, a hash map (mapping struct
+objects) named "struct decorate", amongst other things.</p>
+</li>
+<li>
+<p>When you come up with an API, document its functions and structures
+in the header file that exposes the API to its callers. Use what is
+in "strbuf.h" as a model for the appropriate tone and level of
+detail.</p>
+</li>
+<li>
+<p>The first #include in C files, except in platform specific compat/
+implementations, must be either "git-compat-util.h", "cache.h" or
+"builtin.h".  You do not have to include more than one of these.</p>
+</li>
+<li>
+<p>A C file must directly include the header files that declare the
+functions and the types it uses, except for the functions and types
+that are made available to it by including one of the header files
+it must include by the previous rule.</p>
+</li>
+<li>
+<p>If you are planning a new command, consider writing it in shell
+or perl first, so that changes in semantics can be easily
+changed and discussed.  Many Git commands started out like
+that, and a few are still scripts.</p>
+</li>
+<li>
+<p>Avoid introducing a new dependency into Git. This means you
+usually should stay away from scripting languages not already
+used in the Git core command set (unless your command is clearly
+separate from it, such as an importer to convert random-scm-X
+repositories to Git).</p>
+</li>
+<li>
+<p>When we pass &lt;string, length&gt; pair to functions, we should try to
+pass them in that order.</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers to make the user interface
+translatable. See "Marking strings for translation" in po/README.</p>
+</li>
+<li>
+<p>Variables and functions local to a given source file should be marked
+with "static". Variables that are visible to other source files
+must be declared with "extern" in header files. However, function
+declarations should not use "extern", as that is already the default.</p>
+</li>
+<li>
+<p>You can launch gdb around your program using the shorthand GIT_DEBUGGER.
+Run <code>GIT_DEBUGGER=1 ./bin-wrappers/git foo</code> to simply use gdb as is, or
+run <code>GIT_DEBUGGER="&lt;debugger&gt; &lt;debugger-args&gt;" ./bin-wrappers/git foo</code> to
+use your own debugger and arguments. Example: <code>GIT_DEBUGGER="ddd --gdb"
+./bin-wrappers/git log</code> (See <code>wrap-for-bin.sh</code>.)</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Perl programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most of the C guidelines above apply.</p>
+</li>
+<li>
+<p>We try to support Perl 5.8 and later ("use Perl 5.008").</p>
+</li>
+<li>
+<p>use strict and use warnings are strongly preferred.</p>
+</li>
+<li>
+<p>Don&#8217;t overuse statement modifiers unless using them makes the
+result easier to follow.</p>
+<div class="olist lowerroman">
+<ol class="lowerroman" type="i">
+<li>
+<p>do something &#8230;&#8203;
+do_this() unless (condition);</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>is more readable than:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>do something &#8230;&#8203;
+unless (condition) {
+	do_this();
+}</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>*only* when the condition is so rare that do_this() will be almost
+always called.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments inside "if ()" conditions.</p>
+</li>
+<li>
+<p>Learn and use Git.pm if you need that functionality.</p>
+</li>
+<li>
+<p>For Emacs, it&#8217;s useful to put the following in
+GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode:</p>
+<div class="literalblock">
+<div class="content">
+<pre>;; note the first part is useful for C editing, too
+((nil . ((indent-tabs-mode . t)
+              (tab-width . 8)
+              (fill-column . 80)))
+ (cperl-mode . ((cperl-indent-level . 8)
+                (cperl-extra-newline-before-brace . nil)
+                (cperl-merge-trailing-else . t))))</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Python scripts:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We follow PEP-8 (<a href="http://www.python.org/dev/peps/pep-0008/" class="bare">http://www.python.org/dev/peps/pep-0008/</a>).</p>
+</li>
+<li>
+<p>As a minimum, we aim to be compatible with Python 2.6 and 2.7.</p>
+</li>
+<li>
+<p>Where required libraries do not restrict us to Python 2, we try to
+also be compatible with Python 3.1 and later.</p>
+</li>
+<li>
+<p>When you must differentiate between Unicode literals and byte string
+literals, it is OK to use the <em>b</em> prefix.  Even though the Python
+documentation for version 2.6 does not mention this prefix, it has
+been supported since version 2.6.0.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Error Messages</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Do not end error messages with a full stop.</p>
+</li>
+<li>
+<p>Do not capitalize ("unable to open %s", not "Unable to open %s")</p>
+</li>
+<li>
+<p>Say what the error is first ("cannot open %s", not "%s: cannot open")</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Externally Visible Names</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>For configuration variable names, follow the existing convention:</p>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>The section name indicates the affected subsystem.</p>
+</li>
+<li>
+<p>The subsection name, if any, indicates which of an unbounded set
+of things to set the value for.</p>
+</li>
+<li>
+<p>The variable name describes the effect of tweaking this knob.</p>
+<div class="literalblock">
+<div class="content">
+<pre>The section and variable names that consist of multiple words are
+formed by concatenating the words without punctuations (e.g. `-`),
+and are broken using bumpyCaps in documentation as a hint to the
+reader.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>When choosing the variable namespace, do not use variable name for
+specifying possibly unbounded set of things, most notably anything
+an end user can freely come up with (e.g. branch names).  Instead,
+use subsection names or variable values, like the existing variable
+branch.&lt;name&gt;.description does.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Writing Documentation:</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Most (if not all) of the documentation pages are written in the
+AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+processed into HTML and manpages (e.g. git.html and git.1 in the
+same directory).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>The documentation liberally mixes US and UK English (en_US/UK)
+norms for spelling and grammar, which is somewhat unfortunate.
+In an ideal world, it would have been better if it consistently
+used only one and not the other, and we would have picked en_US
+(if you wish to correct the English of some of the existing
+documentation, please see the documentation-related advice in the
+Documentation/SubmittingPatches file).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Every user-visible change should be reflected in the documentation.
+The same general rule as for code applies -- imitate the existing
+conventions.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying command usage strings and synopsis sections in the manual
+pages:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Placeholders are spelled in lowercase and enclosed in angle brackets:
+  &lt;file&gt;
+  --sort=&lt;key&gt;
+  --abbrev[=&lt;n&gt;]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If a placeholder has multiple words, they are separated by dashes:
+  &lt;new-branch-name&gt;
+  --template=&lt;template-directory&gt;</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Possibility of multiple occurrences is indicated by three dots:
+  &lt;file&gt;...
+  (One or more of &lt;file&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Optional parts are enclosed in square brackets:
+  [&lt;extra&gt;]
+  (Zero or one &lt;extra&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>--exec-path[=&lt;path&gt;]
+(Option with an optional argument.  Note that the "=" is inside the
+brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[&lt;patch&gt;...]
+(Zero or more of &lt;patch&gt;.  Note that the dots are inside, not
+outside the brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Multiple alternatives are indicated with vertical bars:
+  [-q | --quiet]
+  [--utf8 | --no-utf8]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Parentheses are used for grouping:
+  [(&lt;rev&gt; | &lt;range&gt;)...]
+  (Any number of either &lt;rev&gt; or &lt;range&gt;.  Parens are needed to make
+  it clear that "..." pertains to both &lt;rev&gt; and &lt;range&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[(-p &lt;parent&gt;)...]
+(Any number of option -p, each with one &lt;parent&gt; argument.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>git remote set-head &lt;name&gt; (-a | -d | &lt;branch&gt;)
+(One and only one of "-a", "-d" or "&lt;branch&gt;" _must_ (no square
+brackets) be provided.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>And a somewhat more contrived example:
+  --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+  Here "=" is outside the brackets, because "--diff-filter=" is a
+  valid usage.  "*" has its own pair of brackets, because it can
+  (optionally) be specified only when one or more of the letters is
+  also provided.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A note on notation:
+ Use 'git' (all lowercase) when talking about commands i.e. something
+ the user would type into a shell and use 'Git' (uppercase first letter)
+ when talking about the version control system and its properties.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying paragraphs or option/command explanations that contain options
+or commands:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Literal examples (e.g. use of command-line options, command names,
+branch names, URLs, pathnames (files and directories), configuration and
+environment variables) must be typeset in monospace (i.e. wrapped with
+backticks):
+  `--pretty=oneline`
+  `git rev-list`
+  `remote.pushDefault`
+  `http://git.example.com`
+  `.git/config`
+  `GIT_DIR`
+  `HEAD`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>An environment variable must be prefixed with "$" only when referring to its
+value and not when referring to the variable itself, in this case there is
+nothing to add except the backticks:
+  `GIT_DIR` is specified
+  `$GIT_DIR/hooks/pre-receive`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Word phrases enclosed in `backtick characters` are rendered literally
+and will not be further expanded. The use of `backticks` to achieve the
+previous rule means that literal examples should not use AsciiDoc
+escapes.
+  Correct:
+     `--pretty=oneline`
+  Incorrect:
+     `\--pretty=oneline`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If some place in the documentation needs to typeset a command usage
+example with inline substitutions, it is fine to use +monospaced and
+inline substituted text+ instead of `monospaced literal text`, and with
+the former, the part that should not get substituted must be
+quoted/escaped.</pre>
+</div>
+</div>
+</div>
+</div>
\ No newline at end of file
diff --git a/external/docs/content/docs/CodingGuidelines/2.28.0.html b/external/docs/content/docs/CodingGuidelines/2.28.0.html
new file mode 100644
index 0000000000..b10af5c2a7
--- /dev/null
+++ b/external/docs/content/docs/CodingGuidelines/2.28.0.html
@@ -0,0 +1,1031 @@
+---
+### DO NOT EDIT! Generated by script/update-docs.rb
+
+category: manual
+section: documentation
+subsection: manual
+title: Git - CodingGuidelines Documentation
+docname: CodingGuidelines
+version: 2.28.0
+aliases:
+- "/docs/CodingGuidelines/2.28.0/index.html"
+- "/docs/CodingGuidelines/2.28.1/index.html"
+- "/docs/CodingGuidelines/2.29.0/index.html"
+- "/docs/CodingGuidelines/2.29.1/index.html"
+- "/docs/CodingGuidelines/2.29.2/index.html"
+- "/docs/CodingGuidelines/2.29.3/index.html"
+- "/docs/CodingGuidelines/2.30.0/index.html"
+- "/docs/CodingGuidelines/2.30.1/index.html"
+- "/docs/CodingGuidelines/2.30.2/index.html"
+- "/docs/CodingGuidelines/2.30.3/index.html"
+- "/docs/CodingGuidelines/2.30.4/index.html"
+- "/docs/CodingGuidelines/2.30.5/index.html"
+- "/docs/CodingGuidelines/2.30.6/index.html"
+- "/docs/CodingGuidelines/2.30.7/index.html"
+- "/docs/CodingGuidelines/2.30.8/index.html"
+- "/docs/CodingGuidelines/2.30.9/index.html"
+- "/docs/CodingGuidelines/2.31.0/index.html"
+- "/docs/CodingGuidelines/2.31.1/index.html"
+- "/docs/CodingGuidelines/2.31.2/index.html"
+- "/docs/CodingGuidelines/2.31.3/index.html"
+- "/docs/CodingGuidelines/2.31.4/index.html"
+- "/docs/CodingGuidelines/2.31.5/index.html"
+- "/docs/CodingGuidelines/2.31.6/index.html"
+- "/docs/CodingGuidelines/2.31.7/index.html"
+- "/docs/CodingGuidelines/2.31.8/index.html"
+---
+<div id="preamble">
+<div class="sectionbody">
+<div class="paragraph">
+<p>Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, a few rough rules are:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most importantly, we never say "It&#8217;s in POSIX; we&#8217;ll happily
+ignore your needs should your system not conform to it."
+We live in the real world.</p>
+</li>
+<li>
+<p>However, we often say "Let&#8217;s stay away from that construct,
+it&#8217;s not even in POSIX".</p>
+</li>
+<li>
+<p>In spite of the above two rules, we sometimes say "Although
+this is not in POSIX, it (is so convenient | makes the code
+much more readable | has other good characteristics) and
+practically all the platforms we care about support it, so
+let&#8217;s use it".</p>
+<div class="literalblock">
+<div class="content">
+<pre>Again, we live in the real world, and it is sometimes a
+judgement call, the decision based more on real world
+constraints people face than what the paper standard says.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Fixing style violations while working on a real change as a
+preparatory clean-up step is good, but otherwise avoid useless code
+churn for the sake of conforming to the style.</p>
+<div class="literalblock">
+<div class="content">
+<pre>"Once it _is_ in the tree, it's not really worth the patch noise to
+go and fix it up."
+Cf. http://lkml.iu.edu/hypermail/linux/kernel/1001.3/01069.html</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Make your code readable and sensible, and don&#8217;t try to be clever.</p>
+</div>
+<div class="paragraph">
+<p>As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the <em>local</em>
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn&#8217;t match the overall style of existing code).</p>
+</div>
+<div class="paragraph">
+<p>But if you must have a list of rules, here they are.</p>
+</div>
+<div class="paragraph">
+<p>For shell scripts specifically (not exhaustive):</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs for indentation.</p>
+</li>
+<li>
+<p>Case arms are indented at the same depth as case and esac lines,
+like this:</p>
+<div class="literalblock">
+<div class="content">
+<pre>case "$variable" in
+pattern1)
+	do this
+	;;
+pattern2)
+	do that
+	;;
+esac</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Redirection operators should be written with space before, but no
+space after them.  In other words, write <em>echo test &gt;"$file"</em>
+instead of <em>echo test&gt; $file</em> or <em>echo test &gt; $file</em>.  Note that
+even though it is not required by POSIX to double-quote the
+redirection target in a variable (as shown above), our code does so
+because some versions of bash issue a warning without the quotes.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+cat hello &gt; world &lt; universe
+echo hello &gt;$world</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+cat hello &gt;world &lt;universe
+echo hello &gt;"$world"</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer $( &#8230;&#8203; ) for command substitution; unlike ``, it
+properly nests.  It should have been the way Bourne spelled
+it from day one, but unfortunately isn&#8217;t.</p>
+</li>
+<li>
+<p>If you want to find out if a command is available on the user&#8217;s
+$PATH, you should use <em>type &lt;command&gt;</em>, instead of <em>which &lt;command&gt;</em>.
+The output of <em>which</em> is not machine parsable and its exit code
+is not reliable across platforms.</p>
+</li>
+<li>
+<p>We use POSIX compliant parameter substitutions and avoid bashisms;
+namely:</p>
+</li>
+<li>
+<p>We use ${parameter-word} and its [-=?+] siblings, and their
+colon&#8217;ed "unset or null" form.</p>
+</li>
+<li>
+<p>We use ${parameter#word} and its [#%] siblings, and their
+doubled "longest matching" form.</p>
+</li>
+<li>
+<p>No "Substring Expansion" ${parameter:offset:length}.</p>
+</li>
+<li>
+<p>No shell arrays.</p>
+</li>
+<li>
+<p>No pattern replacement ${parameter/pattern/string}.</p>
+</li>
+<li>
+<p>We use Arithmetic Expansion $&#8230;&#8203;.</p>
+</li>
+<li>
+<p>We do not use Process Substitution &lt;(list) or &gt;(list).</p>
+</li>
+<li>
+<p>Do not write control structures on a single line with semicolon.
+"then" should be on the next line for if statements, and "do"
+should be on the next line for "while" and "for".</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+if test -f hello; then
+	do this
+fi</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+if test -f hello
+then
+	do this
+fi</pre>
+</div>
+</div>
+</li>
+<li>
+<p>If a command sequence joined with &amp;&amp; or || or | spans multiple
+lines, put each command on a separate line and put &amp;&amp; and || and |
+operators at the end of each line, rather than the start. This
+means you don&#8217;t need to use \ to join lines, since the above
+operators imply the sequence isn&#8217;t finished.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+grep blob verify_pack_result \
+| awk -f print_1.awk \
+| sort &gt;actual &amp;&amp;
+...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+grep blob verify_pack_result |
+awk -f print_1.awk |
+sort &gt;actual &amp;&amp;
+...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer "test" over "[ &#8230;&#8203; ]".</p>
+</li>
+<li>
+<p>We do not write the noiseword "function" in front of shell
+functions.</p>
+</li>
+<li>
+<p>We prefer a space between the function name and the parentheses,
+and no space inside the parentheses. The opening "{" should also
+be on the same line.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+my_function(){
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+my_function () {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+[::], [==], or [..]) for portability.</p>
+</li>
+<li>
+<p>We do not use \{m,n\};</p>
+</li>
+<li>
+<p>We do not use -E;</p>
+</li>
+<li>
+<p>We do not use ? or + (which are \{0,1\} and \{1,\}
+respectively in BRE) but that goes without saying as these
+are ERE elements not BRE (note that \? and \+ are not even part
+of BRE&#8201;&#8212;&#8201;making them accessible from BRE is a GNU extension).</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers in git-sh-i18n to make the user
+interface translatable. See "Marking strings for translation" in
+po/README.</p>
+</li>
+<li>
+<p>We do not write our "test" command with "-a" and "-o" and use "&amp;&amp;"
+or "||" to concatenate multiple "test" commands instead, because
+the use of "-a/-o" is often error-prone.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" -a "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is buggy and breaks when $x is "=", but</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" &amp;&amp; test "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>does not have such a problem.</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For C programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs to indent, and interpret tabs as taking up to
+8 spaces.</p>
+</li>
+<li>
+<p>We try to keep to at most 80 characters per line.</p>
+</li>
+<li>
+<p>As a Git developer we assume you have a reasonably modern compiler
+and we recommend you to enable the DEVELOPER makefile knob to
+ensure your patch is clear of all compiler warnings we care about,
+by e.g. "echo DEVELOPER=1 &gt;&gt;config.mak".</p>
+</li>
+<li>
+<p>We try to support a wide range of C compilers to compile Git with,
+including old ones.  You should not use features from newer C
+standard, even if your compiler groks them.</p>
+<div class="literalblock">
+<div class="content">
+<pre>There are a few exceptions to this guideline:</pre>
+</div>
+</div>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>since early 2012 with e1327023ea, we have been using an enum
+definition whose last element is followed by a comma.  This, like
+an array initializer that ends with a trailing comma, can be used
+to reduce the patch noise when adding a new identifier at the end.</p>
+</li>
+<li>
+<p>since mid 2017 with cbc0f81d, we have been using designated
+initializers for struct (e.g. "struct t v = { .val = <em>a</em> };").</p>
+</li>
+<li>
+<p>since mid 2017 with 512f41cf, we have been using designated
+initializers for array (e.g. "int array[10] = { [5] = 2 }").</p>
+<div class="literalblock">
+<div class="content">
+<pre>These used to be forbidden, but we have not heard any breakage
+report, and they are assumed to be safe.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>Variables have to be declared at the beginning of the block, before
+the first statement (i.e. -Wdeclaration-after-statement).</p>
+</li>
+<li>
+<p>Declaring a variable in the for loop "for (int i = 0; i &lt; 10; i++)"
+is still not allowed in this codebase.</p>
+</li>
+<li>
+<p>NULL pointers shall be written as NULL, not as 0.</p>
+</li>
+<li>
+<p>When declaring pointers, the star sides with the variable
+name, i.e. "char <strong>string", not "char</strong> string" or
+"char * string".  This makes it easier to understand code
+like "char *string, c;".</p>
+</li>
+<li>
+<p>Use whitespace around operators and keywords, but not inside
+parentheses and not around functions. So:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      while (condition)
+func(bar + 1);</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>      while( condition )
+func (bar+1);</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Do not explicitly compare an integral value with constant 0 or <em>\0</em>,
+or a pointer value with constant NULL.  For instance, to validate that
+counted array &lt;ptr, cnt&gt; is initialized but has no elements, write:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (!ptr || cnt)
+	BUG("empty array expected");</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (ptr == NULL || cnt != 0);
+	BUG("empty array expected");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We avoid using braces unnecessarily.  I.e.</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (bla) {
+	x = 1;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is frowned upon. But there are a few exceptions:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When the statement extends over a few lines (e.g., a while loop
+with an embedded conditional, or a comment). E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (foo) {
+	if (x)
+		one();
+	else
+		two();
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	/*
+	 * This one requires some explanation,
+	 * so we're better off with braces to make
+	 * it obvious that the indentation is correct.
+	 */
+	doit();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When there are multiple arms to a conditional and some of them
+require braces, enclose even a single line block in braces for
+consistency. E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	doit();
+} else {
+	one();
+	two();
+	three();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments in the condition of an "if" statement.</p>
+</li>
+<li>
+<p>Try to make your code understandable.  You may put comments
+in, but comments invariably tend to stale out when the code
+they were describing changes.  Often splitting a function
+into two makes the intention of the code much clearer.</p>
+</li>
+<li>
+<p>Multi-line comments include their delimiters on separate lines from
+the text.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * A very long
+ * multi-line comment.
+ */</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Note however that a comment that explains a translatable string to
+translators uses a convention of starting with a magic token
+"TRANSLATORS: ", e.g.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * TRANSLATORS: here is a comment that explains the string to
+ * be translated, that follows immediately after it.
+ */
+_("Here is a translatable string explained by the above.");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Double negation is often harder to understand than no negation
+at all.</p>
+</li>
+<li>
+<p>There are two schools of thought when it comes to comparison,
+especially inside a loop. Some people prefer to have the less stable
+value on the left hand side and the more stable value on the right hand
+side, e.g. if you have a loop that counts variable i down to the
+lower bound,</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (i &gt; lower_bound) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Other people prefer to have the textual order of values match the
+actual order of values in their comparison, so that they can
+mentally draw a number line from left to right and place these
+values in order, i.e.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while (lower_bound &lt; i) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  However, the more "stable" the
+stable side becomes, the more we tend to prefer the former
+(comparison with a constant, "i &gt; 0", is an extreme example).
+Just do not mix styles in the same part of the code and mimic
+existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>There are two schools of thought when it comes to splitting a long
+logical line into multiple lines.  Some people push the second and
+subsequent lines far enough to the right with tabs and align them:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+              ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to align the second and the subsequent
+lines with the column immediately inside the opening parenthesis,
+with tabs and spaces, following our "tabstop is always a multiple
+of 8" convention:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+           ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  Again, just do not mix styles in
+the same part of the code and mimic existing styles in the
+neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, some people change line before
+a binary operator, so that the result looks like a parse tree when
+you turn your head 90-degrees counterclockwise:</p>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to
+|| span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to leave the operator at the end of the
+line:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, but we tend to use the latter more, unless the
+expression gets fairly complex, in which case the former tends to
+be easier to read.  Again, just do not mix styles in the same part
+of the code and mimic existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, with everything else being
+equal, it is preferable to split after the operator at higher
+level in the parse tree.  That is, this is more preferable:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable * that_is_used_in +
+    a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>than</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable *
+    that_is_used_in + a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Some clever tricks, like using the !! operator with arithmetic
+constructs, can be extremely confusing to others.  Avoid them,
+unless there is a compelling reason to use them.</p>
+</li>
+<li>
+<p>Use the API.  No, really.  We have a strbuf (variable length
+string), several arrays with the ALLOC_GROW() macro, a
+string_list for sorted string lists, a hash map (mapping struct
+objects) named "struct decorate", amongst other things.</p>
+</li>
+<li>
+<p>When you come up with an API, document its functions and structures
+in the header file that exposes the API to its callers. Use what is
+in "strbuf.h" as a model for the appropriate tone and level of
+detail.</p>
+</li>
+<li>
+<p>The first #include in C files, except in platform specific compat/
+implementations, must be either "git-compat-util.h", "cache.h" or
+"builtin.h".  You do not have to include more than one of these.</p>
+</li>
+<li>
+<p>A C file must directly include the header files that declare the
+functions and the types it uses, except for the functions and types
+that are made available to it by including one of the header files
+it must include by the previous rule.</p>
+</li>
+<li>
+<p>If you are planning a new command, consider writing it in shell
+or perl first, so that changes in semantics can be easily
+changed and discussed.  Many Git commands started out like
+that, and a few are still scripts.</p>
+</li>
+<li>
+<p>Avoid introducing a new dependency into Git. This means you
+usually should stay away from scripting languages not already
+used in the Git core command set (unless your command is clearly
+separate from it, such as an importer to convert random-scm-X
+repositories to Git).</p>
+</li>
+<li>
+<p>When we pass &lt;string, length&gt; pair to functions, we should try to
+pass them in that order.</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers to make the user interface
+translatable. See "Marking strings for translation" in po/README.</p>
+</li>
+<li>
+<p>Variables and functions local to a given source file should be marked
+with "static". Variables that are visible to other source files
+must be declared with "extern" in header files. However, function
+declarations should not use "extern", as that is already the default.</p>
+</li>
+<li>
+<p>You can launch gdb around your program using the shorthand GIT_DEBUGGER.
+Run <code>GIT_DEBUGGER=1 ./bin-wrappers/git foo</code> to simply use gdb as is, or
+run <code>GIT_DEBUGGER="&lt;debugger&gt; &lt;debugger-args&gt;" ./bin-wrappers/git foo</code> to
+use your own debugger and arguments. Example: <code>GIT_DEBUGGER="ddd --gdb"
+./bin-wrappers/git log</code> (See <code>wrap-for-bin.sh</code>.)</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Perl programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most of the C guidelines above apply.</p>
+</li>
+<li>
+<p>We try to support Perl 5.8 and later ("use Perl 5.008").</p>
+</li>
+<li>
+<p>use strict and use warnings are strongly preferred.</p>
+</li>
+<li>
+<p>Don&#8217;t overuse statement modifiers unless using them makes the
+result easier to follow.</p>
+<div class="olist lowerroman">
+<ol class="lowerroman" type="i">
+<li>
+<p>do something &#8230;&#8203;
+do_this() unless (condition);</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>is more readable than:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>do something &#8230;&#8203;
+unless (condition) {
+	do_this();
+}</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>*only* when the condition is so rare that do_this() will be almost
+always called.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments inside "if ()" conditions.</p>
+</li>
+<li>
+<p>Learn and use Git.pm if you need that functionality.</p>
+</li>
+<li>
+<p>For Emacs, it&#8217;s useful to put the following in
+GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode:</p>
+<div class="literalblock">
+<div class="content">
+<pre>;; note the first part is useful for C editing, too
+((nil . ((indent-tabs-mode . t)
+              (tab-width . 8)
+              (fill-column . 80)))
+ (cperl-mode . ((cperl-indent-level . 8)
+                (cperl-extra-newline-before-brace . nil)
+                (cperl-merge-trailing-else . t))))</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Python scripts:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We follow PEP-8 (<a href="http://www.python.org/dev/peps/pep-0008/" class="bare">http://www.python.org/dev/peps/pep-0008/</a>).</p>
+</li>
+<li>
+<p>As a minimum, we aim to be compatible with Python 2.7.</p>
+</li>
+<li>
+<p>Where required libraries do not restrict us to Python 2, we try to
+also be compatible with Python 3.1 and later.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Error Messages</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Do not end error messages with a full stop.</p>
+</li>
+<li>
+<p>Do not capitalize ("unable to open %s", not "Unable to open %s")</p>
+</li>
+<li>
+<p>Say what the error is first ("cannot open %s", not "%s: cannot open")</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Externally Visible Names</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>For configuration variable names, follow the existing convention:</p>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>The section name indicates the affected subsystem.</p>
+</li>
+<li>
+<p>The subsection name, if any, indicates which of an unbounded set
+of things to set the value for.</p>
+</li>
+<li>
+<p>The variable name describes the effect of tweaking this knob.</p>
+<div class="literalblock">
+<div class="content">
+<pre>The section and variable names that consist of multiple words are
+formed by concatenating the words without punctuations (e.g. `-`),
+and are broken using bumpyCaps in documentation as a hint to the
+reader.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>When choosing the variable namespace, do not use variable name for
+specifying possibly unbounded set of things, most notably anything
+an end user can freely come up with (e.g. branch names).  Instead,
+use subsection names or variable values, like the existing variable
+branch.&lt;name&gt;.description does.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Writing Documentation:</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Most (if not all) of the documentation pages are written in the
+AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+processed into HTML and manpages (e.g. git.html and git.1 in the
+same directory).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>The documentation liberally mixes US and UK English (en_US/UK)
+norms for spelling and grammar, which is somewhat unfortunate.
+In an ideal world, it would have been better if it consistently
+used only one and not the other, and we would have picked en_US
+(if you wish to correct the English of some of the existing
+documentation, please see the documentation-related advice in the
+Documentation/SubmittingPatches file).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Every user-visible change should be reflected in the documentation.
+The same general rule as for code applies -- imitate the existing
+conventions.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying command usage strings and synopsis sections in the manual
+pages:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Placeholders are spelled in lowercase and enclosed in angle brackets:
+  &lt;file&gt;
+  --sort=&lt;key&gt;
+  --abbrev[=&lt;n&gt;]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If a placeholder has multiple words, they are separated by dashes:
+  &lt;new-branch-name&gt;
+  --template=&lt;template-directory&gt;</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Possibility of multiple occurrences is indicated by three dots:
+  &lt;file&gt;...
+  (One or more of &lt;file&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Optional parts are enclosed in square brackets:
+  [&lt;extra&gt;]
+  (Zero or one &lt;extra&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>--exec-path[=&lt;path&gt;]
+(Option with an optional argument.  Note that the "=" is inside the
+brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[&lt;patch&gt;...]
+(Zero or more of &lt;patch&gt;.  Note that the dots are inside, not
+outside the brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Multiple alternatives are indicated with vertical bars:
+  [-q | --quiet]
+  [--utf8 | --no-utf8]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Parentheses are used for grouping:
+  [(&lt;rev&gt; | &lt;range&gt;)...]
+  (Any number of either &lt;rev&gt; or &lt;range&gt;.  Parens are needed to make
+  it clear that "..." pertains to both &lt;rev&gt; and &lt;range&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[(-p &lt;parent&gt;)...]
+(Any number of option -p, each with one &lt;parent&gt; argument.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>git remote set-head &lt;name&gt; (-a | -d | &lt;branch&gt;)
+(One and only one of "-a", "-d" or "&lt;branch&gt;" _must_ (no square
+brackets) be provided.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>And a somewhat more contrived example:
+  --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+  Here "=" is outside the brackets, because "--diff-filter=" is a
+  valid usage.  "*" has its own pair of brackets, because it can
+  (optionally) be specified only when one or more of the letters is
+  also provided.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A note on notation:
+ Use 'git' (all lowercase) when talking about commands i.e. something
+ the user would type into a shell and use 'Git' (uppercase first letter)
+ when talking about the version control system and its properties.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying paragraphs or option/command explanations that contain options
+or commands:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Literal examples (e.g. use of command-line options, command names,
+branch names, URLs, pathnames (files and directories), configuration and
+environment variables) must be typeset in monospace (i.e. wrapped with
+backticks):
+  `--pretty=oneline`
+  `git rev-list`
+  `remote.pushDefault`
+  `http://git.example.com`
+  `.git/config`
+  `GIT_DIR`
+  `HEAD`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>An environment variable must be prefixed with "$" only when referring to its
+value and not when referring to the variable itself, in this case there is
+nothing to add except the backticks:
+  `GIT_DIR` is specified
+  `$GIT_DIR/hooks/pre-receive`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Word phrases enclosed in `backtick characters` are rendered literally
+and will not be further expanded. The use of `backticks` to achieve the
+previous rule means that literal examples should not use AsciiDoc
+escapes.
+  Correct:
+     `--pretty=oneline`
+  Incorrect:
+     `\--pretty=oneline`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If some place in the documentation needs to typeset a command usage
+example with inline substitutions, it is fine to use +monospaced and
+inline substituted text+ instead of `monospaced literal text`, and with
+the former, the part that should not get substituted must be
+quoted/escaped.</pre>
+</div>
+</div>
+</div>
+</div>
\ No newline at end of file
diff --git a/external/docs/content/docs/CodingGuidelines/2.3.10.html b/external/docs/content/docs/CodingGuidelines/2.3.10.html
new file mode 100644
index 0000000000..315d72f5c1
--- /dev/null
+++ b/external/docs/content/docs/CodingGuidelines/2.3.10.html
@@ -0,0 +1,853 @@
+---
+### DO NOT EDIT! Generated by script/update-docs.rb
+
+category: manual
+section: documentation
+subsection: manual
+title: Git - CodingGuidelines Documentation
+docname: CodingGuidelines
+version: 2.3.10
+aliases:
+- "/docs/CodingGuidelines/2.3.10/index.html"
+---
+<div id="preamble">
+<div class="sectionbody">
+<div class="paragraph">
+<p>Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, a few rough rules are:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most importantly, we never say "It&#8217;s in POSIX; we&#8217;ll happily
+ignore your needs should your system not conform to it."
+We live in the real world.</p>
+</li>
+<li>
+<p>However, we often say "Let&#8217;s stay away from that construct,
+it&#8217;s not even in POSIX".</p>
+</li>
+<li>
+<p>In spite of the above two rules, we sometimes say "Although
+this is not in POSIX, it (is so convenient | makes the code
+much more readable | has other good characteristics) and
+practically all the platforms we care about support it, so
+let&#8217;s use it".</p>
+<div class="literalblock">
+<div class="content">
+<pre>Again, we live in the real world, and it is sometimes a
+judgement call, the decision based more on real world
+constraints people face than what the paper standard says.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Fixing style violations while working on a real change as a
+preparatory clean-up step is good, but otherwise avoid useless code
+churn for the sake of conforming to the style.</p>
+<div class="literalblock">
+<div class="content">
+<pre>"Once it _is_ in the tree, it's not really worth the patch noise to
+go and fix it up."
+Cf. http://article.gmane.org/gmane.linux.kernel/943020</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Make your code readable and sensible, and don&#8217;t try to be clever.</p>
+</div>
+<div class="paragraph">
+<p>As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the <em>local</em>
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn&#8217;t match the overall style of existing code).</p>
+</div>
+<div class="paragraph">
+<p>But if you must have a list of rules, here they are.</p>
+</div>
+<div class="paragraph">
+<p>For shell scripts specifically (not exhaustive):</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs for indentation.</p>
+</li>
+<li>
+<p>Case arms are indented at the same depth as case and esac lines,
+like this:</p>
+<div class="literalblock">
+<div class="content">
+<pre>case "$variable" in
+pattern1)
+	do this
+	;;
+pattern2)
+	do that
+	;;
+esac</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Redirection operators should be written with space before, but no
+space after them.  In other words, write <em>echo test &gt;"$file"</em>
+instead of <em>echo test&gt; $file</em> or <em>echo test &gt; $file</em>.  Note that
+even though it is not required by POSIX to double-quote the
+redirection target in a variable (as shown above), our code does so
+because some versions of bash issue a warning without the quotes.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+cat hello &gt; world &lt; universe
+echo hello &gt;$world</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+cat hello &gt;world &lt;universe
+echo hello &gt;"$world"</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer $( &#8230;&#8203; ) for command substitution; unlike ``, it
+properly nests.  It should have been the way Bourne spelled
+it from day one, but unfortunately isn&#8217;t.</p>
+</li>
+<li>
+<p>If you want to find out if a command is available on the user&#8217;s
+$PATH, you should use <em>type &lt;command&gt;</em>, instead of <em>which &lt;command&gt;</em>.
+The output of <em>which</em> is not machine parseable and its exit code
+is not reliable across platforms.</p>
+</li>
+<li>
+<p>We use POSIX compliant parameter substitutions and avoid bashisms;
+namely:</p>
+</li>
+<li>
+<p>We use ${parameter-word} and its [-=?+] siblings, and their
+colon&#8217;ed "unset or null" form.</p>
+</li>
+<li>
+<p>We use ${parameter#word} and its [#%] siblings, and their
+doubled "longest matching" form.</p>
+</li>
+<li>
+<p>No "Substring Expansion" ${parameter:offset:length}.</p>
+</li>
+<li>
+<p>No shell arrays.</p>
+</li>
+<li>
+<p>No strlen ${#parameter}.</p>
+</li>
+<li>
+<p>No pattern replacement ${parameter/pattern/string}.</p>
+</li>
+<li>
+<p>We use Arithmetic Expansion $&#8230;&#8203;.</p>
+</li>
+<li>
+<p>Inside Arithmetic Expansion, spell shell variables with $ in front
+of them, as some shells do not grok $x while accepting $$x
+just fine (e.g. dash older than 0.5.4).</p>
+</li>
+<li>
+<p>We do not use Process Substitution &lt;(list) or &gt;(list).</p>
+</li>
+<li>
+<p>Do not write control structures on a single line with semicolon.
+"then" should be on the next line for if statements, and "do"
+should be on the next line for "while" and "for".</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+if test -f hello; then
+	do this
+fi</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+if test -f hello
+then
+	do this
+fi</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer "test" over "[ &#8230;&#8203; ]".</p>
+</li>
+<li>
+<p>We do not write the noiseword "function" in front of shell
+functions.</p>
+</li>
+<li>
+<p>We prefer a space between the function name and the parentheses,
+and no space inside the parentheses. The opening "{" should also
+be on the same line.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+my_function(){
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+my_function () {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+[::], [==], or [..]) for portability.</p>
+</li>
+<li>
+<p>We do not use \{m,n\};</p>
+</li>
+<li>
+<p>We do not use -E;</p>
+</li>
+<li>
+<p>We do not use ? or + (which are \{0,1\} and \{1,\}
+respectively in BRE) but that goes without saying as these
+are ERE elements not BRE (note that \? and \+ are not even part
+of BRE&#8201;&#8212;&#8201;making them accessible from BRE is a GNU extension).</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers in git-sh-i18n to make the user
+interface translatable. See "Marking strings for translation" in
+po/README.</p>
+</li>
+<li>
+<p>We do not write our "test" command with "-a" and "-o" and use "&amp;&amp;"
+or "||" to concatenate multiple "test" commands instead, because
+the use of "-a/-o" is often error-prone.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" -a "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is buggy and breaks when $x is "=", but</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" &amp;&amp; test "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>does not have such a problem.</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For C programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs to indent, and interpret tabs as taking up to
+8 spaces.</p>
+</li>
+<li>
+<p>We try to keep to at most 80 characters per line.</p>
+</li>
+<li>
+<p>We try to support a wide range of C compilers to compile Git with,
+including old ones. That means that you should not use C99
+initializers, even if a lot of compilers grok it.</p>
+</li>
+<li>
+<p>Variables have to be declared at the beginning of the block.</p>
+</li>
+<li>
+<p>NULL pointers shall be written as NULL, not as 0.</p>
+</li>
+<li>
+<p>When declaring pointers, the star sides with the variable
+name, i.e. "char <strong>string", not "char</strong> string" or
+"char * string".  This makes it easier to understand code
+like "char *string, c;".</p>
+</li>
+<li>
+<p>Use whitespace around operators and keywords, but not inside
+parentheses and not around functions. So:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      while (condition)
+func(bar + 1);</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>      while( condition )
+func (bar+1);</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We avoid using braces unnecessarily.  I.e.</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (bla) {
+	x = 1;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is frowned upon.  A gray area is when the statement extends
+over a few lines, and/or you have a lengthy comment atop of
+it.  Also, like in the Linux kernel, if there is a long list
+of "else if" statements, it can make sense to add braces to
+single line blocks.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments in the condition of an "if" statement.</p>
+</li>
+<li>
+<p>Try to make your code understandable.  You may put comments
+in, but comments invariably tend to stale out when the code
+they were describing changes.  Often splitting a function
+into two makes the intention of the code much clearer.</p>
+</li>
+<li>
+<p>Multi-line comments include their delimiters on separate lines from
+the text.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * A very long
+ * multi-line comment.
+ */</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Note however that a comment that explains a translatable string to
+translators uses a convention of starting with a magic token
+"TRANSLATORS: " immediately after the opening delimiter, even when
+it spans multiple lines.  We do not add an asterisk at the beginning
+of each line, either.  E.g.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>/* TRANSLATORS: here is a comment that explains the string
+   to be translated, that follows immediately after it */
+_("Here is a translatable string explained by the above.");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Double negation is often harder to understand than no negation
+at all.</p>
+</li>
+<li>
+<p>There are two schools of thought when it comes to comparison,
+especially inside a loop. Some people prefer to have the less stable
+value on the left hand side and the more stable value on the right hand
+side, e.g. if you have a loop that counts variable i down to the
+lower bound,</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (i &gt; lower_bound) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Other people prefer to have the textual order of values match the
+actual order of values in their comparison, so that they can
+mentally draw a number line from left to right and place these
+values in order, i.e.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while (lower_bound &lt; i) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  However, the more "stable" the
+stable side becomes, the more we tend to prefer the former
+(comparison with a constant, "i &gt; 0", is an extreme example).
+Just do not mix styles in the same part of the code and mimic
+existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>There are two schools of thought when it comes to splitting a long
+logical line into multiple lines.  Some people push the second and
+subsequent lines far enough to the right with tabs and align them:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+              ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to align the second and the subsequent
+lines with the column immediately inside the opening parenthesis,
+with tabs and spaces, following our "tabstop is always a multiple
+of 8" convention:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+           ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  Again, just do not mix styles in
+the same part of the code and mimic existing styles in the
+neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, some people change line before
+a binary operator, so that the result looks like a parse tree when
+you turn your head 90-degrees counterclockwise:</p>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to
+|| span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to leave the operator at the end of the
+line:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, but we tend to use the latter more, unless the
+expression gets fairly complex, in which case the former tends to
+be easier to read.  Again, just do not mix styles in the same part
+of the code and mimic existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, with everything else being
+equal, it is preferable to split after the operator at higher
+level in the parse tree.  That is, this is more preferable:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable * that_is_used_in +
+    a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>than</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable *
+    that_is_used_in + a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Some clever tricks, like using the !! operator with arithmetic
+constructs, can be extremely confusing to others.  Avoid them,
+unless there is a compelling reason to use them.</p>
+</li>
+<li>
+<p>Use the API.  No, really.  We have a strbuf (variable length
+string), several arrays with the ALLOC_GROW() macro, a
+string_list for sorted string lists, a hash map (mapping struct
+objects) named "struct decorate", amongst other things.</p>
+</li>
+<li>
+<p>When you come up with an API, document it.</p>
+</li>
+<li>
+<p>The first #include in C files, except in platform specific
+compat/ implementations, should be git-compat-util.h or another
+header file that includes it, such as cache.h or builtin.h.</p>
+</li>
+<li>
+<p>If you are planning a new command, consider writing it in shell
+or perl first, so that changes in semantics can be easily
+changed and discussed.  Many Git commands started out like
+that, and a few are still scripts.</p>
+</li>
+<li>
+<p>Avoid introducing a new dependency into Git. This means you
+usually should stay away from scripting languages not already
+used in the Git core command set (unless your command is clearly
+separate from it, such as an importer to convert random-scm-X
+repositories to Git).</p>
+</li>
+<li>
+<p>When we pass &lt;string, length&gt; pair to functions, we should try to
+pass them in that order.</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers to make the user interface
+translatable. See "Marking strings for translation" in po/README.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Perl programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most of the C guidelines above apply.</p>
+</li>
+<li>
+<p>We try to support Perl 5.8 and later ("use Perl 5.008").</p>
+</li>
+<li>
+<p>use strict and use warnings are strongly preferred.</p>
+</li>
+<li>
+<p>Don&#8217;t overuse statement modifiers unless using them makes the
+result easier to follow.</p>
+<div class="olist lowerroman">
+<ol class="lowerroman" type="i">
+<li>
+<p>do something &#8230;&#8203;
+do_this() unless (condition);</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>is more readable than:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>do something &#8230;&#8203;
+unless (condition) {
+	do_this();
+}</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>*only* when the condition is so rare that do_this() will be almost
+always called.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments inside "if ()" conditions.</p>
+</li>
+<li>
+<p>Learn and use Git.pm if you need that functionality.</p>
+</li>
+<li>
+<p>For Emacs, it&#8217;s useful to put the following in
+GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode:</p>
+<div class="literalblock">
+<div class="content">
+<pre>;; note the first part is useful for C editing, too
+((nil . ((indent-tabs-mode . t)
+              (tab-width . 8)
+              (fill-column . 80)))
+ (cperl-mode . ((cperl-indent-level . 8)
+                (cperl-extra-newline-before-brace . nil)
+                (cperl-merge-trailing-else . t))))</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Python scripts:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We follow PEP-8 (<a href="http://www.python.org/dev/peps/pep-0008/" class="bare">http://www.python.org/dev/peps/pep-0008/</a>).</p>
+</li>
+<li>
+<p>As a minimum, we aim to be compatible with Python 2.6 and 2.7.</p>
+</li>
+<li>
+<p>Where required libraries do not restrict us to Python 2, we try to
+also be compatible with Python 3.1 and later.</p>
+</li>
+<li>
+<p>When you must differentiate between Unicode literals and byte string
+literals, it is OK to use the <em>b</em> prefix.  Even though the Python
+documentation for version 2.6 does not mention this prefix, it has
+been supported since version 2.6.0.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Error Messages</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Do not end error messages with a full stop.</p>
+</li>
+<li>
+<p>Do not capitalize ("unable to open %s", not "Unable to open %s")</p>
+</li>
+<li>
+<p>Say what the error is first ("cannot open %s", not "%s: cannot open")</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Externally Visible Names</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>For configuration variable names, follow the existing convention:</p>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>The section name indicates the affected subsystem.</p>
+</li>
+<li>
+<p>The subsection name, if any, indicates which of an unbounded set
+of things to set the value for.</p>
+</li>
+<li>
+<p>The variable name describes the effect of tweaking this knob.</p>
+<div class="literalblock">
+<div class="content">
+<pre>The section and variable names that consist of multiple words are
+formed by concatenating the words without punctuations (e.g. `-`),
+and are broken using bumpyCaps in documentation as a hint to the
+reader.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>When choosing the variable namespace, do not use variable name for
+specifying possibly unbounded set of things, most notably anything
+an end user can freely come up with (e.g. branch names).  Instead,
+use subsection names or variable values, like the existing variable
+branch.&lt;name&gt;.description does.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Writing Documentation:</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Most (if not all) of the documentation pages are written in the
+AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+processed into HTML and manpages (e.g. git.html and git.1 in the
+same directory).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>The documentation liberally mixes US and UK English (en_US/UK)
+norms for spelling and grammar, which is somewhat unfortunate.
+In an ideal world, it would have been better if it consistently
+used only one and not the other, and we would have picked en_US
+(if you wish to correct the English of some of the existing
+documentation, please see the documentation-related advice in the
+Documentation/SubmittingPatches file).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Every user-visible change should be reflected in the documentation.
+The same general rule as for code applies -- imitate the existing
+conventions.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying command usage strings and synopsis sections in the manual
+pages:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Placeholders are spelled in lowercase and enclosed in angle brackets:
+  &lt;file&gt;
+  --sort=&lt;key&gt;
+  --abbrev[=&lt;n&gt;]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Possibility of multiple occurrences is indicated by three dots:
+  &lt;file&gt;...
+  (One or more of &lt;file&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Optional parts are enclosed in square brackets:
+  [&lt;extra&gt;]
+  (Zero or one &lt;extra&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>--exec-path[=&lt;path&gt;]
+(Option with an optional argument.  Note that the "=" is inside the
+brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[&lt;patch&gt;...]
+(Zero or more of &lt;patch&gt;.  Note that the dots are inside, not
+outside the brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Multiple alternatives are indicated with vertical bar:
+  [-q | --quiet]
+  [--utf8 | --no-utf8]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Parentheses are used for grouping:
+  [(&lt;rev&gt;|&lt;range&gt;)...]
+  (Any number of either &lt;rev&gt; or &lt;range&gt;.  Parens are needed to make
+  it clear that "..." pertains to both &lt;rev&gt; and &lt;range&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[(-p &lt;parent&gt;)...]
+(Any number of option -p, each with one &lt;parent&gt; argument.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>git remote set-head &lt;name&gt; (-a | -d | &lt;branch&gt;)
+(One and only one of "-a", "-d" or "&lt;branch&gt;" _must_ (no square
+brackets) be provided.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>And a somewhat more contrived example:
+  --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+  Here "=" is outside the brackets, because "--diff-filter=" is a
+  valid usage.  "*" has its own pair of brackets, because it can
+  (optionally) be specified only when one or more of the letters is
+  also provided.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A note on notation:
+ Use 'git' (all lowercase) when talking about commands i.e. something
+ the user would type into a shell and use 'Git' (uppercase first letter)
+ when talking about the version control system and its properties.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying paragraphs or option/command explanations that contain options
+or commands:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Literal examples (e.g. use of command-line options, command names, and
+configuration variables) are typeset in monospace, and if you can use
+`backticks around word phrases`, do so.
+  `--pretty=oneline`
+  `git rev-list`
+  `remote.pushdefault`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Word phrases enclosed in `backtick characters` are rendered literally
+and will not be further expanded. The use of `backticks` to achieve the
+previous rule means that literal examples should not use AsciiDoc
+escapes.
+  Correct:
+     `--pretty=oneline`
+  Incorrect:
+     `\--pretty=oneline`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If some place in the documentation needs to typeset a command usage
+example with inline substitutions, it is fine to use +monospaced and
+inline substituted text+ instead of `monospaced literal text`, and with
+the former, the part that should not get substituted must be
+quoted/escaped.</pre>
+</div>
+</div>
+</div>
+</div>
\ No newline at end of file
diff --git a/external/docs/content/docs/CodingGuidelines/2.32.0.html b/external/docs/content/docs/CodingGuidelines/2.32.0.html
new file mode 100644
index 0000000000..a87b5ffaca
--- /dev/null
+++ b/external/docs/content/docs/CodingGuidelines/2.32.0.html
@@ -0,0 +1,1025 @@
+---
+### DO NOT EDIT! Generated by script/update-docs.rb
+
+category: manual
+section: documentation
+subsection: manual
+title: Git - CodingGuidelines Documentation
+docname: CodingGuidelines
+version: 2.32.0
+aliases:
+- "/docs/CodingGuidelines/2.32.0/index.html"
+- "/docs/CodingGuidelines/2.32.1/index.html"
+- "/docs/CodingGuidelines/2.32.2/index.html"
+- "/docs/CodingGuidelines/2.32.3/index.html"
+- "/docs/CodingGuidelines/2.32.4/index.html"
+- "/docs/CodingGuidelines/2.32.5/index.html"
+- "/docs/CodingGuidelines/2.32.6/index.html"
+- "/docs/CodingGuidelines/2.32.7/index.html"
+---
+<div id="preamble">
+<div class="sectionbody">
+<div class="paragraph">
+<p>Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, a few rough rules are:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most importantly, we never say "It&#8217;s in POSIX; we&#8217;ll happily
+ignore your needs should your system not conform to it."
+We live in the real world.</p>
+</li>
+<li>
+<p>However, we often say "Let&#8217;s stay away from that construct,
+it&#8217;s not even in POSIX".</p>
+</li>
+<li>
+<p>In spite of the above two rules, we sometimes say "Although
+this is not in POSIX, it (is so convenient | makes the code
+much more readable | has other good characteristics) and
+practically all the platforms we care about support it, so
+let&#8217;s use it".</p>
+<div class="literalblock">
+<div class="content">
+<pre>Again, we live in the real world, and it is sometimes a
+judgement call, the decision based more on real world
+constraints people face than what the paper standard says.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Fixing style violations while working on a real change as a
+preparatory clean-up step is good, but otherwise avoid useless code
+churn for the sake of conforming to the style.</p>
+<div class="literalblock">
+<div class="content">
+<pre>"Once it _is_ in the tree, it's not really worth the patch noise to
+go and fix it up."
+Cf. http://lkml.iu.edu/hypermail/linux/kernel/1001.3/01069.html</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Make your code readable and sensible, and don&#8217;t try to be clever.</p>
+</div>
+<div class="paragraph">
+<p>As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the <em>local</em>
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn&#8217;t match the overall style of existing code).</p>
+</div>
+<div class="paragraph">
+<p>But if you must have a list of rules, here they are.</p>
+</div>
+<div class="paragraph">
+<p>For shell scripts specifically (not exhaustive):</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs for indentation.</p>
+</li>
+<li>
+<p>Case arms are indented at the same depth as case and esac lines,
+like this:</p>
+<div class="literalblock">
+<div class="content">
+<pre>case "$variable" in
+pattern1)
+	do this
+	;;
+pattern2)
+	do that
+	;;
+esac</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Redirection operators should be written with space before, but no
+space after them.  In other words, write <em>echo test &gt;"$file"</em>
+instead of <em>echo test&gt; $file</em> or <em>echo test &gt; $file</em>.  Note that
+even though it is not required by POSIX to double-quote the
+redirection target in a variable (as shown above), our code does so
+because some versions of bash issue a warning without the quotes.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+cat hello &gt; world &lt; universe
+echo hello &gt;$world</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+cat hello &gt;world &lt;universe
+echo hello &gt;"$world"</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer $( &#8230;&#8203; ) for command substitution; unlike ``, it
+properly nests.  It should have been the way Bourne spelled
+it from day one, but unfortunately isn&#8217;t.</p>
+</li>
+<li>
+<p>If you want to find out if a command is available on the user&#8217;s
+$PATH, you should use <em>type &lt;command&gt;</em>, instead of <em>which &lt;command&gt;</em>.
+The output of <em>which</em> is not machine parsable and its exit code
+is not reliable across platforms.</p>
+</li>
+<li>
+<p>We use POSIX compliant parameter substitutions and avoid bashisms;
+namely:</p>
+</li>
+<li>
+<p>We use ${parameter-word} and its [-=?+] siblings, and their
+colon&#8217;ed "unset or null" form.</p>
+</li>
+<li>
+<p>We use ${parameter#word} and its [#%] siblings, and their
+doubled "longest matching" form.</p>
+</li>
+<li>
+<p>No "Substring Expansion" ${parameter:offset:length}.</p>
+</li>
+<li>
+<p>No shell arrays.</p>
+</li>
+<li>
+<p>No pattern replacement ${parameter/pattern/string}.</p>
+</li>
+<li>
+<p>We use Arithmetic Expansion $&#8230;&#8203;.</p>
+</li>
+<li>
+<p>We do not use Process Substitution &lt;(list) or &gt;(list).</p>
+</li>
+<li>
+<p>Do not write control structures on a single line with semicolon.
+"then" should be on the next line for if statements, and "do"
+should be on the next line for "while" and "for".</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+if test -f hello; then
+	do this
+fi</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+if test -f hello
+then
+	do this
+fi</pre>
+</div>
+</div>
+</li>
+<li>
+<p>If a command sequence joined with &amp;&amp; or || or | spans multiple
+lines, put each command on a separate line and put &amp;&amp; and || and |
+operators at the end of each line, rather than the start. This
+means you don&#8217;t need to use \ to join lines, since the above
+operators imply the sequence isn&#8217;t finished.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+grep blob verify_pack_result \
+| awk -f print_1.awk \
+| sort &gt;actual &amp;&amp;
+...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+grep blob verify_pack_result |
+awk -f print_1.awk |
+sort &gt;actual &amp;&amp;
+...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer "test" over "[ &#8230;&#8203; ]".</p>
+</li>
+<li>
+<p>We do not write the noiseword "function" in front of shell
+functions.</p>
+</li>
+<li>
+<p>We prefer a space between the function name and the parentheses,
+and no space inside the parentheses. The opening "{" should also
+be on the same line.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+my_function(){
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+my_function () {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+[::], [==], or [..]) for portability.</p>
+</li>
+<li>
+<p>We do not use \{m,n\};</p>
+</li>
+<li>
+<p>We do not use -E;</p>
+</li>
+<li>
+<p>We do not use ? or + (which are \{0,1\} and \{1,\}
+respectively in BRE) but that goes without saying as these
+are ERE elements not BRE (note that \? and \+ are not even part
+of BRE&#8201;&#8212;&#8201;making them accessible from BRE is a GNU extension).</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers in git-sh-i18n to make the user
+interface translatable. See "Marking strings for translation" in
+po/README.</p>
+</li>
+<li>
+<p>We do not write our "test" command with "-a" and "-o" and use "&amp;&amp;"
+or "||" to concatenate multiple "test" commands instead, because
+the use of "-a/-o" is often error-prone.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" -a "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is buggy and breaks when $x is "=", but</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" &amp;&amp; test "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>does not have such a problem.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Even though "local" is not part of POSIX, we make heavy use of it
+in our test suite.  We do not use it in scripted Porcelains, and
+hopefully nobody starts using "local" before they are reimplemented
+in C ;-)</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For C programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs to indent, and interpret tabs as taking up to
+8 spaces.</p>
+</li>
+<li>
+<p>We try to keep to at most 80 characters per line.</p>
+</li>
+<li>
+<p>As a Git developer we assume you have a reasonably modern compiler
+and we recommend you to enable the DEVELOPER makefile knob to
+ensure your patch is clear of all compiler warnings we care about,
+by e.g. "echo DEVELOPER=1 &gt;&gt;config.mak".</p>
+</li>
+<li>
+<p>We try to support a wide range of C compilers to compile Git with,
+including old ones.  You should not use features from newer C
+standard, even if your compiler groks them.</p>
+<div class="literalblock">
+<div class="content">
+<pre>There are a few exceptions to this guideline:</pre>
+</div>
+</div>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>since early 2012 with e1327023ea, we have been using an enum
+definition whose last element is followed by a comma.  This, like
+an array initializer that ends with a trailing comma, can be used
+to reduce the patch noise when adding a new identifier at the end.</p>
+</li>
+<li>
+<p>since mid 2017 with cbc0f81d, we have been using designated
+initializers for struct (e.g. "struct t v = { .val = <em>a</em> };").</p>
+</li>
+<li>
+<p>since mid 2017 with 512f41cf, we have been using designated
+initializers for array (e.g. "int array[10] = { [5] = 2 }").</p>
+<div class="literalblock">
+<div class="content">
+<pre>These used to be forbidden, but we have not heard any breakage
+report, and they are assumed to be safe.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>Variables have to be declared at the beginning of the block, before
+the first statement (i.e. -Wdeclaration-after-statement).</p>
+</li>
+<li>
+<p>Declaring a variable in the for loop "for (int i = 0; i &lt; 10; i++)"
+is still not allowed in this codebase.</p>
+</li>
+<li>
+<p>NULL pointers shall be written as NULL, not as 0.</p>
+</li>
+<li>
+<p>When declaring pointers, the star sides with the variable
+name, i.e. "char <strong>string", not "char</strong> string" or
+"char * string".  This makes it easier to understand code
+like "char *string, c;".</p>
+</li>
+<li>
+<p>Use whitespace around operators and keywords, but not inside
+parentheses and not around functions. So:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      while (condition)
+func(bar + 1);</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>      while( condition )
+func (bar+1);</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Do not explicitly compare an integral value with constant 0 or <em>\0</em>,
+or a pointer value with constant NULL.  For instance, to validate that
+counted array &lt;ptr, cnt&gt; is initialized but has no elements, write:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (!ptr || cnt)
+	BUG("empty array expected");</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (ptr == NULL || cnt != 0);
+	BUG("empty array expected");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We avoid using braces unnecessarily.  I.e.</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (bla) {
+	x = 1;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is frowned upon. But there are a few exceptions:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When the statement extends over a few lines (e.g., a while loop
+with an embedded conditional, or a comment). E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (foo) {
+	if (x)
+		one();
+	else
+		two();
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	/*
+	 * This one requires some explanation,
+	 * so we're better off with braces to make
+	 * it obvious that the indentation is correct.
+	 */
+	doit();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When there are multiple arms to a conditional and some of them
+require braces, enclose even a single line block in braces for
+consistency. E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	doit();
+} else {
+	one();
+	two();
+	three();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments in the condition of an "if" statement.</p>
+</li>
+<li>
+<p>Try to make your code understandable.  You may put comments
+in, but comments invariably tend to stale out when the code
+they were describing changes.  Often splitting a function
+into two makes the intention of the code much clearer.</p>
+</li>
+<li>
+<p>Multi-line comments include their delimiters on separate lines from
+the text.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * A very long
+ * multi-line comment.
+ */</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Note however that a comment that explains a translatable string to
+translators uses a convention of starting with a magic token
+"TRANSLATORS: ", e.g.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * TRANSLATORS: here is a comment that explains the string to
+ * be translated, that follows immediately after it.
+ */
+_("Here is a translatable string explained by the above.");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Double negation is often harder to understand than no negation
+at all.</p>
+</li>
+<li>
+<p>There are two schools of thought when it comes to comparison,
+especially inside a loop. Some people prefer to have the less stable
+value on the left hand side and the more stable value on the right hand
+side, e.g. if you have a loop that counts variable i down to the
+lower bound,</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (i &gt; lower_bound) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Other people prefer to have the textual order of values match the
+actual order of values in their comparison, so that they can
+mentally draw a number line from left to right and place these
+values in order, i.e.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while (lower_bound &lt; i) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  However, the more "stable" the
+stable side becomes, the more we tend to prefer the former
+(comparison with a constant, "i &gt; 0", is an extreme example).
+Just do not mix styles in the same part of the code and mimic
+existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>There are two schools of thought when it comes to splitting a long
+logical line into multiple lines.  Some people push the second and
+subsequent lines far enough to the right with tabs and align them:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+              ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to align the second and the subsequent
+lines with the column immediately inside the opening parenthesis,
+with tabs and spaces, following our "tabstop is always a multiple
+of 8" convention:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+           ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  Again, just do not mix styles in
+the same part of the code and mimic existing styles in the
+neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, some people change line before
+a binary operator, so that the result looks like a parse tree when
+you turn your head 90-degrees counterclockwise:</p>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to
+|| span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to leave the operator at the end of the
+line:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, but we tend to use the latter more, unless the
+expression gets fairly complex, in which case the former tends to
+be easier to read.  Again, just do not mix styles in the same part
+of the code and mimic existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, with everything else being
+equal, it is preferable to split after the operator at higher
+level in the parse tree.  That is, this is more preferable:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable * that_is_used_in +
+    a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>than</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable *
+    that_is_used_in + a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Some clever tricks, like using the !! operator with arithmetic
+constructs, can be extremely confusing to others.  Avoid them,
+unless there is a compelling reason to use them.</p>
+</li>
+<li>
+<p>Use the API.  No, really.  We have a strbuf (variable length
+string), several arrays with the ALLOC_GROW() macro, a
+string_list for sorted string lists, a hash map (mapping struct
+objects) named "struct decorate", amongst other things.</p>
+</li>
+<li>
+<p>When you come up with an API, document its functions and structures
+in the header file that exposes the API to its callers. Use what is
+in "strbuf.h" as a model for the appropriate tone and level of
+detail.</p>
+</li>
+<li>
+<p>The first #include in C files, except in platform specific compat/
+implementations, must be either "git-compat-util.h", "cache.h" or
+"builtin.h".  You do not have to include more than one of these.</p>
+</li>
+<li>
+<p>A C file must directly include the header files that declare the
+functions and the types it uses, except for the functions and types
+that are made available to it by including one of the header files
+it must include by the previous rule.</p>
+</li>
+<li>
+<p>If you are planning a new command, consider writing it in shell
+or perl first, so that changes in semantics can be easily
+changed and discussed.  Many Git commands started out like
+that, and a few are still scripts.</p>
+</li>
+<li>
+<p>Avoid introducing a new dependency into Git. This means you
+usually should stay away from scripting languages not already
+used in the Git core command set (unless your command is clearly
+separate from it, such as an importer to convert random-scm-X
+repositories to Git).</p>
+</li>
+<li>
+<p>When we pass &lt;string, length&gt; pair to functions, we should try to
+pass them in that order.</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers to make the user interface
+translatable. See "Marking strings for translation" in po/README.</p>
+</li>
+<li>
+<p>Variables and functions local to a given source file should be marked
+with "static". Variables that are visible to other source files
+must be declared with "extern" in header files. However, function
+declarations should not use "extern", as that is already the default.</p>
+</li>
+<li>
+<p>You can launch gdb around your program using the shorthand GIT_DEBUGGER.
+Run <code>GIT_DEBUGGER=1 ./bin-wrappers/git foo</code> to simply use gdb as is, or
+run <code>GIT_DEBUGGER="&lt;debugger&gt; &lt;debugger-args&gt;" ./bin-wrappers/git foo</code> to
+use your own debugger and arguments. Example: <code>GIT_DEBUGGER="ddd --gdb"
+./bin-wrappers/git log</code> (See <code>wrap-for-bin.sh</code>.)</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Perl programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most of the C guidelines above apply.</p>
+</li>
+<li>
+<p>We try to support Perl 5.8 and later ("use Perl 5.008").</p>
+</li>
+<li>
+<p>use strict and use warnings are strongly preferred.</p>
+</li>
+<li>
+<p>Don&#8217;t overuse statement modifiers unless using them makes the
+result easier to follow.</p>
+<div class="olist lowerroman">
+<ol class="lowerroman" type="i">
+<li>
+<p>do something &#8230;&#8203;
+do_this() unless (condition);</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>is more readable than:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>do something &#8230;&#8203;
+unless (condition) {
+	do_this();
+}</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>*only* when the condition is so rare that do_this() will be almost
+always called.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments inside "if ()" conditions.</p>
+</li>
+<li>
+<p>Learn and use Git.pm if you need that functionality.</p>
+</li>
+<li>
+<p>For Emacs, it&#8217;s useful to put the following in
+GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode:</p>
+<div class="literalblock">
+<div class="content">
+<pre>;; note the first part is useful for C editing, too
+((nil . ((indent-tabs-mode . t)
+              (tab-width . 8)
+              (fill-column . 80)))
+ (cperl-mode . ((cperl-indent-level . 8)
+                (cperl-extra-newline-before-brace . nil)
+                (cperl-merge-trailing-else . t))))</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Python scripts:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We follow PEP-8 (<a href="http://www.python.org/dev/peps/pep-0008/" class="bare">http://www.python.org/dev/peps/pep-0008/</a>).</p>
+</li>
+<li>
+<p>As a minimum, we aim to be compatible with Python 2.7.</p>
+</li>
+<li>
+<p>Where required libraries do not restrict us to Python 2, we try to
+also be compatible with Python 3.1 and later.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Error Messages</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Do not end error messages with a full stop.</p>
+</li>
+<li>
+<p>Do not capitalize the first word, only because it is the first word
+in the message ("unable to open %s", not "Unable to open %s").  But
+"SHA-3 not supported" is fine, because the reason the first word is
+capitalized is not because it is at the beginning of the sentence,
+but because the word would be spelled in capital letters even when
+it appeared in the middle of the sentence.</p>
+</li>
+<li>
+<p>Say what the error is first ("cannot open %s", not "%s: cannot open")</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Externally Visible Names</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>For configuration variable names, follow the existing convention:</p>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>The section name indicates the affected subsystem.</p>
+</li>
+<li>
+<p>The subsection name, if any, indicates which of an unbounded set
+of things to set the value for.</p>
+</li>
+<li>
+<p>The variable name describes the effect of tweaking this knob.</p>
+<div class="literalblock">
+<div class="content">
+<pre>The section and variable names that consist of multiple words are
+formed by concatenating the words without punctuations (e.g. `-`),
+and are broken using bumpyCaps in documentation as a hint to the
+reader.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>When choosing the variable namespace, do not use variable name for
+specifying possibly unbounded set of things, most notably anything
+an end user can freely come up with (e.g. branch names).  Instead,
+use subsection names or variable values, like the existing variable
+branch.&lt;name&gt;.description does.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Writing Documentation:</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Most (if not all) of the documentation pages are written in the
+AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+processed into HTML and manpages (e.g. git.html and git.1 in the
+same directory).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>The documentation liberally mixes US and UK English (en_US/UK)
+norms for spelling and grammar, which is somewhat unfortunate.
+In an ideal world, it would have been better if it consistently
+used only one and not the other, and we would have picked en_US
+(if you wish to correct the English of some of the existing
+documentation, please see the documentation-related advice in the
+Documentation/SubmittingPatches file).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Every user-visible change should be reflected in the documentation.
+The same general rule as for code applies -- imitate the existing
+conventions.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying command usage strings and synopsis sections in the manual
+pages:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Placeholders are spelled in lowercase and enclosed in angle brackets:
+  &lt;file&gt;
+  --sort=&lt;key&gt;
+  --abbrev[=&lt;n&gt;]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If a placeholder has multiple words, they are separated by dashes:
+  &lt;new-branch-name&gt;
+  --template=&lt;template-directory&gt;</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Possibility of multiple occurrences is indicated by three dots:
+  &lt;file&gt;...
+  (One or more of &lt;file&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Optional parts are enclosed in square brackets:
+  [&lt;extra&gt;]
+  (Zero or one &lt;extra&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>--exec-path[=&lt;path&gt;]
+(Option with an optional argument.  Note that the "=" is inside the
+brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[&lt;patch&gt;...]
+(Zero or more of &lt;patch&gt;.  Note that the dots are inside, not
+outside the brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Multiple alternatives are indicated with vertical bars:
+  [-q | --quiet]
+  [--utf8 | --no-utf8]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Parentheses are used for grouping:
+  [(&lt;rev&gt; | &lt;range&gt;)...]
+  (Any number of either &lt;rev&gt; or &lt;range&gt;.  Parens are needed to make
+  it clear that "..." pertains to both &lt;rev&gt; and &lt;range&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[(-p &lt;parent&gt;)...]
+(Any number of option -p, each with one &lt;parent&gt; argument.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>git remote set-head &lt;name&gt; (-a | -d | &lt;branch&gt;)
+(One and only one of "-a", "-d" or "&lt;branch&gt;" _must_ (no square
+brackets) be provided.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>And a somewhat more contrived example:
+  --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+  Here "=" is outside the brackets, because "--diff-filter=" is a
+  valid usage.  "*" has its own pair of brackets, because it can
+  (optionally) be specified only when one or more of the letters is
+  also provided.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A note on notation:
+ Use 'git' (all lowercase) when talking about commands i.e. something
+ the user would type into a shell and use 'Git' (uppercase first letter)
+ when talking about the version control system and its properties.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying paragraphs or option/command explanations that contain options
+or commands:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Literal examples (e.g. use of command-line options, command names,
+branch names, URLs, pathnames (files and directories), configuration and
+environment variables) must be typeset in monospace (i.e. wrapped with
+backticks):
+  `--pretty=oneline`
+  `git rev-list`
+  `remote.pushDefault`
+  `http://git.example.com`
+  `.git/config`
+  `GIT_DIR`
+  `HEAD`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>An environment variable must be prefixed with "$" only when referring to its
+value and not when referring to the variable itself, in this case there is
+nothing to add except the backticks:
+  `GIT_DIR` is specified
+  `$GIT_DIR/hooks/pre-receive`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Word phrases enclosed in `backtick characters` are rendered literally
+and will not be further expanded. The use of `backticks` to achieve the
+previous rule means that literal examples should not use AsciiDoc
+escapes.
+  Correct:
+     `--pretty=oneline`
+  Incorrect:
+     `\--pretty=oneline`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If some place in the documentation needs to typeset a command usage
+example with inline substitutions, it is fine to use +monospaced and
+inline substituted text+ instead of `monospaced literal text`, and with
+the former, the part that should not get substituted must be
+quoted/escaped.</pre>
+</div>
+</div>
+</div>
+</div>
\ No newline at end of file
diff --git a/external/docs/content/docs/CodingGuidelines/2.33.0.html b/external/docs/content/docs/CodingGuidelines/2.33.0.html
new file mode 100644
index 0000000000..5c8662afe4
--- /dev/null
+++ b/external/docs/content/docs/CodingGuidelines/2.33.0.html
@@ -0,0 +1,1128 @@
+---
+### DO NOT EDIT! Generated by script/update-docs.rb
+
+category: manual
+section: documentation
+subsection: manual
+title: Git - CodingGuidelines Documentation
+docname: CodingGuidelines
+version: 2.33.0
+aliases:
+- "/docs/CodingGuidelines/2.33.0/index.html"
+- "/docs/CodingGuidelines/2.33.1/index.html"
+- "/docs/CodingGuidelines/2.33.2/index.html"
+- "/docs/CodingGuidelines/2.33.3/index.html"
+- "/docs/CodingGuidelines/2.33.4/index.html"
+- "/docs/CodingGuidelines/2.33.5/index.html"
+- "/docs/CodingGuidelines/2.33.6/index.html"
+- "/docs/CodingGuidelines/2.33.7/index.html"
+- "/docs/CodingGuidelines/2.33.8/index.html"
+- "/docs/CodingGuidelines/2.34.0/index.html"
+- "/docs/CodingGuidelines/2.34.1/index.html"
+- "/docs/CodingGuidelines/2.34.2/index.html"
+- "/docs/CodingGuidelines/2.34.3/index.html"
+- "/docs/CodingGuidelines/2.34.4/index.html"
+- "/docs/CodingGuidelines/2.34.5/index.html"
+- "/docs/CodingGuidelines/2.34.6/index.html"
+- "/docs/CodingGuidelines/2.34.7/index.html"
+- "/docs/CodingGuidelines/2.34.8/index.html"
+---
+<div id="preamble">
+<div class="sectionbody">
+<div class="paragraph">
+<p>Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, a few rough rules are:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most importantly, we never say "It&#8217;s in POSIX; we&#8217;ll happily
+ignore your needs should your system not conform to it."
+We live in the real world.</p>
+</li>
+<li>
+<p>However, we often say "Let&#8217;s stay away from that construct,
+it&#8217;s not even in POSIX".</p>
+</li>
+<li>
+<p>In spite of the above two rules, we sometimes say "Although
+this is not in POSIX, it (is so convenient | makes the code
+much more readable | has other good characteristics) and
+practically all the platforms we care about support it, so
+let&#8217;s use it".</p>
+<div class="literalblock">
+<div class="content">
+<pre>Again, we live in the real world, and it is sometimes a
+judgement call, the decision based more on real world
+constraints people face than what the paper standard says.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Fixing style violations while working on a real change as a
+preparatory clean-up step is good, but otherwise avoid useless code
+churn for the sake of conforming to the style.</p>
+<div class="literalblock">
+<div class="content">
+<pre>"Once it _is_ in the tree, it's not really worth the patch noise to
+go and fix it up."
+Cf. http://lkml.iu.edu/hypermail/linux/kernel/1001.3/01069.html</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Make your code readable and sensible, and don&#8217;t try to be clever.</p>
+</div>
+<div class="paragraph">
+<p>As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the <em>local</em>
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn&#8217;t match the overall style of existing code).</p>
+</div>
+<div class="paragraph">
+<p>But if you must have a list of rules, here they are.</p>
+</div>
+<div class="paragraph">
+<p>For shell scripts specifically (not exhaustive):</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs for indentation.</p>
+</li>
+<li>
+<p>Case arms are indented at the same depth as case and esac lines,
+like this:</p>
+<div class="literalblock">
+<div class="content">
+<pre>case "$variable" in
+pattern1)
+	do this
+	;;
+pattern2)
+	do that
+	;;
+esac</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Redirection operators should be written with space before, but no
+space after them.  In other words, write <em>echo test &gt;"$file"</em>
+instead of <em>echo test&gt; $file</em> or <em>echo test &gt; $file</em>.  Note that
+even though it is not required by POSIX to double-quote the
+redirection target in a variable (as shown above), our code does so
+because some versions of bash issue a warning without the quotes.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+cat hello &gt; world &lt; universe
+echo hello &gt;$world</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+cat hello &gt;world &lt;universe
+echo hello &gt;"$world"</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer $( &#8230;&#8203; ) for command substitution; unlike ``, it
+properly nests.  It should have been the way Bourne spelled
+it from day one, but unfortunately isn&#8217;t.</p>
+</li>
+<li>
+<p>If you want to find out if a command is available on the user&#8217;s
+$PATH, you should use <em>type &lt;command&gt;</em>, instead of <em>which &lt;command&gt;</em>.
+The output of <em>which</em> is not machine parsable and its exit code
+is not reliable across platforms.</p>
+</li>
+<li>
+<p>We use POSIX compliant parameter substitutions and avoid bashisms;
+namely:</p>
+</li>
+<li>
+<p>We use ${parameter-word} and its [-=?+] siblings, and their
+colon&#8217;ed "unset or null" form.</p>
+</li>
+<li>
+<p>We use ${parameter#word} and its [#%] siblings, and their
+doubled "longest matching" form.</p>
+</li>
+<li>
+<p>No "Substring Expansion" ${parameter:offset:length}.</p>
+</li>
+<li>
+<p>No shell arrays.</p>
+</li>
+<li>
+<p>No pattern replacement ${parameter/pattern/string}.</p>
+</li>
+<li>
+<p>We use Arithmetic Expansion $&#8230;&#8203;.</p>
+</li>
+<li>
+<p>We do not use Process Substitution &lt;(list) or &gt;(list).</p>
+</li>
+<li>
+<p>Do not write control structures on a single line with semicolon.
+"then" should be on the next line for if statements, and "do"
+should be on the next line for "while" and "for".</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+if test -f hello; then
+	do this
+fi</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+if test -f hello
+then
+	do this
+fi</pre>
+</div>
+</div>
+</li>
+<li>
+<p>If a command sequence joined with &amp;&amp; or || or | spans multiple
+lines, put each command on a separate line and put &amp;&amp; and || and |
+operators at the end of each line, rather than the start. This
+means you don&#8217;t need to use \ to join lines, since the above
+operators imply the sequence isn&#8217;t finished.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+grep blob verify_pack_result \
+| awk -f print_1.awk \
+| sort &gt;actual &amp;&amp;
+...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+grep blob verify_pack_result |
+awk -f print_1.awk |
+sort &gt;actual &amp;&amp;
+...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer "test" over "[ &#8230;&#8203; ]".</p>
+</li>
+<li>
+<p>We do not write the noiseword "function" in front of shell
+functions.</p>
+</li>
+<li>
+<p>We prefer a space between the function name and the parentheses,
+and no space inside the parentheses. The opening "{" should also
+be on the same line.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+my_function(){
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+my_function () {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+[::], [==], or [..]) for portability.</p>
+</li>
+<li>
+<p>We do not use \{m,n\};</p>
+</li>
+<li>
+<p>We do not use -E;</p>
+</li>
+<li>
+<p>We do not use ? or + (which are \{0,1\} and \{1,\}
+respectively in BRE) but that goes without saying as these
+are ERE elements not BRE (note that \? and \+ are not even part
+of BRE&#8201;&#8212;&#8201;making them accessible from BRE is a GNU extension).</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers in git-sh-i18n to make the user
+interface translatable. See "Marking strings for translation" in
+po/README.</p>
+</li>
+<li>
+<p>We do not write our "test" command with "-a" and "-o" and use "&amp;&amp;"
+or "||" to concatenate multiple "test" commands instead, because
+the use of "-a/-o" is often error-prone.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" -a "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is buggy and breaks when $x is "=", but</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" &amp;&amp; test "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>does not have such a problem.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Even though "local" is not part of POSIX, we make heavy use of it
+in our test suite.  We do not use it in scripted Porcelains, and
+hopefully nobody starts using "local" before they are reimplemented
+in C ;-)</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For C programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs to indent, and interpret tabs as taking up to
+8 spaces.</p>
+</li>
+<li>
+<p>We try to keep to at most 80 characters per line.</p>
+</li>
+<li>
+<p>As a Git developer we assume you have a reasonably modern compiler
+and we recommend you to enable the DEVELOPER makefile knob to
+ensure your patch is clear of all compiler warnings we care about,
+by e.g. "echo DEVELOPER=1 &gt;&gt;config.mak".</p>
+</li>
+<li>
+<p>We try to support a wide range of C compilers to compile Git with,
+including old ones.  You should not use features from newer C
+standard, even if your compiler groks them.</p>
+<div class="literalblock">
+<div class="content">
+<pre>There are a few exceptions to this guideline:</pre>
+</div>
+</div>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>since early 2012 with e1327023ea, we have been using an enum
+definition whose last element is followed by a comma.  This, like
+an array initializer that ends with a trailing comma, can be used
+to reduce the patch noise when adding a new identifier at the end.</p>
+</li>
+<li>
+<p>since mid 2017 with cbc0f81d, we have been using designated
+initializers for struct (e.g. "struct t v = { .val = <em>a</em> };").</p>
+</li>
+<li>
+<p>since mid 2017 with 512f41cf, we have been using designated
+initializers for array (e.g. "int array[10] = { [5] = 2 }").</p>
+<div class="literalblock">
+<div class="content">
+<pre>These used to be forbidden, but we have not heard any breakage
+report, and they are assumed to be safe.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>Variables have to be declared at the beginning of the block, before
+the first statement (i.e. -Wdeclaration-after-statement).</p>
+</li>
+<li>
+<p>Declaring a variable in the for loop "for (int i = 0; i &lt; 10; i++)"
+is still not allowed in this codebase.</p>
+</li>
+<li>
+<p>NULL pointers shall be written as NULL, not as 0.</p>
+</li>
+<li>
+<p>When declaring pointers, the star sides with the variable
+name, i.e. "char <strong>string", not "char</strong> string" or
+"char * string".  This makes it easier to understand code
+like "char *string, c;".</p>
+</li>
+<li>
+<p>Use whitespace around operators and keywords, but not inside
+parentheses and not around functions. So:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      while (condition)
+func(bar + 1);</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>      while( condition )
+func (bar+1);</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Do not explicitly compare an integral value with constant 0 or <em>\0</em>,
+or a pointer value with constant NULL.  For instance, to validate that
+counted array &lt;ptr, cnt&gt; is initialized but has no elements, write:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (!ptr || cnt)
+	BUG("empty array expected");</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (ptr == NULL || cnt != 0);
+	BUG("empty array expected");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We avoid using braces unnecessarily.  I.e.</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (bla) {
+	x = 1;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is frowned upon. But there are a few exceptions:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When the statement extends over a few lines (e.g., a while loop
+with an embedded conditional, or a comment). E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (foo) {
+	if (x)
+		one();
+	else
+		two();
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	/*
+	 * This one requires some explanation,
+	 * so we're better off with braces to make
+	 * it obvious that the indentation is correct.
+	 */
+	doit();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When there are multiple arms to a conditional and some of them
+require braces, enclose even a single line block in braces for
+consistency. E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	doit();
+} else {
+	one();
+	two();
+	three();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments in the condition of an "if" statement.</p>
+</li>
+<li>
+<p>Try to make your code understandable.  You may put comments
+in, but comments invariably tend to stale out when the code
+they were describing changes.  Often splitting a function
+into two makes the intention of the code much clearer.</p>
+</li>
+<li>
+<p>Multi-line comments include their delimiters on separate lines from
+the text.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * A very long
+ * multi-line comment.
+ */</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Note however that a comment that explains a translatable string to
+translators uses a convention of starting with a magic token
+"TRANSLATORS: ", e.g.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * TRANSLATORS: here is a comment that explains the string to
+ * be translated, that follows immediately after it.
+ */
+_("Here is a translatable string explained by the above.");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Double negation is often harder to understand than no negation
+at all.</p>
+</li>
+<li>
+<p>There are two schools of thought when it comes to comparison,
+especially inside a loop. Some people prefer to have the less stable
+value on the left hand side and the more stable value on the right hand
+side, e.g. if you have a loop that counts variable i down to the
+lower bound,</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (i &gt; lower_bound) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Other people prefer to have the textual order of values match the
+actual order of values in their comparison, so that they can
+mentally draw a number line from left to right and place these
+values in order, i.e.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while (lower_bound &lt; i) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  However, the more "stable" the
+stable side becomes, the more we tend to prefer the former
+(comparison with a constant, "i &gt; 0", is an extreme example).
+Just do not mix styles in the same part of the code and mimic
+existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>There are two schools of thought when it comes to splitting a long
+logical line into multiple lines.  Some people push the second and
+subsequent lines far enough to the right with tabs and align them:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+              ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to align the second and the subsequent
+lines with the column immediately inside the opening parenthesis,
+with tabs and spaces, following our "tabstop is always a multiple
+of 8" convention:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+           ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  Again, just do not mix styles in
+the same part of the code and mimic existing styles in the
+neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, some people change line before
+a binary operator, so that the result looks like a parse tree when
+you turn your head 90-degrees counterclockwise:</p>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to
+|| span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to leave the operator at the end of the
+line:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, but we tend to use the latter more, unless the
+expression gets fairly complex, in which case the former tends to
+be easier to read.  Again, just do not mix styles in the same part
+of the code and mimic existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, with everything else being
+equal, it is preferable to split after the operator at higher
+level in the parse tree.  That is, this is more preferable:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable * that_is_used_in +
+    a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>than</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable *
+    that_is_used_in + a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Some clever tricks, like using the !! operator with arithmetic
+constructs, can be extremely confusing to others.  Avoid them,
+unless there is a compelling reason to use them.</p>
+</li>
+<li>
+<p>Use the API.  No, really.  We have a strbuf (variable length
+string), several arrays with the ALLOC_GROW() macro, a
+string_list for sorted string lists, a hash map (mapping struct
+objects) named "struct decorate", amongst other things.</p>
+</li>
+<li>
+<p>When you come up with an API, document its functions and structures
+in the header file that exposes the API to its callers. Use what is
+in "strbuf.h" as a model for the appropriate tone and level of
+detail.</p>
+</li>
+<li>
+<p>The first #include in C files, except in platform specific compat/
+implementations, must be either "git-compat-util.h", "cache.h" or
+"builtin.h".  You do not have to include more than one of these.</p>
+</li>
+<li>
+<p>A C file must directly include the header files that declare the
+functions and the types it uses, except for the functions and types
+that are made available to it by including one of the header files
+it must include by the previous rule.</p>
+</li>
+<li>
+<p>If you are planning a new command, consider writing it in shell
+or perl first, so that changes in semantics can be easily
+changed and discussed.  Many Git commands started out like
+that, and a few are still scripts.</p>
+</li>
+<li>
+<p>Avoid introducing a new dependency into Git. This means you
+usually should stay away from scripting languages not already
+used in the Git core command set (unless your command is clearly
+separate from it, such as an importer to convert random-scm-X
+repositories to Git).</p>
+</li>
+<li>
+<p>When we pass &lt;string, length&gt; pair to functions, we should try to
+pass them in that order.</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers to make the user interface
+translatable. See "Marking strings for translation" in po/README.</p>
+</li>
+<li>
+<p>Variables and functions local to a given source file should be marked
+with "static". Variables that are visible to other source files
+must be declared with "extern" in header files. However, function
+declarations should not use "extern", as that is already the default.</p>
+</li>
+<li>
+<p>You can launch gdb around your program using the shorthand GIT_DEBUGGER.
+Run <code>GIT_DEBUGGER=1 ./bin-wrappers/git foo</code> to simply use gdb as is, or
+run <code>GIT_DEBUGGER="&lt;debugger&gt; &lt;debugger-args&gt;" ./bin-wrappers/git foo</code> to
+use your own debugger and arguments. Example: <code>GIT_DEBUGGER="ddd --gdb"
+./bin-wrappers/git log</code> (See <code>wrap-for-bin.sh</code>.)</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Perl programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most of the C guidelines above apply.</p>
+</li>
+<li>
+<p>We try to support Perl 5.8 and later ("use Perl 5.008").</p>
+</li>
+<li>
+<p>use strict and use warnings are strongly preferred.</p>
+</li>
+<li>
+<p>Don&#8217;t overuse statement modifiers unless using them makes the
+result easier to follow.</p>
+<div class="olist lowerroman">
+<ol class="lowerroman" type="i">
+<li>
+<p>do something &#8230;&#8203;
+do_this() unless (condition);</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>is more readable than:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>do something &#8230;&#8203;
+unless (condition) {
+	do_this();
+}</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>*only* when the condition is so rare that do_this() will be almost
+always called.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments inside "if ()" conditions.</p>
+</li>
+<li>
+<p>Learn and use Git.pm if you need that functionality.</p>
+</li>
+<li>
+<p>For Emacs, it&#8217;s useful to put the following in
+GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode:</p>
+<div class="literalblock">
+<div class="content">
+<pre>;; note the first part is useful for C editing, too
+((nil . ((indent-tabs-mode . t)
+              (tab-width . 8)
+              (fill-column . 80)))
+ (cperl-mode . ((cperl-indent-level . 8)
+                (cperl-extra-newline-before-brace . nil)
+                (cperl-merge-trailing-else . t))))</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Python scripts:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We follow PEP-8 (<a href="http://www.python.org/dev/peps/pep-0008/" class="bare">http://www.python.org/dev/peps/pep-0008/</a>).</p>
+</li>
+<li>
+<p>As a minimum, we aim to be compatible with Python 2.7.</p>
+</li>
+<li>
+<p>Where required libraries do not restrict us to Python 2, we try to
+also be compatible with Python 3.1 and later.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Error Messages</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Do not end error messages with a full stop.</p>
+</li>
+<li>
+<p>Do not capitalize the first word, only because it is the first word
+in the message ("unable to open %s", not "Unable to open %s").  But
+"SHA-3 not supported" is fine, because the reason the first word is
+capitalized is not because it is at the beginning of the sentence,
+but because the word would be spelled in capital letters even when
+it appeared in the middle of the sentence.</p>
+</li>
+<li>
+<p>Say what the error is first ("cannot open %s", not "%s: cannot open")</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Externally Visible Names</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>For configuration variable names, follow the existing convention:</p>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>The section name indicates the affected subsystem.</p>
+</li>
+<li>
+<p>The subsection name, if any, indicates which of an unbounded set
+of things to set the value for.</p>
+</li>
+<li>
+<p>The variable name describes the effect of tweaking this knob.</p>
+<div class="literalblock">
+<div class="content">
+<pre>The section and variable names that consist of multiple words are
+formed by concatenating the words without punctuations (e.g. `-`),
+and are broken using bumpyCaps in documentation as a hint to the
+reader.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>When choosing the variable namespace, do not use variable name for
+specifying possibly unbounded set of things, most notably anything
+an end user can freely come up with (e.g. branch names).  Instead,
+use subsection names or variable values, like the existing variable
+branch.&lt;name&gt;.description does.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Writing Documentation:</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Most (if not all) of the documentation pages are written in the
+AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+processed into HTML and manpages (e.g. git.html and git.1 in the
+same directory).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>The documentation liberally mixes US and UK English (en_US/UK)
+norms for spelling and grammar, which is somewhat unfortunate.
+In an ideal world, it would have been better if it consistently
+used only one and not the other, and we would have picked en_US
+(if you wish to correct the English of some of the existing
+documentation, please see the documentation-related advice in the
+Documentation/SubmittingPatches file).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>In order to ensure the documentation is inclusive, avoid assuming
+that an unspecified example person is male or female, and think
+twice before using "he", "him", "she", or "her".  Here are some
+tips to avoid use of gendered pronouns:</pre>
+</div>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Prefer succinctness and matter-of-factly describing functionality
+in the abstract.  E.g.</p>
+<div class="dlist">
+<dl>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short"> <a class="anchor" href="#Documentation/CodingGuidelines---short"></a>--short </dt>
+<dd>
+<p>Emit output in the short-format.</p>
+<div class="literalblock">
+<div class="content">
+<pre>and avoid something like these overly verbose alternatives:</pre>
+</div>
+</div>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short-1"> <a class="anchor" href="#Documentation/CodingGuidelines---short-1"></a>--short </dt>
+<dd>
+<p>Use this to emit output in the short-format.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short-1-1"> <a class="anchor" href="#Documentation/CodingGuidelines---short-1-1"></a>--short </dt>
+<dd>
+<p>You can use this to get output in the short-format.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short-1-1-1"> <a class="anchor" href="#Documentation/CodingGuidelines---short-1-1-1"></a>--short </dt>
+<dd>
+<p>A user who prefers shorter output could&#8230;&#8203;.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short-1-1-1-1"> <a class="anchor" href="#Documentation/CodingGuidelines---short-1-1-1-1"></a>--short </dt>
+<dd>
+<p>Should a person and/or program want shorter output, he
+she/they/it can&#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>This practice often eliminates the need to involve human actors in
+your description, but it is a good practice regardless of the
+avoidance of gendered pronouns.</pre>
+</div>
+</div>
+</dd>
+</dl>
+</div>
+</li>
+<li>
+<p>When it becomes awkward to stick to this style, prefer "you" when
+addressing the the hypothetical user, and possibly "we" when
+discussing how the program might react to the user.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>You can use this option instead of --xyz, but we might remove
+support for it in future versions.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while keeping in mind that you can probably be less verbose, e.g.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Use this instead of --xyz. This option might be removed in future
+versions.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>If you still need to refer to an example person that is
+third-person singular, you may resort to "singular they" to avoid
+"he/she/him/her", e.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>A contributor asks their upstream to pull from them.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Note that this sounds ungrammatical and unnatural to those who
+learned that "they" is only used for third-person plural, e.g.
+those who learn English as a second language in some parts of the
+world.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Every user-visible change should be reflected in the documentation.
+The same general rule as for code applies -- imitate the existing
+conventions.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying command usage strings and synopsis sections in the manual
+pages:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Placeholders are spelled in lowercase and enclosed in angle brackets:
+  &lt;file&gt;
+  --sort=&lt;key&gt;
+  --abbrev[=&lt;n&gt;]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If a placeholder has multiple words, they are separated by dashes:
+  &lt;new-branch-name&gt;
+  --template=&lt;template-directory&gt;</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Possibility of multiple occurrences is indicated by three dots:
+  &lt;file&gt;...
+  (One or more of &lt;file&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Optional parts are enclosed in square brackets:
+  [&lt;extra&gt;]
+  (Zero or one &lt;extra&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>--exec-path[=&lt;path&gt;]
+(Option with an optional argument.  Note that the "=" is inside the
+brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[&lt;patch&gt;...]
+(Zero or more of &lt;patch&gt;.  Note that the dots are inside, not
+outside the brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Multiple alternatives are indicated with vertical bars:
+  [-q | --quiet]
+  [--utf8 | --no-utf8]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Parentheses are used for grouping:
+  [(&lt;rev&gt; | &lt;range&gt;)...]
+  (Any number of either &lt;rev&gt; or &lt;range&gt;.  Parens are needed to make
+  it clear that "..." pertains to both &lt;rev&gt; and &lt;range&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[(-p &lt;parent&gt;)...]
+(Any number of option -p, each with one &lt;parent&gt; argument.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>git remote set-head &lt;name&gt; (-a | -d | &lt;branch&gt;)
+(One and only one of "-a", "-d" or "&lt;branch&gt;" _must_ (no square
+brackets) be provided.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>And a somewhat more contrived example:
+  --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+  Here "=" is outside the brackets, because "--diff-filter=" is a
+  valid usage.  "*" has its own pair of brackets, because it can
+  (optionally) be specified only when one or more of the letters is
+  also provided.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A note on notation:
+ Use 'git' (all lowercase) when talking about commands i.e. something
+ the user would type into a shell and use 'Git' (uppercase first letter)
+ when talking about the version control system and its properties.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying paragraphs or option/command explanations that contain options
+or commands:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Literal examples (e.g. use of command-line options, command names,
+branch names, URLs, pathnames (files and directories), configuration and
+environment variables) must be typeset in monospace (i.e. wrapped with
+backticks):
+  `--pretty=oneline`
+  `git rev-list`
+  `remote.pushDefault`
+  `http://git.example.com`
+  `.git/config`
+  `GIT_DIR`
+  `HEAD`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>An environment variable must be prefixed with "$" only when referring to its
+value and not when referring to the variable itself, in this case there is
+nothing to add except the backticks:
+  `GIT_DIR` is specified
+  `$GIT_DIR/hooks/pre-receive`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Word phrases enclosed in `backtick characters` are rendered literally
+and will not be further expanded. The use of `backticks` to achieve the
+previous rule means that literal examples should not use AsciiDoc
+escapes.
+  Correct:
+     `--pretty=oneline`
+  Incorrect:
+     `\--pretty=oneline`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If some place in the documentation needs to typeset a command usage
+example with inline substitutions, it is fine to use +monospaced and
+inline substituted text+ instead of `monospaced literal text`, and with
+the former, the part that should not get substituted must be
+quoted/escaped.</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+</div>
+</div>
\ No newline at end of file
diff --git a/external/docs/content/docs/CodingGuidelines/2.35.0.html b/external/docs/content/docs/CodingGuidelines/2.35.0.html
new file mode 100644
index 0000000000..ad86a2acc0
--- /dev/null
+++ b/external/docs/content/docs/CodingGuidelines/2.35.0.html
@@ -0,0 +1,1157 @@
+---
+### DO NOT EDIT! Generated by script/update-docs.rb
+
+category: manual
+section: documentation
+subsection: manual
+title: Git - CodingGuidelines Documentation
+docname: CodingGuidelines
+version: 2.35.0
+aliases:
+- "/docs/CodingGuidelines/2.35.0/index.html"
+- "/docs/CodingGuidelines/2.35.1/index.html"
+- "/docs/CodingGuidelines/2.35.2/index.html"
+- "/docs/CodingGuidelines/2.35.3/index.html"
+- "/docs/CodingGuidelines/2.35.4/index.html"
+- "/docs/CodingGuidelines/2.35.5/index.html"
+- "/docs/CodingGuidelines/2.35.6/index.html"
+- "/docs/CodingGuidelines/2.35.7/index.html"
+- "/docs/CodingGuidelines/2.35.8/index.html"
+---
+<div id="preamble">
+<div class="sectionbody">
+<div class="paragraph">
+<p>Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, a few rough rules are:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most importantly, we never say "It&#8217;s in POSIX; we&#8217;ll happily
+ignore your needs should your system not conform to it."
+We live in the real world.</p>
+</li>
+<li>
+<p>However, we often say "Let&#8217;s stay away from that construct,
+it&#8217;s not even in POSIX".</p>
+</li>
+<li>
+<p>In spite of the above two rules, we sometimes say "Although
+this is not in POSIX, it (is so convenient | makes the code
+much more readable | has other good characteristics) and
+practically all the platforms we care about support it, so
+let&#8217;s use it".</p>
+<div class="literalblock">
+<div class="content">
+<pre>Again, we live in the real world, and it is sometimes a
+judgement call, the decision based more on real world
+constraints people face than what the paper standard says.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Fixing style violations while working on a real change as a
+preparatory clean-up step is good, but otherwise avoid useless code
+churn for the sake of conforming to the style.</p>
+<div class="literalblock">
+<div class="content">
+<pre>"Once it _is_ in the tree, it's not really worth the patch noise to
+go and fix it up."
+Cf. http://lkml.iu.edu/hypermail/linux/kernel/1001.3/01069.html</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Make your code readable and sensible, and don&#8217;t try to be clever.</p>
+</div>
+<div class="paragraph">
+<p>As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the <em>local</em>
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn&#8217;t match the overall style of existing code).</p>
+</div>
+<div class="paragraph">
+<p>But if you must have a list of rules, here they are.</p>
+</div>
+<div class="paragraph">
+<p>For shell scripts specifically (not exhaustive):</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs for indentation.</p>
+</li>
+<li>
+<p>Case arms are indented at the same depth as case and esac lines,
+like this:</p>
+<div class="literalblock">
+<div class="content">
+<pre>case "$variable" in
+pattern1)
+	do this
+	;;
+pattern2)
+	do that
+	;;
+esac</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Redirection operators should be written with space before, but no
+space after them.  In other words, write <em>echo test &gt;"$file"</em>
+instead of <em>echo test&gt; $file</em> or <em>echo test &gt; $file</em>.  Note that
+even though it is not required by POSIX to double-quote the
+redirection target in a variable (as shown above), our code does so
+because some versions of bash issue a warning without the quotes.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+cat hello &gt; world &lt; universe
+echo hello &gt;$world</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+cat hello &gt;world &lt;universe
+echo hello &gt;"$world"</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer $( &#8230;&#8203; ) for command substitution; unlike ``, it
+properly nests.  It should have been the way Bourne spelled
+it from day one, but unfortunately isn&#8217;t.</p>
+</li>
+<li>
+<p>If you want to find out if a command is available on the user&#8217;s
+$PATH, you should use <em>type &lt;command&gt;</em>, instead of <em>which &lt;command&gt;</em>.
+The output of <em>which</em> is not machine parsable and its exit code
+is not reliable across platforms.</p>
+</li>
+<li>
+<p>We use POSIX compliant parameter substitutions and avoid bashisms;
+namely:</p>
+</li>
+<li>
+<p>We use ${parameter-word} and its [-=?+] siblings, and their
+colon&#8217;ed "unset or null" form.</p>
+</li>
+<li>
+<p>We use ${parameter#word} and its [#%] siblings, and their
+doubled "longest matching" form.</p>
+</li>
+<li>
+<p>No "Substring Expansion" ${parameter:offset:length}.</p>
+</li>
+<li>
+<p>No shell arrays.</p>
+</li>
+<li>
+<p>No pattern replacement ${parameter/pattern/string}.</p>
+</li>
+<li>
+<p>We use Arithmetic Expansion $&#8230;&#8203;.</p>
+</li>
+<li>
+<p>We do not use Process Substitution &lt;(list) or &gt;(list).</p>
+</li>
+<li>
+<p>Do not write control structures on a single line with semicolon.
+"then" should be on the next line for if statements, and "do"
+should be on the next line for "while" and "for".</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+if test -f hello; then
+	do this
+fi</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+if test -f hello
+then
+	do this
+fi</pre>
+</div>
+</div>
+</li>
+<li>
+<p>If a command sequence joined with &amp;&amp; or || or | spans multiple
+lines, put each command on a separate line and put &amp;&amp; and || and |
+operators at the end of each line, rather than the start. This
+means you don&#8217;t need to use \ to join lines, since the above
+operators imply the sequence isn&#8217;t finished.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+grep blob verify_pack_result \
+| awk -f print_1.awk \
+| sort &gt;actual &amp;&amp;
+...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+grep blob verify_pack_result |
+awk -f print_1.awk |
+sort &gt;actual &amp;&amp;
+...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer "test" over "[ &#8230;&#8203; ]".</p>
+</li>
+<li>
+<p>We do not write the noiseword "function" in front of shell
+functions.</p>
+</li>
+<li>
+<p>We prefer a space between the function name and the parentheses,
+and no space inside the parentheses. The opening "{" should also
+be on the same line.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+my_function(){
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+my_function () {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+[::], [==], or [..]) for portability.</p>
+</li>
+<li>
+<p>We do not use \{m,n\};</p>
+</li>
+<li>
+<p>We do not use -E;</p>
+</li>
+<li>
+<p>We do not use ? or + (which are \{0,1\} and \{1,\}
+respectively in BRE) but that goes without saying as these
+are ERE elements not BRE (note that \? and \+ are not even part
+of BRE&#8201;&#8212;&#8201;making them accessible from BRE is a GNU extension).</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers in git-sh-i18n to make the user
+interface translatable. See "Marking strings for translation" in
+po/README.</p>
+</li>
+<li>
+<p>We do not write our "test" command with "-a" and "-o" and use "&amp;&amp;"
+or "||" to concatenate multiple "test" commands instead, because
+the use of "-a/-o" is often error-prone.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" -a "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is buggy and breaks when $x is "=", but</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" &amp;&amp; test "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>does not have such a problem.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Even though "local" is not part of POSIX, we make heavy use of it
+in our test suite.  We do not use it in scripted Porcelains, and
+hopefully nobody starts using "local" before they are reimplemented
+in C ;-)</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For C programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs to indent, and interpret tabs as taking up to
+8 spaces.</p>
+</li>
+<li>
+<p>We try to keep to at most 80 characters per line.</p>
+</li>
+<li>
+<p>As a Git developer we assume you have a reasonably modern compiler
+and we recommend you to enable the DEVELOPER makefile knob to
+ensure your patch is clear of all compiler warnings we care about,
+by e.g. "echo DEVELOPER=1 &gt;&gt;config.mak".</p>
+</li>
+<li>
+<p>We try to support a wide range of C compilers to compile Git with,
+including old ones.  You should not use features from newer C
+standard, even if your compiler groks them.</p>
+<div class="literalblock">
+<div class="content">
+<pre>There are a few exceptions to this guideline:</pre>
+</div>
+</div>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>since early 2012 with e1327023ea, we have been using an enum
+definition whose last element is followed by a comma.  This, like
+an array initializer that ends with a trailing comma, can be used
+to reduce the patch noise when adding a new identifier at the end.</p>
+</li>
+<li>
+<p>since mid 2017 with cbc0f81d, we have been using designated
+initializers for struct (e.g. "struct t v = { .val = <em>a</em> };").</p>
+</li>
+<li>
+<p>since mid 2017 with 512f41cf, we have been using designated
+initializers for array (e.g. "int array[10] = { [5] = 2 }").</p>
+<div class="literalblock">
+<div class="content">
+<pre>These used to be forbidden, but we have not heard any breakage
+report, and they are assumed to be safe.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>Variables have to be declared at the beginning of the block, before
+the first statement (i.e. -Wdeclaration-after-statement).</p>
+</li>
+<li>
+<p>Declaring a variable in the for loop "for (int i = 0; i &lt; 10; i++)"
+is still not allowed in this codebase.</p>
+</li>
+<li>
+<p>NULL pointers shall be written as NULL, not as 0.</p>
+</li>
+<li>
+<p>When declaring pointers, the star sides with the variable
+name, i.e. "char <strong>string", not "char</strong> string" or
+"char * string".  This makes it easier to understand code
+like "char *string, c;".</p>
+</li>
+<li>
+<p>Use whitespace around operators and keywords, but not inside
+parentheses and not around functions. So:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      while (condition)
+func(bar + 1);</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>      while( condition )
+func (bar+1);</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Do not explicitly compare an integral value with constant 0 or <em>\0</em>,
+or a pointer value with constant NULL.  For instance, to validate that
+counted array &lt;ptr, cnt&gt; is initialized but has no elements, write:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (!ptr || cnt)
+	BUG("empty array expected");</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (ptr == NULL || cnt != 0);
+	BUG("empty array expected");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We avoid using braces unnecessarily.  I.e.</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (bla) {
+	x = 1;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is frowned upon. But there are a few exceptions:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When the statement extends over a few lines (e.g., a while loop
+with an embedded conditional, or a comment). E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (foo) {
+	if (x)
+		one();
+	else
+		two();
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	/*
+	 * This one requires some explanation,
+	 * so we're better off with braces to make
+	 * it obvious that the indentation is correct.
+	 */
+	doit();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When there are multiple arms to a conditional and some of them
+require braces, enclose even a single line block in braces for
+consistency. E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	doit();
+} else {
+	one();
+	two();
+	three();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments in the condition of an "if" statement.</p>
+</li>
+<li>
+<p>Try to make your code understandable.  You may put comments
+in, but comments invariably tend to stale out when the code
+they were describing changes.  Often splitting a function
+into two makes the intention of the code much clearer.</p>
+</li>
+<li>
+<p>Multi-line comments include their delimiters on separate lines from
+the text.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * A very long
+ * multi-line comment.
+ */</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Note however that a comment that explains a translatable string to
+translators uses a convention of starting with a magic token
+"TRANSLATORS: ", e.g.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * TRANSLATORS: here is a comment that explains the string to
+ * be translated, that follows immediately after it.
+ */
+_("Here is a translatable string explained by the above.");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Double negation is often harder to understand than no negation
+at all.</p>
+</li>
+<li>
+<p>There are two schools of thought when it comes to comparison,
+especially inside a loop. Some people prefer to have the less stable
+value on the left hand side and the more stable value on the right hand
+side, e.g. if you have a loop that counts variable i down to the
+lower bound,</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (i &gt; lower_bound) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Other people prefer to have the textual order of values match the
+actual order of values in their comparison, so that they can
+mentally draw a number line from left to right and place these
+values in order, i.e.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while (lower_bound &lt; i) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  However, the more "stable" the
+stable side becomes, the more we tend to prefer the former
+(comparison with a constant, "i &gt; 0", is an extreme example).
+Just do not mix styles in the same part of the code and mimic
+existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>There are two schools of thought when it comes to splitting a long
+logical line into multiple lines.  Some people push the second and
+subsequent lines far enough to the right with tabs and align them:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+              ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to align the second and the subsequent
+lines with the column immediately inside the opening parenthesis,
+with tabs and spaces, following our "tabstop is always a multiple
+of 8" convention:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+           ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  Again, just do not mix styles in
+the same part of the code and mimic existing styles in the
+neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, some people change line before
+a binary operator, so that the result looks like a parse tree when
+you turn your head 90-degrees counterclockwise:</p>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to
+|| span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to leave the operator at the end of the
+line:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, but we tend to use the latter more, unless the
+expression gets fairly complex, in which case the former tends to
+be easier to read.  Again, just do not mix styles in the same part
+of the code and mimic existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, with everything else being
+equal, it is preferable to split after the operator at higher
+level in the parse tree.  That is, this is more preferable:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable * that_is_used_in +
+    a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>than</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable *
+    that_is_used_in + a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Some clever tricks, like using the !! operator with arithmetic
+constructs, can be extremely confusing to others.  Avoid them,
+unless there is a compelling reason to use them.</p>
+</li>
+<li>
+<p>Use the API.  No, really.  We have a strbuf (variable length
+string), several arrays with the ALLOC_GROW() macro, a
+string_list for sorted string lists, a hash map (mapping struct
+objects) named "struct decorate", amongst other things.</p>
+</li>
+<li>
+<p>When you come up with an API, document its functions and structures
+in the header file that exposes the API to its callers. Use what is
+in "strbuf.h" as a model for the appropriate tone and level of
+detail.</p>
+</li>
+<li>
+<p>The first #include in C files, except in platform specific compat/
+implementations, must be either "git-compat-util.h", "cache.h" or
+"builtin.h".  You do not have to include more than one of these.</p>
+</li>
+<li>
+<p>A C file must directly include the header files that declare the
+functions and the types it uses, except for the functions and types
+that are made available to it by including one of the header files
+it must include by the previous rule.</p>
+</li>
+<li>
+<p>If you are planning a new command, consider writing it in shell
+or perl first, so that changes in semantics can be easily
+changed and discussed.  Many Git commands started out like
+that, and a few are still scripts.</p>
+</li>
+<li>
+<p>Avoid introducing a new dependency into Git. This means you
+usually should stay away from scripting languages not already
+used in the Git core command set (unless your command is clearly
+separate from it, such as an importer to convert random-scm-X
+repositories to Git).</p>
+</li>
+<li>
+<p>When we pass &lt;string, length&gt; pair to functions, we should try to
+pass them in that order.</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers to make the user interface
+translatable. See "Marking strings for translation" in po/README.</p>
+</li>
+<li>
+<p>Variables and functions local to a given source file should be marked
+with "static". Variables that are visible to other source files
+must be declared with "extern" in header files. However, function
+declarations should not use "extern", as that is already the default.</p>
+</li>
+<li>
+<p>You can launch gdb around your program using the shorthand GIT_DEBUGGER.
+Run <code>GIT_DEBUGGER=1 ./bin-wrappers/git foo</code> to simply use gdb as is, or
+run <code>GIT_DEBUGGER="&lt;debugger&gt; &lt;debugger-args&gt;" ./bin-wrappers/git foo</code> to
+use your own debugger and arguments. Example: <code>GIT_DEBUGGER="ddd --gdb"
+./bin-wrappers/git log</code> (See <code>wrap-for-bin.sh</code>.)</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Perl programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most of the C guidelines above apply.</p>
+</li>
+<li>
+<p>We try to support Perl 5.8 and later ("use Perl 5.008").</p>
+</li>
+<li>
+<p>use strict and use warnings are strongly preferred.</p>
+</li>
+<li>
+<p>Don&#8217;t overuse statement modifiers unless using them makes the
+result easier to follow.</p>
+<div class="olist lowerroman">
+<ol class="lowerroman" type="i">
+<li>
+<p>do something &#8230;&#8203;
+do_this() unless (condition);</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>is more readable than:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>do something &#8230;&#8203;
+unless (condition) {
+	do_this();
+}</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>*only* when the condition is so rare that do_this() will be almost
+always called.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments inside "if ()" conditions.</p>
+</li>
+<li>
+<p>Learn and use Git.pm if you need that functionality.</p>
+</li>
+<li>
+<p>For Emacs, it&#8217;s useful to put the following in
+GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode:</p>
+<div class="literalblock">
+<div class="content">
+<pre>;; note the first part is useful for C editing, too
+((nil . ((indent-tabs-mode . t)
+              (tab-width . 8)
+              (fill-column . 80)))
+ (cperl-mode . ((cperl-indent-level . 8)
+                (cperl-extra-newline-before-brace . nil)
+                (cperl-merge-trailing-else . t))))</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Python scripts:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We follow PEP-8 (<a href="http://www.python.org/dev/peps/pep-0008/" class="bare">http://www.python.org/dev/peps/pep-0008/</a>).</p>
+</li>
+<li>
+<p>As a minimum, we aim to be compatible with Python 2.7.</p>
+</li>
+<li>
+<p>Where required libraries do not restrict us to Python 2, we try to
+also be compatible with Python 3.1 and later.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Program Output</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>We make a distinction between a Git command's primary output and
+output which is merely chatty feedback (for instance, status
+messages, running transcript, or progress display), as well as error
+messages. Roughly speaking, a Git command's primary output is that
+which one might want to capture to a file or send down a pipe; its
+chatty output should not interfere with these use-cases.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>As such, primary output should be sent to the standard output stream
+(stdout), and chatty output should be sent to the standard error
+stream (stderr). Examples of commands which produce primary output
+include `git log`, `git show`, and `git branch --list` which generate
+output on the stdout stream.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Not all Git commands have primary output; this is often true of
+commands whose main function is to perform an action. Some action
+commands are silent, whereas others are chatty. An example of a
+chatty action commands is `git clone` with its "Cloning into
+'&lt;path&gt;'..." and "Checking connectivity..." status messages which it
+sends to the stderr stream.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Error messages from Git commands should always be sent to the stderr
+stream.</pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Error Messages</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Do not end error messages with a full stop.</p>
+</li>
+<li>
+<p>Do not capitalize the first word, only because it is the first word
+in the message ("unable to open %s", not "Unable to open %s").  But
+"SHA-3 not supported" is fine, because the reason the first word is
+capitalized is not because it is at the beginning of the sentence,
+but because the word would be spelled in capital letters even when
+it appeared in the middle of the sentence.</p>
+</li>
+<li>
+<p>Say what the error is first ("cannot open %s", not "%s: cannot open")</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Externally Visible Names</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>For configuration variable names, follow the existing convention:</p>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>The section name indicates the affected subsystem.</p>
+</li>
+<li>
+<p>The subsection name, if any, indicates which of an unbounded set
+of things to set the value for.</p>
+</li>
+<li>
+<p>The variable name describes the effect of tweaking this knob.</p>
+<div class="literalblock">
+<div class="content">
+<pre>The section and variable names that consist of multiple words are
+formed by concatenating the words without punctuations (e.g. `-`),
+and are broken using bumpyCaps in documentation as a hint to the
+reader.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>When choosing the variable namespace, do not use variable name for
+specifying possibly unbounded set of things, most notably anything
+an end user can freely come up with (e.g. branch names).  Instead,
+use subsection names or variable values, like the existing variable
+branch.&lt;name&gt;.description does.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Writing Documentation:</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Most (if not all) of the documentation pages are written in the
+AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+processed into HTML and manpages (e.g. git.html and git.1 in the
+same directory).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>The documentation liberally mixes US and UK English (en_US/UK)
+norms for spelling and grammar, which is somewhat unfortunate.
+In an ideal world, it would have been better if it consistently
+used only one and not the other, and we would have picked en_US
+(if you wish to correct the English of some of the existing
+documentation, please see the documentation-related advice in the
+Documentation/SubmittingPatches file).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>In order to ensure the documentation is inclusive, avoid assuming
+that an unspecified example person is male or female, and think
+twice before using "he", "him", "she", or "her".  Here are some
+tips to avoid use of gendered pronouns:</pre>
+</div>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Prefer succinctness and matter-of-factly describing functionality
+in the abstract.  E.g.</p>
+<div class="dlist">
+<dl>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short"> <a class="anchor" href="#Documentation/CodingGuidelines---short"></a>--short </dt>
+<dd>
+<p>Emit output in the short-format.</p>
+<div class="literalblock">
+<div class="content">
+<pre>and avoid something like these overly verbose alternatives:</pre>
+</div>
+</div>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short-1"> <a class="anchor" href="#Documentation/CodingGuidelines---short-1"></a>--short </dt>
+<dd>
+<p>Use this to emit output in the short-format.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short-1-1"> <a class="anchor" href="#Documentation/CodingGuidelines---short-1-1"></a>--short </dt>
+<dd>
+<p>You can use this to get output in the short-format.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short-1-1-1"> <a class="anchor" href="#Documentation/CodingGuidelines---short-1-1-1"></a>--short </dt>
+<dd>
+<p>A user who prefers shorter output could&#8230;&#8203;.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short-1-1-1-1"> <a class="anchor" href="#Documentation/CodingGuidelines---short-1-1-1-1"></a>--short </dt>
+<dd>
+<p>Should a person and/or program want shorter output, he
+she/they/it can&#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>This practice often eliminates the need to involve human actors in
+your description, but it is a good practice regardless of the
+avoidance of gendered pronouns.</pre>
+</div>
+</div>
+</dd>
+</dl>
+</div>
+</li>
+<li>
+<p>When it becomes awkward to stick to this style, prefer "you" when
+addressing the the hypothetical user, and possibly "we" when
+discussing how the program might react to the user.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>You can use this option instead of --xyz, but we might remove
+support for it in future versions.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while keeping in mind that you can probably be less verbose, e.g.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Use this instead of --xyz. This option might be removed in future
+versions.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>If you still need to refer to an example person that is
+third-person singular, you may resort to "singular they" to avoid
+"he/she/him/her", e.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>A contributor asks their upstream to pull from them.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Note that this sounds ungrammatical and unnatural to those who
+learned that "they" is only used for third-person plural, e.g.
+those who learn English as a second language in some parts of the
+world.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Every user-visible change should be reflected in the documentation.
+The same general rule as for code applies -- imitate the existing
+conventions.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying command usage strings and synopsis sections in the manual
+pages:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Placeholders are spelled in lowercase and enclosed in angle brackets:
+  &lt;file&gt;
+  --sort=&lt;key&gt;
+  --abbrev[=&lt;n&gt;]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If a placeholder has multiple words, they are separated by dashes:
+  &lt;new-branch-name&gt;
+  --template=&lt;template-directory&gt;</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Possibility of multiple occurrences is indicated by three dots:
+  &lt;file&gt;...
+  (One or more of &lt;file&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Optional parts are enclosed in square brackets:
+  [&lt;extra&gt;]
+  (Zero or one &lt;extra&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>--exec-path[=&lt;path&gt;]
+(Option with an optional argument.  Note that the "=" is inside the
+brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[&lt;patch&gt;...]
+(Zero or more of &lt;patch&gt;.  Note that the dots are inside, not
+outside the brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Multiple alternatives are indicated with vertical bars:
+  [-q | --quiet]
+  [--utf8 | --no-utf8]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Parentheses are used for grouping:
+  [(&lt;rev&gt; | &lt;range&gt;)...]
+  (Any number of either &lt;rev&gt; or &lt;range&gt;.  Parens are needed to make
+  it clear that "..." pertains to both &lt;rev&gt; and &lt;range&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[(-p &lt;parent&gt;)...]
+(Any number of option -p, each with one &lt;parent&gt; argument.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>git remote set-head &lt;name&gt; (-a | -d | &lt;branch&gt;)
+(One and only one of "-a", "-d" or "&lt;branch&gt;" _must_ (no square
+brackets) be provided.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>And a somewhat more contrived example:
+  --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+  Here "=" is outside the brackets, because "--diff-filter=" is a
+  valid usage.  "*" has its own pair of brackets, because it can
+  (optionally) be specified only when one or more of the letters is
+  also provided.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A note on notation:
+ Use 'git' (all lowercase) when talking about commands i.e. something
+ the user would type into a shell and use 'Git' (uppercase first letter)
+ when talking about the version control system and its properties.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying paragraphs or option/command explanations that contain options
+or commands:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Literal examples (e.g. use of command-line options, command names,
+branch names, URLs, pathnames (files and directories), configuration and
+environment variables) must be typeset in monospace (i.e. wrapped with
+backticks):
+  `--pretty=oneline`
+  `git rev-list`
+  `remote.pushDefault`
+  `http://git.example.com`
+  `.git/config`
+  `GIT_DIR`
+  `HEAD`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>An environment variable must be prefixed with "$" only when referring to its
+value and not when referring to the variable itself, in this case there is
+nothing to add except the backticks:
+  `GIT_DIR` is specified
+  `$GIT_DIR/hooks/pre-receive`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Word phrases enclosed in `backtick characters` are rendered literally
+and will not be further expanded. The use of `backticks` to achieve the
+previous rule means that literal examples should not use AsciiDoc
+escapes.
+  Correct:
+     `--pretty=oneline`
+  Incorrect:
+     `\--pretty=oneline`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If some place in the documentation needs to typeset a command usage
+example with inline substitutions, it is fine to use +monospaced and
+inline substituted text+ instead of `monospaced literal text`, and with
+the former, the part that should not get substituted must be
+quoted/escaped.</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+</div>
+</div>
\ No newline at end of file
diff --git a/external/docs/content/docs/CodingGuidelines/2.36.0.html b/external/docs/content/docs/CodingGuidelines/2.36.0.html
new file mode 100644
index 0000000000..a92a0c8a2b
--- /dev/null
+++ b/external/docs/content/docs/CodingGuidelines/2.36.0.html
@@ -0,0 +1,1170 @@
+---
+### DO NOT EDIT! Generated by script/update-docs.rb
+
+category: manual
+section: documentation
+subsection: manual
+title: Git - CodingGuidelines Documentation
+docname: CodingGuidelines
+version: 2.36.0
+aliases:
+- "/docs/CodingGuidelines/2.36.0/index.html"
+- "/docs/CodingGuidelines/2.36.1/index.html"
+- "/docs/CodingGuidelines/2.36.2/index.html"
+- "/docs/CodingGuidelines/2.36.3/index.html"
+- "/docs/CodingGuidelines/2.36.4/index.html"
+- "/docs/CodingGuidelines/2.36.5/index.html"
+- "/docs/CodingGuidelines/2.36.6/index.html"
+---
+<div id="preamble">
+<div class="sectionbody">
+<div class="paragraph">
+<p>Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, a few rough rules are:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most importantly, we never say "It&#8217;s in POSIX; we&#8217;ll happily
+ignore your needs should your system not conform to it."
+We live in the real world.</p>
+</li>
+<li>
+<p>However, we often say "Let&#8217;s stay away from that construct,
+it&#8217;s not even in POSIX".</p>
+</li>
+<li>
+<p>In spite of the above two rules, we sometimes say "Although
+this is not in POSIX, it (is so convenient | makes the code
+much more readable | has other good characteristics) and
+practically all the platforms we care about support it, so
+let&#8217;s use it".</p>
+<div class="literalblock">
+<div class="content">
+<pre>Again, we live in the real world, and it is sometimes a
+judgement call, the decision based more on real world
+constraints people face than what the paper standard says.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Fixing style violations while working on a real change as a
+preparatory clean-up step is good, but otherwise avoid useless code
+churn for the sake of conforming to the style.</p>
+<div class="literalblock">
+<div class="content">
+<pre>"Once it _is_ in the tree, it's not really worth the patch noise to
+go and fix it up."
+Cf. http://lkml.iu.edu/hypermail/linux/kernel/1001.3/01069.html</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Log messages to explain your changes are as important as the
+changes themselves.  Clearly written code and in-code comments
+explain how the code works and what is assumed from the surrounding
+context.  The log messages explain what the changes wanted to
+achieve and why the changes were necessary (more on this in the
+accompanying SubmittingPatches document).</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Make your code readable and sensible, and don&#8217;t try to be clever.</p>
+</div>
+<div class="paragraph">
+<p>As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the <em>local</em>
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn&#8217;t match the overall style of existing code).</p>
+</div>
+<div class="paragraph">
+<p>But if you must have a list of rules, here they are.</p>
+</div>
+<div class="paragraph">
+<p>For shell scripts specifically (not exhaustive):</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs for indentation.</p>
+</li>
+<li>
+<p>Case arms are indented at the same depth as case and esac lines,
+like this:</p>
+<div class="literalblock">
+<div class="content">
+<pre>case "$variable" in
+pattern1)
+	do this
+	;;
+pattern2)
+	do that
+	;;
+esac</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Redirection operators should be written with space before, but no
+space after them.  In other words, write <em>echo test &gt;"$file"</em>
+instead of <em>echo test&gt; $file</em> or <em>echo test &gt; $file</em>.  Note that
+even though it is not required by POSIX to double-quote the
+redirection target in a variable (as shown above), our code does so
+because some versions of bash issue a warning without the quotes.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+cat hello &gt; world &lt; universe
+echo hello &gt;$world</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+cat hello &gt;world &lt;universe
+echo hello &gt;"$world"</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer $( &#8230;&#8203; ) for command substitution; unlike ``, it
+properly nests.  It should have been the way Bourne spelled
+it from day one, but unfortunately isn&#8217;t.</p>
+</li>
+<li>
+<p>If you want to find out if a command is available on the user&#8217;s
+$PATH, you should use <em>type &lt;command&gt;</em>, instead of <em>which &lt;command&gt;</em>.
+The output of <em>which</em> is not machine parsable and its exit code
+is not reliable across platforms.</p>
+</li>
+<li>
+<p>We use POSIX compliant parameter substitutions and avoid bashisms;
+namely:</p>
+</li>
+<li>
+<p>We use ${parameter-word} and its [-=?+] siblings, and their
+colon&#8217;ed "unset or null" form.</p>
+</li>
+<li>
+<p>We use ${parameter#word} and its [#%] siblings, and their
+doubled "longest matching" form.</p>
+</li>
+<li>
+<p>No "Substring Expansion" ${parameter:offset:length}.</p>
+</li>
+<li>
+<p>No shell arrays.</p>
+</li>
+<li>
+<p>No pattern replacement ${parameter/pattern/string}.</p>
+</li>
+<li>
+<p>We use Arithmetic Expansion $&#8230;&#8203;.</p>
+</li>
+<li>
+<p>We do not use Process Substitution &lt;(list) or &gt;(list).</p>
+</li>
+<li>
+<p>Do not write control structures on a single line with semicolon.
+"then" should be on the next line for if statements, and "do"
+should be on the next line for "while" and "for".</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+if test -f hello; then
+	do this
+fi</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+if test -f hello
+then
+	do this
+fi</pre>
+</div>
+</div>
+</li>
+<li>
+<p>If a command sequence joined with &amp;&amp; or || or | spans multiple
+lines, put each command on a separate line and put &amp;&amp; and || and |
+operators at the end of each line, rather than the start. This
+means you don&#8217;t need to use \ to join lines, since the above
+operators imply the sequence isn&#8217;t finished.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+grep blob verify_pack_result \
+| awk -f print_1.awk \
+| sort &gt;actual &amp;&amp;
+...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+grep blob verify_pack_result |
+awk -f print_1.awk |
+sort &gt;actual &amp;&amp;
+...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer "test" over "[ &#8230;&#8203; ]".</p>
+</li>
+<li>
+<p>We do not write the noiseword "function" in front of shell
+functions.</p>
+</li>
+<li>
+<p>We prefer a space between the function name and the parentheses,
+and no space inside the parentheses. The opening "{" should also
+be on the same line.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+my_function(){
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+my_function () {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+[::], [==], or [..]) for portability.</p>
+</li>
+<li>
+<p>We do not use \{m,n\};</p>
+</li>
+<li>
+<p>We do not use -E;</p>
+</li>
+<li>
+<p>We do not use ? or + (which are \{0,1\} and \{1,\}
+respectively in BRE) but that goes without saying as these
+are ERE elements not BRE (note that \? and \+ are not even part
+of BRE&#8201;&#8212;&#8201;making them accessible from BRE is a GNU extension).</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers in git-sh-i18n to make the user
+interface translatable. See "Marking strings for translation" in
+po/README.</p>
+</li>
+<li>
+<p>We do not write our "test" command with "-a" and "-o" and use "&amp;&amp;"
+or "||" to concatenate multiple "test" commands instead, because
+the use of "-a/-o" is often error-prone.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" -a "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is buggy and breaks when $x is "=", but</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" &amp;&amp; test "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>does not have such a problem.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Even though "local" is not part of POSIX, we make heavy use of it
+in our test suite.  We do not use it in scripted Porcelains, and
+hopefully nobody starts using "local" before they are reimplemented
+in C ;-)</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For C programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs to indent, and interpret tabs as taking up to
+8 spaces.</p>
+</li>
+<li>
+<p>We try to keep to at most 80 characters per line.</p>
+</li>
+<li>
+<p>As a Git developer we assume you have a reasonably modern compiler
+and we recommend you to enable the DEVELOPER makefile knob to
+ensure your patch is clear of all compiler warnings we care about,
+by e.g. "echo DEVELOPER=1 &gt;&gt;config.mak".</p>
+</li>
+<li>
+<p>We try to support a wide range of C compilers to compile Git with,
+including old ones.  You should not use features from newer C
+standard, even if your compiler groks them.</p>
+<div class="literalblock">
+<div class="content">
+<pre>There are a few exceptions to this guideline:</pre>
+</div>
+</div>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>since early 2012 with e1327023ea, we have been using an enum
+definition whose last element is followed by a comma.  This, like
+an array initializer that ends with a trailing comma, can be used
+to reduce the patch noise when adding a new identifier at the end.</p>
+</li>
+<li>
+<p>since mid 2017 with cbc0f81d, we have been using designated
+initializers for struct (e.g. "struct t v = { .val = <em>a</em> };").</p>
+</li>
+<li>
+<p>since mid 2017 with 512f41cf, we have been using designated
+initializers for array (e.g. "int array[10] = { [5] = 2 }").</p>
+</li>
+<li>
+<p>since early 2021 with 765dc168882, we have been using variadic
+macros, mostly for printf-like trace and debug macros.</p>
+<div class="literalblock">
+<div class="content">
+<pre>These used to be forbidden, but we have not heard any breakage
+report, and they are assumed to be safe.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>Variables have to be declared at the beginning of the block, before
+the first statement (i.e. -Wdeclaration-after-statement).</p>
+</li>
+<li>
+<p>Declaring a variable in the for loop "for (int i = 0; i &lt; 10; i++)"
+is still not allowed in this codebase.  We are in the process of
+allowing it by waiting to see that 44ba10d6 (revision: use C99
+declaration of variable in for() loop, 2021-11-14) does not get
+complaints.  Let&#8217;s revisit this around November 2022.</p>
+</li>
+<li>
+<p>NULL pointers shall be written as NULL, not as 0.</p>
+</li>
+<li>
+<p>When declaring pointers, the star sides with the variable
+name, i.e. "char <strong>string", not "char</strong> string" or
+"char * string".  This makes it easier to understand code
+like "char *string, c;".</p>
+</li>
+<li>
+<p>Use whitespace around operators and keywords, but not inside
+parentheses and not around functions. So:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      while (condition)
+func(bar + 1);</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>      while( condition )
+func (bar+1);</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Do not explicitly compare an integral value with constant 0 or <em>\0</em>,
+or a pointer value with constant NULL.  For instance, to validate that
+counted array &lt;ptr, cnt&gt; is initialized but has no elements, write:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (!ptr || cnt)
+	BUG("empty array expected");</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (ptr == NULL || cnt != 0);
+	BUG("empty array expected");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We avoid using braces unnecessarily.  I.e.</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (bla) {
+	x = 1;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is frowned upon. But there are a few exceptions:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When the statement extends over a few lines (e.g., a while loop
+with an embedded conditional, or a comment). E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (foo) {
+	if (x)
+		one();
+	else
+		two();
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	/*
+	 * This one requires some explanation,
+	 * so we're better off with braces to make
+	 * it obvious that the indentation is correct.
+	 */
+	doit();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When there are multiple arms to a conditional and some of them
+require braces, enclose even a single line block in braces for
+consistency. E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	doit();
+} else {
+	one();
+	two();
+	three();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments in the condition of an "if" statement.</p>
+</li>
+<li>
+<p>Try to make your code understandable.  You may put comments
+in, but comments invariably tend to stale out when the code
+they were describing changes.  Often splitting a function
+into two makes the intention of the code much clearer.</p>
+</li>
+<li>
+<p>Multi-line comments include their delimiters on separate lines from
+the text.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * A very long
+ * multi-line comment.
+ */</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Note however that a comment that explains a translatable string to
+translators uses a convention of starting with a magic token
+"TRANSLATORS: ", e.g.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * TRANSLATORS: here is a comment that explains the string to
+ * be translated, that follows immediately after it.
+ */
+_("Here is a translatable string explained by the above.");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Double negation is often harder to understand than no negation
+at all.</p>
+</li>
+<li>
+<p>There are two schools of thought when it comes to comparison,
+especially inside a loop. Some people prefer to have the less stable
+value on the left hand side and the more stable value on the right hand
+side, e.g. if you have a loop that counts variable i down to the
+lower bound,</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (i &gt; lower_bound) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Other people prefer to have the textual order of values match the
+actual order of values in their comparison, so that they can
+mentally draw a number line from left to right and place these
+values in order, i.e.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while (lower_bound &lt; i) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  However, the more "stable" the
+stable side becomes, the more we tend to prefer the former
+(comparison with a constant, "i &gt; 0", is an extreme example).
+Just do not mix styles in the same part of the code and mimic
+existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>There are two schools of thought when it comes to splitting a long
+logical line into multiple lines.  Some people push the second and
+subsequent lines far enough to the right with tabs and align them:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+              ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to align the second and the subsequent
+lines with the column immediately inside the opening parenthesis,
+with tabs and spaces, following our "tabstop is always a multiple
+of 8" convention:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+           ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  Again, just do not mix styles in
+the same part of the code and mimic existing styles in the
+neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, some people change line before
+a binary operator, so that the result looks like a parse tree when
+you turn your head 90-degrees counterclockwise:</p>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to
+|| span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to leave the operator at the end of the
+line:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, but we tend to use the latter more, unless the
+expression gets fairly complex, in which case the former tends to
+be easier to read.  Again, just do not mix styles in the same part
+of the code and mimic existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, with everything else being
+equal, it is preferable to split after the operator at higher
+level in the parse tree.  That is, this is more preferable:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable * that_is_used_in +
+    a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>than</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable *
+    that_is_used_in + a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Some clever tricks, like using the !! operator with arithmetic
+constructs, can be extremely confusing to others.  Avoid them,
+unless there is a compelling reason to use them.</p>
+</li>
+<li>
+<p>Use the API.  No, really.  We have a strbuf (variable length
+string), several arrays with the ALLOC_GROW() macro, a
+string_list for sorted string lists, a hash map (mapping struct
+objects) named "struct decorate", amongst other things.</p>
+</li>
+<li>
+<p>When you come up with an API, document its functions and structures
+in the header file that exposes the API to its callers. Use what is
+in "strbuf.h" as a model for the appropriate tone and level of
+detail.</p>
+</li>
+<li>
+<p>The first #include in C files, except in platform specific compat/
+implementations, must be either "git-compat-util.h", "cache.h" or
+"builtin.h".  You do not have to include more than one of these.</p>
+</li>
+<li>
+<p>A C file must directly include the header files that declare the
+functions and the types it uses, except for the functions and types
+that are made available to it by including one of the header files
+it must include by the previous rule.</p>
+</li>
+<li>
+<p>If you are planning a new command, consider writing it in shell
+or perl first, so that changes in semantics can be easily
+changed and discussed.  Many Git commands started out like
+that, and a few are still scripts.</p>
+</li>
+<li>
+<p>Avoid introducing a new dependency into Git. This means you
+usually should stay away from scripting languages not already
+used in the Git core command set (unless your command is clearly
+separate from it, such as an importer to convert random-scm-X
+repositories to Git).</p>
+</li>
+<li>
+<p>When we pass &lt;string, length&gt; pair to functions, we should try to
+pass them in that order.</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers to make the user interface
+translatable. See "Marking strings for translation" in po/README.</p>
+</li>
+<li>
+<p>Variables and functions local to a given source file should be marked
+with "static". Variables that are visible to other source files
+must be declared with "extern" in header files. However, function
+declarations should not use "extern", as that is already the default.</p>
+</li>
+<li>
+<p>You can launch gdb around your program using the shorthand GIT_DEBUGGER.
+Run <code>GIT_DEBUGGER=1 ./bin-wrappers/git foo</code> to simply use gdb as is, or
+run <code>GIT_DEBUGGER="&lt;debugger&gt; &lt;debugger-args&gt;" ./bin-wrappers/git foo</code> to
+use your own debugger and arguments. Example: <code>GIT_DEBUGGER="ddd --gdb"
+./bin-wrappers/git log</code> (See <code>wrap-for-bin.sh</code>.)</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Perl programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most of the C guidelines above apply.</p>
+</li>
+<li>
+<p>We try to support Perl 5.8 and later ("use Perl 5.008").</p>
+</li>
+<li>
+<p>use strict and use warnings are strongly preferred.</p>
+</li>
+<li>
+<p>Don&#8217;t overuse statement modifiers unless using them makes the
+result easier to follow.</p>
+<div class="olist lowerroman">
+<ol class="lowerroman" type="i">
+<li>
+<p>do something &#8230;&#8203;
+do_this() unless (condition);</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>is more readable than:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>do something &#8230;&#8203;
+unless (condition) {
+	do_this();
+}</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>*only* when the condition is so rare that do_this() will be almost
+always called.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments inside "if ()" conditions.</p>
+</li>
+<li>
+<p>Learn and use Git.pm if you need that functionality.</p>
+</li>
+<li>
+<p>For Emacs, it&#8217;s useful to put the following in
+GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode:</p>
+<div class="literalblock">
+<div class="content">
+<pre>;; note the first part is useful for C editing, too
+((nil . ((indent-tabs-mode . t)
+              (tab-width . 8)
+              (fill-column . 80)))
+ (cperl-mode . ((cperl-indent-level . 8)
+                (cperl-extra-newline-before-brace . nil)
+                (cperl-merge-trailing-else . t))))</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Python scripts:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We follow PEP-8 (<a href="http://www.python.org/dev/peps/pep-0008/" class="bare">http://www.python.org/dev/peps/pep-0008/</a>).</p>
+</li>
+<li>
+<p>As a minimum, we aim to be compatible with Python 2.7.</p>
+</li>
+<li>
+<p>Where required libraries do not restrict us to Python 2, we try to
+also be compatible with Python 3.1 and later.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Program Output</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>We make a distinction between a Git command's primary output and
+output which is merely chatty feedback (for instance, status
+messages, running transcript, or progress display), as well as error
+messages. Roughly speaking, a Git command's primary output is that
+which one might want to capture to a file or send down a pipe; its
+chatty output should not interfere with these use-cases.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>As such, primary output should be sent to the standard output stream
+(stdout), and chatty output should be sent to the standard error
+stream (stderr). Examples of commands which produce primary output
+include `git log`, `git show`, and `git branch --list` which generate
+output on the stdout stream.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Not all Git commands have primary output; this is often true of
+commands whose main function is to perform an action. Some action
+commands are silent, whereas others are chatty. An example of a
+chatty action commands is `git clone` with its "Cloning into
+'&lt;path&gt;'..." and "Checking connectivity..." status messages which it
+sends to the stderr stream.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Error messages from Git commands should always be sent to the stderr
+stream.</pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Error Messages</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Do not end error messages with a full stop.</p>
+</li>
+<li>
+<p>Do not capitalize the first word, only because it is the first word
+in the message ("unable to open %s", not "Unable to open %s").  But
+"SHA-3 not supported" is fine, because the reason the first word is
+capitalized is not because it is at the beginning of the sentence,
+but because the word would be spelled in capital letters even when
+it appeared in the middle of the sentence.</p>
+</li>
+<li>
+<p>Say what the error is first ("cannot open %s", not "%s: cannot open")</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Externally Visible Names</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>For configuration variable names, follow the existing convention:</p>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>The section name indicates the affected subsystem.</p>
+</li>
+<li>
+<p>The subsection name, if any, indicates which of an unbounded set
+of things to set the value for.</p>
+</li>
+<li>
+<p>The variable name describes the effect of tweaking this knob.</p>
+<div class="literalblock">
+<div class="content">
+<pre>The section and variable names that consist of multiple words are
+formed by concatenating the words without punctuations (e.g. `-`),
+and are broken using bumpyCaps in documentation as a hint to the
+reader.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>When choosing the variable namespace, do not use variable name for
+specifying possibly unbounded set of things, most notably anything
+an end user can freely come up with (e.g. branch names).  Instead,
+use subsection names or variable values, like the existing variable
+branch.&lt;name&gt;.description does.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Writing Documentation:</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Most (if not all) of the documentation pages are written in the
+AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+processed into HTML and manpages (e.g. git.html and git.1 in the
+same directory).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>The documentation liberally mixes US and UK English (en_US/UK)
+norms for spelling and grammar, which is somewhat unfortunate.
+In an ideal world, it would have been better if it consistently
+used only one and not the other, and we would have picked en_US
+(if you wish to correct the English of some of the existing
+documentation, please see the documentation-related advice in the
+Documentation/SubmittingPatches file).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>In order to ensure the documentation is inclusive, avoid assuming
+that an unspecified example person is male or female, and think
+twice before using "he", "him", "she", or "her".  Here are some
+tips to avoid use of gendered pronouns:</pre>
+</div>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Prefer succinctness and matter-of-factly describing functionality
+in the abstract.  E.g.</p>
+<div class="dlist">
+<dl>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short"> <a class="anchor" href="#Documentation/CodingGuidelines---short"></a>--short </dt>
+<dd>
+<p>Emit output in the short-format.</p>
+<div class="literalblock">
+<div class="content">
+<pre>and avoid something like these overly verbose alternatives:</pre>
+</div>
+</div>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short-1"> <a class="anchor" href="#Documentation/CodingGuidelines---short-1"></a>--short </dt>
+<dd>
+<p>Use this to emit output in the short-format.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short-1-1"> <a class="anchor" href="#Documentation/CodingGuidelines---short-1-1"></a>--short </dt>
+<dd>
+<p>You can use this to get output in the short-format.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short-1-1-1"> <a class="anchor" href="#Documentation/CodingGuidelines---short-1-1-1"></a>--short </dt>
+<dd>
+<p>A user who prefers shorter output could&#8230;&#8203;.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short-1-1-1-1"> <a class="anchor" href="#Documentation/CodingGuidelines---short-1-1-1-1"></a>--short </dt>
+<dd>
+<p>Should a person and/or program want shorter output, he
+she/they/it can&#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>This practice often eliminates the need to involve human actors in
+your description, but it is a good practice regardless of the
+avoidance of gendered pronouns.</pre>
+</div>
+</div>
+</dd>
+</dl>
+</div>
+</li>
+<li>
+<p>When it becomes awkward to stick to this style, prefer "you" when
+addressing the the hypothetical user, and possibly "we" when
+discussing how the program might react to the user.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>You can use this option instead of --xyz, but we might remove
+support for it in future versions.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while keeping in mind that you can probably be less verbose, e.g.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Use this instead of --xyz. This option might be removed in future
+versions.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>If you still need to refer to an example person that is
+third-person singular, you may resort to "singular they" to avoid
+"he/she/him/her", e.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>A contributor asks their upstream to pull from them.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Note that this sounds ungrammatical and unnatural to those who
+learned that "they" is only used for third-person plural, e.g.
+those who learn English as a second language in some parts of the
+world.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Every user-visible change should be reflected in the documentation.
+The same general rule as for code applies -- imitate the existing
+conventions.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying command usage strings and synopsis sections in the manual
+pages:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Placeholders are spelled in lowercase and enclosed in angle brackets:
+  &lt;file&gt;
+  --sort=&lt;key&gt;
+  --abbrev[=&lt;n&gt;]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If a placeholder has multiple words, they are separated by dashes:
+  &lt;new-branch-name&gt;
+  --template=&lt;template-directory&gt;</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Possibility of multiple occurrences is indicated by three dots:
+  &lt;file&gt;...
+  (One or more of &lt;file&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Optional parts are enclosed in square brackets:
+  [&lt;extra&gt;]
+  (Zero or one &lt;extra&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>--exec-path[=&lt;path&gt;]
+(Option with an optional argument.  Note that the "=" is inside the
+brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[&lt;patch&gt;...]
+(Zero or more of &lt;patch&gt;.  Note that the dots are inside, not
+outside the brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Multiple alternatives are indicated with vertical bars:
+  [-q | --quiet]
+  [--utf8 | --no-utf8]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Parentheses are used for grouping:
+  [(&lt;rev&gt; | &lt;range&gt;)...]
+  (Any number of either &lt;rev&gt; or &lt;range&gt;.  Parens are needed to make
+  it clear that "..." pertains to both &lt;rev&gt; and &lt;range&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[(-p &lt;parent&gt;)...]
+(Any number of option -p, each with one &lt;parent&gt; argument.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>git remote set-head &lt;name&gt; (-a | -d | &lt;branch&gt;)
+(One and only one of "-a", "-d" or "&lt;branch&gt;" _must_ (no square
+brackets) be provided.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>And a somewhat more contrived example:
+  --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+  Here "=" is outside the brackets, because "--diff-filter=" is a
+  valid usage.  "*" has its own pair of brackets, because it can
+  (optionally) be specified only when one or more of the letters is
+  also provided.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A note on notation:
+ Use 'git' (all lowercase) when talking about commands i.e. something
+ the user would type into a shell and use 'Git' (uppercase first letter)
+ when talking about the version control system and its properties.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying paragraphs or option/command explanations that contain options
+or commands:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Literal examples (e.g. use of command-line options, command names,
+branch names, URLs, pathnames (files and directories), configuration and
+environment variables) must be typeset in monospace (i.e. wrapped with
+backticks):
+  `--pretty=oneline`
+  `git rev-list`
+  `remote.pushDefault`
+  `http://git.example.com`
+  `.git/config`
+  `GIT_DIR`
+  `HEAD`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>An environment variable must be prefixed with "$" only when referring to its
+value and not when referring to the variable itself, in this case there is
+nothing to add except the backticks:
+  `GIT_DIR` is specified
+  `$GIT_DIR/hooks/pre-receive`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Word phrases enclosed in `backtick characters` are rendered literally
+and will not be further expanded. The use of `backticks` to achieve the
+previous rule means that literal examples should not use AsciiDoc
+escapes.
+  Correct:
+     `--pretty=oneline`
+  Incorrect:
+     `\--pretty=oneline`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If some place in the documentation needs to typeset a command usage
+example with inline substitutions, it is fine to use +monospaced and
+inline substituted text+ instead of `monospaced literal text`, and with
+the former, the part that should not get substituted must be
+quoted/escaped.</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+</div>
+</div>
\ No newline at end of file
diff --git a/external/docs/content/docs/CodingGuidelines/2.37.0.html b/external/docs/content/docs/CodingGuidelines/2.37.0.html
new file mode 100644
index 0000000000..18e083ae30
--- /dev/null
+++ b/external/docs/content/docs/CodingGuidelines/2.37.0.html
@@ -0,0 +1,1159 @@
+---
+### DO NOT EDIT! Generated by script/update-docs.rb
+
+category: manual
+section: documentation
+subsection: manual
+title: Git - CodingGuidelines Documentation
+docname: CodingGuidelines
+version: 2.37.0
+aliases:
+- "/docs/CodingGuidelines/2.37.0/index.html"
+- "/docs/CodingGuidelines/2.37.1/index.html"
+- "/docs/CodingGuidelines/2.37.2/index.html"
+- "/docs/CodingGuidelines/2.37.3/index.html"
+- "/docs/CodingGuidelines/2.37.4/index.html"
+- "/docs/CodingGuidelines/2.37.5/index.html"
+- "/docs/CodingGuidelines/2.37.6/index.html"
+- "/docs/CodingGuidelines/2.37.7/index.html"
+---
+<div id="preamble">
+<div class="sectionbody">
+<div class="paragraph">
+<p>Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, a few rough rules are:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most importantly, we never say "It&#8217;s in POSIX; we&#8217;ll happily
+ignore your needs should your system not conform to it."
+We live in the real world.</p>
+</li>
+<li>
+<p>However, we often say "Let&#8217;s stay away from that construct,
+it&#8217;s not even in POSIX".</p>
+</li>
+<li>
+<p>In spite of the above two rules, we sometimes say "Although
+this is not in POSIX, it (is so convenient | makes the code
+much more readable | has other good characteristics) and
+practically all the platforms we care about support it, so
+let&#8217;s use it".</p>
+<div class="literalblock">
+<div class="content">
+<pre>Again, we live in the real world, and it is sometimes a
+judgement call, the decision based more on real world
+constraints people face than what the paper standard says.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Fixing style violations while working on a real change as a
+preparatory clean-up step is good, but otherwise avoid useless code
+churn for the sake of conforming to the style.</p>
+<div class="literalblock">
+<div class="content">
+<pre>"Once it _is_ in the tree, it's not really worth the patch noise to
+go and fix it up."
+Cf. http://lkml.iu.edu/hypermail/linux/kernel/1001.3/01069.html</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Log messages to explain your changes are as important as the
+changes themselves.  Clearly written code and in-code comments
+explain how the code works and what is assumed from the surrounding
+context.  The log messages explain what the changes wanted to
+achieve and why the changes were necessary (more on this in the
+accompanying SubmittingPatches document).</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Make your code readable and sensible, and don&#8217;t try to be clever.</p>
+</div>
+<div class="paragraph">
+<p>As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the <em>local</em>
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn&#8217;t match the overall style of existing code).</p>
+</div>
+<div class="paragraph">
+<p>But if you must have a list of rules, here are some language
+specific ones. Note that Documentation/ToolsForGit.txt document
+has a collection of tips to help you use some external tools
+to conform to these guidelines.</p>
+</div>
+<div class="paragraph">
+<p>For shell scripts specifically (not exhaustive):</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs for indentation.</p>
+</li>
+<li>
+<p>Case arms are indented at the same depth as case and esac lines,
+like this:</p>
+<div class="literalblock">
+<div class="content">
+<pre>case "$variable" in
+pattern1)
+	do this
+	;;
+pattern2)
+	do that
+	;;
+esac</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Redirection operators should be written with space before, but no
+space after them.  In other words, write <em>echo test &gt;"$file"</em>
+instead of <em>echo test&gt; $file</em> or <em>echo test &gt; $file</em>.  Note that
+even though it is not required by POSIX to double-quote the
+redirection target in a variable (as shown above), our code does so
+because some versions of bash issue a warning without the quotes.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+cat hello &gt; world &lt; universe
+echo hello &gt;$world</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+cat hello &gt;world &lt;universe
+echo hello &gt;"$world"</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer $( &#8230;&#8203; ) for command substitution; unlike ``, it
+properly nests.  It should have been the way Bourne spelled
+it from day one, but unfortunately isn&#8217;t.</p>
+</li>
+<li>
+<p>If you want to find out if a command is available on the user&#8217;s
+$PATH, you should use <em>type &lt;command&gt;</em>, instead of <em>which &lt;command&gt;</em>.
+The output of <em>which</em> is not machine parsable and its exit code
+is not reliable across platforms.</p>
+</li>
+<li>
+<p>We use POSIX compliant parameter substitutions and avoid bashisms;
+namely:</p>
+</li>
+<li>
+<p>We use ${parameter-word} and its [-=?+] siblings, and their
+colon&#8217;ed "unset or null" form.</p>
+</li>
+<li>
+<p>We use ${parameter#word} and its [#%] siblings, and their
+doubled "longest matching" form.</p>
+</li>
+<li>
+<p>No "Substring Expansion" ${parameter:offset:length}.</p>
+</li>
+<li>
+<p>No shell arrays.</p>
+</li>
+<li>
+<p>No pattern replacement ${parameter/pattern/string}.</p>
+</li>
+<li>
+<p>We use Arithmetic Expansion $&#8230;&#8203;.</p>
+</li>
+<li>
+<p>We do not use Process Substitution &lt;(list) or &gt;(list).</p>
+</li>
+<li>
+<p>Do not write control structures on a single line with semicolon.
+"then" should be on the next line for if statements, and "do"
+should be on the next line for "while" and "for".</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+if test -f hello; then
+	do this
+fi</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+if test -f hello
+then
+	do this
+fi</pre>
+</div>
+</div>
+</li>
+<li>
+<p>If a command sequence joined with &amp;&amp; or || or | spans multiple
+lines, put each command on a separate line and put &amp;&amp; and || and |
+operators at the end of each line, rather than the start. This
+means you don&#8217;t need to use \ to join lines, since the above
+operators imply the sequence isn&#8217;t finished.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+grep blob verify_pack_result \
+| awk -f print_1.awk \
+| sort &gt;actual &amp;&amp;
+...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+grep blob verify_pack_result |
+awk -f print_1.awk |
+sort &gt;actual &amp;&amp;
+...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer "test" over "[ &#8230;&#8203; ]".</p>
+</li>
+<li>
+<p>We do not write the noiseword "function" in front of shell
+functions.</p>
+</li>
+<li>
+<p>We prefer a space between the function name and the parentheses,
+and no space inside the parentheses. The opening "{" should also
+be on the same line.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+my_function(){
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+my_function () {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+[::], [==], or [..]) for portability.</p>
+</li>
+<li>
+<p>We do not use \{m,n\};</p>
+</li>
+<li>
+<p>We do not use -E;</p>
+</li>
+<li>
+<p>We do not use ? or + (which are \{0,1\} and \{1,\}
+respectively in BRE) but that goes without saying as these
+are ERE elements not BRE (note that \? and \+ are not even part
+of BRE&#8201;&#8212;&#8201;making them accessible from BRE is a GNU extension).</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers in git-sh-i18n to make the user
+interface translatable. See "Marking strings for translation" in
+po/README.</p>
+</li>
+<li>
+<p>We do not write our "test" command with "-a" and "-o" and use "&amp;&amp;"
+or "||" to concatenate multiple "test" commands instead, because
+the use of "-a/-o" is often error-prone.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" -a "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is buggy and breaks when $x is "=", but</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" &amp;&amp; test "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>does not have such a problem.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Even though "local" is not part of POSIX, we make heavy use of it
+in our test suite.  We do not use it in scripted Porcelains, and
+hopefully nobody starts using "local" before they are reimplemented
+in C ;-)</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For C programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs to indent, and interpret tabs as taking up to
+8 spaces.</p>
+</li>
+<li>
+<p>We try to keep to at most 80 characters per line.</p>
+</li>
+<li>
+<p>As a Git developer we assume you have a reasonably modern compiler
+and we recommend you to enable the DEVELOPER makefile knob to
+ensure your patch is clear of all compiler warnings we care about,
+by e.g. "echo DEVELOPER=1 &gt;&gt;config.mak".</p>
+</li>
+<li>
+<p>We try to support a wide range of C compilers to compile Git with,
+including old ones.  You should not use features from newer C
+standard, even if your compiler groks them.</p>
+<div class="literalblock">
+<div class="content">
+<pre>There are a few exceptions to this guideline:</pre>
+</div>
+</div>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>since early 2012 with e1327023ea, we have been using an enum
+definition whose last element is followed by a comma.  This, like
+an array initializer that ends with a trailing comma, can be used
+to reduce the patch noise when adding a new identifier at the end.</p>
+</li>
+<li>
+<p>since mid 2017 with cbc0f81d, we have been using designated
+initializers for struct (e.g. "struct t v = { .val = <em>a</em> };").</p>
+</li>
+<li>
+<p>since mid 2017 with 512f41cf, we have been using designated
+initializers for array (e.g. "int array[10] = { [5] = 2 }").</p>
+</li>
+<li>
+<p>since early 2021 with 765dc168882, we have been using variadic
+macros, mostly for printf-like trace and debug macros.</p>
+<div class="literalblock">
+<div class="content">
+<pre>These used to be forbidden, but we have not heard any breakage
+report, and they are assumed to be safe.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>Variables have to be declared at the beginning of the block, before
+the first statement (i.e. -Wdeclaration-after-statement).</p>
+</li>
+<li>
+<p>Declaring a variable in the for loop "for (int i = 0; i &lt; 10; i++)"
+is still not allowed in this codebase.  We are in the process of
+allowing it by waiting to see that 44ba10d6 (revision: use C99
+declaration of variable in for() loop, 2021-11-14) does not get
+complaints.  Let&#8217;s revisit this around November 2022.</p>
+</li>
+<li>
+<p>NULL pointers shall be written as NULL, not as 0.</p>
+</li>
+<li>
+<p>When declaring pointers, the star sides with the variable
+name, i.e. "char <strong>string", not "char</strong> string" or
+"char * string".  This makes it easier to understand code
+like "char *string, c;".</p>
+</li>
+<li>
+<p>Use whitespace around operators and keywords, but not inside
+parentheses and not around functions. So:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      while (condition)
+func(bar + 1);</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>      while( condition )
+func (bar+1);</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Do not explicitly compare an integral value with constant 0 or <em>\0</em>,
+or a pointer value with constant NULL.  For instance, to validate that
+counted array &lt;ptr, cnt&gt; is initialized but has no elements, write:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (!ptr || cnt)
+	BUG("empty array expected");</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (ptr == NULL || cnt != 0);
+	BUG("empty array expected");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We avoid using braces unnecessarily.  I.e.</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (bla) {
+	x = 1;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is frowned upon. But there are a few exceptions:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When the statement extends over a few lines (e.g., a while loop
+with an embedded conditional, or a comment). E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (foo) {
+	if (x)
+		one();
+	else
+		two();
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	/*
+	 * This one requires some explanation,
+	 * so we're better off with braces to make
+	 * it obvious that the indentation is correct.
+	 */
+	doit();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When there are multiple arms to a conditional and some of them
+require braces, enclose even a single line block in braces for
+consistency. E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	doit();
+} else {
+	one();
+	two();
+	three();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments in the condition of an "if" statement.</p>
+</li>
+<li>
+<p>Try to make your code understandable.  You may put comments
+in, but comments invariably tend to stale out when the code
+they were describing changes.  Often splitting a function
+into two makes the intention of the code much clearer.</p>
+</li>
+<li>
+<p>Multi-line comments include their delimiters on separate lines from
+the text.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * A very long
+ * multi-line comment.
+ */</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Note however that a comment that explains a translatable string to
+translators uses a convention of starting with a magic token
+"TRANSLATORS: ", e.g.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * TRANSLATORS: here is a comment that explains the string to
+ * be translated, that follows immediately after it.
+ */
+_("Here is a translatable string explained by the above.");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Double negation is often harder to understand than no negation
+at all.</p>
+</li>
+<li>
+<p>There are two schools of thought when it comes to comparison,
+especially inside a loop. Some people prefer to have the less stable
+value on the left hand side and the more stable value on the right hand
+side, e.g. if you have a loop that counts variable i down to the
+lower bound,</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (i &gt; lower_bound) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Other people prefer to have the textual order of values match the
+actual order of values in their comparison, so that they can
+mentally draw a number line from left to right and place these
+values in order, i.e.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while (lower_bound &lt; i) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  However, the more "stable" the
+stable side becomes, the more we tend to prefer the former
+(comparison with a constant, "i &gt; 0", is an extreme example).
+Just do not mix styles in the same part of the code and mimic
+existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>There are two schools of thought when it comes to splitting a long
+logical line into multiple lines.  Some people push the second and
+subsequent lines far enough to the right with tabs and align them:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+              ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to align the second and the subsequent
+lines with the column immediately inside the opening parenthesis,
+with tabs and spaces, following our "tabstop is always a multiple
+of 8" convention:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+           ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  Again, just do not mix styles in
+the same part of the code and mimic existing styles in the
+neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, some people change line before
+a binary operator, so that the result looks like a parse tree when
+you turn your head 90-degrees counterclockwise:</p>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to
+|| span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to leave the operator at the end of the
+line:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, but we tend to use the latter more, unless the
+expression gets fairly complex, in which case the former tends to
+be easier to read.  Again, just do not mix styles in the same part
+of the code and mimic existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, with everything else being
+equal, it is preferable to split after the operator at higher
+level in the parse tree.  That is, this is more preferable:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable * that_is_used_in +
+    a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>than</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable *
+    that_is_used_in + a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Some clever tricks, like using the !! operator with arithmetic
+constructs, can be extremely confusing to others.  Avoid them,
+unless there is a compelling reason to use them.</p>
+</li>
+<li>
+<p>Use the API.  No, really.  We have a strbuf (variable length
+string), several arrays with the ALLOC_GROW() macro, a
+string_list for sorted string lists, a hash map (mapping struct
+objects) named "struct decorate", amongst other things.</p>
+</li>
+<li>
+<p>When you come up with an API, document its functions and structures
+in the header file that exposes the API to its callers. Use what is
+in "strbuf.h" as a model for the appropriate tone and level of
+detail.</p>
+</li>
+<li>
+<p>The first #include in C files, except in platform specific compat/
+implementations, must be either "git-compat-util.h", "cache.h" or
+"builtin.h".  You do not have to include more than one of these.</p>
+</li>
+<li>
+<p>A C file must directly include the header files that declare the
+functions and the types it uses, except for the functions and types
+that are made available to it by including one of the header files
+it must include by the previous rule.</p>
+</li>
+<li>
+<p>If you are planning a new command, consider writing it in shell
+or perl first, so that changes in semantics can be easily
+changed and discussed.  Many Git commands started out like
+that, and a few are still scripts.</p>
+</li>
+<li>
+<p>Avoid introducing a new dependency into Git. This means you
+usually should stay away from scripting languages not already
+used in the Git core command set (unless your command is clearly
+separate from it, such as an importer to convert random-scm-X
+repositories to Git).</p>
+</li>
+<li>
+<p>When we pass &lt;string, length&gt; pair to functions, we should try to
+pass them in that order.</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers to make the user interface
+translatable. See "Marking strings for translation" in po/README.</p>
+</li>
+<li>
+<p>Variables and functions local to a given source file should be marked
+with "static". Variables that are visible to other source files
+must be declared with "extern" in header files. However, function
+declarations should not use "extern", as that is already the default.</p>
+</li>
+<li>
+<p>You can launch gdb around your program using the shorthand GIT_DEBUGGER.
+Run <code>GIT_DEBUGGER=1 ./bin-wrappers/git foo</code> to simply use gdb as is, or
+run <code>GIT_DEBUGGER="&lt;debugger&gt; &lt;debugger-args&gt;" ./bin-wrappers/git foo</code> to
+use your own debugger and arguments. Example: <code>GIT_DEBUGGER="ddd --gdb"
+./bin-wrappers/git log</code> (See <code>wrap-for-bin.sh</code>.)</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Perl programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most of the C guidelines above apply.</p>
+</li>
+<li>
+<p>We try to support Perl 5.8 and later ("use Perl 5.008").</p>
+</li>
+<li>
+<p>use strict and use warnings are strongly preferred.</p>
+</li>
+<li>
+<p>Don&#8217;t overuse statement modifiers unless using them makes the
+result easier to follow.</p>
+<div class="olist lowerroman">
+<ol class="lowerroman" type="i">
+<li>
+<p>do something &#8230;&#8203;
+do_this() unless (condition);</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>is more readable than:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>do something &#8230;&#8203;
+unless (condition) {
+	do_this();
+}</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>*only* when the condition is so rare that do_this() will be almost
+always called.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments inside "if ()" conditions.</p>
+</li>
+<li>
+<p>Learn and use Git.pm if you need that functionality.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Python scripts:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We follow PEP-8 (<a href="http://www.python.org/dev/peps/pep-0008/" class="bare">http://www.python.org/dev/peps/pep-0008/</a>).</p>
+</li>
+<li>
+<p>As a minimum, we aim to be compatible with Python 2.7.</p>
+</li>
+<li>
+<p>Where required libraries do not restrict us to Python 2, we try to
+also be compatible with Python 3.1 and later.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Program Output</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>We make a distinction between a Git command's primary output and
+output which is merely chatty feedback (for instance, status
+messages, running transcript, or progress display), as well as error
+messages. Roughly speaking, a Git command's primary output is that
+which one might want to capture to a file or send down a pipe; its
+chatty output should not interfere with these use-cases.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>As such, primary output should be sent to the standard output stream
+(stdout), and chatty output should be sent to the standard error
+stream (stderr). Examples of commands which produce primary output
+include `git log`, `git show`, and `git branch --list` which generate
+output on the stdout stream.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Not all Git commands have primary output; this is often true of
+commands whose main function is to perform an action. Some action
+commands are silent, whereas others are chatty. An example of a
+chatty action commands is `git clone` with its "Cloning into
+'&lt;path&gt;'..." and "Checking connectivity..." status messages which it
+sends to the stderr stream.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Error messages from Git commands should always be sent to the stderr
+stream.</pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Error Messages</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Do not end error messages with a full stop.</p>
+</li>
+<li>
+<p>Do not capitalize the first word, only because it is the first word
+in the message ("unable to open %s", not "Unable to open %s").  But
+"SHA-3 not supported" is fine, because the reason the first word is
+capitalized is not because it is at the beginning of the sentence,
+but because the word would be spelled in capital letters even when
+it appeared in the middle of the sentence.</p>
+</li>
+<li>
+<p>Say what the error is first ("cannot open %s", not "%s: cannot open")</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Externally Visible Names</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>For configuration variable names, follow the existing convention:</p>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>The section name indicates the affected subsystem.</p>
+</li>
+<li>
+<p>The subsection name, if any, indicates which of an unbounded set
+of things to set the value for.</p>
+</li>
+<li>
+<p>The variable name describes the effect of tweaking this knob.</p>
+<div class="literalblock">
+<div class="content">
+<pre>The section and variable names that consist of multiple words are
+formed by concatenating the words without punctuations (e.g. `-`),
+and are broken using bumpyCaps in documentation as a hint to the
+reader.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>When choosing the variable namespace, do not use variable name for
+specifying possibly unbounded set of things, most notably anything
+an end user can freely come up with (e.g. branch names).  Instead,
+use subsection names or variable values, like the existing variable
+branch.&lt;name&gt;.description does.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Writing Documentation:</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Most (if not all) of the documentation pages are written in the
+AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+processed into HTML and manpages (e.g. git.html and git.1 in the
+same directory).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>The documentation liberally mixes US and UK English (en_US/UK)
+norms for spelling and grammar, which is somewhat unfortunate.
+In an ideal world, it would have been better if it consistently
+used only one and not the other, and we would have picked en_US
+(if you wish to correct the English of some of the existing
+documentation, please see the documentation-related advice in the
+Documentation/SubmittingPatches file).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>In order to ensure the documentation is inclusive, avoid assuming
+that an unspecified example person is male or female, and think
+twice before using "he", "him", "she", or "her".  Here are some
+tips to avoid use of gendered pronouns:</pre>
+</div>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Prefer succinctness and matter-of-factly describing functionality
+in the abstract.  E.g.</p>
+<div class="dlist">
+<dl>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short"> <a class="anchor" href="#Documentation/CodingGuidelines---short"></a>--short </dt>
+<dd>
+<p>Emit output in the short-format.</p>
+<div class="literalblock">
+<div class="content">
+<pre>and avoid something like these overly verbose alternatives:</pre>
+</div>
+</div>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short-1"> <a class="anchor" href="#Documentation/CodingGuidelines---short-1"></a>--short </dt>
+<dd>
+<p>Use this to emit output in the short-format.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short-1-1"> <a class="anchor" href="#Documentation/CodingGuidelines---short-1-1"></a>--short </dt>
+<dd>
+<p>You can use this to get output in the short-format.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short-1-1-1"> <a class="anchor" href="#Documentation/CodingGuidelines---short-1-1-1"></a>--short </dt>
+<dd>
+<p>A user who prefers shorter output could&#8230;&#8203;.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short-1-1-1-1"> <a class="anchor" href="#Documentation/CodingGuidelines---short-1-1-1-1"></a>--short </dt>
+<dd>
+<p>Should a person and/or program want shorter output, he
+she/they/it can&#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>This practice often eliminates the need to involve human actors in
+your description, but it is a good practice regardless of the
+avoidance of gendered pronouns.</pre>
+</div>
+</div>
+</dd>
+</dl>
+</div>
+</li>
+<li>
+<p>When it becomes awkward to stick to this style, prefer "you" when
+addressing the the hypothetical user, and possibly "we" when
+discussing how the program might react to the user.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>You can use this option instead of --xyz, but we might remove
+support for it in future versions.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while keeping in mind that you can probably be less verbose, e.g.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Use this instead of --xyz. This option might be removed in future
+versions.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>If you still need to refer to an example person that is
+third-person singular, you may resort to "singular they" to avoid
+"he/she/him/her", e.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>A contributor asks their upstream to pull from them.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Note that this sounds ungrammatical and unnatural to those who
+learned that "they" is only used for third-person plural, e.g.
+those who learn English as a second language in some parts of the
+world.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Every user-visible change should be reflected in the documentation.
+The same general rule as for code applies -- imitate the existing
+conventions.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying command usage strings and synopsis sections in the manual
+pages:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Placeholders are spelled in lowercase and enclosed in angle brackets:
+  &lt;file&gt;
+  --sort=&lt;key&gt;
+  --abbrev[=&lt;n&gt;]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If a placeholder has multiple words, they are separated by dashes:
+  &lt;new-branch-name&gt;
+  --template=&lt;template-directory&gt;</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Possibility of multiple occurrences is indicated by three dots:
+  &lt;file&gt;...
+  (One or more of &lt;file&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Optional parts are enclosed in square brackets:
+  [&lt;extra&gt;]
+  (Zero or one &lt;extra&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>--exec-path[=&lt;path&gt;]
+(Option with an optional argument.  Note that the "=" is inside the
+brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[&lt;patch&gt;...]
+(Zero or more of &lt;patch&gt;.  Note that the dots are inside, not
+outside the brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Multiple alternatives are indicated with vertical bars:
+  [-q | --quiet]
+  [--utf8 | --no-utf8]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Parentheses are used for grouping:
+  [(&lt;rev&gt; | &lt;range&gt;)...]
+  (Any number of either &lt;rev&gt; or &lt;range&gt;.  Parens are needed to make
+  it clear that "..." pertains to both &lt;rev&gt; and &lt;range&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[(-p &lt;parent&gt;)...]
+(Any number of option -p, each with one &lt;parent&gt; argument.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>git remote set-head &lt;name&gt; (-a | -d | &lt;branch&gt;)
+(One and only one of "-a", "-d" or "&lt;branch&gt;" _must_ (no square
+brackets) be provided.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>And a somewhat more contrived example:
+  --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+  Here "=" is outside the brackets, because "--diff-filter=" is a
+  valid usage.  "*" has its own pair of brackets, because it can
+  (optionally) be specified only when one or more of the letters is
+  also provided.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A note on notation:
+ Use 'git' (all lowercase) when talking about commands i.e. something
+ the user would type into a shell and use 'Git' (uppercase first letter)
+ when talking about the version control system and its properties.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying paragraphs or option/command explanations that contain options
+or commands:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Literal examples (e.g. use of command-line options, command names,
+branch names, URLs, pathnames (files and directories), configuration and
+environment variables) must be typeset in monospace (i.e. wrapped with
+backticks):
+  `--pretty=oneline`
+  `git rev-list`
+  `remote.pushDefault`
+  `http://git.example.com`
+  `.git/config`
+  `GIT_DIR`
+  `HEAD`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>An environment variable must be prefixed with "$" only when referring to its
+value and not when referring to the variable itself, in this case there is
+nothing to add except the backticks:
+  `GIT_DIR` is specified
+  `$GIT_DIR/hooks/pre-receive`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Word phrases enclosed in `backtick characters` are rendered literally
+and will not be further expanded. The use of `backticks` to achieve the
+previous rule means that literal examples should not use AsciiDoc
+escapes.
+  Correct:
+     `--pretty=oneline`
+  Incorrect:
+     `\--pretty=oneline`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If some place in the documentation needs to typeset a command usage
+example with inline substitutions, it is fine to use +monospaced and
+inline substituted text+ instead of `monospaced literal text`, and with
+the former, the part that should not get substituted must be
+quoted/escaped.</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+</div>
+</div>
\ No newline at end of file
diff --git a/external/docs/content/docs/CodingGuidelines/2.38.0.html b/external/docs/content/docs/CodingGuidelines/2.38.0.html
new file mode 100644
index 0000000000..6978e56350
--- /dev/null
+++ b/external/docs/content/docs/CodingGuidelines/2.38.0.html
@@ -0,0 +1,1153 @@
+---
+### DO NOT EDIT! Generated by script/update-docs.rb
+
+category: manual
+section: documentation
+subsection: manual
+title: Git - CodingGuidelines Documentation
+docname: CodingGuidelines
+version: 2.38.0
+aliases:
+- "/docs/CodingGuidelines/2.38.0/index.html"
+- "/docs/CodingGuidelines/2.38.1/index.html"
+---
+<div id="preamble">
+<div class="sectionbody">
+<div class="paragraph">
+<p>Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, a few rough rules are:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most importantly, we never say "It&#8217;s in POSIX; we&#8217;ll happily
+ignore your needs should your system not conform to it."
+We live in the real world.</p>
+</li>
+<li>
+<p>However, we often say "Let&#8217;s stay away from that construct,
+it&#8217;s not even in POSIX".</p>
+</li>
+<li>
+<p>In spite of the above two rules, we sometimes say "Although
+this is not in POSIX, it (is so convenient | makes the code
+much more readable | has other good characteristics) and
+practically all the platforms we care about support it, so
+let&#8217;s use it".</p>
+<div class="literalblock">
+<div class="content">
+<pre>Again, we live in the real world, and it is sometimes a
+judgement call, the decision based more on real world
+constraints people face than what the paper standard says.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Fixing style violations while working on a real change as a
+preparatory clean-up step is good, but otherwise avoid useless code
+churn for the sake of conforming to the style.</p>
+<div class="literalblock">
+<div class="content">
+<pre>"Once it _is_ in the tree, it's not really worth the patch noise to
+go and fix it up."
+Cf. http://lkml.iu.edu/hypermail/linux/kernel/1001.3/01069.html</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Log messages to explain your changes are as important as the
+changes themselves.  Clearly written code and in-code comments
+explain how the code works and what is assumed from the surrounding
+context.  The log messages explain what the changes wanted to
+achieve and why the changes were necessary (more on this in the
+accompanying SubmittingPatches document).</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Make your code readable and sensible, and don&#8217;t try to be clever.</p>
+</div>
+<div class="paragraph">
+<p>As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the <em>local</em>
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn&#8217;t match the overall style of existing code).</p>
+</div>
+<div class="paragraph">
+<p>But if you must have a list of rules, here are some language
+specific ones. Note that Documentation/ToolsForGit.txt document
+has a collection of tips to help you use some external tools
+to conform to these guidelines.</p>
+</div>
+<div class="paragraph">
+<p>For shell scripts specifically (not exhaustive):</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs for indentation.</p>
+</li>
+<li>
+<p>Case arms are indented at the same depth as case and esac lines,
+like this:</p>
+<div class="literalblock">
+<div class="content">
+<pre>case "$variable" in
+pattern1)
+	do this
+	;;
+pattern2)
+	do that
+	;;
+esac</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Redirection operators should be written with space before, but no
+space after them.  In other words, write <em>echo test &gt;"$file"</em>
+instead of <em>echo test&gt; $file</em> or <em>echo test &gt; $file</em>.  Note that
+even though it is not required by POSIX to double-quote the
+redirection target in a variable (as shown above), our code does so
+because some versions of bash issue a warning without the quotes.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+cat hello &gt; world &lt; universe
+echo hello &gt;$world</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+cat hello &gt;world &lt;universe
+echo hello &gt;"$world"</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer $( &#8230;&#8203; ) for command substitution; unlike ``, it
+properly nests.  It should have been the way Bourne spelled
+it from day one, but unfortunately isn&#8217;t.</p>
+</li>
+<li>
+<p>If you want to find out if a command is available on the user&#8217;s
+$PATH, you should use <em>type &lt;command&gt;</em>, instead of <em>which &lt;command&gt;</em>.
+The output of <em>which</em> is not machine parsable and its exit code
+is not reliable across platforms.</p>
+</li>
+<li>
+<p>We use POSIX compliant parameter substitutions and avoid bashisms;
+namely:</p>
+</li>
+<li>
+<p>We use ${parameter-word} and its [-=?+] siblings, and their
+colon&#8217;ed "unset or null" form.</p>
+</li>
+<li>
+<p>We use ${parameter#word} and its [#%] siblings, and their
+doubled "longest matching" form.</p>
+</li>
+<li>
+<p>No "Substring Expansion" ${parameter:offset:length}.</p>
+</li>
+<li>
+<p>No shell arrays.</p>
+</li>
+<li>
+<p>No pattern replacement ${parameter/pattern/string}.</p>
+</li>
+<li>
+<p>We use Arithmetic Expansion $&#8230;&#8203;.</p>
+</li>
+<li>
+<p>We do not use Process Substitution &lt;(list) or &gt;(list).</p>
+</li>
+<li>
+<p>Do not write control structures on a single line with semicolon.
+"then" should be on the next line for if statements, and "do"
+should be on the next line for "while" and "for".</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+if test -f hello; then
+	do this
+fi</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+if test -f hello
+then
+	do this
+fi</pre>
+</div>
+</div>
+</li>
+<li>
+<p>If a command sequence joined with &amp;&amp; or || or | spans multiple
+lines, put each command on a separate line and put &amp;&amp; and || and |
+operators at the end of each line, rather than the start. This
+means you don&#8217;t need to use \ to join lines, since the above
+operators imply the sequence isn&#8217;t finished.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+grep blob verify_pack_result \
+| awk -f print_1.awk \
+| sort &gt;actual &amp;&amp;
+...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+grep blob verify_pack_result |
+awk -f print_1.awk |
+sort &gt;actual &amp;&amp;
+...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer "test" over "[ &#8230;&#8203; ]".</p>
+</li>
+<li>
+<p>We do not write the noiseword "function" in front of shell
+functions.</p>
+</li>
+<li>
+<p>We prefer a space between the function name and the parentheses,
+and no space inside the parentheses. The opening "{" should also
+be on the same line.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+my_function(){
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+my_function () {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+[::], [==], or [..]) for portability.</p>
+</li>
+<li>
+<p>We do not use \{m,n\};</p>
+</li>
+<li>
+<p>We do not use -E;</p>
+</li>
+<li>
+<p>We do not use ? or + (which are \{0,1\} and \{1,\}
+respectively in BRE) but that goes without saying as these
+are ERE elements not BRE (note that \? and \+ are not even part
+of BRE&#8201;&#8212;&#8201;making them accessible from BRE is a GNU extension).</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers in git-sh-i18n to make the user
+interface translatable. See "Marking strings for translation" in
+po/README.</p>
+</li>
+<li>
+<p>We do not write our "test" command with "-a" and "-o" and use "&amp;&amp;"
+or "||" to concatenate multiple "test" commands instead, because
+the use of "-a/-o" is often error-prone.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" -a "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is buggy and breaks when $x is "=", but</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" &amp;&amp; test "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>does not have such a problem.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Even though "local" is not part of POSIX, we make heavy use of it
+in our test suite.  We do not use it in scripted Porcelains, and
+hopefully nobody starts using "local" before they are reimplemented
+in C ;-)</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For C programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs to indent, and interpret tabs as taking up to
+8 spaces.</p>
+</li>
+<li>
+<p>We try to keep to at most 80 characters per line.</p>
+</li>
+<li>
+<p>As a Git developer we assume you have a reasonably modern compiler
+and we recommend you to enable the DEVELOPER makefile knob to
+ensure your patch is clear of all compiler warnings we care about,
+by e.g. "echo DEVELOPER=1 &gt;&gt;config.mak".</p>
+</li>
+<li>
+<p>We try to support a wide range of C compilers to compile Git with,
+including old ones.  You should not use features from newer C
+standard, even if your compiler groks them.</p>
+<div class="literalblock">
+<div class="content">
+<pre>There are a few exceptions to this guideline:</pre>
+</div>
+</div>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>since early 2012 with e1327023ea, we have been using an enum
+definition whose last element is followed by a comma.  This, like
+an array initializer that ends with a trailing comma, can be used
+to reduce the patch noise when adding a new identifier at the end.</p>
+</li>
+<li>
+<p>since mid 2017 with cbc0f81d, we have been using designated
+initializers for struct (e.g. "struct t v = { .val = <em>a</em> };").</p>
+</li>
+<li>
+<p>since mid 2017 with 512f41cf, we have been using designated
+initializers for array (e.g. "int array[10] = { [5] = 2 }").</p>
+</li>
+<li>
+<p>since early 2021 with 765dc168882, we have been using variadic
+macros, mostly for printf-like trace and debug macros.</p>
+<div class="literalblock">
+<div class="content">
+<pre>These used to be forbidden, but we have not heard any breakage
+report, and they are assumed to be safe.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>Variables have to be declared at the beginning of the block, before
+the first statement (i.e. -Wdeclaration-after-statement).</p>
+</li>
+<li>
+<p>Declaring a variable in the for loop "for (int i = 0; i &lt; 10; i++)"
+is still not allowed in this codebase.  We are in the process of
+allowing it by waiting to see that 44ba10d6 (revision: use C99
+declaration of variable in for() loop, 2021-11-14) does not get
+complaints.  Let&#8217;s revisit this around November 2022.</p>
+</li>
+<li>
+<p>NULL pointers shall be written as NULL, not as 0.</p>
+</li>
+<li>
+<p>When declaring pointers, the star sides with the variable
+name, i.e. "char <strong>string", not "char</strong> string" or
+"char * string".  This makes it easier to understand code
+like "char *string, c;".</p>
+</li>
+<li>
+<p>Use whitespace around operators and keywords, but not inside
+parentheses and not around functions. So:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      while (condition)
+func(bar + 1);</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>      while( condition )
+func (bar+1);</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Do not explicitly compare an integral value with constant 0 or <em>\0</em>,
+or a pointer value with constant NULL.  For instance, to validate that
+counted array &lt;ptr, cnt&gt; is initialized but has no elements, write:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (!ptr || cnt)
+	BUG("empty array expected");</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (ptr == NULL || cnt != 0);
+	BUG("empty array expected");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We avoid using braces unnecessarily.  I.e.</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (bla) {
+	x = 1;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is frowned upon. But there are a few exceptions:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When the statement extends over a few lines (e.g., a while loop
+with an embedded conditional, or a comment). E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (foo) {
+	if (x)
+		one();
+	else
+		two();
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	/*
+	 * This one requires some explanation,
+	 * so we're better off with braces to make
+	 * it obvious that the indentation is correct.
+	 */
+	doit();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When there are multiple arms to a conditional and some of them
+require braces, enclose even a single line block in braces for
+consistency. E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	doit();
+} else {
+	one();
+	two();
+	three();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments in the condition of an "if" statement.</p>
+</li>
+<li>
+<p>Try to make your code understandable.  You may put comments
+in, but comments invariably tend to stale out when the code
+they were describing changes.  Often splitting a function
+into two makes the intention of the code much clearer.</p>
+</li>
+<li>
+<p>Multi-line comments include their delimiters on separate lines from
+the text.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * A very long
+ * multi-line comment.
+ */</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Note however that a comment that explains a translatable string to
+translators uses a convention of starting with a magic token
+"TRANSLATORS: ", e.g.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * TRANSLATORS: here is a comment that explains the string to
+ * be translated, that follows immediately after it.
+ */
+_("Here is a translatable string explained by the above.");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Double negation is often harder to understand than no negation
+at all.</p>
+</li>
+<li>
+<p>There are two schools of thought when it comes to comparison,
+especially inside a loop. Some people prefer to have the less stable
+value on the left hand side and the more stable value on the right hand
+side, e.g. if you have a loop that counts variable i down to the
+lower bound,</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (i &gt; lower_bound) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Other people prefer to have the textual order of values match the
+actual order of values in their comparison, so that they can
+mentally draw a number line from left to right and place these
+values in order, i.e.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while (lower_bound &lt; i) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  However, the more "stable" the
+stable side becomes, the more we tend to prefer the former
+(comparison with a constant, "i &gt; 0", is an extreme example).
+Just do not mix styles in the same part of the code and mimic
+existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>There are two schools of thought when it comes to splitting a long
+logical line into multiple lines.  Some people push the second and
+subsequent lines far enough to the right with tabs and align them:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+              ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to align the second and the subsequent
+lines with the column immediately inside the opening parenthesis,
+with tabs and spaces, following our "tabstop is always a multiple
+of 8" convention:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+           ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  Again, just do not mix styles in
+the same part of the code and mimic existing styles in the
+neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, some people change line before
+a binary operator, so that the result looks like a parse tree when
+you turn your head 90-degrees counterclockwise:</p>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to
+|| span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to leave the operator at the end of the
+line:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, but we tend to use the latter more, unless the
+expression gets fairly complex, in which case the former tends to
+be easier to read.  Again, just do not mix styles in the same part
+of the code and mimic existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, with everything else being
+equal, it is preferable to split after the operator at higher
+level in the parse tree.  That is, this is more preferable:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable * that_is_used_in +
+    a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>than</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable *
+    that_is_used_in + a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Some clever tricks, like using the !! operator with arithmetic
+constructs, can be extremely confusing to others.  Avoid them,
+unless there is a compelling reason to use them.</p>
+</li>
+<li>
+<p>Use the API.  No, really.  We have a strbuf (variable length
+string), several arrays with the ALLOC_GROW() macro, a
+string_list for sorted string lists, a hash map (mapping struct
+objects) named "struct decorate", amongst other things.</p>
+</li>
+<li>
+<p>When you come up with an API, document its functions and structures
+in the header file that exposes the API to its callers. Use what is
+in "strbuf.h" as a model for the appropriate tone and level of
+detail.</p>
+</li>
+<li>
+<p>The first #include in C files, except in platform specific compat/
+implementations, must be either "git-compat-util.h", "cache.h" or
+"builtin.h".  You do not have to include more than one of these.</p>
+</li>
+<li>
+<p>A C file must directly include the header files that declare the
+functions and the types it uses, except for the functions and types
+that are made available to it by including one of the header files
+it must include by the previous rule.</p>
+</li>
+<li>
+<p>If you are planning a new command, consider writing it in shell
+or perl first, so that changes in semantics can be easily
+changed and discussed.  Many Git commands started out like
+that, and a few are still scripts.</p>
+</li>
+<li>
+<p>Avoid introducing a new dependency into Git. This means you
+usually should stay away from scripting languages not already
+used in the Git core command set (unless your command is clearly
+separate from it, such as an importer to convert random-scm-X
+repositories to Git).</p>
+</li>
+<li>
+<p>When we pass &lt;string, length&gt; pair to functions, we should try to
+pass them in that order.</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers to make the user interface
+translatable. See "Marking strings for translation" in po/README.</p>
+</li>
+<li>
+<p>Variables and functions local to a given source file should be marked
+with "static". Variables that are visible to other source files
+must be declared with "extern" in header files. However, function
+declarations should not use "extern", as that is already the default.</p>
+</li>
+<li>
+<p>You can launch gdb around your program using the shorthand GIT_DEBUGGER.
+Run <code>GIT_DEBUGGER=1 ./bin-wrappers/git foo</code> to simply use gdb as is, or
+run <code>GIT_DEBUGGER="&lt;debugger&gt; &lt;debugger-args&gt;" ./bin-wrappers/git foo</code> to
+use your own debugger and arguments. Example: <code>GIT_DEBUGGER="ddd --gdb"
+./bin-wrappers/git log</code> (See <code>wrap-for-bin.sh</code>.)</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Perl programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most of the C guidelines above apply.</p>
+</li>
+<li>
+<p>We try to support Perl 5.8 and later ("use Perl 5.008").</p>
+</li>
+<li>
+<p>use strict and use warnings are strongly preferred.</p>
+</li>
+<li>
+<p>Don&#8217;t overuse statement modifiers unless using them makes the
+result easier to follow.</p>
+<div class="olist lowerroman">
+<ol class="lowerroman" type="i">
+<li>
+<p>do something &#8230;&#8203;
+do_this() unless (condition);</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>is more readable than:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>do something &#8230;&#8203;
+unless (condition) {
+	do_this();
+}</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>*only* when the condition is so rare that do_this() will be almost
+always called.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments inside "if ()" conditions.</p>
+</li>
+<li>
+<p>Learn and use Git.pm if you need that functionality.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Python scripts:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We follow PEP-8 (<a href="http://www.python.org/dev/peps/pep-0008/" class="bare">http://www.python.org/dev/peps/pep-0008/</a>).</p>
+</li>
+<li>
+<p>As a minimum, we aim to be compatible with Python 2.7.</p>
+</li>
+<li>
+<p>Where required libraries do not restrict us to Python 2, we try to
+also be compatible with Python 3.1 and later.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Program Output</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>We make a distinction between a Git command's primary output and
+output which is merely chatty feedback (for instance, status
+messages, running transcript, or progress display), as well as error
+messages. Roughly speaking, a Git command's primary output is that
+which one might want to capture to a file or send down a pipe; its
+chatty output should not interfere with these use-cases.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>As such, primary output should be sent to the standard output stream
+(stdout), and chatty output should be sent to the standard error
+stream (stderr). Examples of commands which produce primary output
+include `git log`, `git show`, and `git branch --list` which generate
+output on the stdout stream.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Not all Git commands have primary output; this is often true of
+commands whose main function is to perform an action. Some action
+commands are silent, whereas others are chatty. An example of a
+chatty action commands is `git clone` with its "Cloning into
+'&lt;path&gt;'..." and "Checking connectivity..." status messages which it
+sends to the stderr stream.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Error messages from Git commands should always be sent to the stderr
+stream.</pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Error Messages</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Do not end error messages with a full stop.</p>
+</li>
+<li>
+<p>Do not capitalize the first word, only because it is the first word
+in the message ("unable to open %s", not "Unable to open %s").  But
+"SHA-3 not supported" is fine, because the reason the first word is
+capitalized is not because it is at the beginning of the sentence,
+but because the word would be spelled in capital letters even when
+it appeared in the middle of the sentence.</p>
+</li>
+<li>
+<p>Say what the error is first ("cannot open %s", not "%s: cannot open")</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Externally Visible Names</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>For configuration variable names, follow the existing convention:</p>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>The section name indicates the affected subsystem.</p>
+</li>
+<li>
+<p>The subsection name, if any, indicates which of an unbounded set
+of things to set the value for.</p>
+</li>
+<li>
+<p>The variable name describes the effect of tweaking this knob.</p>
+<div class="literalblock">
+<div class="content">
+<pre>The section and variable names that consist of multiple words are
+formed by concatenating the words without punctuations (e.g. `-`),
+and are broken using bumpyCaps in documentation as a hint to the
+reader.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>When choosing the variable namespace, do not use variable name for
+specifying possibly unbounded set of things, most notably anything
+an end user can freely come up with (e.g. branch names).  Instead,
+use subsection names or variable values, like the existing variable
+branch.&lt;name&gt;.description does.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Writing Documentation:</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Most (if not all) of the documentation pages are written in the
+AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+processed into HTML and manpages (e.g. git.html and git.1 in the
+same directory).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>The documentation liberally mixes US and UK English (en_US/UK)
+norms for spelling and grammar, which is somewhat unfortunate.
+In an ideal world, it would have been better if it consistently
+used only one and not the other, and we would have picked en_US
+(if you wish to correct the English of some of the existing
+documentation, please see the documentation-related advice in the
+Documentation/SubmittingPatches file).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>In order to ensure the documentation is inclusive, avoid assuming
+that an unspecified example person is male or female, and think
+twice before using "he", "him", "she", or "her".  Here are some
+tips to avoid use of gendered pronouns:</pre>
+</div>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Prefer succinctness and matter-of-factly describing functionality
+in the abstract.  E.g.</p>
+<div class="dlist">
+<dl>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short"> <a class="anchor" href="#Documentation/CodingGuidelines---short"></a>--short </dt>
+<dd>
+<p>Emit output in the short-format.</p>
+<div class="literalblock">
+<div class="content">
+<pre>and avoid something like these overly verbose alternatives:</pre>
+</div>
+</div>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short-1"> <a class="anchor" href="#Documentation/CodingGuidelines---short-1"></a>--short </dt>
+<dd>
+<p>Use this to emit output in the short-format.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short-1-1"> <a class="anchor" href="#Documentation/CodingGuidelines---short-1-1"></a>--short </dt>
+<dd>
+<p>You can use this to get output in the short-format.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short-1-1-1"> <a class="anchor" href="#Documentation/CodingGuidelines---short-1-1-1"></a>--short </dt>
+<dd>
+<p>A user who prefers shorter output could&#8230;&#8203;.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short-1-1-1-1"> <a class="anchor" href="#Documentation/CodingGuidelines---short-1-1-1-1"></a>--short </dt>
+<dd>
+<p>Should a person and/or program want shorter output, he
+she/they/it can&#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>This practice often eliminates the need to involve human actors in
+your description, but it is a good practice regardless of the
+avoidance of gendered pronouns.</pre>
+</div>
+</div>
+</dd>
+</dl>
+</div>
+</li>
+<li>
+<p>When it becomes awkward to stick to this style, prefer "you" when
+addressing the hypothetical user, and possibly "we" when
+discussing how the program might react to the user.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>You can use this option instead of --xyz, but we might remove
+support for it in future versions.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while keeping in mind that you can probably be less verbose, e.g.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Use this instead of --xyz. This option might be removed in future
+versions.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>If you still need to refer to an example person that is
+third-person singular, you may resort to "singular they" to avoid
+"he/she/him/her", e.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>A contributor asks their upstream to pull from them.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Note that this sounds ungrammatical and unnatural to those who
+learned that "they" is only used for third-person plural, e.g.
+those who learn English as a second language in some parts of the
+world.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Every user-visible change should be reflected in the documentation.
+The same general rule as for code applies -- imitate the existing
+conventions.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying command usage strings and synopsis sections in the manual
+pages:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Placeholders are spelled in lowercase and enclosed in angle brackets:
+  &lt;file&gt;
+  --sort=&lt;key&gt;
+  --abbrev[=&lt;n&gt;]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If a placeholder has multiple words, they are separated by dashes:
+  &lt;new-branch-name&gt;
+  --template=&lt;template-directory&gt;</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Possibility of multiple occurrences is indicated by three dots:
+  &lt;file&gt;...
+  (One or more of &lt;file&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Optional parts are enclosed in square brackets:
+  [&lt;extra&gt;]
+  (Zero or one &lt;extra&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>--exec-path[=&lt;path&gt;]
+(Option with an optional argument.  Note that the "=" is inside the
+brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[&lt;patch&gt;...]
+(Zero or more of &lt;patch&gt;.  Note that the dots are inside, not
+outside the brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Multiple alternatives are indicated with vertical bars:
+  [-q | --quiet]
+  [--utf8 | --no-utf8]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Parentheses are used for grouping:
+  [(&lt;rev&gt; | &lt;range&gt;)...]
+  (Any number of either &lt;rev&gt; or &lt;range&gt;.  Parens are needed to make
+  it clear that "..." pertains to both &lt;rev&gt; and &lt;range&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[(-p &lt;parent&gt;)...]
+(Any number of option -p, each with one &lt;parent&gt; argument.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>git remote set-head &lt;name&gt; (-a | -d | &lt;branch&gt;)
+(One and only one of "-a", "-d" or "&lt;branch&gt;" _must_ (no square
+brackets) be provided.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>And a somewhat more contrived example:
+  --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+  Here "=" is outside the brackets, because "--diff-filter=" is a
+  valid usage.  "*" has its own pair of brackets, because it can
+  (optionally) be specified only when one or more of the letters is
+  also provided.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A note on notation:
+ Use 'git' (all lowercase) when talking about commands i.e. something
+ the user would type into a shell and use 'Git' (uppercase first letter)
+ when talking about the version control system and its properties.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying paragraphs or option/command explanations that contain options
+or commands:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Literal examples (e.g. use of command-line options, command names,
+branch names, URLs, pathnames (files and directories), configuration and
+environment variables) must be typeset in monospace (i.e. wrapped with
+backticks):
+  `--pretty=oneline`
+  `git rev-list`
+  `remote.pushDefault`
+  `http://git.example.com`
+  `.git/config`
+  `GIT_DIR`
+  `HEAD`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>An environment variable must be prefixed with "$" only when referring to its
+value and not when referring to the variable itself, in this case there is
+nothing to add except the backticks:
+  `GIT_DIR` is specified
+  `$GIT_DIR/hooks/pre-receive`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Word phrases enclosed in `backtick characters` are rendered literally
+and will not be further expanded. The use of `backticks` to achieve the
+previous rule means that literal examples should not use AsciiDoc
+escapes.
+  Correct:
+     `--pretty=oneline`
+  Incorrect:
+     `\--pretty=oneline`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If some place in the documentation needs to typeset a command usage
+example with inline substitutions, it is fine to use +monospaced and
+inline substituted text+ instead of `monospaced literal text`, and with
+the former, the part that should not get substituted must be
+quoted/escaped.</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+</div>
+</div>
\ No newline at end of file
diff --git a/external/docs/content/docs/CodingGuidelines/2.38.2.html b/external/docs/content/docs/CodingGuidelines/2.38.2.html
new file mode 100644
index 0000000000..9c31ec1441
--- /dev/null
+++ b/external/docs/content/docs/CodingGuidelines/2.38.2.html
@@ -0,0 +1,1176 @@
+---
+### DO NOT EDIT! Generated by script/update-docs.rb
+
+category: manual
+section: documentation
+subsection: manual
+title: Git - CodingGuidelines Documentation
+docname: CodingGuidelines
+version: 2.38.2
+aliases:
+- "/docs/CodingGuidelines/2.38.2/index.html"
+- "/docs/CodingGuidelines/2.38.3/index.html"
+- "/docs/CodingGuidelines/2.38.4/index.html"
+- "/docs/CodingGuidelines/2.38.5/index.html"
+---
+<div id="preamble">
+<div class="sectionbody">
+<div class="paragraph">
+<p>Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, a few rough rules are:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most importantly, we never say "It&#8217;s in POSIX; we&#8217;ll happily
+ignore your needs should your system not conform to it."
+We live in the real world.</p>
+</li>
+<li>
+<p>However, we often say "Let&#8217;s stay away from that construct,
+it&#8217;s not even in POSIX".</p>
+</li>
+<li>
+<p>In spite of the above two rules, we sometimes say "Although
+this is not in POSIX, it (is so convenient | makes the code
+much more readable | has other good characteristics) and
+practically all the platforms we care about support it, so
+let&#8217;s use it".</p>
+<div class="literalblock">
+<div class="content">
+<pre>Again, we live in the real world, and it is sometimes a
+judgement call, the decision based more on real world
+constraints people face than what the paper standard says.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Fixing style violations while working on a real change as a
+preparatory clean-up step is good, but otherwise avoid useless code
+churn for the sake of conforming to the style.</p>
+<div class="literalblock">
+<div class="content">
+<pre>"Once it _is_ in the tree, it's not really worth the patch noise to
+go and fix it up."
+Cf. http://lkml.iu.edu/hypermail/linux/kernel/1001.3/01069.html</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Log messages to explain your changes are as important as the
+changes themselves.  Clearly written code and in-code comments
+explain how the code works and what is assumed from the surrounding
+context.  The log messages explain what the changes wanted to
+achieve and why the changes were necessary (more on this in the
+accompanying SubmittingPatches document).</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Make your code readable and sensible, and don&#8217;t try to be clever.</p>
+</div>
+<div class="paragraph">
+<p>As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the <em>local</em>
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn&#8217;t match the overall style of existing code).</p>
+</div>
+<div class="paragraph">
+<p>But if you must have a list of rules, here are some language
+specific ones. Note that Documentation/ToolsForGit.txt document
+has a collection of tips to help you use some external tools
+to conform to these guidelines.</p>
+</div>
+<div class="paragraph">
+<p>For shell scripts specifically (not exhaustive):</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs for indentation.</p>
+</li>
+<li>
+<p>Case arms are indented at the same depth as case and esac lines,
+like this:</p>
+<div class="literalblock">
+<div class="content">
+<pre>case "$variable" in
+pattern1)
+	do this
+	;;
+pattern2)
+	do that
+	;;
+esac</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Redirection operators should be written with space before, but no
+space after them.  In other words, write <em>echo test &gt;"$file"</em>
+instead of <em>echo test&gt; $file</em> or <em>echo test &gt; $file</em>.  Note that
+even though it is not required by POSIX to double-quote the
+redirection target in a variable (as shown above), our code does so
+because some versions of bash issue a warning without the quotes.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+cat hello &gt; world &lt; universe
+echo hello &gt;$world</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+cat hello &gt;world &lt;universe
+echo hello &gt;"$world"</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer $( &#8230;&#8203; ) for command substitution; unlike ``, it
+properly nests.  It should have been the way Bourne spelled
+it from day one, but unfortunately isn&#8217;t.</p>
+</li>
+<li>
+<p>If you want to find out if a command is available on the user&#8217;s
+$PATH, you should use <em>type &lt;command&gt;</em>, instead of <em>which &lt;command&gt;</em>.
+The output of <em>which</em> is not machine parsable and its exit code
+is not reliable across platforms.</p>
+</li>
+<li>
+<p>We use POSIX compliant parameter substitutions and avoid bashisms;
+namely:</p>
+</li>
+<li>
+<p>We use ${parameter-word} and its [-=?+] siblings, and their
+colon&#8217;ed "unset or null" form.</p>
+</li>
+<li>
+<p>We use ${parameter#word} and its [#%] siblings, and their
+doubled "longest matching" form.</p>
+</li>
+<li>
+<p>No "Substring Expansion" ${parameter:offset:length}.</p>
+</li>
+<li>
+<p>No shell arrays.</p>
+</li>
+<li>
+<p>No pattern replacement ${parameter/pattern/string}.</p>
+</li>
+<li>
+<p>We use Arithmetic Expansion $&#8230;&#8203;.</p>
+</li>
+<li>
+<p>We do not use Process Substitution &lt;(list) or &gt;(list).</p>
+</li>
+<li>
+<p>Do not write control structures on a single line with semicolon.
+"then" should be on the next line for if statements, and "do"
+should be on the next line for "while" and "for".</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+if test -f hello; then
+	do this
+fi</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+if test -f hello
+then
+	do this
+fi</pre>
+</div>
+</div>
+</li>
+<li>
+<p>If a command sequence joined with &amp;&amp; or || or | spans multiple
+lines, put each command on a separate line and put &amp;&amp; and || and |
+operators at the end of each line, rather than the start. This
+means you don&#8217;t need to use \ to join lines, since the above
+operators imply the sequence isn&#8217;t finished.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+grep blob verify_pack_result \
+| awk -f print_1.awk \
+| sort &gt;actual &amp;&amp;
+...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+grep blob verify_pack_result |
+awk -f print_1.awk |
+sort &gt;actual &amp;&amp;
+...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer "test" over "[ &#8230;&#8203; ]".</p>
+</li>
+<li>
+<p>We do not write the noiseword "function" in front of shell
+functions.</p>
+</li>
+<li>
+<p>We prefer a space between the function name and the parentheses,
+and no space inside the parentheses. The opening "{" should also
+be on the same line.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+my_function(){
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+my_function () {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+[::], [==], or [..]) for portability.</p>
+</li>
+<li>
+<p>We do not use \{m,n\};</p>
+</li>
+<li>
+<p>We do not use -E;</p>
+</li>
+<li>
+<p>We do not use ? or + (which are \{0,1\} and \{1,\}
+respectively in BRE) but that goes without saying as these
+are ERE elements not BRE (note that \? and \+ are not even part
+of BRE&#8201;&#8212;&#8201;making them accessible from BRE is a GNU extension).</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers in git-sh-i18n to make the user
+interface translatable. See "Marking strings for translation" in
+po/README.</p>
+</li>
+<li>
+<p>We do not write our "test" command with "-a" and "-o" and use "&amp;&amp;"
+or "||" to concatenate multiple "test" commands instead, because
+the use of "-a/-o" is often error-prone.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" -a "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is buggy and breaks when $x is "=", but</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" &amp;&amp; test "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>does not have such a problem.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Even though "local" is not part of POSIX, we make heavy use of it
+in our test suite.  We do not use it in scripted Porcelains, and
+hopefully nobody starts using "local" before they are reimplemented
+in C ;-)</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For C programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs to indent, and interpret tabs as taking up to
+8 spaces.</p>
+</li>
+<li>
+<p>We try to keep to at most 80 characters per line.</p>
+</li>
+<li>
+<p>As a Git developer we assume you have a reasonably modern compiler
+and we recommend you to enable the DEVELOPER makefile knob to
+ensure your patch is clear of all compiler warnings we care about,
+by e.g. "echo DEVELOPER=1 &gt;&gt;config.mak".</p>
+</li>
+<li>
+<p>We try to support a wide range of C compilers to compile Git with,
+including old ones.  As of Git v2.35.0 Git requires C99 (we check
+"<em>STDC_VERSION</em>"). You should not use features from a newer C
+standard, even if your compiler groks them.</p>
+<div class="literalblock">
+<div class="content">
+<pre>New C99 features have been phased in gradually, if something's new
+in C99 but not used yet don't assume that it's safe to use, some
+compilers we target have only partial support for it. These are
+considered safe to use:</pre>
+</div>
+</div>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>since around 2007 with 2b6854c863a, we have been using
+initializer elements which are not computable at load time. E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>const char *args[] = {"constant", variable, NULL};</pre>
+</div>
+</div>
+</li>
+<li>
+<p>since early 2012 with e1327023ea, we have been using an enum
+definition whose last element is followed by a comma.  This, like
+an array initializer that ends with a trailing comma, can be used
+to reduce the patch noise when adding a new identifier at the end.</p>
+</li>
+<li>
+<p>since mid 2017 with cbc0f81d, we have been using designated
+initializers for struct (e.g. "struct t v = { .val = <em>a</em> };").</p>
+</li>
+<li>
+<p>since mid 2017 with 512f41cf, we have been using designated
+initializers for array (e.g. "int array[10] = { [5] = 2 }").</p>
+</li>
+<li>
+<p>since early 2021 with 765dc168882, we have been using variadic
+macros, mostly for printf-like trace and debug macros.</p>
+</li>
+<li>
+<p>since late 2021 with 44ba10d6, we have had variables declared in
+the for loop "for (int i = 0; i &lt; 10; i++)".</p>
+<div class="literalblock">
+<div class="content">
+<pre>New C99 features that we cannot use yet:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>%z and %zu as a printf() argument for a size_t (the %z being for
+the POSIX-specific ssize_t). Instead you should use
+printf("%"PRIuMAX, (uintmax_t)v).  These days the MSVC version we
+rely on supports %z, but the C library used by MinGW does not.</p>
+</li>
+<li>
+<p>Shorthand like ".a.b = *c" in struct initializations is known to
+trip up an older IBM XLC version, use ".a = { .b = *c }" instead.
+See the 33665d98 (reftable: make assignments portable to AIX xlc
+v12.01, 2022-03-28).</p>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>Variables have to be declared at the beginning of the block, before
+the first statement (i.e. -Wdeclaration-after-statement).</p>
+</li>
+<li>
+<p>NULL pointers shall be written as NULL, not as 0.</p>
+</li>
+<li>
+<p>When declaring pointers, the star sides with the variable
+name, i.e. "char <strong>string", not "char</strong> string" or
+"char * string".  This makes it easier to understand code
+like "char *string, c;".</p>
+</li>
+<li>
+<p>Use whitespace around operators and keywords, but not inside
+parentheses and not around functions. So:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      while (condition)
+func(bar + 1);</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>      while( condition )
+func (bar+1);</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Do not explicitly compare an integral value with constant 0 or <em>\0</em>,
+or a pointer value with constant NULL.  For instance, to validate that
+counted array &lt;ptr, cnt&gt; is initialized but has no elements, write:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (!ptr || cnt)
+	BUG("empty array expected");</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (ptr == NULL || cnt != 0);
+	BUG("empty array expected");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We avoid using braces unnecessarily.  I.e.</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (bla) {
+	x = 1;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is frowned upon. But there are a few exceptions:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When the statement extends over a few lines (e.g., a while loop
+with an embedded conditional, or a comment). E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (foo) {
+	if (x)
+		one();
+	else
+		two();
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	/*
+	 * This one requires some explanation,
+	 * so we're better off with braces to make
+	 * it obvious that the indentation is correct.
+	 */
+	doit();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When there are multiple arms to a conditional and some of them
+require braces, enclose even a single line block in braces for
+consistency. E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	doit();
+} else {
+	one();
+	two();
+	three();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments in the condition of an "if" statement.</p>
+</li>
+<li>
+<p>Try to make your code understandable.  You may put comments
+in, but comments invariably tend to stale out when the code
+they were describing changes.  Often splitting a function
+into two makes the intention of the code much clearer.</p>
+</li>
+<li>
+<p>Multi-line comments include their delimiters on separate lines from
+the text.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * A very long
+ * multi-line comment.
+ */</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Note however that a comment that explains a translatable string to
+translators uses a convention of starting with a magic token
+"TRANSLATORS: ", e.g.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * TRANSLATORS: here is a comment that explains the string to
+ * be translated, that follows immediately after it.
+ */
+_("Here is a translatable string explained by the above.");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Double negation is often harder to understand than no negation
+at all.</p>
+</li>
+<li>
+<p>There are two schools of thought when it comes to comparison,
+especially inside a loop. Some people prefer to have the less stable
+value on the left hand side and the more stable value on the right hand
+side, e.g. if you have a loop that counts variable i down to the
+lower bound,</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (i &gt; lower_bound) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Other people prefer to have the textual order of values match the
+actual order of values in their comparison, so that they can
+mentally draw a number line from left to right and place these
+values in order, i.e.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while (lower_bound &lt; i) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  However, the more "stable" the
+stable side becomes, the more we tend to prefer the former
+(comparison with a constant, "i &gt; 0", is an extreme example).
+Just do not mix styles in the same part of the code and mimic
+existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>There are two schools of thought when it comes to splitting a long
+logical line into multiple lines.  Some people push the second and
+subsequent lines far enough to the right with tabs and align them:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+              ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to align the second and the subsequent
+lines with the column immediately inside the opening parenthesis,
+with tabs and spaces, following our "tabstop is always a multiple
+of 8" convention:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+           ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  Again, just do not mix styles in
+the same part of the code and mimic existing styles in the
+neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, some people change line before
+a binary operator, so that the result looks like a parse tree when
+you turn your head 90-degrees counterclockwise:</p>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to
+|| span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to leave the operator at the end of the
+line:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, but we tend to use the latter more, unless the
+expression gets fairly complex, in which case the former tends to
+be easier to read.  Again, just do not mix styles in the same part
+of the code and mimic existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, with everything else being
+equal, it is preferable to split after the operator at higher
+level in the parse tree.  That is, this is more preferable:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable * that_is_used_in +
+    a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>than</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable *
+    that_is_used_in + a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Some clever tricks, like using the !! operator with arithmetic
+constructs, can be extremely confusing to others.  Avoid them,
+unless there is a compelling reason to use them.</p>
+</li>
+<li>
+<p>Use the API.  No, really.  We have a strbuf (variable length
+string), several arrays with the ALLOC_GROW() macro, a
+string_list for sorted string lists, a hash map (mapping struct
+objects) named "struct decorate", amongst other things.</p>
+</li>
+<li>
+<p>When you come up with an API, document its functions and structures
+in the header file that exposes the API to its callers. Use what is
+in "strbuf.h" as a model for the appropriate tone and level of
+detail.</p>
+</li>
+<li>
+<p>The first #include in C files, except in platform specific compat/
+implementations, must be either "git-compat-util.h", "cache.h" or
+"builtin.h".  You do not have to include more than one of these.</p>
+</li>
+<li>
+<p>A C file must directly include the header files that declare the
+functions and the types it uses, except for the functions and types
+that are made available to it by including one of the header files
+it must include by the previous rule.</p>
+</li>
+<li>
+<p>If you are planning a new command, consider writing it in shell
+or perl first, so that changes in semantics can be easily
+changed and discussed.  Many Git commands started out like
+that, and a few are still scripts.</p>
+</li>
+<li>
+<p>Avoid introducing a new dependency into Git. This means you
+usually should stay away from scripting languages not already
+used in the Git core command set (unless your command is clearly
+separate from it, such as an importer to convert random-scm-X
+repositories to Git).</p>
+</li>
+<li>
+<p>When we pass &lt;string, length&gt; pair to functions, we should try to
+pass them in that order.</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers to make the user interface
+translatable. See "Marking strings for translation" in po/README.</p>
+</li>
+<li>
+<p>Variables and functions local to a given source file should be marked
+with "static". Variables that are visible to other source files
+must be declared with "extern" in header files. However, function
+declarations should not use "extern", as that is already the default.</p>
+</li>
+<li>
+<p>You can launch gdb around your program using the shorthand GIT_DEBUGGER.
+Run <code>GIT_DEBUGGER=1 ./bin-wrappers/git foo</code> to simply use gdb as is, or
+run <code>GIT_DEBUGGER="&lt;debugger&gt; &lt;debugger-args&gt;" ./bin-wrappers/git foo</code> to
+use your own debugger and arguments. Example: <code>GIT_DEBUGGER="ddd --gdb"
+./bin-wrappers/git log</code> (See <code>wrap-for-bin.sh</code>.)</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Perl programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most of the C guidelines above apply.</p>
+</li>
+<li>
+<p>We try to support Perl 5.8 and later ("use Perl 5.008").</p>
+</li>
+<li>
+<p>use strict and use warnings are strongly preferred.</p>
+</li>
+<li>
+<p>Don&#8217;t overuse statement modifiers unless using them makes the
+result easier to follow.</p>
+<div class="olist lowerroman">
+<ol class="lowerroman" type="i">
+<li>
+<p>do something &#8230;&#8203;
+do_this() unless (condition);</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>is more readable than:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>do something &#8230;&#8203;
+unless (condition) {
+	do_this();
+}</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>*only* when the condition is so rare that do_this() will be almost
+always called.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments inside "if ()" conditions.</p>
+</li>
+<li>
+<p>Learn and use Git.pm if you need that functionality.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Python scripts:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We follow PEP-8 (<a href="http://www.python.org/dev/peps/pep-0008/" class="bare">http://www.python.org/dev/peps/pep-0008/</a>).</p>
+</li>
+<li>
+<p>As a minimum, we aim to be compatible with Python 2.7.</p>
+</li>
+<li>
+<p>Where required libraries do not restrict us to Python 2, we try to
+also be compatible with Python 3.1 and later.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Program Output</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>We make a distinction between a Git command's primary output and
+output which is merely chatty feedback (for instance, status
+messages, running transcript, or progress display), as well as error
+messages. Roughly speaking, a Git command's primary output is that
+which one might want to capture to a file or send down a pipe; its
+chatty output should not interfere with these use-cases.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>As such, primary output should be sent to the standard output stream
+(stdout), and chatty output should be sent to the standard error
+stream (stderr). Examples of commands which produce primary output
+include `git log`, `git show`, and `git branch --list` which generate
+output on the stdout stream.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Not all Git commands have primary output; this is often true of
+commands whose main function is to perform an action. Some action
+commands are silent, whereas others are chatty. An example of a
+chatty action commands is `git clone` with its "Cloning into
+'&lt;path&gt;'..." and "Checking connectivity..." status messages which it
+sends to the stderr stream.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Error messages from Git commands should always be sent to the stderr
+stream.</pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Error Messages</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Do not end error messages with a full stop.</p>
+</li>
+<li>
+<p>Do not capitalize the first word, only because it is the first word
+in the message ("unable to open %s", not "Unable to open %s").  But
+"SHA-3 not supported" is fine, because the reason the first word is
+capitalized is not because it is at the beginning of the sentence,
+but because the word would be spelled in capital letters even when
+it appeared in the middle of the sentence.</p>
+</li>
+<li>
+<p>Say what the error is first ("cannot open %s", not "%s: cannot open")</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Externally Visible Names</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>For configuration variable names, follow the existing convention:</p>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>The section name indicates the affected subsystem.</p>
+</li>
+<li>
+<p>The subsection name, if any, indicates which of an unbounded set
+of things to set the value for.</p>
+</li>
+<li>
+<p>The variable name describes the effect of tweaking this knob.</p>
+<div class="literalblock">
+<div class="content">
+<pre>The section and variable names that consist of multiple words are
+formed by concatenating the words without punctuations (e.g. `-`),
+and are broken using bumpyCaps in documentation as a hint to the
+reader.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>When choosing the variable namespace, do not use variable name for
+specifying possibly unbounded set of things, most notably anything
+an end user can freely come up with (e.g. branch names).  Instead,
+use subsection names or variable values, like the existing variable
+branch.&lt;name&gt;.description does.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Writing Documentation:</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Most (if not all) of the documentation pages are written in the
+AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+processed into HTML and manpages (e.g. git.html and git.1 in the
+same directory).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>The documentation liberally mixes US and UK English (en_US/UK)
+norms for spelling and grammar, which is somewhat unfortunate.
+In an ideal world, it would have been better if it consistently
+used only one and not the other, and we would have picked en_US
+(if you wish to correct the English of some of the existing
+documentation, please see the documentation-related advice in the
+Documentation/SubmittingPatches file).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>In order to ensure the documentation is inclusive, avoid assuming
+that an unspecified example person is male or female, and think
+twice before using "he", "him", "she", or "her".  Here are some
+tips to avoid use of gendered pronouns:</pre>
+</div>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Prefer succinctness and matter-of-factly describing functionality
+in the abstract.  E.g.</p>
+<div class="dlist">
+<dl>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short"> <a class="anchor" href="#Documentation/CodingGuidelines---short"></a>--short </dt>
+<dd>
+<p>Emit output in the short-format.</p>
+<div class="literalblock">
+<div class="content">
+<pre>and avoid something like these overly verbose alternatives:</pre>
+</div>
+</div>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short-1"> <a class="anchor" href="#Documentation/CodingGuidelines---short-1"></a>--short </dt>
+<dd>
+<p>Use this to emit output in the short-format.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short-1-1"> <a class="anchor" href="#Documentation/CodingGuidelines---short-1-1"></a>--short </dt>
+<dd>
+<p>You can use this to get output in the short-format.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short-1-1-1"> <a class="anchor" href="#Documentation/CodingGuidelines---short-1-1-1"></a>--short </dt>
+<dd>
+<p>A user who prefers shorter output could&#8230;&#8203;.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short-1-1-1-1"> <a class="anchor" href="#Documentation/CodingGuidelines---short-1-1-1-1"></a>--short </dt>
+<dd>
+<p>Should a person and/or program want shorter output, he
+she/they/it can&#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>This practice often eliminates the need to involve human actors in
+your description, but it is a good practice regardless of the
+avoidance of gendered pronouns.</pre>
+</div>
+</div>
+</dd>
+</dl>
+</div>
+</li>
+<li>
+<p>When it becomes awkward to stick to this style, prefer "you" when
+addressing the hypothetical user, and possibly "we" when
+discussing how the program might react to the user.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>You can use this option instead of --xyz, but we might remove
+support for it in future versions.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while keeping in mind that you can probably be less verbose, e.g.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Use this instead of --xyz. This option might be removed in future
+versions.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>If you still need to refer to an example person that is
+third-person singular, you may resort to "singular they" to avoid
+"he/she/him/her", e.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>A contributor asks their upstream to pull from them.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Note that this sounds ungrammatical and unnatural to those who
+learned that "they" is only used for third-person plural, e.g.
+those who learn English as a second language in some parts of the
+world.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Every user-visible change should be reflected in the documentation.
+The same general rule as for code applies -- imitate the existing
+conventions.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying command usage strings and synopsis sections in the manual
+pages:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Placeholders are spelled in lowercase and enclosed in angle brackets:
+  &lt;file&gt;
+  --sort=&lt;key&gt;
+  --abbrev[=&lt;n&gt;]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If a placeholder has multiple words, they are separated by dashes:
+  &lt;new-branch-name&gt;
+  --template=&lt;template-directory&gt;</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Possibility of multiple occurrences is indicated by three dots:
+  &lt;file&gt;...
+  (One or more of &lt;file&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Optional parts are enclosed in square brackets:
+  [&lt;extra&gt;]
+  (Zero or one &lt;extra&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>--exec-path[=&lt;path&gt;]
+(Option with an optional argument.  Note that the "=" is inside the
+brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[&lt;patch&gt;...]
+(Zero or more of &lt;patch&gt;.  Note that the dots are inside, not
+outside the brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Multiple alternatives are indicated with vertical bars:
+  [-q | --quiet]
+  [--utf8 | --no-utf8]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Parentheses are used for grouping:
+  [(&lt;rev&gt; | &lt;range&gt;)...]
+  (Any number of either &lt;rev&gt; or &lt;range&gt;.  Parens are needed to make
+  it clear that "..." pertains to both &lt;rev&gt; and &lt;range&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[(-p &lt;parent&gt;)...]
+(Any number of option -p, each with one &lt;parent&gt; argument.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>git remote set-head &lt;name&gt; (-a | -d | &lt;branch&gt;)
+(One and only one of "-a", "-d" or "&lt;branch&gt;" _must_ (no square
+brackets) be provided.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>And a somewhat more contrived example:
+  --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+  Here "=" is outside the brackets, because "--diff-filter=" is a
+  valid usage.  "*" has its own pair of brackets, because it can
+  (optionally) be specified only when one or more of the letters is
+  also provided.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A note on notation:
+ Use 'git' (all lowercase) when talking about commands i.e. something
+ the user would type into a shell and use 'Git' (uppercase first letter)
+ when talking about the version control system and its properties.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying paragraphs or option/command explanations that contain options
+or commands:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Literal examples (e.g. use of command-line options, command names,
+branch names, URLs, pathnames (files and directories), configuration and
+environment variables) must be typeset in monospace (i.e. wrapped with
+backticks):
+  `--pretty=oneline`
+  `git rev-list`
+  `remote.pushDefault`
+  `http://git.example.com`
+  `.git/config`
+  `GIT_DIR`
+  `HEAD`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>An environment variable must be prefixed with "$" only when referring to its
+value and not when referring to the variable itself, in this case there is
+nothing to add except the backticks:
+  `GIT_DIR` is specified
+  `$GIT_DIR/hooks/pre-receive`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Word phrases enclosed in `backtick characters` are rendered literally
+and will not be further expanded. The use of `backticks` to achieve the
+previous rule means that literal examples should not use AsciiDoc
+escapes.
+  Correct:
+     `--pretty=oneline`
+  Incorrect:
+     `\--pretty=oneline`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If some place in the documentation needs to typeset a command usage
+example with inline substitutions, it is fine to use +monospaced and
+inline substituted text+ instead of `monospaced literal text`, and with
+the former, the part that should not get substituted must be
+quoted/escaped.</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+</div>
+</div>
\ No newline at end of file
diff --git a/external/docs/content/docs/CodingGuidelines/2.39.0.html b/external/docs/content/docs/CodingGuidelines/2.39.0.html
new file mode 100644
index 0000000000..df83bc4c86
--- /dev/null
+++ b/external/docs/content/docs/CodingGuidelines/2.39.0.html
@@ -0,0 +1,1196 @@
+---
+### DO NOT EDIT! Generated by script/update-docs.rb
+
+category: manual
+section: documentation
+subsection: manual
+title: Git - CodingGuidelines Documentation
+docname: CodingGuidelines
+version: 2.39.0
+aliases:
+- "/docs/CodingGuidelines/2.39.0/index.html"
+- "/docs/CodingGuidelines/2.39.1/index.html"
+- "/docs/CodingGuidelines/2.39.2/index.html"
+- "/docs/CodingGuidelines/2.39.3/index.html"
+- "/docs/CodingGuidelines/2.39.4/index.html"
+- "/docs/CodingGuidelines/2.39.5/index.html"
+- "/docs/CodingGuidelines/2.40.0/index.html"
+- "/docs/CodingGuidelines/2.40.1/index.html"
+- "/docs/CodingGuidelines/2.40.2/index.html"
+- "/docs/CodingGuidelines/2.40.3/index.html"
+- "/docs/CodingGuidelines/2.40.4/index.html"
+---
+<div id="preamble">
+<div class="sectionbody">
+<div class="paragraph">
+<p>Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, a few rough rules are:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most importantly, we never say "It&#8217;s in POSIX; we&#8217;ll happily
+ignore your needs should your system not conform to it."
+We live in the real world.</p>
+</li>
+<li>
+<p>However, we often say "Let&#8217;s stay away from that construct,
+it&#8217;s not even in POSIX".</p>
+</li>
+<li>
+<p>In spite of the above two rules, we sometimes say "Although
+this is not in POSIX, it (is so convenient | makes the code
+much more readable | has other good characteristics) and
+practically all the platforms we care about support it, so
+let&#8217;s use it".</p>
+<div class="literalblock">
+<div class="content">
+<pre>Again, we live in the real world, and it is sometimes a
+judgement call, the decision based more on real world
+constraints people face than what the paper standard says.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Fixing style violations while working on a real change as a
+preparatory clean-up step is good, but otherwise avoid useless code
+churn for the sake of conforming to the style.</p>
+<div class="literalblock">
+<div class="content">
+<pre>"Once it _is_ in the tree, it's not really worth the patch noise to
+go and fix it up."
+Cf. http://lkml.iu.edu/hypermail/linux/kernel/1001.3/01069.html</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Log messages to explain your changes are as important as the
+changes themselves.  Clearly written code and in-code comments
+explain how the code works and what is assumed from the surrounding
+context.  The log messages explain what the changes wanted to
+achieve and why the changes were necessary (more on this in the
+accompanying SubmittingPatches document).</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Make your code readable and sensible, and don&#8217;t try to be clever.</p>
+</div>
+<div class="paragraph">
+<p>As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the <em>local</em>
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn&#8217;t match the overall style of existing code).</p>
+</div>
+<div class="paragraph">
+<p>But if you must have a list of rules, here are some language
+specific ones. Note that Documentation/ToolsForGit.txt document
+has a collection of tips to help you use some external tools
+to conform to these guidelines.</p>
+</div>
+<div class="paragraph">
+<p>For shell scripts specifically (not exhaustive):</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs for indentation.</p>
+</li>
+<li>
+<p>Case arms are indented at the same depth as case and esac lines,
+like this:</p>
+<div class="literalblock">
+<div class="content">
+<pre>case "$variable" in
+pattern1)
+	do this
+	;;
+pattern2)
+	do that
+	;;
+esac</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Redirection operators should be written with space before, but no
+space after them.  In other words, write <em>echo test &gt;"$file"</em>
+instead of <em>echo test&gt; $file</em> or <em>echo test &gt; $file</em>.  Note that
+even though it is not required by POSIX to double-quote the
+redirection target in a variable (as shown above), our code does so
+because some versions of bash issue a warning without the quotes.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+cat hello &gt; world &lt; universe
+echo hello &gt;$world</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+cat hello &gt;world &lt;universe
+echo hello &gt;"$world"</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer $( &#8230;&#8203; ) for command substitution; unlike ``, it
+properly nests.  It should have been the way Bourne spelled
+it from day one, but unfortunately isn&#8217;t.</p>
+</li>
+<li>
+<p>If you want to find out if a command is available on the user&#8217;s
+$PATH, you should use <em>type &lt;command&gt;</em>, instead of <em>which &lt;command&gt;</em>.
+The output of <em>which</em> is not machine parsable and its exit code
+is not reliable across platforms.</p>
+</li>
+<li>
+<p>We use POSIX compliant parameter substitutions and avoid bashisms;
+namely:</p>
+</li>
+<li>
+<p>We use ${parameter-word} and its [-=?+] siblings, and their
+colon&#8217;ed "unset or null" form.</p>
+</li>
+<li>
+<p>We use ${parameter#word} and its [#%] siblings, and their
+doubled "longest matching" form.</p>
+</li>
+<li>
+<p>No "Substring Expansion" ${parameter:offset:length}.</p>
+</li>
+<li>
+<p>No shell arrays.</p>
+</li>
+<li>
+<p>No pattern replacement ${parameter/pattern/string}.</p>
+</li>
+<li>
+<p>We use Arithmetic Expansion $&#8230;&#8203;.</p>
+</li>
+<li>
+<p>We do not use Process Substitution &lt;(list) or &gt;(list).</p>
+</li>
+<li>
+<p>Do not write control structures on a single line with semicolon.
+"then" should be on the next line for if statements, and "do"
+should be on the next line for "while" and "for".</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+if test -f hello; then
+	do this
+fi</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+if test -f hello
+then
+	do this
+fi</pre>
+</div>
+</div>
+</li>
+<li>
+<p>If a command sequence joined with &amp;&amp; or || or | spans multiple
+lines, put each command on a separate line and put &amp;&amp; and || and |
+operators at the end of each line, rather than the start. This
+means you don&#8217;t need to use \ to join lines, since the above
+operators imply the sequence isn&#8217;t finished.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+grep blob verify_pack_result \
+| awk -f print_1.awk \
+| sort &gt;actual &amp;&amp;
+...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+grep blob verify_pack_result |
+awk -f print_1.awk |
+sort &gt;actual &amp;&amp;
+...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer "test" over "[ &#8230;&#8203; ]".</p>
+</li>
+<li>
+<p>We do not write the noiseword "function" in front of shell
+functions.</p>
+</li>
+<li>
+<p>We prefer a space between the function name and the parentheses,
+and no space inside the parentheses. The opening "{" should also
+be on the same line.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+my_function(){
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+my_function () {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+[::], [==], or [..]) for portability.</p>
+</li>
+<li>
+<p>We do not use \{m,n\};</p>
+</li>
+<li>
+<p>We do not use ? or + (which are \{0,1\} and \{1,\}
+respectively in BRE) but that goes without saying as these
+are ERE elements not BRE (note that \? and \+ are not even part
+of BRE&#8201;&#8212;&#8201;making them accessible from BRE is a GNU extension).</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers in git-sh-i18n to make the user
+interface translatable. See "Marking strings for translation" in
+po/README.</p>
+</li>
+<li>
+<p>We do not write our "test" command with "-a" and "-o" and use "&amp;&amp;"
+or "||" to concatenate multiple "test" commands instead, because
+the use of "-a/-o" is often error-prone.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" -a "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is buggy and breaks when $x is "=", but</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" &amp;&amp; test "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>does not have such a problem.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Even though "local" is not part of POSIX, we make heavy use of it
+in our test suite.  We do not use it in scripted Porcelains, and
+hopefully nobody starts using "local" before they are reimplemented
+in C ;-)</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For C programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs to indent, and interpret tabs as taking up to
+8 spaces.</p>
+</li>
+<li>
+<p>We try to keep to at most 80 characters per line.</p>
+</li>
+<li>
+<p>As a Git developer we assume you have a reasonably modern compiler
+and we recommend you to enable the DEVELOPER makefile knob to
+ensure your patch is clear of all compiler warnings we care about,
+by e.g. "echo DEVELOPER=1 &gt;&gt;config.mak".</p>
+</li>
+<li>
+<p>We try to support a wide range of C compilers to compile Git with,
+including old ones.  As of Git v2.35.0 Git requires C99 (we check
+"<em>STDC_VERSION</em>"). You should not use features from a newer C
+standard, even if your compiler groks them.</p>
+<div class="literalblock">
+<div class="content">
+<pre>New C99 features have been phased in gradually, if something's new
+in C99 but not used yet don't assume that it's safe to use, some
+compilers we target have only partial support for it. These are
+considered safe to use:</pre>
+</div>
+</div>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>since around 2007 with 2b6854c863a, we have been using
+initializer elements which are not computable at load time. E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>const char *args[] = {"constant", variable, NULL};</pre>
+</div>
+</div>
+</li>
+<li>
+<p>since early 2012 with e1327023ea, we have been using an enum
+definition whose last element is followed by a comma.  This, like
+an array initializer that ends with a trailing comma, can be used
+to reduce the patch noise when adding a new identifier at the end.</p>
+</li>
+<li>
+<p>since mid 2017 with cbc0f81d, we have been using designated
+initializers for struct (e.g. "struct t v = { .val = <em>a</em> };").</p>
+</li>
+<li>
+<p>since mid 2017 with 512f41cf, we have been using designated
+initializers for array (e.g. "int array[10] = { [5] = 2 }").</p>
+</li>
+<li>
+<p>since early 2021 with 765dc168882, we have been using variadic
+macros, mostly for printf-like trace and debug macros.</p>
+</li>
+<li>
+<p>since late 2021 with 44ba10d6, we have had variables declared in
+the for loop "for (int i = 0; i &lt; 10; i++)".</p>
+<div class="literalblock">
+<div class="content">
+<pre>New C99 features that we cannot use yet:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>%z and %zu as a printf() argument for a size_t (the %z being for
+the POSIX-specific ssize_t). Instead you should use
+printf("%"PRIuMAX, (uintmax_t)v).  These days the MSVC version we
+rely on supports %z, but the C library used by MinGW does not.</p>
+</li>
+<li>
+<p>Shorthand like ".a.b = *c" in struct initializations is known to
+trip up an older IBM XLC version, use ".a = { .b = *c }" instead.
+See the 33665d98 (reftable: make assignments portable to AIX xlc
+v12.01, 2022-03-28).</p>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>Variables have to be declared at the beginning of the block, before
+the first statement (i.e. -Wdeclaration-after-statement).</p>
+</li>
+<li>
+<p>NULL pointers shall be written as NULL, not as 0.</p>
+</li>
+<li>
+<p>When declaring pointers, the star sides with the variable
+name, i.e. "char <strong>string", not "char</strong> string" or
+"char * string".  This makes it easier to understand code
+like "char *string, c;".</p>
+</li>
+<li>
+<p>Use whitespace around operators and keywords, but not inside
+parentheses and not around functions. So:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      while (condition)
+func(bar + 1);</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>      while( condition )
+func (bar+1);</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Do not explicitly compare an integral value with constant 0 or <em>\0</em>,
+or a pointer value with constant NULL.  For instance, to validate that
+counted array &lt;ptr, cnt&gt; is initialized but has no elements, write:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (!ptr || cnt)
+	BUG("empty array expected");</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (ptr == NULL || cnt != 0);
+	BUG("empty array expected");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We avoid using braces unnecessarily.  I.e.</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (bla) {
+	x = 1;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is frowned upon. But there are a few exceptions:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When the statement extends over a few lines (e.g., a while loop
+with an embedded conditional, or a comment). E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (foo) {
+	if (x)
+		one();
+	else
+		two();
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	/*
+	 * This one requires some explanation,
+	 * so we're better off with braces to make
+	 * it obvious that the indentation is correct.
+	 */
+	doit();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When there are multiple arms to a conditional and some of them
+require braces, enclose even a single line block in braces for
+consistency. E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	doit();
+} else {
+	one();
+	two();
+	three();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments in the condition of an "if" statement.</p>
+</li>
+<li>
+<p>Try to make your code understandable.  You may put comments
+in, but comments invariably tend to stale out when the code
+they were describing changes.  Often splitting a function
+into two makes the intention of the code much clearer.</p>
+</li>
+<li>
+<p>Multi-line comments include their delimiters on separate lines from
+the text.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * A very long
+ * multi-line comment.
+ */</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Note however that a comment that explains a translatable string to
+translators uses a convention of starting with a magic token
+"TRANSLATORS: ", e.g.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * TRANSLATORS: here is a comment that explains the string to
+ * be translated, that follows immediately after it.
+ */
+_("Here is a translatable string explained by the above.");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Double negation is often harder to understand than no negation
+at all.</p>
+</li>
+<li>
+<p>There are two schools of thought when it comes to comparison,
+especially inside a loop. Some people prefer to have the less stable
+value on the left hand side and the more stable value on the right hand
+side, e.g. if you have a loop that counts variable i down to the
+lower bound,</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (i &gt; lower_bound) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Other people prefer to have the textual order of values match the
+actual order of values in their comparison, so that they can
+mentally draw a number line from left to right and place these
+values in order, i.e.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while (lower_bound &lt; i) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  However, the more "stable" the
+stable side becomes, the more we tend to prefer the former
+(comparison with a constant, "i &gt; 0", is an extreme example).
+Just do not mix styles in the same part of the code and mimic
+existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>There are two schools of thought when it comes to splitting a long
+logical line into multiple lines.  Some people push the second and
+subsequent lines far enough to the right with tabs and align them:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+              ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to align the second and the subsequent
+lines with the column immediately inside the opening parenthesis,
+with tabs and spaces, following our "tabstop is always a multiple
+of 8" convention:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+           ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  Again, just do not mix styles in
+the same part of the code and mimic existing styles in the
+neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, some people change line before
+a binary operator, so that the result looks like a parse tree when
+you turn your head 90-degrees counterclockwise:</p>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to
+|| span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to leave the operator at the end of the
+line:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, but we tend to use the latter more, unless the
+expression gets fairly complex, in which case the former tends to
+be easier to read.  Again, just do not mix styles in the same part
+of the code and mimic existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, with everything else being
+equal, it is preferable to split after the operator at higher
+level in the parse tree.  That is, this is more preferable:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable * that_is_used_in +
+    a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>than</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable *
+    that_is_used_in + a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Some clever tricks, like using the !! operator with arithmetic
+constructs, can be extremely confusing to others.  Avoid them,
+unless there is a compelling reason to use them.</p>
+</li>
+<li>
+<p>Use the API.  No, really.  We have a strbuf (variable length
+string), several arrays with the ALLOC_GROW() macro, a
+string_list for sorted string lists, a hash map (mapping struct
+objects) named "struct decorate", amongst other things.</p>
+</li>
+<li>
+<p>When you come up with an API, document its functions and structures
+in the header file that exposes the API to its callers. Use what is
+in "strbuf.h" as a model for the appropriate tone and level of
+detail.</p>
+</li>
+<li>
+<p>The first #include in C files, except in platform specific compat/
+implementations, must be either "git-compat-util.h", "cache.h" or
+"builtin.h".  You do not have to include more than one of these.</p>
+</li>
+<li>
+<p>A C file must directly include the header files that declare the
+functions and the types it uses, except for the functions and types
+that are made available to it by including one of the header files
+it must include by the previous rule.</p>
+</li>
+<li>
+<p>If you are planning a new command, consider writing it in shell
+or perl first, so that changes in semantics can be easily
+changed and discussed.  Many Git commands started out like
+that, and a few are still scripts.</p>
+</li>
+<li>
+<p>Avoid introducing a new dependency into Git. This means you
+usually should stay away from scripting languages not already
+used in the Git core command set (unless your command is clearly
+separate from it, such as an importer to convert random-scm-X
+repositories to Git).</p>
+</li>
+<li>
+<p>When we pass &lt;string, length&gt; pair to functions, we should try to
+pass them in that order.</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers to make the user interface
+translatable. See "Marking strings for translation" in po/README.</p>
+</li>
+<li>
+<p>Variables and functions local to a given source file should be marked
+with "static". Variables that are visible to other source files
+must be declared with "extern" in header files. However, function
+declarations should not use "extern", as that is already the default.</p>
+</li>
+<li>
+<p>You can launch gdb around your program using the shorthand GIT_DEBUGGER.
+Run <code>GIT_DEBUGGER=1 ./bin-wrappers/git foo</code> to simply use gdb as is, or
+run <code>GIT_DEBUGGER="&lt;debugger&gt; &lt;debugger-args&gt;" ./bin-wrappers/git foo</code> to
+use your own debugger and arguments. Example: <code>GIT_DEBUGGER="ddd --gdb"
+./bin-wrappers/git log</code> (See <code>wrap-for-bin.sh</code>.)</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Perl programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most of the C guidelines above apply.</p>
+</li>
+<li>
+<p>We try to support Perl 5.8 and later ("use Perl 5.008").</p>
+</li>
+<li>
+<p>use strict and use warnings are strongly preferred.</p>
+</li>
+<li>
+<p>Don&#8217;t overuse statement modifiers unless using them makes the
+result easier to follow.</p>
+<div class="olist lowerroman">
+<ol class="lowerroman" type="i">
+<li>
+<p>do something &#8230;&#8203;
+do_this() unless (condition);</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>is more readable than:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>do something &#8230;&#8203;
+unless (condition) {
+	do_this();
+}</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>*only* when the condition is so rare that do_this() will be almost
+always called.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments inside "if ()" conditions.</p>
+</li>
+<li>
+<p>Learn and use Git.pm if you need that functionality.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Python scripts:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We follow PEP-8 (<a href="http://www.python.org/dev/peps/pep-0008/" class="bare">http://www.python.org/dev/peps/pep-0008/</a>).</p>
+</li>
+<li>
+<p>As a minimum, we aim to be compatible with Python 2.7.</p>
+</li>
+<li>
+<p>Where required libraries do not restrict us to Python 2, we try to
+also be compatible with Python 3.1 and later.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Program Output</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>We make a distinction between a Git command's primary output and
+output which is merely chatty feedback (for instance, status
+messages, running transcript, or progress display), as well as error
+messages. Roughly speaking, a Git command's primary output is that
+which one might want to capture to a file or send down a pipe; its
+chatty output should not interfere with these use-cases.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>As such, primary output should be sent to the standard output stream
+(stdout), and chatty output should be sent to the standard error
+stream (stderr). Examples of commands which produce primary output
+include `git log`, `git show`, and `git branch --list` which generate
+output on the stdout stream.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Not all Git commands have primary output; this is often true of
+commands whose main function is to perform an action. Some action
+commands are silent, whereas others are chatty. An example of a
+chatty action commands is `git clone` with its "Cloning into
+'&lt;path&gt;'..." and "Checking connectivity..." status messages which it
+sends to the stderr stream.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Error messages from Git commands should always be sent to the stderr
+stream.</pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Error Messages</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Do not end error messages with a full stop.</p>
+</li>
+<li>
+<p>Do not capitalize the first word, only because it is the first word
+in the message ("unable to open %s", not "Unable to open %s").  But
+"SHA-3 not supported" is fine, because the reason the first word is
+capitalized is not because it is at the beginning of the sentence,
+but because the word would be spelled in capital letters even when
+it appeared in the middle of the sentence.</p>
+</li>
+<li>
+<p>Say what the error is first ("cannot open %s", not "%s: cannot open")</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Externally Visible Names</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>For configuration variable names, follow the existing convention:</p>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>The section name indicates the affected subsystem.</p>
+</li>
+<li>
+<p>The subsection name, if any, indicates which of an unbounded set
+of things to set the value for.</p>
+</li>
+<li>
+<p>The variable name describes the effect of tweaking this knob.</p>
+<div class="literalblock">
+<div class="content">
+<pre>The section and variable names that consist of multiple words are
+formed by concatenating the words without punctuations (e.g. `-`),
+and are broken using bumpyCaps in documentation as a hint to the
+reader.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>When choosing the variable namespace, do not use variable name for
+specifying possibly unbounded set of things, most notably anything
+an end user can freely come up with (e.g. branch names).  Instead,
+use subsection names or variable values, like the existing variable
+branch.&lt;name&gt;.description does.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Writing Documentation:</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Most (if not all) of the documentation pages are written in the
+AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+processed into HTML and manpages (e.g. git.html and git.1 in the
+same directory).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>The documentation liberally mixes US and UK English (en_US/UK)
+norms for spelling and grammar, which is somewhat unfortunate.
+In an ideal world, it would have been better if it consistently
+used only one and not the other, and we would have picked en_US
+(if you wish to correct the English of some of the existing
+documentation, please see the documentation-related advice in the
+Documentation/SubmittingPatches file).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>In order to ensure the documentation is inclusive, avoid assuming
+that an unspecified example person is male or female, and think
+twice before using "he", "him", "she", or "her".  Here are some
+tips to avoid use of gendered pronouns:</pre>
+</div>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Prefer succinctness and matter-of-factly describing functionality
+in the abstract.  E.g.</p>
+<div class="dlist">
+<dl>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short"> <a class="anchor" href="#Documentation/CodingGuidelines---short"></a>--short </dt>
+<dd>
+<p>Emit output in the short-format.</p>
+<div class="literalblock">
+<div class="content">
+<pre>and avoid something like these overly verbose alternatives:</pre>
+</div>
+</div>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short-1"> <a class="anchor" href="#Documentation/CodingGuidelines---short-1"></a>--short </dt>
+<dd>
+<p>Use this to emit output in the short-format.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short-1-1"> <a class="anchor" href="#Documentation/CodingGuidelines---short-1-1"></a>--short </dt>
+<dd>
+<p>You can use this to get output in the short-format.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short-1-1-1"> <a class="anchor" href="#Documentation/CodingGuidelines---short-1-1-1"></a>--short </dt>
+<dd>
+<p>A user who prefers shorter output could&#8230;&#8203;.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short-1-1-1-1"> <a class="anchor" href="#Documentation/CodingGuidelines---short-1-1-1-1"></a>--short </dt>
+<dd>
+<p>Should a person and/or program want shorter output, he
+she/they/it can&#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>This practice often eliminates the need to involve human actors in
+your description, but it is a good practice regardless of the
+avoidance of gendered pronouns.</pre>
+</div>
+</div>
+</dd>
+</dl>
+</div>
+</li>
+<li>
+<p>When it becomes awkward to stick to this style, prefer "you" when
+addressing the hypothetical user, and possibly "we" when
+discussing how the program might react to the user.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>You can use this option instead of --xyz, but we might remove
+support for it in future versions.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while keeping in mind that you can probably be less verbose, e.g.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Use this instead of --xyz. This option might be removed in future
+versions.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>If you still need to refer to an example person that is
+third-person singular, you may resort to "singular they" to avoid
+"he/she/him/her", e.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>A contributor asks their upstream to pull from them.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Note that this sounds ungrammatical and unnatural to those who
+learned that "they" is only used for third-person plural, e.g.
+those who learn English as a second language in some parts of the
+world.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Every user-visible change should be reflected in the documentation.
+The same general rule as for code applies -- imitate the existing
+conventions.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying command usage strings and synopsis sections in the manual
+pages:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Placeholders are spelled in lowercase and enclosed in angle brackets:
+  &lt;file&gt;
+  --sort=&lt;key&gt;
+  --abbrev[=&lt;n&gt;]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If a placeholder has multiple words, they are separated by dashes:
+  &lt;new-branch-name&gt;
+  --template=&lt;template-directory&gt;</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Possibility of multiple occurrences is indicated by three dots:
+  &lt;file&gt;...
+  (One or more of &lt;file&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Optional parts are enclosed in square brackets:
+  [&lt;file&gt;...]
+  (Zero or more of &lt;file&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>--exec-path[=&lt;path&gt;]
+(Option with an optional argument.  Note that the "=" is inside the
+brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[&lt;patch&gt;...]
+(Zero or more of &lt;patch&gt;.  Note that the dots are inside, not
+outside the brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Multiple alternatives are indicated with vertical bars:
+  [-q | --quiet]
+  [--utf8 | --no-utf8]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Use spacing around "|" token(s), but not immediately after opening or
+before closing a [] or () pair:
+  Do: [-q | --quiet]
+  Don't: [-q|--quiet]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Don't use spacing around "|" tokens when they're used to seperate the
+alternate arguments of an option:
+   Do: --track[=(direct|inherit)]
+   Don't: --track[=(direct | inherit)]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Parentheses are used for grouping:
+  [(&lt;rev&gt; | &lt;range&gt;)...]
+  (Any number of either &lt;rev&gt; or &lt;range&gt;.  Parens are needed to make
+  it clear that "..." pertains to both &lt;rev&gt; and &lt;range&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[(-p &lt;parent&gt;)...]
+(Any number of option -p, each with one &lt;parent&gt; argument.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>git remote set-head &lt;name&gt; (-a | -d | &lt;branch&gt;)
+(One and only one of "-a", "-d" or "&lt;branch&gt;" _must_ (no square
+brackets) be provided.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>And a somewhat more contrived example:
+  --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+  Here "=" is outside the brackets, because "--diff-filter=" is a
+  valid usage.  "*" has its own pair of brackets, because it can
+  (optionally) be specified only when one or more of the letters is
+  also provided.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A note on notation:
+ Use 'git' (all lowercase) when talking about commands i.e. something
+ the user would type into a shell and use 'Git' (uppercase first letter)
+ when talking about the version control system and its properties.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying paragraphs or option/command explanations that contain options
+or commands:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Literal examples (e.g. use of command-line options, command names,
+branch names, URLs, pathnames (files and directories), configuration and
+environment variables) must be typeset in monospace (i.e. wrapped with
+backticks):
+  `--pretty=oneline`
+  `git rev-list`
+  `remote.pushDefault`
+  `http://git.example.com`
+  `.git/config`
+  `GIT_DIR`
+  `HEAD`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>An environment variable must be prefixed with "$" only when referring to its
+value and not when referring to the variable itself, in this case there is
+nothing to add except the backticks:
+  `GIT_DIR` is specified
+  `$GIT_DIR/hooks/pre-receive`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Word phrases enclosed in `backtick characters` are rendered literally
+and will not be further expanded. The use of `backticks` to achieve the
+previous rule means that literal examples should not use AsciiDoc
+escapes.
+  Correct:
+     `--pretty=oneline`
+  Incorrect:
+     `\--pretty=oneline`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If some place in the documentation needs to typeset a command usage
+example with inline substitutions, it is fine to use +monospaced and
+inline substituted text+ instead of `monospaced literal text`, and with
+the former, the part that should not get substituted must be
+quoted/escaped.</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+</div>
+</div>
\ No newline at end of file
diff --git a/external/docs/content/docs/CodingGuidelines/2.4.12.html b/external/docs/content/docs/CodingGuidelines/2.4.12.html
new file mode 100644
index 0000000000..db02c48f94
--- /dev/null
+++ b/external/docs/content/docs/CodingGuidelines/2.4.12.html
@@ -0,0 +1,869 @@
+---
+### DO NOT EDIT! Generated by script/update-docs.rb
+
+category: manual
+section: documentation
+subsection: manual
+title: Git - CodingGuidelines Documentation
+docname: CodingGuidelines
+version: 2.4.12
+aliases:
+- "/docs/CodingGuidelines/2.4.12/index.html"
+- "/docs/CodingGuidelines/2.5.6/index.html"
+- "/docs/CodingGuidelines/2.6.7/index.html"
+- "/docs/CodingGuidelines/2.7.6/index.html"
+---
+<div id="preamble">
+<div class="sectionbody">
+<div class="paragraph">
+<p>Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, a few rough rules are:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most importantly, we never say "It&#8217;s in POSIX; we&#8217;ll happily
+ignore your needs should your system not conform to it."
+We live in the real world.</p>
+</li>
+<li>
+<p>However, we often say "Let&#8217;s stay away from that construct,
+it&#8217;s not even in POSIX".</p>
+</li>
+<li>
+<p>In spite of the above two rules, we sometimes say "Although
+this is not in POSIX, it (is so convenient | makes the code
+much more readable | has other good characteristics) and
+practically all the platforms we care about support it, so
+let&#8217;s use it".</p>
+<div class="literalblock">
+<div class="content">
+<pre>Again, we live in the real world, and it is sometimes a
+judgement call, the decision based more on real world
+constraints people face than what the paper standard says.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Fixing style violations while working on a real change as a
+preparatory clean-up step is good, but otherwise avoid useless code
+churn for the sake of conforming to the style.</p>
+<div class="literalblock">
+<div class="content">
+<pre>"Once it _is_ in the tree, it's not really worth the patch noise to
+go and fix it up."
+Cf. http://article.gmane.org/gmane.linux.kernel/943020</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Make your code readable and sensible, and don&#8217;t try to be clever.</p>
+</div>
+<div class="paragraph">
+<p>As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the <em>local</em>
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn&#8217;t match the overall style of existing code).</p>
+</div>
+<div class="paragraph">
+<p>But if you must have a list of rules, here they are.</p>
+</div>
+<div class="paragraph">
+<p>For shell scripts specifically (not exhaustive):</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs for indentation.</p>
+</li>
+<li>
+<p>Case arms are indented at the same depth as case and esac lines,
+like this:</p>
+<div class="literalblock">
+<div class="content">
+<pre>case "$variable" in
+pattern1)
+	do this
+	;;
+pattern2)
+	do that
+	;;
+esac</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Redirection operators should be written with space before, but no
+space after them.  In other words, write <em>echo test &gt;"$file"</em>
+instead of <em>echo test&gt; $file</em> or <em>echo test &gt; $file</em>.  Note that
+even though it is not required by POSIX to double-quote the
+redirection target in a variable (as shown above), our code does so
+because some versions of bash issue a warning without the quotes.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+cat hello &gt; world &lt; universe
+echo hello &gt;$world</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+cat hello &gt;world &lt;universe
+echo hello &gt;"$world"</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer $( &#8230;&#8203; ) for command substitution; unlike ``, it
+properly nests.  It should have been the way Bourne spelled
+it from day one, but unfortunately isn&#8217;t.</p>
+</li>
+<li>
+<p>If you want to find out if a command is available on the user&#8217;s
+$PATH, you should use <em>type &lt;command&gt;</em>, instead of <em>which &lt;command&gt;</em>.
+The output of <em>which</em> is not machine parseable and its exit code
+is not reliable across platforms.</p>
+</li>
+<li>
+<p>We use POSIX compliant parameter substitutions and avoid bashisms;
+namely:</p>
+</li>
+<li>
+<p>We use ${parameter-word} and its [-=?+] siblings, and their
+colon&#8217;ed "unset or null" form.</p>
+</li>
+<li>
+<p>We use ${parameter#word} and its [#%] siblings, and their
+doubled "longest matching" form.</p>
+</li>
+<li>
+<p>No "Substring Expansion" ${parameter:offset:length}.</p>
+</li>
+<li>
+<p>No shell arrays.</p>
+</li>
+<li>
+<p>No strlen ${#parameter}.</p>
+</li>
+<li>
+<p>No pattern replacement ${parameter/pattern/string}.</p>
+</li>
+<li>
+<p>We use Arithmetic Expansion $&#8230;&#8203;.</p>
+</li>
+<li>
+<p>Inside Arithmetic Expansion, spell shell variables with $ in front
+of them, as some shells do not grok $x while accepting $$x
+just fine (e.g. dash older than 0.5.4).</p>
+</li>
+<li>
+<p>We do not use Process Substitution &lt;(list) or &gt;(list).</p>
+</li>
+<li>
+<p>Do not write control structures on a single line with semicolon.
+"then" should be on the next line for if statements, and "do"
+should be on the next line for "while" and "for".</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+if test -f hello; then
+	do this
+fi</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+if test -f hello
+then
+	do this
+fi</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer "test" over "[ &#8230;&#8203; ]".</p>
+</li>
+<li>
+<p>We do not write the noiseword "function" in front of shell
+functions.</p>
+</li>
+<li>
+<p>We prefer a space between the function name and the parentheses,
+and no space inside the parentheses. The opening "{" should also
+be on the same line.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+my_function(){
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+my_function () {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+[::], [==], or [..]) for portability.</p>
+</li>
+<li>
+<p>We do not use \{m,n\};</p>
+</li>
+<li>
+<p>We do not use -E;</p>
+</li>
+<li>
+<p>We do not use ? or + (which are \{0,1\} and \{1,\}
+respectively in BRE) but that goes without saying as these
+are ERE elements not BRE (note that \? and \+ are not even part
+of BRE&#8201;&#8212;&#8201;making them accessible from BRE is a GNU extension).</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers in git-sh-i18n to make the user
+interface translatable. See "Marking strings for translation" in
+po/README.</p>
+</li>
+<li>
+<p>We do not write our "test" command with "-a" and "-o" and use "&amp;&amp;"
+or "||" to concatenate multiple "test" commands instead, because
+the use of "-a/-o" is often error-prone.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" -a "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is buggy and breaks when $x is "=", but</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" &amp;&amp; test "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>does not have such a problem.</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For C programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs to indent, and interpret tabs as taking up to
+8 spaces.</p>
+</li>
+<li>
+<p>We try to keep to at most 80 characters per line.</p>
+</li>
+<li>
+<p>We try to support a wide range of C compilers to compile Git with,
+including old ones. That means that you should not use C99
+initializers, even if a lot of compilers grok it.</p>
+</li>
+<li>
+<p>Variables have to be declared at the beginning of the block.</p>
+</li>
+<li>
+<p>NULL pointers shall be written as NULL, not as 0.</p>
+</li>
+<li>
+<p>When declaring pointers, the star sides with the variable
+name, i.e. "char <strong>string", not "char</strong> string" or
+"char * string".  This makes it easier to understand code
+like "char *string, c;".</p>
+</li>
+<li>
+<p>Use whitespace around operators and keywords, but not inside
+parentheses and not around functions. So:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      while (condition)
+func(bar + 1);</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>      while( condition )
+func (bar+1);</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We avoid using braces unnecessarily.  I.e.</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (bla) {
+	x = 1;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is frowned upon.  A gray area is when the statement extends
+over a few lines, and/or you have a lengthy comment atop of
+it.  Also, like in the Linux kernel, if there is a long list
+of "else if" statements, it can make sense to add braces to
+single line blocks.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments in the condition of an "if" statement.</p>
+</li>
+<li>
+<p>Try to make your code understandable.  You may put comments
+in, but comments invariably tend to stale out when the code
+they were describing changes.  Often splitting a function
+into two makes the intention of the code much clearer.</p>
+</li>
+<li>
+<p>Multi-line comments include their delimiters on separate lines from
+the text.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * A very long
+ * multi-line comment.
+ */</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Note however that a comment that explains a translatable string to
+translators uses a convention of starting with a magic token
+"TRANSLATORS: " immediately after the opening delimiter, even when
+it spans multiple lines.  We do not add an asterisk at the beginning
+of each line, either.  E.g.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>/* TRANSLATORS: here is a comment that explains the string
+   to be translated, that follows immediately after it */
+_("Here is a translatable string explained by the above.");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Double negation is often harder to understand than no negation
+at all.</p>
+</li>
+<li>
+<p>There are two schools of thought when it comes to comparison,
+especially inside a loop. Some people prefer to have the less stable
+value on the left hand side and the more stable value on the right hand
+side, e.g. if you have a loop that counts variable i down to the
+lower bound,</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (i &gt; lower_bound) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Other people prefer to have the textual order of values match the
+actual order of values in their comparison, so that they can
+mentally draw a number line from left to right and place these
+values in order, i.e.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while (lower_bound &lt; i) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  However, the more "stable" the
+stable side becomes, the more we tend to prefer the former
+(comparison with a constant, "i &gt; 0", is an extreme example).
+Just do not mix styles in the same part of the code and mimic
+existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>There are two schools of thought when it comes to splitting a long
+logical line into multiple lines.  Some people push the second and
+subsequent lines far enough to the right with tabs and align them:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+              ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to align the second and the subsequent
+lines with the column immediately inside the opening parenthesis,
+with tabs and spaces, following our "tabstop is always a multiple
+of 8" convention:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+           ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  Again, just do not mix styles in
+the same part of the code and mimic existing styles in the
+neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, some people change line before
+a binary operator, so that the result looks like a parse tree when
+you turn your head 90-degrees counterclockwise:</p>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to
+|| span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to leave the operator at the end of the
+line:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, but we tend to use the latter more, unless the
+expression gets fairly complex, in which case the former tends to
+be easier to read.  Again, just do not mix styles in the same part
+of the code and mimic existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, with everything else being
+equal, it is preferable to split after the operator at higher
+level in the parse tree.  That is, this is more preferable:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable * that_is_used_in +
+    a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>than</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable *
+    that_is_used_in + a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Some clever tricks, like using the !! operator with arithmetic
+constructs, can be extremely confusing to others.  Avoid them,
+unless there is a compelling reason to use them.</p>
+</li>
+<li>
+<p>Use the API.  No, really.  We have a strbuf (variable length
+string), several arrays with the ALLOC_GROW() macro, a
+string_list for sorted string lists, a hash map (mapping struct
+objects) named "struct decorate", amongst other things.</p>
+</li>
+<li>
+<p>When you come up with an API, document it.</p>
+</li>
+<li>
+<p>The first #include in C files, except in platform specific compat/
+implementations, must be either "git-compat-util.h", "cache.h" or
+"builtin.h".  You do not have to include more than one of these.</p>
+</li>
+<li>
+<p>A C file must directly include the header files that declare the
+functions and the types it uses, except for the functions and types
+that are made available to it by including one of the header files
+it must include by the previous rule.</p>
+</li>
+<li>
+<p>If you are planning a new command, consider writing it in shell
+or perl first, so that changes in semantics can be easily
+changed and discussed.  Many Git commands started out like
+that, and a few are still scripts.</p>
+</li>
+<li>
+<p>Avoid introducing a new dependency into Git. This means you
+usually should stay away from scripting languages not already
+used in the Git core command set (unless your command is clearly
+separate from it, such as an importer to convert random-scm-X
+repositories to Git).</p>
+</li>
+<li>
+<p>When we pass &lt;string, length&gt; pair to functions, we should try to
+pass them in that order.</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers to make the user interface
+translatable. See "Marking strings for translation" in po/README.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Perl programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most of the C guidelines above apply.</p>
+</li>
+<li>
+<p>We try to support Perl 5.8 and later ("use Perl 5.008").</p>
+</li>
+<li>
+<p>use strict and use warnings are strongly preferred.</p>
+</li>
+<li>
+<p>Don&#8217;t overuse statement modifiers unless using them makes the
+result easier to follow.</p>
+<div class="olist lowerroman">
+<ol class="lowerroman" type="i">
+<li>
+<p>do something &#8230;&#8203;
+do_this() unless (condition);</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>is more readable than:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>do something &#8230;&#8203;
+unless (condition) {
+	do_this();
+}</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>*only* when the condition is so rare that do_this() will be almost
+always called.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments inside "if ()" conditions.</p>
+</li>
+<li>
+<p>Learn and use Git.pm if you need that functionality.</p>
+</li>
+<li>
+<p>For Emacs, it&#8217;s useful to put the following in
+GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode:</p>
+<div class="literalblock">
+<div class="content">
+<pre>;; note the first part is useful for C editing, too
+((nil . ((indent-tabs-mode . t)
+              (tab-width . 8)
+              (fill-column . 80)))
+ (cperl-mode . ((cperl-indent-level . 8)
+                (cperl-extra-newline-before-brace . nil)
+                (cperl-merge-trailing-else . t))))</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Python scripts:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We follow PEP-8 (<a href="http://www.python.org/dev/peps/pep-0008/" class="bare">http://www.python.org/dev/peps/pep-0008/</a>).</p>
+</li>
+<li>
+<p>As a minimum, we aim to be compatible with Python 2.6 and 2.7.</p>
+</li>
+<li>
+<p>Where required libraries do not restrict us to Python 2, we try to
+also be compatible with Python 3.1 and later.</p>
+</li>
+<li>
+<p>When you must differentiate between Unicode literals and byte string
+literals, it is OK to use the <em>b</em> prefix.  Even though the Python
+documentation for version 2.6 does not mention this prefix, it has
+been supported since version 2.6.0.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Error Messages</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Do not end error messages with a full stop.</p>
+</li>
+<li>
+<p>Do not capitalize ("unable to open %s", not "Unable to open %s")</p>
+</li>
+<li>
+<p>Say what the error is first ("cannot open %s", not "%s: cannot open")</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Externally Visible Names</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>For configuration variable names, follow the existing convention:</p>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>The section name indicates the affected subsystem.</p>
+</li>
+<li>
+<p>The subsection name, if any, indicates which of an unbounded set
+of things to set the value for.</p>
+</li>
+<li>
+<p>The variable name describes the effect of tweaking this knob.</p>
+<div class="literalblock">
+<div class="content">
+<pre>The section and variable names that consist of multiple words are
+formed by concatenating the words without punctuations (e.g. `-`),
+and are broken using bumpyCaps in documentation as a hint to the
+reader.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>When choosing the variable namespace, do not use variable name for
+specifying possibly unbounded set of things, most notably anything
+an end user can freely come up with (e.g. branch names).  Instead,
+use subsection names or variable values, like the existing variable
+branch.&lt;name&gt;.description does.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Writing Documentation:</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Most (if not all) of the documentation pages are written in the
+AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+processed into HTML and manpages (e.g. git.html and git.1 in the
+same directory).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>The documentation liberally mixes US and UK English (en_US/UK)
+norms for spelling and grammar, which is somewhat unfortunate.
+In an ideal world, it would have been better if it consistently
+used only one and not the other, and we would have picked en_US
+(if you wish to correct the English of some of the existing
+documentation, please see the documentation-related advice in the
+Documentation/SubmittingPatches file).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Every user-visible change should be reflected in the documentation.
+The same general rule as for code applies -- imitate the existing
+conventions.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying command usage strings and synopsis sections in the manual
+pages:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Placeholders are spelled in lowercase and enclosed in angle brackets:
+  &lt;file&gt;
+  --sort=&lt;key&gt;
+  --abbrev[=&lt;n&gt;]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If a placeholder has multiple words, they are separated by dashes:
+  &lt;new-branch-name&gt;
+  --template=&lt;template-directory&gt;</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Possibility of multiple occurrences is indicated by three dots:
+  &lt;file&gt;...
+  (One or more of &lt;file&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Optional parts are enclosed in square brackets:
+  [&lt;extra&gt;]
+  (Zero or one &lt;extra&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>--exec-path[=&lt;path&gt;]
+(Option with an optional argument.  Note that the "=" is inside the
+brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[&lt;patch&gt;...]
+(Zero or more of &lt;patch&gt;.  Note that the dots are inside, not
+outside the brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Multiple alternatives are indicated with vertical bars:
+  [-q | --quiet]
+  [--utf8 | --no-utf8]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Parentheses are used for grouping:
+  [(&lt;rev&gt; | &lt;range&gt;)...]
+  (Any number of either &lt;rev&gt; or &lt;range&gt;.  Parens are needed to make
+  it clear that "..." pertains to both &lt;rev&gt; and &lt;range&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[(-p &lt;parent&gt;)...]
+(Any number of option -p, each with one &lt;parent&gt; argument.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>git remote set-head &lt;name&gt; (-a | -d | &lt;branch&gt;)
+(One and only one of "-a", "-d" or "&lt;branch&gt;" _must_ (no square
+brackets) be provided.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>And a somewhat more contrived example:
+  --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+  Here "=" is outside the brackets, because "--diff-filter=" is a
+  valid usage.  "*" has its own pair of brackets, because it can
+  (optionally) be specified only when one or more of the letters is
+  also provided.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A note on notation:
+ Use 'git' (all lowercase) when talking about commands i.e. something
+ the user would type into a shell and use 'Git' (uppercase first letter)
+ when talking about the version control system and its properties.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying paragraphs or option/command explanations that contain options
+or commands:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Literal examples (e.g. use of command-line options, command names, and
+configuration variables) are typeset in monospace, and if you can use
+`backticks around word phrases`, do so.
+  `--pretty=oneline`
+  `git rev-list`
+  `remote.pushDefault`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Word phrases enclosed in `backtick characters` are rendered literally
+and will not be further expanded. The use of `backticks` to achieve the
+previous rule means that literal examples should not use AsciiDoc
+escapes.
+  Correct:
+     `--pretty=oneline`
+  Incorrect:
+     `\--pretty=oneline`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If some place in the documentation needs to typeset a command usage
+example with inline substitutions, it is fine to use +monospaced and
+inline substituted text+ instead of `monospaced literal text`, and with
+the former, the part that should not get substituted must be
+quoted/escaped.</pre>
+</div>
+</div>
+</div>
+</div>
\ No newline at end of file
diff --git a/external/docs/content/docs/CodingGuidelines/2.41.0.html b/external/docs/content/docs/CodingGuidelines/2.41.0.html
new file mode 100644
index 0000000000..c9b3b4a35e
--- /dev/null
+++ b/external/docs/content/docs/CodingGuidelines/2.41.0.html
@@ -0,0 +1,1193 @@
+---
+### DO NOT EDIT! Generated by script/update-docs.rb
+
+category: manual
+section: documentation
+subsection: manual
+title: Git - CodingGuidelines Documentation
+docname: CodingGuidelines
+version: 2.41.0
+aliases:
+- "/docs/CodingGuidelines/2.41.0/index.html"
+- "/docs/CodingGuidelines/2.41.1/index.html"
+- "/docs/CodingGuidelines/2.41.2/index.html"
+- "/docs/CodingGuidelines/2.41.3/index.html"
+---
+<div id="preamble">
+<div class="sectionbody">
+<div class="paragraph">
+<p>Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, a few rough rules are:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most importantly, we never say "It&#8217;s in POSIX; we&#8217;ll happily
+ignore your needs should your system not conform to it."
+We live in the real world.</p>
+</li>
+<li>
+<p>However, we often say "Let&#8217;s stay away from that construct,
+it&#8217;s not even in POSIX".</p>
+</li>
+<li>
+<p>In spite of the above two rules, we sometimes say "Although
+this is not in POSIX, it (is so convenient | makes the code
+much more readable | has other good characteristics) and
+practically all the platforms we care about support it, so
+let&#8217;s use it".</p>
+<div class="literalblock">
+<div class="content">
+<pre>Again, we live in the real world, and it is sometimes a
+judgement call, the decision based more on real world
+constraints people face than what the paper standard says.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Fixing style violations while working on a real change as a
+preparatory clean-up step is good, but otherwise avoid useless code
+churn for the sake of conforming to the style.</p>
+<div class="literalblock">
+<div class="content">
+<pre>"Once it _is_ in the tree, it's not really worth the patch noise to
+go and fix it up."
+Cf. http://lkml.iu.edu/hypermail/linux/kernel/1001.3/01069.html</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Log messages to explain your changes are as important as the
+changes themselves.  Clearly written code and in-code comments
+explain how the code works and what is assumed from the surrounding
+context.  The log messages explain what the changes wanted to
+achieve and why the changes were necessary (more on this in the
+accompanying SubmittingPatches document).</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Make your code readable and sensible, and don&#8217;t try to be clever.</p>
+</div>
+<div class="paragraph">
+<p>As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the <em>local</em>
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn&#8217;t match the overall style of existing code).</p>
+</div>
+<div class="paragraph">
+<p>But if you must have a list of rules, here are some language
+specific ones. Note that Documentation/ToolsForGit.txt document
+has a collection of tips to help you use some external tools
+to conform to these guidelines.</p>
+</div>
+<div class="paragraph">
+<p>For shell scripts specifically (not exhaustive):</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs for indentation.</p>
+</li>
+<li>
+<p>Case arms are indented at the same depth as case and esac lines,
+like this:</p>
+<div class="literalblock">
+<div class="content">
+<pre>case "$variable" in
+pattern1)
+	do this
+	;;
+pattern2)
+	do that
+	;;
+esac</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Redirection operators should be written with space before, but no
+space after them.  In other words, write <em>echo test &gt;"$file"</em>
+instead of <em>echo test&gt; $file</em> or <em>echo test &gt; $file</em>.  Note that
+even though it is not required by POSIX to double-quote the
+redirection target in a variable (as shown above), our code does so
+because some versions of bash issue a warning without the quotes.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+cat hello &gt; world &lt; universe
+echo hello &gt;$world</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+cat hello &gt;world &lt;universe
+echo hello &gt;"$world"</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer $( &#8230;&#8203; ) for command substitution; unlike ``, it
+properly nests.  It should have been the way Bourne spelled
+it from day one, but unfortunately isn&#8217;t.</p>
+</li>
+<li>
+<p>If you want to find out if a command is available on the user&#8217;s
+$PATH, you should use <em>type &lt;command&gt;</em>, instead of <em>which &lt;command&gt;</em>.
+The output of <em>which</em> is not machine parsable and its exit code
+is not reliable across platforms.</p>
+</li>
+<li>
+<p>We use POSIX compliant parameter substitutions and avoid bashisms;
+namely:</p>
+</li>
+<li>
+<p>We use ${parameter-word} and its [-=?+] siblings, and their
+colon&#8217;ed "unset or null" form.</p>
+</li>
+<li>
+<p>We use ${parameter#word} and its [#%] siblings, and their
+doubled "longest matching" form.</p>
+</li>
+<li>
+<p>No "Substring Expansion" ${parameter:offset:length}.</p>
+</li>
+<li>
+<p>No shell arrays.</p>
+</li>
+<li>
+<p>No pattern replacement ${parameter/pattern/string}.</p>
+</li>
+<li>
+<p>We use Arithmetic Expansion $&#8230;&#8203;.</p>
+</li>
+<li>
+<p>We do not use Process Substitution &lt;(list) or &gt;(list).</p>
+</li>
+<li>
+<p>Do not write control structures on a single line with semicolon.
+"then" should be on the next line for if statements, and "do"
+should be on the next line for "while" and "for".</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+if test -f hello; then
+	do this
+fi</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+if test -f hello
+then
+	do this
+fi</pre>
+</div>
+</div>
+</li>
+<li>
+<p>If a command sequence joined with &amp;&amp; or || or | spans multiple
+lines, put each command on a separate line and put &amp;&amp; and || and |
+operators at the end of each line, rather than the start. This
+means you don&#8217;t need to use \ to join lines, since the above
+operators imply the sequence isn&#8217;t finished.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+grep blob verify_pack_result \
+| awk -f print_1.awk \
+| sort &gt;actual &amp;&amp;
+...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+grep blob verify_pack_result |
+awk -f print_1.awk |
+sort &gt;actual &amp;&amp;
+...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer "test" over "[ &#8230;&#8203; ]".</p>
+</li>
+<li>
+<p>We do not write the noiseword "function" in front of shell
+functions.</p>
+</li>
+<li>
+<p>We prefer a space between the function name and the parentheses,
+and no space inside the parentheses. The opening "{" should also
+be on the same line.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+my_function(){
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+my_function () {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+[::], [==], or [..]) for portability.</p>
+</li>
+<li>
+<p>We do not use \{m,n\};</p>
+</li>
+<li>
+<p>We do not use ? or + (which are \{0,1\} and \{1,\}
+respectively in BRE) but that goes without saying as these
+are ERE elements not BRE (note that \? and \+ are not even part
+of BRE&#8201;&#8212;&#8201;making them accessible from BRE is a GNU extension).</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers in git-sh-i18n to make the user
+interface translatable. See "Marking strings for translation" in
+po/README.</p>
+</li>
+<li>
+<p>We do not write our "test" command with "-a" and "-o" and use "&amp;&amp;"
+or "||" to concatenate multiple "test" commands instead, because
+the use of "-a/-o" is often error-prone.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" -a "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is buggy and breaks when $x is "=", but</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" &amp;&amp; test "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>does not have such a problem.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Even though "local" is not part of POSIX, we make heavy use of it
+in our test suite.  We do not use it in scripted Porcelains, and
+hopefully nobody starts using "local" before they are reimplemented
+in C ;-)</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For C programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs to indent, and interpret tabs as taking up to
+8 spaces.</p>
+</li>
+<li>
+<p>We try to keep to at most 80 characters per line.</p>
+</li>
+<li>
+<p>As a Git developer we assume you have a reasonably modern compiler
+and we recommend you to enable the DEVELOPER makefile knob to
+ensure your patch is clear of all compiler warnings we care about,
+by e.g. "echo DEVELOPER=1 &gt;&gt;config.mak".</p>
+</li>
+<li>
+<p>We try to support a wide range of C compilers to compile Git with,
+including old ones.  As of Git v2.35.0 Git requires C99 (we check
+"<em>STDC_VERSION</em>"). You should not use features from a newer C
+standard, even if your compiler groks them.</p>
+<div class="literalblock">
+<div class="content">
+<pre>New C99 features have been phased in gradually, if something's new
+in C99 but not used yet don't assume that it's safe to use, some
+compilers we target have only partial support for it. These are
+considered safe to use:</pre>
+</div>
+</div>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>since around 2007 with 2b6854c863a, we have been using
+initializer elements which are not computable at load time. E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>const char *args[] = {"constant", variable, NULL};</pre>
+</div>
+</div>
+</li>
+<li>
+<p>since early 2012 with e1327023ea, we have been using an enum
+definition whose last element is followed by a comma.  This, like
+an array initializer that ends with a trailing comma, can be used
+to reduce the patch noise when adding a new identifier at the end.</p>
+</li>
+<li>
+<p>since mid 2017 with cbc0f81d, we have been using designated
+initializers for struct (e.g. "struct t v = { .val = <em>a</em> };").</p>
+</li>
+<li>
+<p>since mid 2017 with 512f41cf, we have been using designated
+initializers for array (e.g. "int array[10] = { [5] = 2 }").</p>
+</li>
+<li>
+<p>since early 2021 with 765dc168882, we have been using variadic
+macros, mostly for printf-like trace and debug macros.</p>
+</li>
+<li>
+<p>since late 2021 with 44ba10d6, we have had variables declared in
+the for loop "for (int i = 0; i &lt; 10; i++)".</p>
+<div class="literalblock">
+<div class="content">
+<pre>New C99 features that we cannot use yet:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>%z and %zu as a printf() argument for a size_t (the %z being for
+the POSIX-specific ssize_t). Instead you should use
+printf("%"PRIuMAX, (uintmax_t)v).  These days the MSVC version we
+rely on supports %z, but the C library used by MinGW does not.</p>
+</li>
+<li>
+<p>Shorthand like ".a.b = *c" in struct initializations is known to
+trip up an older IBM XLC version, use ".a = { .b = *c }" instead.
+See the 33665d98 (reftable: make assignments portable to AIX xlc
+v12.01, 2022-03-28).</p>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>Variables have to be declared at the beginning of the block, before
+the first statement (i.e. -Wdeclaration-after-statement).</p>
+</li>
+<li>
+<p>NULL pointers shall be written as NULL, not as 0.</p>
+</li>
+<li>
+<p>When declaring pointers, the star sides with the variable
+name, i.e. "char <strong>string", not "char</strong> string" or
+"char * string".  This makes it easier to understand code
+like "char *string, c;".</p>
+</li>
+<li>
+<p>Use whitespace around operators and keywords, but not inside
+parentheses and not around functions. So:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      while (condition)
+func(bar + 1);</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>      while( condition )
+func (bar+1);</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Do not explicitly compare an integral value with constant 0 or <em>\0</em>,
+or a pointer value with constant NULL.  For instance, to validate that
+counted array &lt;ptr, cnt&gt; is initialized but has no elements, write:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (!ptr || cnt)
+	BUG("empty array expected");</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (ptr == NULL || cnt != 0);
+	BUG("empty array expected");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We avoid using braces unnecessarily.  I.e.</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (bla) {
+	x = 1;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is frowned upon. But there are a few exceptions:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When the statement extends over a few lines (e.g., a while loop
+with an embedded conditional, or a comment). E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (foo) {
+	if (x)
+		one();
+	else
+		two();
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	/*
+	 * This one requires some explanation,
+	 * so we're better off with braces to make
+	 * it obvious that the indentation is correct.
+	 */
+	doit();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When there are multiple arms to a conditional and some of them
+require braces, enclose even a single line block in braces for
+consistency. E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	doit();
+} else {
+	one();
+	two();
+	three();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments in the condition of an "if" statement.</p>
+</li>
+<li>
+<p>Try to make your code understandable.  You may put comments
+in, but comments invariably tend to stale out when the code
+they were describing changes.  Often splitting a function
+into two makes the intention of the code much clearer.</p>
+</li>
+<li>
+<p>Multi-line comments include their delimiters on separate lines from
+the text.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * A very long
+ * multi-line comment.
+ */</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Note however that a comment that explains a translatable string to
+translators uses a convention of starting with a magic token
+"TRANSLATORS: ", e.g.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * TRANSLATORS: here is a comment that explains the string to
+ * be translated, that follows immediately after it.
+ */
+_("Here is a translatable string explained by the above.");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Double negation is often harder to understand than no negation
+at all.</p>
+</li>
+<li>
+<p>There are two schools of thought when it comes to comparison,
+especially inside a loop. Some people prefer to have the less stable
+value on the left hand side and the more stable value on the right hand
+side, e.g. if you have a loop that counts variable i down to the
+lower bound,</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (i &gt; lower_bound) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Other people prefer to have the textual order of values match the
+actual order of values in their comparison, so that they can
+mentally draw a number line from left to right and place these
+values in order, i.e.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while (lower_bound &lt; i) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  However, the more "stable" the
+stable side becomes, the more we tend to prefer the former
+(comparison with a constant, "i &gt; 0", is an extreme example).
+Just do not mix styles in the same part of the code and mimic
+existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>There are two schools of thought when it comes to splitting a long
+logical line into multiple lines.  Some people push the second and
+subsequent lines far enough to the right with tabs and align them:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+              ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to align the second and the subsequent
+lines with the column immediately inside the opening parenthesis,
+with tabs and spaces, following our "tabstop is always a multiple
+of 8" convention:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+           ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  Again, just do not mix styles in
+the same part of the code and mimic existing styles in the
+neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, some people change line before
+a binary operator, so that the result looks like a parse tree when
+you turn your head 90-degrees counterclockwise:</p>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to
+|| span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to leave the operator at the end of the
+line:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, but we tend to use the latter more, unless the
+expression gets fairly complex, in which case the former tends to
+be easier to read.  Again, just do not mix styles in the same part
+of the code and mimic existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, with everything else being
+equal, it is preferable to split after the operator at higher
+level in the parse tree.  That is, this is more preferable:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable * that_is_used_in +
+    a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>than</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable *
+    that_is_used_in + a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Some clever tricks, like using the !! operator with arithmetic
+constructs, can be extremely confusing to others.  Avoid them,
+unless there is a compelling reason to use them.</p>
+</li>
+<li>
+<p>Use the API.  No, really.  We have a strbuf (variable length
+string), several arrays with the ALLOC_GROW() macro, a
+string_list for sorted string lists, a hash map (mapping struct
+objects) named "struct decorate", amongst other things.</p>
+</li>
+<li>
+<p>When you come up with an API, document its functions and structures
+in the header file that exposes the API to its callers. Use what is
+in "strbuf.h" as a model for the appropriate tone and level of
+detail.</p>
+</li>
+<li>
+<p>The first #include in C files, except in platform specific compat/
+implementations and sha1dc/, must be either "git-compat-util.h" or
+one of the approved headers that includes it first for you.  (The
+approved headers currently include "cache.h", "builtin.h",
+"t/helper/test-tool.h", "xdiff/xinclude.h", or
+"reftable/system.h").  You do not have to include more than one of
+these.</p>
+</li>
+<li>
+<p>A C file must directly include the header files that declare the
+functions and the types it uses, except for the functions and types
+that are made available to it by including one of the header files
+it must include by the previous rule.</p>
+</li>
+<li>
+<p>If you are planning a new command, consider writing it in shell
+or perl first, so that changes in semantics can be easily
+changed and discussed.  Many Git commands started out like
+that, and a few are still scripts.</p>
+</li>
+<li>
+<p>Avoid introducing a new dependency into Git. This means you
+usually should stay away from scripting languages not already
+used in the Git core command set (unless your command is clearly
+separate from it, such as an importer to convert random-scm-X
+repositories to Git).</p>
+</li>
+<li>
+<p>When we pass &lt;string, length&gt; pair to functions, we should try to
+pass them in that order.</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers to make the user interface
+translatable. See "Marking strings for translation" in po/README.</p>
+</li>
+<li>
+<p>Variables and functions local to a given source file should be marked
+with "static". Variables that are visible to other source files
+must be declared with "extern" in header files. However, function
+declarations should not use "extern", as that is already the default.</p>
+</li>
+<li>
+<p>You can launch gdb around your program using the shorthand GIT_DEBUGGER.
+Run <code>GIT_DEBUGGER=1 ./bin-wrappers/git foo</code> to simply use gdb as is, or
+run <code>GIT_DEBUGGER="&lt;debugger&gt; &lt;debugger-args&gt;" ./bin-wrappers/git foo</code> to
+use your own debugger and arguments. Example: <code>GIT_DEBUGGER="ddd --gdb"
+./bin-wrappers/git log</code> (See <code>wrap-for-bin.sh</code>.)</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Perl programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most of the C guidelines above apply.</p>
+</li>
+<li>
+<p>We try to support Perl 5.8 and later ("use Perl 5.008").</p>
+</li>
+<li>
+<p>use strict and use warnings are strongly preferred.</p>
+</li>
+<li>
+<p>Don&#8217;t overuse statement modifiers unless using them makes the
+result easier to follow.</p>
+<div class="olist lowerroman">
+<ol class="lowerroman" type="i">
+<li>
+<p>do something &#8230;&#8203;
+do_this() unless (condition);</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>is more readable than:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>do something &#8230;&#8203;
+unless (condition) {
+	do_this();
+}</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>*only* when the condition is so rare that do_this() will be almost
+always called.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments inside "if ()" conditions.</p>
+</li>
+<li>
+<p>Learn and use Git.pm if you need that functionality.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Python scripts:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We follow PEP-8 (<a href="http://www.python.org/dev/peps/pep-0008/" class="bare">http://www.python.org/dev/peps/pep-0008/</a>).</p>
+</li>
+<li>
+<p>As a minimum, we aim to be compatible with Python 2.7.</p>
+</li>
+<li>
+<p>Where required libraries do not restrict us to Python 2, we try to
+also be compatible with Python 3.1 and later.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Program Output</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>We make a distinction between a Git command's primary output and
+output which is merely chatty feedback (for instance, status
+messages, running transcript, or progress display), as well as error
+messages. Roughly speaking, a Git command's primary output is that
+which one might want to capture to a file or send down a pipe; its
+chatty output should not interfere with these use-cases.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>As such, primary output should be sent to the standard output stream
+(stdout), and chatty output should be sent to the standard error
+stream (stderr). Examples of commands which produce primary output
+include `git log`, `git show`, and `git branch --list` which generate
+output on the stdout stream.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Not all Git commands have primary output; this is often true of
+commands whose main function is to perform an action. Some action
+commands are silent, whereas others are chatty. An example of a
+chatty action commands is `git clone` with its "Cloning into
+'&lt;path&gt;'..." and "Checking connectivity..." status messages which it
+sends to the stderr stream.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Error messages from Git commands should always be sent to the stderr
+stream.</pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Error Messages</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Do not end error messages with a full stop.</p>
+</li>
+<li>
+<p>Do not capitalize the first word, only because it is the first word
+in the message ("unable to open %s", not "Unable to open %s").  But
+"SHA-3 not supported" is fine, because the reason the first word is
+capitalized is not because it is at the beginning of the sentence,
+but because the word would be spelled in capital letters even when
+it appeared in the middle of the sentence.</p>
+</li>
+<li>
+<p>Say what the error is first ("cannot open %s", not "%s: cannot open")</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Externally Visible Names</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>For configuration variable names, follow the existing convention:</p>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>The section name indicates the affected subsystem.</p>
+</li>
+<li>
+<p>The subsection name, if any, indicates which of an unbounded set
+of things to set the value for.</p>
+</li>
+<li>
+<p>The variable name describes the effect of tweaking this knob.</p>
+<div class="literalblock">
+<div class="content">
+<pre>The section and variable names that consist of multiple words are
+formed by concatenating the words without punctuations (e.g. `-`),
+and are broken using bumpyCaps in documentation as a hint to the
+reader.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>When choosing the variable namespace, do not use variable name for
+specifying possibly unbounded set of things, most notably anything
+an end user can freely come up with (e.g. branch names).  Instead,
+use subsection names or variable values, like the existing variable
+branch.&lt;name&gt;.description does.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Writing Documentation:</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Most (if not all) of the documentation pages are written in the
+AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+processed into HTML and manpages (e.g. git.html and git.1 in the
+same directory).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>The documentation liberally mixes US and UK English (en_US/UK)
+norms for spelling and grammar, which is somewhat unfortunate.
+In an ideal world, it would have been better if it consistently
+used only one and not the other, and we would have picked en_US
+(if you wish to correct the English of some of the existing
+documentation, please see the documentation-related advice in the
+Documentation/SubmittingPatches file).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>In order to ensure the documentation is inclusive, avoid assuming
+that an unspecified example person is male or female, and think
+twice before using "he", "him", "she", or "her".  Here are some
+tips to avoid use of gendered pronouns:</pre>
+</div>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Prefer succinctness and matter-of-factly describing functionality
+in the abstract.  E.g.</p>
+<div class="dlist">
+<dl>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short"> <a class="anchor" href="#Documentation/CodingGuidelines---short"></a>--short </dt>
+<dd>
+<p>Emit output in the short-format.</p>
+<div class="literalblock">
+<div class="content">
+<pre>and avoid something like these overly verbose alternatives:</pre>
+</div>
+</div>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short-1"> <a class="anchor" href="#Documentation/CodingGuidelines---short-1"></a>--short </dt>
+<dd>
+<p>Use this to emit output in the short-format.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short-1-1"> <a class="anchor" href="#Documentation/CodingGuidelines---short-1-1"></a>--short </dt>
+<dd>
+<p>You can use this to get output in the short-format.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short-1-1-1"> <a class="anchor" href="#Documentation/CodingGuidelines---short-1-1-1"></a>--short </dt>
+<dd>
+<p>A user who prefers shorter output could&#8230;&#8203;.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short-1-1-1-1"> <a class="anchor" href="#Documentation/CodingGuidelines---short-1-1-1-1"></a>--short </dt>
+<dd>
+<p>Should a person and/or program want shorter output, he
+she/they/it can&#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>This practice often eliminates the need to involve human actors in
+your description, but it is a good practice regardless of the
+avoidance of gendered pronouns.</pre>
+</div>
+</div>
+</dd>
+</dl>
+</div>
+</li>
+<li>
+<p>When it becomes awkward to stick to this style, prefer "you" when
+addressing the hypothetical user, and possibly "we" when
+discussing how the program might react to the user.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>You can use this option instead of --xyz, but we might remove
+support for it in future versions.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while keeping in mind that you can probably be less verbose, e.g.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Use this instead of --xyz. This option might be removed in future
+versions.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>If you still need to refer to an example person that is
+third-person singular, you may resort to "singular they" to avoid
+"he/she/him/her", e.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>A contributor asks their upstream to pull from them.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Note that this sounds ungrammatical and unnatural to those who
+learned that "they" is only used for third-person plural, e.g.
+those who learn English as a second language in some parts of the
+world.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Every user-visible change should be reflected in the documentation.
+The same general rule as for code applies -- imitate the existing
+conventions.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying command usage strings and synopsis sections in the manual
+pages:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Placeholders are spelled in lowercase and enclosed in angle brackets:
+  &lt;file&gt;
+  --sort=&lt;key&gt;
+  --abbrev[=&lt;n&gt;]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If a placeholder has multiple words, they are separated by dashes:
+  &lt;new-branch-name&gt;
+  --template=&lt;template-directory&gt;</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Possibility of multiple occurrences is indicated by three dots:
+  &lt;file&gt;...
+  (One or more of &lt;file&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Optional parts are enclosed in square brackets:
+  [&lt;file&gt;...]
+  (Zero or more of &lt;file&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>--exec-path[=&lt;path&gt;]
+(Option with an optional argument.  Note that the "=" is inside the
+brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[&lt;patch&gt;...]
+(Zero or more of &lt;patch&gt;.  Note that the dots are inside, not
+outside the brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Multiple alternatives are indicated with vertical bars:
+  [-q | --quiet]
+  [--utf8 | --no-utf8]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Use spacing around "|" token(s), but not immediately after opening or
+before closing a [] or () pair:
+  Do: [-q | --quiet]
+  Don't: [-q|--quiet]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Don't use spacing around "|" tokens when they're used to seperate the
+alternate arguments of an option:
+   Do: --track[=(direct|inherit)]
+   Don't: --track[=(direct | inherit)]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Parentheses are used for grouping:
+  [(&lt;rev&gt; | &lt;range&gt;)...]
+  (Any number of either &lt;rev&gt; or &lt;range&gt;.  Parens are needed to make
+  it clear that "..." pertains to both &lt;rev&gt; and &lt;range&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[(-p &lt;parent&gt;)...]
+(Any number of option -p, each with one &lt;parent&gt; argument.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>git remote set-head &lt;name&gt; (-a | -d | &lt;branch&gt;)
+(One and only one of "-a", "-d" or "&lt;branch&gt;" _must_ (no square
+brackets) be provided.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>And a somewhat more contrived example:
+  --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+  Here "=" is outside the brackets, because "--diff-filter=" is a
+  valid usage.  "*" has its own pair of brackets, because it can
+  (optionally) be specified only when one or more of the letters is
+  also provided.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A note on notation:
+ Use 'git' (all lowercase) when talking about commands i.e. something
+ the user would type into a shell and use 'Git' (uppercase first letter)
+ when talking about the version control system and its properties.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying paragraphs or option/command explanations that contain options
+or commands:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Literal examples (e.g. use of command-line options, command names,
+branch names, URLs, pathnames (files and directories), configuration and
+environment variables) must be typeset in monospace (i.e. wrapped with
+backticks):
+  `--pretty=oneline`
+  `git rev-list`
+  `remote.pushDefault`
+  `http://git.example.com`
+  `.git/config`
+  `GIT_DIR`
+  `HEAD`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>An environment variable must be prefixed with "$" only when referring to its
+value and not when referring to the variable itself, in this case there is
+nothing to add except the backticks:
+  `GIT_DIR` is specified
+  `$GIT_DIR/hooks/pre-receive`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Word phrases enclosed in `backtick characters` are rendered literally
+and will not be further expanded. The use of `backticks` to achieve the
+previous rule means that literal examples should not use AsciiDoc
+escapes.
+  Correct:
+     `--pretty=oneline`
+  Incorrect:
+     `\--pretty=oneline`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If some place in the documentation needs to typeset a command usage
+example with inline substitutions, it is fine to use +monospaced and
+inline substituted text+ instead of `monospaced literal text`, and with
+the former, the part that should not get substituted must be
+quoted/escaped.</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+</div>
+</div>
\ No newline at end of file
diff --git a/external/docs/content/docs/CodingGuidelines/2.42.0.html b/external/docs/content/docs/CodingGuidelines/2.42.0.html
new file mode 100644
index 0000000000..6f74362630
--- /dev/null
+++ b/external/docs/content/docs/CodingGuidelines/2.42.0.html
@@ -0,0 +1,1195 @@
+---
+### DO NOT EDIT! Generated by script/update-docs.rb
+
+category: manual
+section: documentation
+subsection: manual
+title: Git - CodingGuidelines Documentation
+docname: CodingGuidelines
+version: 2.42.0
+aliases:
+- "/docs/CodingGuidelines/2.42.0/index.html"
+---
+<div id="preamble">
+<div class="sectionbody">
+<div class="paragraph">
+<p>Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, a few rough rules are:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most importantly, we never say "It&#8217;s in POSIX; we&#8217;ll happily
+ignore your needs should your system not conform to it."
+We live in the real world.</p>
+</li>
+<li>
+<p>However, we often say "Let&#8217;s stay away from that construct,
+it&#8217;s not even in POSIX".</p>
+</li>
+<li>
+<p>In spite of the above two rules, we sometimes say "Although
+this is not in POSIX, it (is so convenient | makes the code
+much more readable | has other good characteristics) and
+practically all the platforms we care about support it, so
+let&#8217;s use it".</p>
+<div class="literalblock">
+<div class="content">
+<pre>Again, we live in the real world, and it is sometimes a
+judgement call, the decision based more on real world
+constraints people face than what the paper standard says.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Fixing style violations while working on a real change as a
+preparatory clean-up step is good, but otherwise avoid useless code
+churn for the sake of conforming to the style.</p>
+<div class="literalblock">
+<div class="content">
+<pre>"Once it _is_ in the tree, it's not really worth the patch noise to
+go and fix it up."
+Cf. http://lkml.iu.edu/hypermail/linux/kernel/1001.3/01069.html</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Log messages to explain your changes are as important as the
+changes themselves.  Clearly written code and in-code comments
+explain how the code works and what is assumed from the surrounding
+context.  The log messages explain what the changes wanted to
+achieve and why the changes were necessary (more on this in the
+accompanying SubmittingPatches document).</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Make your code readable and sensible, and don&#8217;t try to be clever.</p>
+</div>
+<div class="paragraph">
+<p>As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the <em>local</em>
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn&#8217;t match the overall style of existing code).</p>
+</div>
+<div class="paragraph">
+<p>But if you must have a list of rules, here are some language
+specific ones. Note that Documentation/ToolsForGit.txt document
+has a collection of tips to help you use some external tools
+to conform to these guidelines.</p>
+</div>
+<div class="paragraph">
+<p>For shell scripts specifically (not exhaustive):</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs for indentation.</p>
+</li>
+<li>
+<p>Case arms are indented at the same depth as case and esac lines,
+like this:</p>
+<div class="literalblock">
+<div class="content">
+<pre>case "$variable" in
+pattern1)
+	do this
+	;;
+pattern2)
+	do that
+	;;
+esac</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Redirection operators should be written with space before, but no
+space after them.  In other words, write <em>echo test &gt;"$file"</em>
+instead of <em>echo test&gt; $file</em> or <em>echo test &gt; $file</em>.  Note that
+even though it is not required by POSIX to double-quote the
+redirection target in a variable (as shown above), our code does so
+because some versions of bash issue a warning without the quotes.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+cat hello &gt; world &lt; universe
+echo hello &gt;$world</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+cat hello &gt;world &lt;universe
+echo hello &gt;"$world"</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer $( &#8230;&#8203; ) for command substitution; unlike ``, it
+properly nests.  It should have been the way Bourne spelled
+it from day one, but unfortunately isn&#8217;t.</p>
+</li>
+<li>
+<p>If you want to find out if a command is available on the user&#8217;s
+$PATH, you should use <em>type &lt;command&gt;</em>, instead of <em>which &lt;command&gt;</em>.
+The output of <em>which</em> is not machine parsable and its exit code
+is not reliable across platforms.</p>
+</li>
+<li>
+<p>We use POSIX compliant parameter substitutions and avoid bashisms;
+namely:</p>
+</li>
+<li>
+<p>We use ${parameter-word} and its [-=?+] siblings, and their
+colon&#8217;ed "unset or null" form.</p>
+</li>
+<li>
+<p>We use ${parameter#word} and its [#%] siblings, and their
+doubled "longest matching" form.</p>
+</li>
+<li>
+<p>No "Substring Expansion" ${parameter:offset:length}.</p>
+</li>
+<li>
+<p>No shell arrays.</p>
+</li>
+<li>
+<p>No pattern replacement ${parameter/pattern/string}.</p>
+</li>
+<li>
+<p>We use Arithmetic Expansion $&#8230;&#8203;.</p>
+</li>
+<li>
+<p>We do not use Process Substitution &lt;(list) or &gt;(list).</p>
+</li>
+<li>
+<p>Do not write control structures on a single line with semicolon.
+"then" should be on the next line for if statements, and "do"
+should be on the next line for "while" and "for".</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+if test -f hello; then
+	do this
+fi</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+if test -f hello
+then
+	do this
+fi</pre>
+</div>
+</div>
+</li>
+<li>
+<p>If a command sequence joined with &amp;&amp; or || or | spans multiple
+lines, put each command on a separate line and put &amp;&amp; and || and |
+operators at the end of each line, rather than the start. This
+means you don&#8217;t need to use \ to join lines, since the above
+operators imply the sequence isn&#8217;t finished.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+grep blob verify_pack_result \
+| awk -f print_1.awk \
+| sort &gt;actual &amp;&amp;
+...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+grep blob verify_pack_result |
+awk -f print_1.awk |
+sort &gt;actual &amp;&amp;
+...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer "test" over "[ &#8230;&#8203; ]".</p>
+</li>
+<li>
+<p>We do not write the noiseword "function" in front of shell
+functions.</p>
+</li>
+<li>
+<p>We prefer a space between the function name and the parentheses,
+and no space inside the parentheses. The opening "{" should also
+be on the same line.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+my_function(){
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+my_function () {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+[::], [==], or [..]) for portability.</p>
+</li>
+<li>
+<p>We do not use \{m,n\};</p>
+</li>
+<li>
+<p>We do not use ? or + (which are \{0,1\} and \{1,\}
+respectively in BRE) but that goes without saying as these
+are ERE elements not BRE (note that \? and \+ are not even part
+of BRE&#8201;&#8212;&#8201;making them accessible from BRE is a GNU extension).</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers in git-sh-i18n to make the user
+interface translatable. See "Marking strings for translation" in
+po/README.</p>
+</li>
+<li>
+<p>We do not write our "test" command with "-a" and "-o" and use "&amp;&amp;"
+or "||" to concatenate multiple "test" commands instead, because
+the use of "-a/-o" is often error-prone.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" -a "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is buggy and breaks when $x is "=", but</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" &amp;&amp; test "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>does not have such a problem.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Even though "local" is not part of POSIX, we make heavy use of it
+in our test suite.  We do not use it in scripted Porcelains, and
+hopefully nobody starts using "local" before they are reimplemented
+in C ;-)</p>
+</li>
+<li>
+<p>Use octal escape sequences (e.g. "\302\242"), not hexadecimal (e.g.
+"\xc2\xa2") in printf format strings, since hexadecimal escape
+sequences are not portable.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For C programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs to indent, and interpret tabs as taking up to
+8 spaces.</p>
+</li>
+<li>
+<p>We try to keep to at most 80 characters per line.</p>
+</li>
+<li>
+<p>As a Git developer we assume you have a reasonably modern compiler
+and we recommend you to enable the DEVELOPER makefile knob to
+ensure your patch is clear of all compiler warnings we care about,
+by e.g. "echo DEVELOPER=1 &gt;&gt;config.mak".</p>
+</li>
+<li>
+<p>We try to support a wide range of C compilers to compile Git with,
+including old ones.  As of Git v2.35.0 Git requires C99 (we check
+"<em>STDC_VERSION</em>"). You should not use features from a newer C
+standard, even if your compiler groks them.</p>
+<div class="literalblock">
+<div class="content">
+<pre>New C99 features have been phased in gradually, if something's new
+in C99 but not used yet don't assume that it's safe to use, some
+compilers we target have only partial support for it. These are
+considered safe to use:</pre>
+</div>
+</div>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>since around 2007 with 2b6854c863a, we have been using
+initializer elements which are not computable at load time. E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>const char *args[] = {"constant", variable, NULL};</pre>
+</div>
+</div>
+</li>
+<li>
+<p>since early 2012 with e1327023ea, we have been using an enum
+definition whose last element is followed by a comma.  This, like
+an array initializer that ends with a trailing comma, can be used
+to reduce the patch noise when adding a new identifier at the end.</p>
+</li>
+<li>
+<p>since mid 2017 with cbc0f81d, we have been using designated
+initializers for struct (e.g. "struct t v = { .val = <em>a</em> };").</p>
+</li>
+<li>
+<p>since mid 2017 with 512f41cf, we have been using designated
+initializers for array (e.g. "int array[10] = { [5] = 2 }").</p>
+</li>
+<li>
+<p>since early 2021 with 765dc168882, we have been using variadic
+macros, mostly for printf-like trace and debug macros.</p>
+</li>
+<li>
+<p>since late 2021 with 44ba10d6, we have had variables declared in
+the for loop "for (int i = 0; i &lt; 10; i++)".</p>
+<div class="literalblock">
+<div class="content">
+<pre>New C99 features that we cannot use yet:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>%z and %zu as a printf() argument for a size_t (the %z being for
+the POSIX-specific ssize_t). Instead you should use
+printf("%"PRIuMAX, (uintmax_t)v).  These days the MSVC version we
+rely on supports %z, but the C library used by MinGW does not.</p>
+</li>
+<li>
+<p>Shorthand like ".a.b = *c" in struct initializations is known to
+trip up an older IBM XLC version, use ".a = { .b = *c }" instead.
+See the 33665d98 (reftable: make assignments portable to AIX xlc
+v12.01, 2022-03-28).</p>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>Variables have to be declared at the beginning of the block, before
+the first statement (i.e. -Wdeclaration-after-statement).</p>
+</li>
+<li>
+<p>NULL pointers shall be written as NULL, not as 0.</p>
+</li>
+<li>
+<p>When declaring pointers, the star sides with the variable
+name, i.e. "char <strong>string", not "char</strong> string" or
+"char * string".  This makes it easier to understand code
+like "char *string, c;".</p>
+</li>
+<li>
+<p>Use whitespace around operators and keywords, but not inside
+parentheses and not around functions. So:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      while (condition)
+func(bar + 1);</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>      while( condition )
+func (bar+1);</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Do not explicitly compare an integral value with constant 0 or <em>\0</em>,
+or a pointer value with constant NULL.  For instance, to validate that
+counted array &lt;ptr, cnt&gt; is initialized but has no elements, write:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (!ptr || cnt)
+	BUG("empty array expected");</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (ptr == NULL || cnt != 0);
+	BUG("empty array expected");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We avoid using braces unnecessarily.  I.e.</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (bla) {
+	x = 1;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is frowned upon. But there are a few exceptions:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When the statement extends over a few lines (e.g., a while loop
+with an embedded conditional, or a comment). E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (foo) {
+	if (x)
+		one();
+	else
+		two();
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	/*
+	 * This one requires some explanation,
+	 * so we're better off with braces to make
+	 * it obvious that the indentation is correct.
+	 */
+	doit();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When there are multiple arms to a conditional and some of them
+require braces, enclose even a single line block in braces for
+consistency. E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	doit();
+} else {
+	one();
+	two();
+	three();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments in the condition of an "if" statement.</p>
+</li>
+<li>
+<p>Try to make your code understandable.  You may put comments
+in, but comments invariably tend to stale out when the code
+they were describing changes.  Often splitting a function
+into two makes the intention of the code much clearer.</p>
+</li>
+<li>
+<p>Multi-line comments include their delimiters on separate lines from
+the text.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * A very long
+ * multi-line comment.
+ */</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Note however that a comment that explains a translatable string to
+translators uses a convention of starting with a magic token
+"TRANSLATORS: ", e.g.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * TRANSLATORS: here is a comment that explains the string to
+ * be translated, that follows immediately after it.
+ */
+_("Here is a translatable string explained by the above.");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Double negation is often harder to understand than no negation
+at all.</p>
+</li>
+<li>
+<p>There are two schools of thought when it comes to comparison,
+especially inside a loop. Some people prefer to have the less stable
+value on the left hand side and the more stable value on the right hand
+side, e.g. if you have a loop that counts variable i down to the
+lower bound,</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (i &gt; lower_bound) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Other people prefer to have the textual order of values match the
+actual order of values in their comparison, so that they can
+mentally draw a number line from left to right and place these
+values in order, i.e.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while (lower_bound &lt; i) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  However, the more "stable" the
+stable side becomes, the more we tend to prefer the former
+(comparison with a constant, "i &gt; 0", is an extreme example).
+Just do not mix styles in the same part of the code and mimic
+existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>There are two schools of thought when it comes to splitting a long
+logical line into multiple lines.  Some people push the second and
+subsequent lines far enough to the right with tabs and align them:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+              ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to align the second and the subsequent
+lines with the column immediately inside the opening parenthesis,
+with tabs and spaces, following our "tabstop is always a multiple
+of 8" convention:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+           ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  Again, just do not mix styles in
+the same part of the code and mimic existing styles in the
+neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, some people change line before
+a binary operator, so that the result looks like a parse tree when
+you turn your head 90-degrees counterclockwise:</p>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to
+|| span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to leave the operator at the end of the
+line:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, but we tend to use the latter more, unless the
+expression gets fairly complex, in which case the former tends to
+be easier to read.  Again, just do not mix styles in the same part
+of the code and mimic existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, with everything else being
+equal, it is preferable to split after the operator at higher
+level in the parse tree.  That is, this is more preferable:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable * that_is_used_in +
+    a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>than</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable *
+    that_is_used_in + a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Some clever tricks, like using the !! operator with arithmetic
+constructs, can be extremely confusing to others.  Avoid them,
+unless there is a compelling reason to use them.</p>
+</li>
+<li>
+<p>Use the API.  No, really.  We have a strbuf (variable length
+string), several arrays with the ALLOC_GROW() macro, a
+string_list for sorted string lists, a hash map (mapping struct
+objects) named "struct decorate", amongst other things.</p>
+</li>
+<li>
+<p>When you come up with an API, document its functions and structures
+in the header file that exposes the API to its callers. Use what is
+in "strbuf.h" as a model for the appropriate tone and level of
+detail.</p>
+</li>
+<li>
+<p>The first #include in C files, except in platform specific compat/
+implementations and sha1dc/, must be either "git-compat-util.h" or
+one of the approved headers that includes it first for you.  (The
+approved headers currently include "builtin.h",
+"t/helper/test-tool.h", "xdiff/xinclude.h", or
+"reftable/system.h").  You do not have to include more than one of
+these.</p>
+</li>
+<li>
+<p>A C file must directly include the header files that declare the
+functions and the types it uses, except for the functions and types
+that are made available to it by including one of the header files
+it must include by the previous rule.</p>
+</li>
+<li>
+<p>If you are planning a new command, consider writing it in shell
+or perl first, so that changes in semantics can be easily
+changed and discussed.  Many Git commands started out like
+that, and a few are still scripts.</p>
+</li>
+<li>
+<p>Avoid introducing a new dependency into Git. This means you
+usually should stay away from scripting languages not already
+used in the Git core command set (unless your command is clearly
+separate from it, such as an importer to convert random-scm-X
+repositories to Git).</p>
+</li>
+<li>
+<p>When we pass &lt;string, length&gt; pair to functions, we should try to
+pass them in that order.</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers to make the user interface
+translatable. See "Marking strings for translation" in po/README.</p>
+</li>
+<li>
+<p>Variables and functions local to a given source file should be marked
+with "static". Variables that are visible to other source files
+must be declared with "extern" in header files. However, function
+declarations should not use "extern", as that is already the default.</p>
+</li>
+<li>
+<p>You can launch gdb around your program using the shorthand GIT_DEBUGGER.
+Run <code>GIT_DEBUGGER=1 ./bin-wrappers/git foo</code> to simply use gdb as is, or
+run <code>GIT_DEBUGGER="&lt;debugger&gt; &lt;debugger-args&gt;" ./bin-wrappers/git foo</code> to
+use your own debugger and arguments. Example: <code>GIT_DEBUGGER="ddd --gdb"
+./bin-wrappers/git log</code> (See <code>wrap-for-bin.sh</code>.)</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Perl programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most of the C guidelines above apply.</p>
+</li>
+<li>
+<p>We try to support Perl 5.8 and later ("use Perl 5.008").</p>
+</li>
+<li>
+<p>use strict and use warnings are strongly preferred.</p>
+</li>
+<li>
+<p>Don&#8217;t overuse statement modifiers unless using them makes the
+result easier to follow.</p>
+<div class="olist lowerroman">
+<ol class="lowerroman" type="i">
+<li>
+<p>do something &#8230;&#8203;
+do_this() unless (condition);</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>is more readable than:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>do something &#8230;&#8203;
+unless (condition) {
+	do_this();
+}</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>*only* when the condition is so rare that do_this() will be almost
+always called.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments inside "if ()" conditions.</p>
+</li>
+<li>
+<p>Learn and use Git.pm if you need that functionality.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Python scripts:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We follow PEP-8 (<a href="http://www.python.org/dev/peps/pep-0008/" class="bare">http://www.python.org/dev/peps/pep-0008/</a>).</p>
+</li>
+<li>
+<p>As a minimum, we aim to be compatible with Python 2.7.</p>
+</li>
+<li>
+<p>Where required libraries do not restrict us to Python 2, we try to
+also be compatible with Python 3.1 and later.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Program Output</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>We make a distinction between a Git command's primary output and
+output which is merely chatty feedback (for instance, status
+messages, running transcript, or progress display), as well as error
+messages. Roughly speaking, a Git command's primary output is that
+which one might want to capture to a file or send down a pipe; its
+chatty output should not interfere with these use-cases.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>As such, primary output should be sent to the standard output stream
+(stdout), and chatty output should be sent to the standard error
+stream (stderr). Examples of commands which produce primary output
+include `git log`, `git show`, and `git branch --list` which generate
+output on the stdout stream.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Not all Git commands have primary output; this is often true of
+commands whose main function is to perform an action. Some action
+commands are silent, whereas others are chatty. An example of a
+chatty action commands is `git clone` with its "Cloning into
+'&lt;path&gt;'..." and "Checking connectivity..." status messages which it
+sends to the stderr stream.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Error messages from Git commands should always be sent to the stderr
+stream.</pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Error Messages</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Do not end error messages with a full stop.</p>
+</li>
+<li>
+<p>Do not capitalize the first word, only because it is the first word
+in the message ("unable to open %s", not "Unable to open %s").  But
+"SHA-3 not supported" is fine, because the reason the first word is
+capitalized is not because it is at the beginning of the sentence,
+but because the word would be spelled in capital letters even when
+it appeared in the middle of the sentence.</p>
+</li>
+<li>
+<p>Say what the error is first ("cannot open %s", not "%s: cannot open")</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Externally Visible Names</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>For configuration variable names, follow the existing convention:</p>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>The section name indicates the affected subsystem.</p>
+</li>
+<li>
+<p>The subsection name, if any, indicates which of an unbounded set
+of things to set the value for.</p>
+</li>
+<li>
+<p>The variable name describes the effect of tweaking this knob.</p>
+<div class="literalblock">
+<div class="content">
+<pre>The section and variable names that consist of multiple words are
+formed by concatenating the words without punctuations (e.g. `-`),
+and are broken using bumpyCaps in documentation as a hint to the
+reader.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>When choosing the variable namespace, do not use variable name for
+specifying possibly unbounded set of things, most notably anything
+an end user can freely come up with (e.g. branch names).  Instead,
+use subsection names or variable values, like the existing variable
+branch.&lt;name&gt;.description does.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Writing Documentation:</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Most (if not all) of the documentation pages are written in the
+AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+processed into HTML and manpages (e.g. git.html and git.1 in the
+same directory).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>The documentation liberally mixes US and UK English (en_US/UK)
+norms for spelling and grammar, which is somewhat unfortunate.
+In an ideal world, it would have been better if it consistently
+used only one and not the other, and we would have picked en_US
+(if you wish to correct the English of some of the existing
+documentation, please see the documentation-related advice in the
+Documentation/SubmittingPatches file).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>In order to ensure the documentation is inclusive, avoid assuming
+that an unspecified example person is male or female, and think
+twice before using "he", "him", "she", or "her".  Here are some
+tips to avoid use of gendered pronouns:</pre>
+</div>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Prefer succinctness and matter-of-factly describing functionality
+in the abstract.  E.g.</p>
+<div class="dlist">
+<dl>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short"> <a class="anchor" href="#Documentation/CodingGuidelines---short"></a>--short </dt>
+<dd>
+<p>Emit output in the short-format.</p>
+<div class="literalblock">
+<div class="content">
+<pre>and avoid something like these overly verbose alternatives:</pre>
+</div>
+</div>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short-1"> <a class="anchor" href="#Documentation/CodingGuidelines---short-1"></a>--short </dt>
+<dd>
+<p>Use this to emit output in the short-format.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short-1-1"> <a class="anchor" href="#Documentation/CodingGuidelines---short-1-1"></a>--short </dt>
+<dd>
+<p>You can use this to get output in the short-format.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short-1-1-1"> <a class="anchor" href="#Documentation/CodingGuidelines---short-1-1-1"></a>--short </dt>
+<dd>
+<p>A user who prefers shorter output could&#8230;&#8203;.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short-1-1-1-1"> <a class="anchor" href="#Documentation/CodingGuidelines---short-1-1-1-1"></a>--short </dt>
+<dd>
+<p>Should a person and/or program want shorter output, he
+she/they/it can&#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>This practice often eliminates the need to involve human actors in
+your description, but it is a good practice regardless of the
+avoidance of gendered pronouns.</pre>
+</div>
+</div>
+</dd>
+</dl>
+</div>
+</li>
+<li>
+<p>When it becomes awkward to stick to this style, prefer "you" when
+addressing the hypothetical user, and possibly "we" when
+discussing how the program might react to the user.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>You can use this option instead of --xyz, but we might remove
+support for it in future versions.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while keeping in mind that you can probably be less verbose, e.g.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Use this instead of --xyz. This option might be removed in future
+versions.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>If you still need to refer to an example person that is
+third-person singular, you may resort to "singular they" to avoid
+"he/she/him/her", e.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>A contributor asks their upstream to pull from them.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Note that this sounds ungrammatical and unnatural to those who
+learned that "they" is only used for third-person plural, e.g.
+those who learn English as a second language in some parts of the
+world.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Every user-visible change should be reflected in the documentation.
+The same general rule as for code applies -- imitate the existing
+conventions.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying command usage strings and synopsis sections in the manual
+pages:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Placeholders are spelled in lowercase and enclosed in angle brackets:
+  &lt;file&gt;
+  --sort=&lt;key&gt;
+  --abbrev[=&lt;n&gt;]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If a placeholder has multiple words, they are separated by dashes:
+  &lt;new-branch-name&gt;
+  --template=&lt;template-directory&gt;</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Possibility of multiple occurrences is indicated by three dots:
+  &lt;file&gt;...
+  (One or more of &lt;file&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Optional parts are enclosed in square brackets:
+  [&lt;file&gt;...]
+  (Zero or more of &lt;file&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>--exec-path[=&lt;path&gt;]
+(Option with an optional argument.  Note that the "=" is inside the
+brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[&lt;patch&gt;...]
+(Zero or more of &lt;patch&gt;.  Note that the dots are inside, not
+outside the brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Multiple alternatives are indicated with vertical bars:
+  [-q | --quiet]
+  [--utf8 | --no-utf8]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Use spacing around "|" token(s), but not immediately after opening or
+before closing a [] or () pair:
+  Do: [-q | --quiet]
+  Don't: [-q|--quiet]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Don't use spacing around "|" tokens when they're used to separate the
+alternate arguments of an option:
+   Do: --track[=(direct|inherit)]
+   Don't: --track[=(direct | inherit)]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Parentheses are used for grouping:
+  [(&lt;rev&gt; | &lt;range&gt;)...]
+  (Any number of either &lt;rev&gt; or &lt;range&gt;.  Parens are needed to make
+  it clear that "..." pertains to both &lt;rev&gt; and &lt;range&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[(-p &lt;parent&gt;)...]
+(Any number of option -p, each with one &lt;parent&gt; argument.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>git remote set-head &lt;name&gt; (-a | -d | &lt;branch&gt;)
+(One and only one of "-a", "-d" or "&lt;branch&gt;" _must_ (no square
+brackets) be provided.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>And a somewhat more contrived example:
+  --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+  Here "=" is outside the brackets, because "--diff-filter=" is a
+  valid usage.  "*" has its own pair of brackets, because it can
+  (optionally) be specified only when one or more of the letters is
+  also provided.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A note on notation:
+ Use 'git' (all lowercase) when talking about commands i.e. something
+ the user would type into a shell and use 'Git' (uppercase first letter)
+ when talking about the version control system and its properties.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying paragraphs or option/command explanations that contain options
+or commands:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Literal examples (e.g. use of command-line options, command names,
+branch names, URLs, pathnames (files and directories), configuration and
+environment variables) must be typeset in monospace (i.e. wrapped with
+backticks):
+  `--pretty=oneline`
+  `git rev-list`
+  `remote.pushDefault`
+  `http://git.example.com`
+  `.git/config`
+  `GIT_DIR`
+  `HEAD`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>An environment variable must be prefixed with "$" only when referring to its
+value and not when referring to the variable itself, in this case there is
+nothing to add except the backticks:
+  `GIT_DIR` is specified
+  `$GIT_DIR/hooks/pre-receive`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Word phrases enclosed in `backtick characters` are rendered literally
+and will not be further expanded. The use of `backticks` to achieve the
+previous rule means that literal examples should not use AsciiDoc
+escapes.
+  Correct:
+     `--pretty=oneline`
+  Incorrect:
+     `\--pretty=oneline`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If some place in the documentation needs to typeset a command usage
+example with inline substitutions, it is fine to use +monospaced and
+inline substituted text+ instead of `monospaced literal text`, and with
+the former, the part that should not get substituted must be
+quoted/escaped.</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+</div>
+</div>
\ No newline at end of file
diff --git a/external/docs/content/docs/CodingGuidelines/2.42.1.html b/external/docs/content/docs/CodingGuidelines/2.42.1.html
new file mode 100644
index 0000000000..948c48436b
--- /dev/null
+++ b/external/docs/content/docs/CodingGuidelines/2.42.1.html
@@ -0,0 +1,1198 @@
+---
+### DO NOT EDIT! Generated by script/update-docs.rb
+
+category: manual
+section: documentation
+subsection: manual
+title: Git - CodingGuidelines Documentation
+docname: CodingGuidelines
+version: 2.42.1
+aliases:
+- "/docs/CodingGuidelines/2.42.1/index.html"
+- "/docs/CodingGuidelines/2.42.2/index.html"
+- "/docs/CodingGuidelines/2.42.3/index.html"
+- "/docs/CodingGuidelines/2.42.4/index.html"
+---
+<div id="preamble">
+<div class="sectionbody">
+<div class="paragraph">
+<p>Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, a few rough rules are:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most importantly, we never say "It&#8217;s in POSIX; we&#8217;ll happily
+ignore your needs should your system not conform to it."
+We live in the real world.</p>
+</li>
+<li>
+<p>However, we often say "Let&#8217;s stay away from that construct,
+it&#8217;s not even in POSIX".</p>
+</li>
+<li>
+<p>In spite of the above two rules, we sometimes say "Although
+this is not in POSIX, it (is so convenient | makes the code
+much more readable | has other good characteristics) and
+practically all the platforms we care about support it, so
+let&#8217;s use it".</p>
+<div class="literalblock">
+<div class="content">
+<pre>Again, we live in the real world, and it is sometimes a
+judgement call, the decision based more on real world
+constraints people face than what the paper standard says.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Fixing style violations while working on a real change as a
+preparatory clean-up step is good, but otherwise avoid useless code
+churn for the sake of conforming to the style.</p>
+<div class="literalblock">
+<div class="content">
+<pre>"Once it _is_ in the tree, it's not really worth the patch noise to
+go and fix it up."
+Cf. https://lore.kernel.org/all/20100126160632.3bdbe172.akpm@linux-foundation.org/</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Log messages to explain your changes are as important as the
+changes themselves.  Clearly written code and in-code comments
+explain how the code works and what is assumed from the surrounding
+context.  The log messages explain what the changes wanted to
+achieve and why the changes were necessary (more on this in the
+accompanying SubmittingPatches document).</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Make your code readable and sensible, and don&#8217;t try to be clever.</p>
+</div>
+<div class="paragraph">
+<p>As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the <em>local</em>
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn&#8217;t match the overall style of existing code).</p>
+</div>
+<div class="paragraph">
+<p>But if you must have a list of rules, here are some language
+specific ones. Note that Documentation/ToolsForGit.txt document
+has a collection of tips to help you use some external tools
+to conform to these guidelines.</p>
+</div>
+<div class="paragraph">
+<p>For shell scripts specifically (not exhaustive):</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs for indentation.</p>
+</li>
+<li>
+<p>Case arms are indented at the same depth as case and esac lines,
+like this:</p>
+<div class="literalblock">
+<div class="content">
+<pre>case "$variable" in
+pattern1)
+	do this
+	;;
+pattern2)
+	do that
+	;;
+esac</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Redirection operators should be written with space before, but no
+space after them.  In other words, write <em>echo test &gt;"$file"</em>
+instead of <em>echo test&gt; $file</em> or <em>echo test &gt; $file</em>.  Note that
+even though it is not required by POSIX to double-quote the
+redirection target in a variable (as shown above), our code does so
+because some versions of bash issue a warning without the quotes.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+cat hello &gt; world &lt; universe
+echo hello &gt;$world</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+cat hello &gt;world &lt;universe
+echo hello &gt;"$world"</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer $( &#8230;&#8203; ) for command substitution; unlike ``, it
+properly nests.  It should have been the way Bourne spelled
+it from day one, but unfortunately isn&#8217;t.</p>
+</li>
+<li>
+<p>If you want to find out if a command is available on the user&#8217;s
+$PATH, you should use <em>type &lt;command&gt;</em>, instead of <em>which &lt;command&gt;</em>.
+The output of <em>which</em> is not machine parsable and its exit code
+is not reliable across platforms.</p>
+</li>
+<li>
+<p>We use POSIX compliant parameter substitutions and avoid bashisms;
+namely:</p>
+</li>
+<li>
+<p>We use ${parameter-word} and its [-=?+] siblings, and their
+colon&#8217;ed "unset or null" form.</p>
+</li>
+<li>
+<p>We use ${parameter#word} and its [#%] siblings, and their
+doubled "longest matching" form.</p>
+</li>
+<li>
+<p>No "Substring Expansion" ${parameter:offset:length}.</p>
+</li>
+<li>
+<p>No shell arrays.</p>
+</li>
+<li>
+<p>No pattern replacement ${parameter/pattern/string}.</p>
+</li>
+<li>
+<p>We use Arithmetic Expansion $&#8230;&#8203;.</p>
+</li>
+<li>
+<p>We do not use Process Substitution &lt;(list) or &gt;(list).</p>
+</li>
+<li>
+<p>Do not write control structures on a single line with semicolon.
+"then" should be on the next line for if statements, and "do"
+should be on the next line for "while" and "for".</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+if test -f hello; then
+	do this
+fi</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+if test -f hello
+then
+	do this
+fi</pre>
+</div>
+</div>
+</li>
+<li>
+<p>If a command sequence joined with &amp;&amp; or || or | spans multiple
+lines, put each command on a separate line and put &amp;&amp; and || and |
+operators at the end of each line, rather than the start. This
+means you don&#8217;t need to use \ to join lines, since the above
+operators imply the sequence isn&#8217;t finished.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+grep blob verify_pack_result \
+| awk -f print_1.awk \
+| sort &gt;actual &amp;&amp;
+...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+grep blob verify_pack_result |
+awk -f print_1.awk |
+sort &gt;actual &amp;&amp;
+...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer "test" over "[ &#8230;&#8203; ]".</p>
+</li>
+<li>
+<p>We do not write the noiseword "function" in front of shell
+functions.</p>
+</li>
+<li>
+<p>We prefer a space between the function name and the parentheses,
+and no space inside the parentheses. The opening "{" should also
+be on the same line.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+my_function(){
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+my_function () {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+[::], [==], or [..]) for portability.</p>
+</li>
+<li>
+<p>We do not use \{m,n\};</p>
+</li>
+<li>
+<p>We do not use ? or + (which are \{0,1\} and \{1,\}
+respectively in BRE) but that goes without saying as these
+are ERE elements not BRE (note that \? and \+ are not even part
+of BRE&#8201;&#8212;&#8201;making them accessible from BRE is a GNU extension).</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers in git-sh-i18n to make the user
+interface translatable. See "Marking strings for translation" in
+po/README.</p>
+</li>
+<li>
+<p>We do not write our "test" command with "-a" and "-o" and use "&amp;&amp;"
+or "||" to concatenate multiple "test" commands instead, because
+the use of "-a/-o" is often error-prone.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" -a "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is buggy and breaks when $x is "=", but</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" &amp;&amp; test "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>does not have such a problem.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Even though "local" is not part of POSIX, we make heavy use of it
+in our test suite.  We do not use it in scripted Porcelains, and
+hopefully nobody starts using "local" before they are reimplemented
+in C ;-)</p>
+</li>
+<li>
+<p>Use octal escape sequences (e.g. "\302\242"), not hexadecimal (e.g.
+"\xc2\xa2") in printf format strings, since hexadecimal escape
+sequences are not portable.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For C programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs to indent, and interpret tabs as taking up to
+8 spaces.</p>
+</li>
+<li>
+<p>We try to keep to at most 80 characters per line.</p>
+</li>
+<li>
+<p>As a Git developer we assume you have a reasonably modern compiler
+and we recommend you to enable the DEVELOPER makefile knob to
+ensure your patch is clear of all compiler warnings we care about,
+by e.g. "echo DEVELOPER=1 &gt;&gt;config.mak".</p>
+</li>
+<li>
+<p>We try to support a wide range of C compilers to compile Git with,
+including old ones.  As of Git v2.35.0 Git requires C99 (we check
+"<em>STDC_VERSION</em>"). You should not use features from a newer C
+standard, even if your compiler groks them.</p>
+<div class="literalblock">
+<div class="content">
+<pre>New C99 features have been phased in gradually, if something's new
+in C99 but not used yet don't assume that it's safe to use, some
+compilers we target have only partial support for it. These are
+considered safe to use:</pre>
+</div>
+</div>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>since around 2007 with 2b6854c863a, we have been using
+initializer elements which are not computable at load time. E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>const char *args[] = {"constant", variable, NULL};</pre>
+</div>
+</div>
+</li>
+<li>
+<p>since early 2012 with e1327023ea, we have been using an enum
+definition whose last element is followed by a comma.  This, like
+an array initializer that ends with a trailing comma, can be used
+to reduce the patch noise when adding a new identifier at the end.</p>
+</li>
+<li>
+<p>since mid 2017 with cbc0f81d, we have been using designated
+initializers for struct (e.g. "struct t v = { .val = <em>a</em> };").</p>
+</li>
+<li>
+<p>since mid 2017 with 512f41cf, we have been using designated
+initializers for array (e.g. "int array[10] = { [5] = 2 }").</p>
+</li>
+<li>
+<p>since early 2021 with 765dc168882, we have been using variadic
+macros, mostly for printf-like trace and debug macros.</p>
+</li>
+<li>
+<p>since late 2021 with 44ba10d6, we have had variables declared in
+the for loop "for (int i = 0; i &lt; 10; i++)".</p>
+<div class="literalblock">
+<div class="content">
+<pre>New C99 features that we cannot use yet:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>%z and %zu as a printf() argument for a size_t (the %z being for
+the POSIX-specific ssize_t). Instead you should use
+printf("%"PRIuMAX, (uintmax_t)v).  These days the MSVC version we
+rely on supports %z, but the C library used by MinGW does not.</p>
+</li>
+<li>
+<p>Shorthand like ".a.b = *c" in struct initializations is known to
+trip up an older IBM XLC version, use ".a = { .b = *c }" instead.
+See the 33665d98 (reftable: make assignments portable to AIX xlc
+v12.01, 2022-03-28).</p>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>Variables have to be declared at the beginning of the block, before
+the first statement (i.e. -Wdeclaration-after-statement).</p>
+</li>
+<li>
+<p>NULL pointers shall be written as NULL, not as 0.</p>
+</li>
+<li>
+<p>When declaring pointers, the star sides with the variable
+name, i.e. "char <strong>string", not "char</strong> string" or
+"char * string".  This makes it easier to understand code
+like "char *string, c;".</p>
+</li>
+<li>
+<p>Use whitespace around operators and keywords, but not inside
+parentheses and not around functions. So:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      while (condition)
+func(bar + 1);</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>      while( condition )
+func (bar+1);</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Do not explicitly compare an integral value with constant 0 or <em>\0</em>,
+or a pointer value with constant NULL.  For instance, to validate that
+counted array &lt;ptr, cnt&gt; is initialized but has no elements, write:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (!ptr || cnt)
+	BUG("empty array expected");</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (ptr == NULL || cnt != 0);
+	BUG("empty array expected");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We avoid using braces unnecessarily.  I.e.</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (bla) {
+	x = 1;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is frowned upon. But there are a few exceptions:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When the statement extends over a few lines (e.g., a while loop
+with an embedded conditional, or a comment). E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (foo) {
+	if (x)
+		one();
+	else
+		two();
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	/*
+	 * This one requires some explanation,
+	 * so we're better off with braces to make
+	 * it obvious that the indentation is correct.
+	 */
+	doit();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When there are multiple arms to a conditional and some of them
+require braces, enclose even a single line block in braces for
+consistency. E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	doit();
+} else {
+	one();
+	two();
+	three();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments in the condition of an "if" statement.</p>
+</li>
+<li>
+<p>Try to make your code understandable.  You may put comments
+in, but comments invariably tend to stale out when the code
+they were describing changes.  Often splitting a function
+into two makes the intention of the code much clearer.</p>
+</li>
+<li>
+<p>Multi-line comments include their delimiters on separate lines from
+the text.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * A very long
+ * multi-line comment.
+ */</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Note however that a comment that explains a translatable string to
+translators uses a convention of starting with a magic token
+"TRANSLATORS: ", e.g.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * TRANSLATORS: here is a comment that explains the string to
+ * be translated, that follows immediately after it.
+ */
+_("Here is a translatable string explained by the above.");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Double negation is often harder to understand than no negation
+at all.</p>
+</li>
+<li>
+<p>There are two schools of thought when it comes to comparison,
+especially inside a loop. Some people prefer to have the less stable
+value on the left hand side and the more stable value on the right hand
+side, e.g. if you have a loop that counts variable i down to the
+lower bound,</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (i &gt; lower_bound) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Other people prefer to have the textual order of values match the
+actual order of values in their comparison, so that they can
+mentally draw a number line from left to right and place these
+values in order, i.e.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while (lower_bound &lt; i) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  However, the more "stable" the
+stable side becomes, the more we tend to prefer the former
+(comparison with a constant, "i &gt; 0", is an extreme example).
+Just do not mix styles in the same part of the code and mimic
+existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>There are two schools of thought when it comes to splitting a long
+logical line into multiple lines.  Some people push the second and
+subsequent lines far enough to the right with tabs and align them:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+              ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to align the second and the subsequent
+lines with the column immediately inside the opening parenthesis,
+with tabs and spaces, following our "tabstop is always a multiple
+of 8" convention:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+           ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  Again, just do not mix styles in
+the same part of the code and mimic existing styles in the
+neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, some people change line before
+a binary operator, so that the result looks like a parse tree when
+you turn your head 90-degrees counterclockwise:</p>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to
+|| span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to leave the operator at the end of the
+line:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, but we tend to use the latter more, unless the
+expression gets fairly complex, in which case the former tends to
+be easier to read.  Again, just do not mix styles in the same part
+of the code and mimic existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, with everything else being
+equal, it is preferable to split after the operator at higher
+level in the parse tree.  That is, this is more preferable:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable * that_is_used_in +
+    a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>than</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable *
+    that_is_used_in + a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Some clever tricks, like using the !! operator with arithmetic
+constructs, can be extremely confusing to others.  Avoid them,
+unless there is a compelling reason to use them.</p>
+</li>
+<li>
+<p>Use the API.  No, really.  We have a strbuf (variable length
+string), several arrays with the ALLOC_GROW() macro, a
+string_list for sorted string lists, a hash map (mapping struct
+objects) named "struct decorate", amongst other things.</p>
+</li>
+<li>
+<p>When you come up with an API, document its functions and structures
+in the header file that exposes the API to its callers. Use what is
+in "strbuf.h" as a model for the appropriate tone and level of
+detail.</p>
+</li>
+<li>
+<p>The first #include in C files, except in platform specific compat/
+implementations and sha1dc/, must be either "git-compat-util.h" or
+one of the approved headers that includes it first for you.  (The
+approved headers currently include "builtin.h",
+"t/helper/test-tool.h", "xdiff/xinclude.h", or
+"reftable/system.h").  You do not have to include more than one of
+these.</p>
+</li>
+<li>
+<p>A C file must directly include the header files that declare the
+functions and the types it uses, except for the functions and types
+that are made available to it by including one of the header files
+it must include by the previous rule.</p>
+</li>
+<li>
+<p>If you are planning a new command, consider writing it in shell
+or perl first, so that changes in semantics can be easily
+changed and discussed.  Many Git commands started out like
+that, and a few are still scripts.</p>
+</li>
+<li>
+<p>Avoid introducing a new dependency into Git. This means you
+usually should stay away from scripting languages not already
+used in the Git core command set (unless your command is clearly
+separate from it, such as an importer to convert random-scm-X
+repositories to Git).</p>
+</li>
+<li>
+<p>When we pass &lt;string, length&gt; pair to functions, we should try to
+pass them in that order.</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers to make the user interface
+translatable. See "Marking strings for translation" in po/README.</p>
+</li>
+<li>
+<p>Variables and functions local to a given source file should be marked
+with "static". Variables that are visible to other source files
+must be declared with "extern" in header files. However, function
+declarations should not use "extern", as that is already the default.</p>
+</li>
+<li>
+<p>You can launch gdb around your program using the shorthand GIT_DEBUGGER.
+Run <code>GIT_DEBUGGER=1 ./bin-wrappers/git foo</code> to simply use gdb as is, or
+run <code>GIT_DEBUGGER="&lt;debugger&gt; &lt;debugger-args&gt;" ./bin-wrappers/git foo</code> to
+use your own debugger and arguments. Example: <code>GIT_DEBUGGER="ddd --gdb"
+./bin-wrappers/git log</code> (See <code>wrap-for-bin.sh</code>.)</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Perl programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most of the C guidelines above apply.</p>
+</li>
+<li>
+<p>We try to support Perl 5.8 and later ("use Perl 5.008").</p>
+</li>
+<li>
+<p>use strict and use warnings are strongly preferred.</p>
+</li>
+<li>
+<p>Don&#8217;t overuse statement modifiers unless using them makes the
+result easier to follow.</p>
+<div class="olist lowerroman">
+<ol class="lowerroman" type="i">
+<li>
+<p>do something &#8230;&#8203;
+do_this() unless (condition);</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>is more readable than:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>do something &#8230;&#8203;
+unless (condition) {
+	do_this();
+}</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>*only* when the condition is so rare that do_this() will be almost
+always called.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments inside "if ()" conditions.</p>
+</li>
+<li>
+<p>Learn and use Git.pm if you need that functionality.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Python scripts:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We follow PEP-8 (<a href="http://www.python.org/dev/peps/pep-0008/" class="bare">http://www.python.org/dev/peps/pep-0008/</a>).</p>
+</li>
+<li>
+<p>As a minimum, we aim to be compatible with Python 2.7.</p>
+</li>
+<li>
+<p>Where required libraries do not restrict us to Python 2, we try to
+also be compatible with Python 3.1 and later.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Program Output</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>We make a distinction between a Git command's primary output and
+output which is merely chatty feedback (for instance, status
+messages, running transcript, or progress display), as well as error
+messages. Roughly speaking, a Git command's primary output is that
+which one might want to capture to a file or send down a pipe; its
+chatty output should not interfere with these use-cases.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>As such, primary output should be sent to the standard output stream
+(stdout), and chatty output should be sent to the standard error
+stream (stderr). Examples of commands which produce primary output
+include `git log`, `git show`, and `git branch --list` which generate
+output on the stdout stream.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Not all Git commands have primary output; this is often true of
+commands whose main function is to perform an action. Some action
+commands are silent, whereas others are chatty. An example of a
+chatty action commands is `git clone` with its "Cloning into
+'&lt;path&gt;'..." and "Checking connectivity..." status messages which it
+sends to the stderr stream.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Error messages from Git commands should always be sent to the stderr
+stream.</pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Error Messages</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Do not end error messages with a full stop.</p>
+</li>
+<li>
+<p>Do not capitalize the first word, only because it is the first word
+in the message ("unable to open %s", not "Unable to open %s").  But
+"SHA-3 not supported" is fine, because the reason the first word is
+capitalized is not because it is at the beginning of the sentence,
+but because the word would be spelled in capital letters even when
+it appeared in the middle of the sentence.</p>
+</li>
+<li>
+<p>Say what the error is first ("cannot open %s", not "%s: cannot open")</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Externally Visible Names</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>For configuration variable names, follow the existing convention:</p>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>The section name indicates the affected subsystem.</p>
+</li>
+<li>
+<p>The subsection name, if any, indicates which of an unbounded set
+of things to set the value for.</p>
+</li>
+<li>
+<p>The variable name describes the effect of tweaking this knob.</p>
+<div class="literalblock">
+<div class="content">
+<pre>The section and variable names that consist of multiple words are
+formed by concatenating the words without punctuations (e.g. `-`),
+and are broken using bumpyCaps in documentation as a hint to the
+reader.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>When choosing the variable namespace, do not use variable name for
+specifying possibly unbounded set of things, most notably anything
+an end user can freely come up with (e.g. branch names).  Instead,
+use subsection names or variable values, like the existing variable
+branch.&lt;name&gt;.description does.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Writing Documentation:</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Most (if not all) of the documentation pages are written in the
+AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+processed into HTML and manpages (e.g. git.html and git.1 in the
+same directory).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>The documentation liberally mixes US and UK English (en_US/UK)
+norms for spelling and grammar, which is somewhat unfortunate.
+In an ideal world, it would have been better if it consistently
+used only one and not the other, and we would have picked en_US
+(if you wish to correct the English of some of the existing
+documentation, please see the documentation-related advice in the
+Documentation/SubmittingPatches file).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>In order to ensure the documentation is inclusive, avoid assuming
+that an unspecified example person is male or female, and think
+twice before using "he", "him", "she", or "her".  Here are some
+tips to avoid use of gendered pronouns:</pre>
+</div>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Prefer succinctness and matter-of-factly describing functionality
+in the abstract.  E.g.</p>
+<div class="dlist">
+<dl>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short"> <a class="anchor" href="#Documentation/CodingGuidelines---short"></a>--short </dt>
+<dd>
+<p>Emit output in the short-format.</p>
+<div class="literalblock">
+<div class="content">
+<pre>and avoid something like these overly verbose alternatives:</pre>
+</div>
+</div>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short-1"> <a class="anchor" href="#Documentation/CodingGuidelines---short-1"></a>--short </dt>
+<dd>
+<p>Use this to emit output in the short-format.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short-1-1"> <a class="anchor" href="#Documentation/CodingGuidelines---short-1-1"></a>--short </dt>
+<dd>
+<p>You can use this to get output in the short-format.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short-1-1-1"> <a class="anchor" href="#Documentation/CodingGuidelines---short-1-1-1"></a>--short </dt>
+<dd>
+<p>A user who prefers shorter output could&#8230;&#8203;.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short-1-1-1-1"> <a class="anchor" href="#Documentation/CodingGuidelines---short-1-1-1-1"></a>--short </dt>
+<dd>
+<p>Should a person and/or program want shorter output, he
+she/they/it can&#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>This practice often eliminates the need to involve human actors in
+your description, but it is a good practice regardless of the
+avoidance of gendered pronouns.</pre>
+</div>
+</div>
+</dd>
+</dl>
+</div>
+</li>
+<li>
+<p>When it becomes awkward to stick to this style, prefer "you" when
+addressing the hypothetical user, and possibly "we" when
+discussing how the program might react to the user.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>You can use this option instead of --xyz, but we might remove
+support for it in future versions.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while keeping in mind that you can probably be less verbose, e.g.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Use this instead of --xyz. This option might be removed in future
+versions.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>If you still need to refer to an example person that is
+third-person singular, you may resort to "singular they" to avoid
+"he/she/him/her", e.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>A contributor asks their upstream to pull from them.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Note that this sounds ungrammatical and unnatural to those who
+learned that "they" is only used for third-person plural, e.g.
+those who learn English as a second language in some parts of the
+world.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Every user-visible change should be reflected in the documentation.
+The same general rule as for code applies -- imitate the existing
+conventions.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying command usage strings and synopsis sections in the manual
+pages:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Placeholders are spelled in lowercase and enclosed in angle brackets:
+  &lt;file&gt;
+  --sort=&lt;key&gt;
+  --abbrev[=&lt;n&gt;]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If a placeholder has multiple words, they are separated by dashes:
+  &lt;new-branch-name&gt;
+  --template=&lt;template-directory&gt;</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Possibility of multiple occurrences is indicated by three dots:
+  &lt;file&gt;...
+  (One or more of &lt;file&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Optional parts are enclosed in square brackets:
+  [&lt;file&gt;...]
+  (Zero or more of &lt;file&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>--exec-path[=&lt;path&gt;]
+(Option with an optional argument.  Note that the "=" is inside the
+brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[&lt;patch&gt;...]
+(Zero or more of &lt;patch&gt;.  Note that the dots are inside, not
+outside the brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Multiple alternatives are indicated with vertical bars:
+  [-q | --quiet]
+  [--utf8 | --no-utf8]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Use spacing around "|" token(s), but not immediately after opening or
+before closing a [] or () pair:
+  Do: [-q | --quiet]
+  Don't: [-q|--quiet]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Don't use spacing around "|" tokens when they're used to separate the
+alternate arguments of an option:
+   Do: --track[=(direct|inherit)]
+   Don't: --track[=(direct | inherit)]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Parentheses are used for grouping:
+  [(&lt;rev&gt; | &lt;range&gt;)...]
+  (Any number of either &lt;rev&gt; or &lt;range&gt;.  Parens are needed to make
+  it clear that "..." pertains to both &lt;rev&gt; and &lt;range&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[(-p &lt;parent&gt;)...]
+(Any number of option -p, each with one &lt;parent&gt; argument.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>git remote set-head &lt;name&gt; (-a | -d | &lt;branch&gt;)
+(One and only one of "-a", "-d" or "&lt;branch&gt;" _must_ (no square
+brackets) be provided.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>And a somewhat more contrived example:
+  --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+  Here "=" is outside the brackets, because "--diff-filter=" is a
+  valid usage.  "*" has its own pair of brackets, because it can
+  (optionally) be specified only when one or more of the letters is
+  also provided.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A note on notation:
+ Use 'git' (all lowercase) when talking about commands i.e. something
+ the user would type into a shell and use 'Git' (uppercase first letter)
+ when talking about the version control system and its properties.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying paragraphs or option/command explanations that contain options
+or commands:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Literal examples (e.g. use of command-line options, command names,
+branch names, URLs, pathnames (files and directories), configuration and
+environment variables) must be typeset in monospace (i.e. wrapped with
+backticks):
+  `--pretty=oneline`
+  `git rev-list`
+  `remote.pushDefault`
+  `http://git.example.com`
+  `.git/config`
+  `GIT_DIR`
+  `HEAD`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>An environment variable must be prefixed with "$" only when referring to its
+value and not when referring to the variable itself, in this case there is
+nothing to add except the backticks:
+  `GIT_DIR` is specified
+  `$GIT_DIR/hooks/pre-receive`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Word phrases enclosed in `backtick characters` are rendered literally
+and will not be further expanded. The use of `backticks` to achieve the
+previous rule means that literal examples should not use AsciiDoc
+escapes.
+  Correct:
+     `--pretty=oneline`
+  Incorrect:
+     `\--pretty=oneline`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If some place in the documentation needs to typeset a command usage
+example with inline substitutions, it is fine to use +monospaced and
+inline substituted text+ instead of `monospaced literal text`, and with
+the former, the part that should not get substituted must be
+quoted/escaped.</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+</div>
+</div>
\ No newline at end of file
diff --git a/external/docs/content/docs/CodingGuidelines/2.43.0.html b/external/docs/content/docs/CodingGuidelines/2.43.0.html
new file mode 100644
index 0000000000..ad70ab8c38
--- /dev/null
+++ b/external/docs/content/docs/CodingGuidelines/2.43.0.html
@@ -0,0 +1,1195 @@
+---
+### DO NOT EDIT! Generated by script/update-docs.rb
+
+category: manual
+section: documentation
+subsection: manual
+title: Git - CodingGuidelines Documentation
+docname: CodingGuidelines
+version: 2.43.0
+aliases:
+- "/docs/CodingGuidelines/2.43.0/index.html"
+---
+<div id="preamble">
+<div class="sectionbody">
+<div class="paragraph">
+<p>Like other projects, we also have some guidelines for our code.  For
+Git in general, a few rough rules are:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most importantly, we never say "It&#8217;s in POSIX; we&#8217;ll happily
+ignore your needs should your system not conform to it."
+We live in the real world.</p>
+</li>
+<li>
+<p>However, we often say "Let&#8217;s stay away from that construct,
+it&#8217;s not even in POSIX".</p>
+</li>
+<li>
+<p>In spite of the above two rules, we sometimes say "Although
+this is not in POSIX, it (is so convenient | makes the code
+much more readable | has other good characteristics) and
+practically all the platforms we care about support it, so
+let&#8217;s use it".</p>
+<div class="literalblock">
+<div class="content">
+<pre>Again, we live in the real world, and it is sometimes a
+judgement call, the decision based more on real world
+constraints people face than what the paper standard says.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Fixing style violations while working on a real change as a
+preparatory clean-up step is good, but otherwise avoid useless code
+churn for the sake of conforming to the style.</p>
+<div class="literalblock">
+<div class="content">
+<pre>"Once it _is_ in the tree, it's not really worth the patch noise to
+go and fix it up."
+Cf. https://lore.kernel.org/all/20100126160632.3bdbe172.akpm@linux-foundation.org/</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Log messages to explain your changes are as important as the
+changes themselves.  Clearly written code and in-code comments
+explain how the code works and what is assumed from the surrounding
+context.  The log messages explain what the changes wanted to
+achieve and why the changes were necessary (more on this in the
+accompanying SubmittingPatches document).</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Make your code readable and sensible, and don&#8217;t try to be clever.</p>
+</div>
+<div class="paragraph">
+<p>As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the <em>local</em>
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code are expected to match the style the surrounding code already
+uses (even if it doesn&#8217;t match the overall style of existing code).</p>
+</div>
+<div class="paragraph">
+<p>But if you must have a list of rules, here are some language
+specific ones. Note that Documentation/ToolsForGit.txt document
+has a collection of tips to help you use some external tools
+to conform to these guidelines.</p>
+</div>
+<div class="paragraph">
+<p>For shell scripts specifically (not exhaustive):</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs for indentation.</p>
+</li>
+<li>
+<p>Case arms are indented at the same depth as case and esac lines,
+like this:</p>
+<div class="literalblock">
+<div class="content">
+<pre>case "$variable" in
+pattern1)
+	do this
+	;;
+pattern2)
+	do that
+	;;
+esac</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Redirection operators should be written with space before, but no
+space after them.  In other words, write <em>echo test &gt;"$file"</em>
+instead of <em>echo test&gt; $file</em> or <em>echo test &gt; $file</em>.  Note that
+even though it is not required by POSIX to double-quote the
+redirection target in a variable (as shown above), our code does so
+because some versions of bash issue a warning without the quotes.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+cat hello &gt; world &lt; universe
+echo hello &gt;$world</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+cat hello &gt;world &lt;universe
+echo hello &gt;"$world"</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer $( &#8230;&#8203; ) for command substitution; unlike ``, it
+properly nests.  It should have been the way Bourne spelled
+it from day one, but unfortunately isn&#8217;t.</p>
+</li>
+<li>
+<p>If you want to find out if a command is available on the user&#8217;s
+$PATH, you should use <em>type &lt;command&gt;</em>, instead of <em>which &lt;command&gt;</em>.
+The output of <em>which</em> is not machine parsable and its exit code
+is not reliable across platforms.</p>
+</li>
+<li>
+<p>We use POSIX compliant parameter substitutions and avoid bashisms;
+namely:</p>
+</li>
+<li>
+<p>We use ${parameter-word} and its [-=?+] siblings, and their
+colon&#8217;ed "unset or null" form.</p>
+</li>
+<li>
+<p>We use ${parameter#word} and its [#%] siblings, and their
+doubled "longest matching" form.</p>
+</li>
+<li>
+<p>No "Substring Expansion" ${parameter:offset:length}.</p>
+</li>
+<li>
+<p>No shell arrays.</p>
+</li>
+<li>
+<p>No pattern replacement ${parameter/pattern/string}.</p>
+</li>
+<li>
+<p>We use Arithmetic Expansion $&#8230;&#8203;.</p>
+</li>
+<li>
+<p>We do not use Process Substitution &lt;(list) or &gt;(list).</p>
+</li>
+<li>
+<p>Do not write control structures on a single line with semicolon.
+"then" should be on the next line for if statements, and "do"
+should be on the next line for "while" and "for".</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+if test -f hello; then
+	do this
+fi</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+if test -f hello
+then
+	do this
+fi</pre>
+</div>
+</div>
+</li>
+<li>
+<p>If a command sequence joined with &amp;&amp; or || or | spans multiple
+lines, put each command on a separate line and put &amp;&amp; and || and |
+operators at the end of each line, rather than the start. This
+means you don&#8217;t need to use \ to join lines, since the above
+operators imply the sequence isn&#8217;t finished.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+grep blob verify_pack_result \
+| awk -f print_1.awk \
+| sort &gt;actual &amp;&amp;
+...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+grep blob verify_pack_result |
+awk -f print_1.awk |
+sort &gt;actual &amp;&amp;
+...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer "test" over "[ &#8230;&#8203; ]".</p>
+</li>
+<li>
+<p>We do not write the noiseword "function" in front of shell
+functions.</p>
+</li>
+<li>
+<p>We prefer a space between the function name and the parentheses,
+and no space inside the parentheses. The opening "{" should also
+be on the same line.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+my_function(){
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+my_function () {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+[::], [==], or [..]) for portability.</p>
+</li>
+<li>
+<p>We do not use \{m,n\};</p>
+</li>
+<li>
+<p>We do not use ? or + (which are \{0,1\} and \{1,\}
+respectively in BRE) but that goes without saying as these
+are ERE elements not BRE (note that \? and \+ are not even part
+of BRE&#8201;&#8212;&#8201;making them accessible from BRE is a GNU extension).</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers in git-sh-i18n to make the user
+interface translatable. See "Marking strings for translation" in
+po/README.</p>
+</li>
+<li>
+<p>We do not write our "test" command with "-a" and "-o" and use "&amp;&amp;"
+or "||" to concatenate multiple "test" commands instead, because
+the use of "-a/-o" is often error-prone.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" -a "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is buggy and breaks when $x is "=", but</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" &amp;&amp; test "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>does not have such a problem.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Even though "local" is not part of POSIX, we make heavy use of it
+in our test suite.  We do not use it in scripted Porcelains, and
+hopefully nobody starts using "local" before they are reimplemented
+in C ;-)</p>
+</li>
+<li>
+<p>Use octal escape sequences (e.g. "\302\242"), not hexadecimal (e.g.
+"\xc2\xa2") in printf format strings, since hexadecimal escape
+sequences are not portable.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For C programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs to indent, and interpret tabs as taking up to
+8 spaces.</p>
+</li>
+<li>
+<p>We try to keep to at most 80 characters per line.</p>
+</li>
+<li>
+<p>As a Git developer we assume you have a reasonably modern compiler
+and we recommend you to enable the DEVELOPER makefile knob to
+ensure your patch is clear of all compiler warnings we care about,
+by e.g. "echo DEVELOPER=1 &gt;&gt;config.mak".</p>
+</li>
+<li>
+<p>We try to support a wide range of C compilers to compile Git with,
+including old ones.  As of Git v2.35.0 Git requires C99 (we check
+"<em>STDC_VERSION</em>"). You should not use features from a newer C
+standard, even if your compiler groks them.</p>
+<div class="literalblock">
+<div class="content">
+<pre>New C99 features have been phased in gradually, if something's new
+in C99 but not used yet don't assume that it's safe to use, some
+compilers we target have only partial support for it. These are
+considered safe to use:</pre>
+</div>
+</div>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>since around 2007 with 2b6854c863a, we have been using
+initializer elements which are not computable at load time. E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>const char *args[] = {"constant", variable, NULL};</pre>
+</div>
+</div>
+</li>
+<li>
+<p>since early 2012 with e1327023ea, we have been using an enum
+definition whose last element is followed by a comma.  This, like
+an array initializer that ends with a trailing comma, can be used
+to reduce the patch noise when adding a new identifier at the end.</p>
+</li>
+<li>
+<p>since mid 2017 with cbc0f81d, we have been using designated
+initializers for struct (e.g. "struct t v = { .val = <em>a</em> };").</p>
+</li>
+<li>
+<p>since mid 2017 with 512f41cf, we have been using designated
+initializers for array (e.g. "int array[10] = { [5] = 2 }").</p>
+</li>
+<li>
+<p>since early 2021 with 765dc168882, we have been using variadic
+macros, mostly for printf-like trace and debug macros.</p>
+</li>
+<li>
+<p>since late 2021 with 44ba10d6, we have had variables declared in
+the for loop "for (int i = 0; i &lt; 10; i++)".</p>
+<div class="literalblock">
+<div class="content">
+<pre>New C99 features that we cannot use yet:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>%z and %zu as a printf() argument for a size_t (the %z being for
+the POSIX-specific ssize_t). Instead you should use
+printf("%"PRIuMAX, (uintmax_t)v).  These days the MSVC version we
+rely on supports %z, but the C library used by MinGW does not.</p>
+</li>
+<li>
+<p>Shorthand like ".a.b = *c" in struct initializations is known to
+trip up an older IBM XLC version, use ".a = { .b = *c }" instead.
+See the 33665d98 (reftable: make assignments portable to AIX xlc
+v12.01, 2022-03-28).</p>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>Variables have to be declared at the beginning of the block, before
+the first statement (i.e. -Wdeclaration-after-statement).</p>
+</li>
+<li>
+<p>NULL pointers shall be written as NULL, not as 0.</p>
+</li>
+<li>
+<p>When declaring pointers, the star sides with the variable
+name, i.e. "char <strong>string", not "char</strong> string" or
+"char * string".  This makes it easier to understand code
+like "char *string, c;".</p>
+</li>
+<li>
+<p>Use whitespace around operators and keywords, but not inside
+parentheses and not around functions. So:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      while (condition)
+func(bar + 1);</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>      while( condition )
+func (bar+1);</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Do not explicitly compare an integral value with constant 0 or <em>\0</em>,
+or a pointer value with constant NULL.  For instance, to validate that
+counted array &lt;ptr, cnt&gt; is initialized but has no elements, write:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (!ptr || cnt)
+	BUG("empty array expected");</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (ptr == NULL || cnt != 0);
+	BUG("empty array expected");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We avoid using braces unnecessarily.  I.e.</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (bla) {
+	x = 1;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is frowned upon. But there are a few exceptions:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When the statement extends over a few lines (e.g., a while loop
+with an embedded conditional, or a comment). E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (foo) {
+	if (x)
+		one();
+	else
+		two();
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	/*
+	 * This one requires some explanation,
+	 * so we're better off with braces to make
+	 * it obvious that the indentation is correct.
+	 */
+	doit();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When there are multiple arms to a conditional and some of them
+require braces, enclose even a single line block in braces for
+consistency. E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	doit();
+} else {
+	one();
+	two();
+	three();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments in the condition of an "if" statement.</p>
+</li>
+<li>
+<p>Try to make your code understandable.  You may put comments
+in, but comments invariably tend to stale out when the code
+they were describing changes.  Often splitting a function
+into two makes the intention of the code much clearer.</p>
+</li>
+<li>
+<p>Multi-line comments include their delimiters on separate lines from
+the text.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * A very long
+ * multi-line comment.
+ */</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Note however that a comment that explains a translatable string to
+translators uses a convention of starting with a magic token
+"TRANSLATORS: ", e.g.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * TRANSLATORS: here is a comment that explains the string to
+ * be translated, that follows immediately after it.
+ */
+_("Here is a translatable string explained by the above.");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Double negation is often harder to understand than no negation
+at all.</p>
+</li>
+<li>
+<p>There are two schools of thought when it comes to comparison,
+especially inside a loop. Some people prefer to have the less stable
+value on the left hand side and the more stable value on the right hand
+side, e.g. if you have a loop that counts variable i down to the
+lower bound,</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (i &gt; lower_bound) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Other people prefer to have the textual order of values match the
+actual order of values in their comparison, so that they can
+mentally draw a number line from left to right and place these
+values in order, i.e.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while (lower_bound &lt; i) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  However, the more "stable" the
+stable side becomes, the more we tend to prefer the former
+(comparison with a constant, "i &gt; 0", is an extreme example).
+Just do not mix styles in the same part of the code and mimic
+existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>There are two schools of thought when it comes to splitting a long
+logical line into multiple lines.  Some people push the second and
+subsequent lines far enough to the right with tabs and align them:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+              ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to align the second and the subsequent
+lines with the column immediately inside the opening parenthesis,
+with tabs and spaces, following our "tabstop is always a multiple
+of 8" convention:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+           ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  Again, just do not mix styles in
+the same part of the code and mimic existing styles in the
+neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, some people change line before
+a binary operator, so that the result looks like a parse tree when
+you turn your head 90-degrees counterclockwise:</p>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to
+|| span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to leave the operator at the end of the
+line:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, but we tend to use the latter more, unless the
+expression gets fairly complex, in which case the former tends to
+be easier to read.  Again, just do not mix styles in the same part
+of the code and mimic existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, with everything else being
+equal, it is preferable to split after the operator at higher
+level in the parse tree.  That is, this is more preferable:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable * that_is_used_in +
+    a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>than</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable *
+    that_is_used_in + a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Some clever tricks, like using the !! operator with arithmetic
+constructs, can be extremely confusing to others.  Avoid them,
+unless there is a compelling reason to use them.</p>
+</li>
+<li>
+<p>Use the API.  No, really.  We have a strbuf (variable length
+string), several arrays with the ALLOC_GROW() macro, a
+string_list for sorted string lists, a hash map (mapping struct
+objects) named "struct decorate", amongst other things.</p>
+</li>
+<li>
+<p>When you come up with an API, document its functions and structures
+in the header file that exposes the API to its callers. Use what is
+in "strbuf.h" as a model for the appropriate tone and level of
+detail.</p>
+</li>
+<li>
+<p>The first #include in C files, except in platform specific compat/
+implementations and sha1dc/, must be either "git-compat-util.h" or
+one of the approved headers that includes it first for you.  (The
+approved headers currently include "builtin.h",
+"t/helper/test-tool.h", "xdiff/xinclude.h", or
+"reftable/system.h").  You do not have to include more than one of
+these.</p>
+</li>
+<li>
+<p>A C file must directly include the header files that declare the
+functions and the types it uses, except for the functions and types
+that are made available to it by including one of the header files
+it must include by the previous rule.</p>
+</li>
+<li>
+<p>If you are planning a new command, consider writing it in shell
+or perl first, so that changes in semantics can be easily
+changed and discussed.  Many Git commands started out like
+that, and a few are still scripts.</p>
+</li>
+<li>
+<p>Avoid introducing a new dependency into Git. This means you
+usually should stay away from scripting languages not already
+used in the Git core command set (unless your command is clearly
+separate from it, such as an importer to convert random-scm-X
+repositories to Git).</p>
+</li>
+<li>
+<p>When we pass &lt;string, length&gt; pair to functions, we should try to
+pass them in that order.</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers to make the user interface
+translatable. See "Marking strings for translation" in po/README.</p>
+</li>
+<li>
+<p>Variables and functions local to a given source file should be marked
+with "static". Variables that are visible to other source files
+must be declared with "extern" in header files. However, function
+declarations should not use "extern", as that is already the default.</p>
+</li>
+<li>
+<p>You can launch gdb around your program using the shorthand GIT_DEBUGGER.
+Run <code>GIT_DEBUGGER=1 ./bin-wrappers/git foo</code> to simply use gdb as is, or
+run <code>GIT_DEBUGGER="&lt;debugger&gt; &lt;debugger-args&gt;" ./bin-wrappers/git foo</code> to
+use your own debugger and arguments. Example: <code>GIT_DEBUGGER="ddd --gdb"
+./bin-wrappers/git log</code> (See <code>wrap-for-bin.sh</code>.)</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Perl programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most of the C guidelines above apply.</p>
+</li>
+<li>
+<p>We try to support Perl 5.8 and later ("use Perl 5.008").</p>
+</li>
+<li>
+<p>use strict and use warnings are strongly preferred.</p>
+</li>
+<li>
+<p>Don&#8217;t overuse statement modifiers unless using them makes the
+result easier to follow.</p>
+<div class="olist lowerroman">
+<ol class="lowerroman" type="i">
+<li>
+<p>do something &#8230;&#8203;
+do_this() unless (condition);</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>is more readable than:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>do something &#8230;&#8203;
+unless (condition) {
+	do_this();
+}</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>*only* when the condition is so rare that do_this() will be almost
+always called.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments inside "if ()" conditions.</p>
+</li>
+<li>
+<p>Learn and use Git.pm if you need that functionality.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Python scripts:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We follow PEP-8 (<a href="http://www.python.org/dev/peps/pep-0008/" class="bare">http://www.python.org/dev/peps/pep-0008/</a>).</p>
+</li>
+<li>
+<p>As a minimum, we aim to be compatible with Python 2.7.</p>
+</li>
+<li>
+<p>Where required libraries do not restrict us to Python 2, we try to
+also be compatible with Python 3.1 and later.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Program Output</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>We make a distinction between a Git command's primary output and
+output which is merely chatty feedback (for instance, status
+messages, running transcript, or progress display), as well as error
+messages. Roughly speaking, a Git command's primary output is that
+which one might want to capture to a file or send down a pipe; its
+chatty output should not interfere with these use-cases.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>As such, primary output should be sent to the standard output stream
+(stdout), and chatty output should be sent to the standard error
+stream (stderr). Examples of commands which produce primary output
+include `git log`, `git show`, and `git branch --list` which generate
+output on the stdout stream.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Not all Git commands have primary output; this is often true of
+commands whose main function is to perform an action. Some action
+commands are silent, whereas others are chatty. An example of a
+chatty action commands is `git clone` with its "Cloning into
+'&lt;path&gt;'..." and "Checking connectivity..." status messages which it
+sends to the stderr stream.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Error messages from Git commands should always be sent to the stderr
+stream.</pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Error Messages</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Do not end error messages with a full stop.</p>
+</li>
+<li>
+<p>Do not capitalize the first word, only because it is the first word
+in the message ("unable to open %s", not "Unable to open %s").  But
+"SHA-3 not supported" is fine, because the reason the first word is
+capitalized is not because it is at the beginning of the sentence,
+but because the word would be spelled in capital letters even when
+it appeared in the middle of the sentence.</p>
+</li>
+<li>
+<p>Say what the error is first ("cannot open %s", not "%s: cannot open")</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Externally Visible Names</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>For configuration variable names, follow the existing convention:</p>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>The section name indicates the affected subsystem.</p>
+</li>
+<li>
+<p>The subsection name, if any, indicates which of an unbounded set
+of things to set the value for.</p>
+</li>
+<li>
+<p>The variable name describes the effect of tweaking this knob.</p>
+<div class="literalblock">
+<div class="content">
+<pre>The section and variable names that consist of multiple words are
+formed by concatenating the words without punctuations (e.g. `-`),
+and are broken using bumpyCaps in documentation as a hint to the
+reader.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>When choosing the variable namespace, do not use variable name for
+specifying possibly unbounded set of things, most notably anything
+an end user can freely come up with (e.g. branch names).  Instead,
+use subsection names or variable values, like the existing variable
+branch.&lt;name&gt;.description does.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Writing Documentation:</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Most (if not all) of the documentation pages are written in the
+AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+processed into HTML and manpages (e.g. git.html and git.1 in the
+same directory).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>The documentation liberally mixes US and UK English (en_US/UK)
+norms for spelling and grammar, which is somewhat unfortunate.
+In an ideal world, it would have been better if it consistently
+used only one and not the other, and we would have picked en_US
+(if you wish to correct the English of some of the existing
+documentation, please see the documentation-related advice in the
+Documentation/SubmittingPatches file).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>In order to ensure the documentation is inclusive, avoid assuming
+that an unspecified example person is male or female, and think
+twice before using "he", "him", "she", or "her".  Here are some
+tips to avoid use of gendered pronouns:</pre>
+</div>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Prefer succinctness and matter-of-factly describing functionality
+in the abstract.  E.g.</p>
+<div class="dlist">
+<dl>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short"> <a class="anchor" href="#Documentation/CodingGuidelines---short"></a>--short </dt>
+<dd>
+<p>Emit output in the short-format.</p>
+<div class="literalblock">
+<div class="content">
+<pre>and avoid something like these overly verbose alternatives:</pre>
+</div>
+</div>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short-1"> <a class="anchor" href="#Documentation/CodingGuidelines---short-1"></a>--short </dt>
+<dd>
+<p>Use this to emit output in the short-format.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short-1-1"> <a class="anchor" href="#Documentation/CodingGuidelines---short-1-1"></a>--short </dt>
+<dd>
+<p>You can use this to get output in the short-format.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short-1-1-1"> <a class="anchor" href="#Documentation/CodingGuidelines---short-1-1-1"></a>--short </dt>
+<dd>
+<p>A user who prefers shorter output could&#8230;&#8203;.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short-1-1-1-1"> <a class="anchor" href="#Documentation/CodingGuidelines---short-1-1-1-1"></a>--short </dt>
+<dd>
+<p>Should a person and/or program want shorter output, he
+she/they/it can&#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>This practice often eliminates the need to involve human actors in
+your description, but it is a good practice regardless of the
+avoidance of gendered pronouns.</pre>
+</div>
+</div>
+</dd>
+</dl>
+</div>
+</li>
+<li>
+<p>When it becomes awkward to stick to this style, prefer "you" when
+addressing the hypothetical user, and possibly "we" when
+discussing how the program might react to the user.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>You can use this option instead of --xyz, but we might remove
+support for it in future versions.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while keeping in mind that you can probably be less verbose, e.g.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Use this instead of --xyz. This option might be removed in future
+versions.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>If you still need to refer to an example person that is
+third-person singular, you may resort to "singular they" to avoid
+"he/she/him/her", e.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>A contributor asks their upstream to pull from them.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Note that this sounds ungrammatical and unnatural to those who
+learned that "they" is only used for third-person plural, e.g.
+those who learn English as a second language in some parts of the
+world.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Every user-visible change should be reflected in the documentation.
+The same general rule as for code applies -- imitate the existing
+conventions.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying command usage strings and synopsis sections in the manual
+pages:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Placeholders are spelled in lowercase and enclosed in angle brackets:
+  &lt;file&gt;
+  --sort=&lt;key&gt;
+  --abbrev[=&lt;n&gt;]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If a placeholder has multiple words, they are separated by dashes:
+  &lt;new-branch-name&gt;
+  --template=&lt;template-directory&gt;</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Possibility of multiple occurrences is indicated by three dots:
+  &lt;file&gt;...
+  (One or more of &lt;file&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Optional parts are enclosed in square brackets:
+  [&lt;file&gt;...]
+  (Zero or more of &lt;file&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>--exec-path[=&lt;path&gt;]
+(Option with an optional argument.  Note that the "=" is inside the
+brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[&lt;patch&gt;...]
+(Zero or more of &lt;patch&gt;.  Note that the dots are inside, not
+outside the brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Multiple alternatives are indicated with vertical bars:
+  [-q | --quiet]
+  [--utf8 | --no-utf8]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Use spacing around "|" token(s), but not immediately after opening or
+before closing a [] or () pair:
+  Do: [-q | --quiet]
+  Don't: [-q|--quiet]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Don't use spacing around "|" tokens when they're used to separate the
+alternate arguments of an option:
+   Do: --track[=(direct|inherit)]
+   Don't: --track[=(direct | inherit)]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Parentheses are used for grouping:
+  [(&lt;rev&gt; | &lt;range&gt;)...]
+  (Any number of either &lt;rev&gt; or &lt;range&gt;.  Parens are needed to make
+  it clear that "..." pertains to both &lt;rev&gt; and &lt;range&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[(-p &lt;parent&gt;)...]
+(Any number of option -p, each with one &lt;parent&gt; argument.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>git remote set-head &lt;name&gt; (-a | -d | &lt;branch&gt;)
+(One and only one of "-a", "-d" or "&lt;branch&gt;" _must_ (no square
+brackets) be provided.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>And a somewhat more contrived example:
+  --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+  Here "=" is outside the brackets, because "--diff-filter=" is a
+  valid usage.  "*" has its own pair of brackets, because it can
+  (optionally) be specified only when one or more of the letters is
+  also provided.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A note on notation:
+ Use 'git' (all lowercase) when talking about commands i.e. something
+ the user would type into a shell and use 'Git' (uppercase first letter)
+ when talking about the version control system and its properties.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying paragraphs or option/command explanations that contain options
+or commands:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Literal examples (e.g. use of command-line options, command names,
+branch names, URLs, pathnames (files and directories), configuration and
+environment variables) must be typeset in monospace (i.e. wrapped with
+backticks):
+  `--pretty=oneline`
+  `git rev-list`
+  `remote.pushDefault`
+  `http://git.example.com`
+  `.git/config`
+  `GIT_DIR`
+  `HEAD`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>An environment variable must be prefixed with "$" only when referring to its
+value and not when referring to the variable itself, in this case there is
+nothing to add except the backticks:
+  `GIT_DIR` is specified
+  `$GIT_DIR/hooks/pre-receive`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Word phrases enclosed in `backtick characters` are rendered literally
+and will not be further expanded. The use of `backticks` to achieve the
+previous rule means that literal examples should not use AsciiDoc
+escapes.
+  Correct:
+     `--pretty=oneline`
+  Incorrect:
+     `\--pretty=oneline`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If some place in the documentation needs to typeset a command usage
+example with inline substitutions, it is fine to use +monospaced and
+inline substituted text+ instead of `monospaced literal text`, and with
+the former, the part that should not get substituted must be
+quoted/escaped.</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+</div>
+</div>
\ No newline at end of file
diff --git a/external/docs/content/docs/CodingGuidelines/2.43.1.html b/external/docs/content/docs/CodingGuidelines/2.43.1.html
new file mode 100644
index 0000000000..a2f67ef9dd
--- /dev/null
+++ b/external/docs/content/docs/CodingGuidelines/2.43.1.html
@@ -0,0 +1,1204 @@
+---
+### DO NOT EDIT! Generated by script/update-docs.rb
+
+category: manual
+section: documentation
+subsection: manual
+title: Git - CodingGuidelines Documentation
+docname: CodingGuidelines
+version: 2.43.1
+aliases:
+- "/docs/CodingGuidelines/2.43.1/index.html"
+- "/docs/CodingGuidelines/2.43.2/index.html"
+- "/docs/CodingGuidelines/2.43.3/index.html"
+- "/docs/CodingGuidelines/2.43.4/index.html"
+- "/docs/CodingGuidelines/2.43.5/index.html"
+- "/docs/CodingGuidelines/2.43.6/index.html"
+- "/docs/CodingGuidelines/2.44.0/index.html"
+- "/docs/CodingGuidelines/2.44.1/index.html"
+- "/docs/CodingGuidelines/2.44.2/index.html"
+- "/docs/CodingGuidelines/2.44.3/index.html"
+---
+<div id="preamble">
+<div class="sectionbody">
+<div class="paragraph">
+<p>Like other projects, we also have some guidelines for our code.  For
+Git in general, a few rough rules are:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most importantly, we never say "It&#8217;s in POSIX; we&#8217;ll happily
+ignore your needs should your system not conform to it."
+We live in the real world.</p>
+</li>
+<li>
+<p>However, we often say "Let&#8217;s stay away from that construct,
+it&#8217;s not even in POSIX".</p>
+</li>
+<li>
+<p>In spite of the above two rules, we sometimes say "Although
+this is not in POSIX, it (is so convenient | makes the code
+much more readable | has other good characteristics) and
+practically all the platforms we care about support it, so
+let&#8217;s use it".</p>
+<div class="literalblock">
+<div class="content">
+<pre>Again, we live in the real world, and it is sometimes a
+judgement call, the decision based more on real world
+constraints people face than what the paper standard says.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Fixing style violations while working on a real change as a
+preparatory clean-up step is good, but otherwise avoid useless code
+churn for the sake of conforming to the style.</p>
+<div class="literalblock">
+<div class="content">
+<pre>"Once it _is_ in the tree, it's not really worth the patch noise to
+go and fix it up."
+Cf. https://lore.kernel.org/all/20100126160632.3bdbe172.akpm@linux-foundation.org/</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Log messages to explain your changes are as important as the
+changes themselves.  Clearly written code and in-code comments
+explain how the code works and what is assumed from the surrounding
+context.  The log messages explain what the changes wanted to
+achieve and why the changes were necessary (more on this in the
+accompanying SubmittingPatches document).</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Make your code readable and sensible, and don&#8217;t try to be clever.</p>
+</div>
+<div class="paragraph">
+<p>As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the <em>local</em>
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code are expected to match the style the surrounding code already
+uses (even if it doesn&#8217;t match the overall style of existing code).</p>
+</div>
+<div class="paragraph">
+<p>But if you must have a list of rules, here are some language
+specific ones. Note that Documentation/ToolsForGit.txt document
+has a collection of tips to help you use some external tools
+to conform to these guidelines.</p>
+</div>
+<div class="paragraph">
+<p>For shell scripts specifically (not exhaustive):</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs for indentation.</p>
+</li>
+<li>
+<p>Case arms are indented at the same depth as case and esac lines,
+like this:</p>
+<div class="literalblock">
+<div class="content">
+<pre>case "$variable" in
+pattern1)
+	do this
+	;;
+pattern2)
+	do that
+	;;
+esac</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Redirection operators should be written with space before, but no
+space after them.  In other words, write <em>echo test &gt;"$file"</em>
+instead of <em>echo test&gt; $file</em> or <em>echo test &gt; $file</em>.  Note that
+even though it is not required by POSIX to double-quote the
+redirection target in a variable (as shown above), our code does so
+because some versions of bash issue a warning without the quotes.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+cat hello &gt; world &lt; universe
+echo hello &gt;$world</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+cat hello &gt;world &lt;universe
+echo hello &gt;"$world"</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer $( &#8230;&#8203; ) for command substitution; unlike ``, it
+properly nests.  It should have been the way Bourne spelled
+it from day one, but unfortunately isn&#8217;t.</p>
+</li>
+<li>
+<p>If you want to find out if a command is available on the user&#8217;s
+$PATH, you should use <em>type &lt;command&gt;</em>, instead of <em>which &lt;command&gt;</em>.
+The output of <em>which</em> is not machine parsable and its exit code
+is not reliable across platforms.</p>
+</li>
+<li>
+<p>We use POSIX compliant parameter substitutions and avoid bashisms;
+namely:</p>
+</li>
+<li>
+<p>We use ${parameter-word} and its [-=?+] siblings, and their
+colon&#8217;ed "unset or null" form.</p>
+</li>
+<li>
+<p>We use ${parameter#word} and its [#%] siblings, and their
+doubled "longest matching" form.</p>
+</li>
+<li>
+<p>No "Substring Expansion" ${parameter:offset:length}.</p>
+</li>
+<li>
+<p>No shell arrays.</p>
+</li>
+<li>
+<p>No pattern replacement ${parameter/pattern/string}.</p>
+</li>
+<li>
+<p>We use Arithmetic Expansion $&#8230;&#8203;.</p>
+</li>
+<li>
+<p>We do not use Process Substitution &lt;(list) or &gt;(list).</p>
+</li>
+<li>
+<p>Do not write control structures on a single line with semicolon.
+"then" should be on the next line for if statements, and "do"
+should be on the next line for "while" and "for".</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+if test -f hello; then
+	do this
+fi</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+if test -f hello
+then
+	do this
+fi</pre>
+</div>
+</div>
+</li>
+<li>
+<p>If a command sequence joined with &amp;&amp; or || or | spans multiple
+lines, put each command on a separate line and put &amp;&amp; and || and |
+operators at the end of each line, rather than the start. This
+means you don&#8217;t need to use \ to join lines, since the above
+operators imply the sequence isn&#8217;t finished.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+grep blob verify_pack_result \
+| awk -f print_1.awk \
+| sort &gt;actual &amp;&amp;
+...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+grep blob verify_pack_result |
+awk -f print_1.awk |
+sort &gt;actual &amp;&amp;
+...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer "test" over "[ &#8230;&#8203; ]".</p>
+</li>
+<li>
+<p>We do not write the noiseword "function" in front of shell
+functions.</p>
+</li>
+<li>
+<p>We prefer a space between the function name and the parentheses,
+and no space inside the parentheses. The opening "{" should also
+be on the same line.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+my_function(){
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+my_function () {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+[::], [==], or [..]) for portability.</p>
+</li>
+<li>
+<p>We do not use \{m,n\};</p>
+</li>
+<li>
+<p>We do not use ? or + (which are \{0,1\} and \{1,\}
+respectively in BRE) but that goes without saying as these
+are ERE elements not BRE (note that \? and \+ are not even part
+of BRE&#8201;&#8212;&#8201;making them accessible from BRE is a GNU extension).</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers in git-sh-i18n to make the user
+interface translatable. See "Marking strings for translation" in
+po/README.</p>
+</li>
+<li>
+<p>We do not write our "test" command with "-a" and "-o" and use "&amp;&amp;"
+or "||" to concatenate multiple "test" commands instead, because
+the use of "-a/-o" is often error-prone.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" -a "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is buggy and breaks when $x is "=", but</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" &amp;&amp; test "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>does not have such a problem.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Even though "local" is not part of POSIX, we make heavy use of it
+in our test suite.  We do not use it in scripted Porcelains, and
+hopefully nobody starts using "local" before they are reimplemented
+in C ;-)</p>
+</li>
+<li>
+<p>Use octal escape sequences (e.g. "\302\242"), not hexadecimal (e.g.
+"\xc2\xa2") in printf format strings, since hexadecimal escape
+sequences are not portable.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For C programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs to indent, and interpret tabs as taking up to
+8 spaces.</p>
+</li>
+<li>
+<p>We try to keep to at most 80 characters per line.</p>
+</li>
+<li>
+<p>As a Git developer we assume you have a reasonably modern compiler
+and we recommend you to enable the DEVELOPER makefile knob to
+ensure your patch is clear of all compiler warnings we care about,
+by e.g. "echo DEVELOPER=1 &gt;&gt;config.mak".</p>
+</li>
+<li>
+<p>We try to support a wide range of C compilers to compile Git with,
+including old ones.  As of Git v2.35.0 Git requires C99 (we check
+"<em>STDC_VERSION</em>"). You should not use features from a newer C
+standard, even if your compiler groks them.</p>
+<div class="literalblock">
+<div class="content">
+<pre>New C99 features have been phased in gradually, if something's new
+in C99 but not used yet don't assume that it's safe to use, some
+compilers we target have only partial support for it. These are
+considered safe to use:</pre>
+</div>
+</div>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>since around 2007 with 2b6854c863a, we have been using
+initializer elements which are not computable at load time. E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>const char *args[] = {"constant", variable, NULL};</pre>
+</div>
+</div>
+</li>
+<li>
+<p>since early 2012 with e1327023ea, we have been using an enum
+definition whose last element is followed by a comma.  This, like
+an array initializer that ends with a trailing comma, can be used
+to reduce the patch noise when adding a new identifier at the end.</p>
+</li>
+<li>
+<p>since mid 2017 with cbc0f81d, we have been using designated
+initializers for struct (e.g. "struct t v = { .val = <em>a</em> };").</p>
+</li>
+<li>
+<p>since mid 2017 with 512f41cf, we have been using designated
+initializers for array (e.g. "int array[10] = { [5] = 2 }").</p>
+</li>
+<li>
+<p>since early 2021 with 765dc168882, we have been using variadic
+macros, mostly for printf-like trace and debug macros.</p>
+</li>
+<li>
+<p>since late 2021 with 44ba10d6, we have had variables declared in
+the for loop "for (int i = 0; i &lt; 10; i++)".</p>
+<div class="literalblock">
+<div class="content">
+<pre>New C99 features that we cannot use yet:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>%z and %zu as a printf() argument for a size_t (the %z being for
+the POSIX-specific ssize_t). Instead you should use
+printf("%"PRIuMAX, (uintmax_t)v).  These days the MSVC version we
+rely on supports %z, but the C library used by MinGW does not.</p>
+</li>
+<li>
+<p>Shorthand like ".a.b = *c" in struct initializations is known to
+trip up an older IBM XLC version, use ".a = { .b = *c }" instead.
+See the 33665d98 (reftable: make assignments portable to AIX xlc
+v12.01, 2022-03-28).</p>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>Variables have to be declared at the beginning of the block, before
+the first statement (i.e. -Wdeclaration-after-statement).</p>
+</li>
+<li>
+<p>NULL pointers shall be written as NULL, not as 0.</p>
+</li>
+<li>
+<p>When declaring pointers, the star sides with the variable
+name, i.e. "char <strong>string", not "char</strong> string" or
+"char * string".  This makes it easier to understand code
+like "char *string, c;".</p>
+</li>
+<li>
+<p>Use whitespace around operators and keywords, but not inside
+parentheses and not around functions. So:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      while (condition)
+func(bar + 1);</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>      while( condition )
+func (bar+1);</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Do not explicitly compare an integral value with constant 0 or <em>\0</em>,
+or a pointer value with constant NULL.  For instance, to validate that
+counted array &lt;ptr, cnt&gt; is initialized but has no elements, write:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (!ptr || cnt)
+	BUG("empty array expected");</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (ptr == NULL || cnt != 0);
+	BUG("empty array expected");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We avoid using braces unnecessarily.  I.e.</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (bla) {
+	x = 1;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is frowned upon. But there are a few exceptions:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When the statement extends over a few lines (e.g., a while loop
+with an embedded conditional, or a comment). E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (foo) {
+	if (x)
+		one();
+	else
+		two();
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	/*
+	 * This one requires some explanation,
+	 * so we're better off with braces to make
+	 * it obvious that the indentation is correct.
+	 */
+	doit();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When there are multiple arms to a conditional and some of them
+require braces, enclose even a single line block in braces for
+consistency. E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	doit();
+} else {
+	one();
+	two();
+	three();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments in the condition of an "if" statement.</p>
+</li>
+<li>
+<p>Try to make your code understandable.  You may put comments
+in, but comments invariably tend to stale out when the code
+they were describing changes.  Often splitting a function
+into two makes the intention of the code much clearer.</p>
+</li>
+<li>
+<p>Multi-line comments include their delimiters on separate lines from
+the text.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * A very long
+ * multi-line comment.
+ */</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Note however that a comment that explains a translatable string to
+translators uses a convention of starting with a magic token
+"TRANSLATORS: ", e.g.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * TRANSLATORS: here is a comment that explains the string to
+ * be translated, that follows immediately after it.
+ */
+_("Here is a translatable string explained by the above.");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Double negation is often harder to understand than no negation
+at all.</p>
+</li>
+<li>
+<p>There are two schools of thought when it comes to comparison,
+especially inside a loop. Some people prefer to have the less stable
+value on the left hand side and the more stable value on the right hand
+side, e.g. if you have a loop that counts variable i down to the
+lower bound,</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (i &gt; lower_bound) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Other people prefer to have the textual order of values match the
+actual order of values in their comparison, so that they can
+mentally draw a number line from left to right and place these
+values in order, i.e.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while (lower_bound &lt; i) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  However, the more "stable" the
+stable side becomes, the more we tend to prefer the former
+(comparison with a constant, "i &gt; 0", is an extreme example).
+Just do not mix styles in the same part of the code and mimic
+existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>There are two schools of thought when it comes to splitting a long
+logical line into multiple lines.  Some people push the second and
+subsequent lines far enough to the right with tabs and align them:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+              ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to align the second and the subsequent
+lines with the column immediately inside the opening parenthesis,
+with tabs and spaces, following our "tabstop is always a multiple
+of 8" convention:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+           ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  Again, just do not mix styles in
+the same part of the code and mimic existing styles in the
+neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, some people change line before
+a binary operator, so that the result looks like a parse tree when
+you turn your head 90-degrees counterclockwise:</p>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to
+|| span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to leave the operator at the end of the
+line:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, but we tend to use the latter more, unless the
+expression gets fairly complex, in which case the former tends to
+be easier to read.  Again, just do not mix styles in the same part
+of the code and mimic existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, with everything else being
+equal, it is preferable to split after the operator at higher
+level in the parse tree.  That is, this is more preferable:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable * that_is_used_in +
+    a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>than</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable *
+    that_is_used_in + a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Some clever tricks, like using the !! operator with arithmetic
+constructs, can be extremely confusing to others.  Avoid them,
+unless there is a compelling reason to use them.</p>
+</li>
+<li>
+<p>Use the API.  No, really.  We have a strbuf (variable length
+string), several arrays with the ALLOC_GROW() macro, a
+string_list for sorted string lists, a hash map (mapping struct
+objects) named "struct decorate", amongst other things.</p>
+</li>
+<li>
+<p>When you come up with an API, document its functions and structures
+in the header file that exposes the API to its callers. Use what is
+in "strbuf.h" as a model for the appropriate tone and level of
+detail.</p>
+</li>
+<li>
+<p>The first #include in C files, except in platform specific compat/
+implementations and sha1dc/, must be either "git-compat-util.h" or
+one of the approved headers that includes it first for you.  (The
+approved headers currently include "builtin.h",
+"t/helper/test-tool.h", "xdiff/xinclude.h", or
+"reftable/system.h".)  You do not have to include more than one of
+these.</p>
+</li>
+<li>
+<p>A C file must directly include the header files that declare the
+functions and the types it uses, except for the functions and types
+that are made available to it by including one of the header files
+it must include by the previous rule.</p>
+</li>
+<li>
+<p>If you are planning a new command, consider writing it in shell
+or perl first, so that changes in semantics can be easily
+changed and discussed.  Many Git commands started out like
+that, and a few are still scripts.</p>
+</li>
+<li>
+<p>Avoid introducing a new dependency into Git. This means you
+usually should stay away from scripting languages not already
+used in the Git core command set (unless your command is clearly
+separate from it, such as an importer to convert random-scm-X
+repositories to Git).</p>
+</li>
+<li>
+<p>When we pass &lt;string, length&gt; pair to functions, we should try to
+pass them in that order.</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers to make the user interface
+translatable. See "Marking strings for translation" in po/README.</p>
+</li>
+<li>
+<p>Variables and functions local to a given source file should be marked
+with "static". Variables that are visible to other source files
+must be declared with "extern" in header files. However, function
+declarations should not use "extern", as that is already the default.</p>
+</li>
+<li>
+<p>You can launch gdb around your program using the shorthand GIT_DEBUGGER.
+Run <code>GIT_DEBUGGER=1 ./bin-wrappers/git foo</code> to simply use gdb as is, or
+run <code>GIT_DEBUGGER="&lt;debugger&gt; &lt;debugger-args&gt;" ./bin-wrappers/git foo</code> to
+use your own debugger and arguments. Example: <code>GIT_DEBUGGER="ddd --gdb"
+./bin-wrappers/git log</code> (See <code>wrap-for-bin.sh</code>.)</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Perl programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most of the C guidelines above apply.</p>
+</li>
+<li>
+<p>We try to support Perl 5.8.1 and later ("use Perl 5.008001").</p>
+</li>
+<li>
+<p>use strict and use warnings are strongly preferred.</p>
+</li>
+<li>
+<p>Don&#8217;t overuse statement modifiers unless using them makes the
+result easier to follow.</p>
+<div class="olist lowerroman">
+<ol class="lowerroman" type="i">
+<li>
+<p>do something &#8230;&#8203;
+do_this() unless (condition);</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>is more readable than:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>do something &#8230;&#8203;
+unless (condition) {
+	do_this();
+}</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>*only* when the condition is so rare that do_this() will be almost
+always called.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments inside "if ()" conditions.</p>
+</li>
+<li>
+<p>Learn and use Git.pm if you need that functionality.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Python scripts:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We follow PEP-8 (<a href="https://peps.python.org/pep-0008/" class="bare">https://peps.python.org/pep-0008/</a>).</p>
+</li>
+<li>
+<p>As a minimum, we aim to be compatible with Python 2.7.</p>
+</li>
+<li>
+<p>Where required libraries do not restrict us to Python 2, we try to
+also be compatible with Python 3.1 and later.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Program Output</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>We make a distinction between a Git command's primary output and
+output which is merely chatty feedback (for instance, status
+messages, running transcript, or progress display), as well as error
+messages. Roughly speaking, a Git command's primary output is that
+which one might want to capture to a file or send down a pipe; its
+chatty output should not interfere with these use-cases.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>As such, primary output should be sent to the standard output stream
+(stdout), and chatty output should be sent to the standard error
+stream (stderr). Examples of commands which produce primary output
+include `git log`, `git show`, and `git branch --list` which generate
+output on the stdout stream.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Not all Git commands have primary output; this is often true of
+commands whose main function is to perform an action. Some action
+commands are silent, whereas others are chatty. An example of a
+chatty action commands is `git clone` with its "Cloning into
+'&lt;path&gt;'..." and "Checking connectivity..." status messages which it
+sends to the stderr stream.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Error messages from Git commands should always be sent to the stderr
+stream.</pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Error Messages</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Do not end error messages with a full stop.</p>
+</li>
+<li>
+<p>Do not capitalize the first word, only because it is the first word
+in the message ("unable to open %s", not "Unable to open %s").  But
+"SHA-3 not supported" is fine, because the reason the first word is
+capitalized is not because it is at the beginning of the sentence,
+but because the word would be spelled in capital letters even when
+it appeared in the middle of the sentence.</p>
+</li>
+<li>
+<p>Say what the error is first ("cannot open %s", not "%s: cannot open")</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Externally Visible Names</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>For configuration variable names, follow the existing convention:</p>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>The section name indicates the affected subsystem.</p>
+</li>
+<li>
+<p>The subsection name, if any, indicates which of an unbounded set
+of things to set the value for.</p>
+</li>
+<li>
+<p>The variable name describes the effect of tweaking this knob.</p>
+<div class="literalblock">
+<div class="content">
+<pre>The section and variable names that consist of multiple words are
+formed by concatenating the words without punctuation marks (e.g. `-`),
+and are broken using bumpyCaps in documentation as a hint to the
+reader.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>When choosing the variable namespace, do not use variable name for
+specifying possibly unbounded set of things, most notably anything
+an end user can freely come up with (e.g. branch names).  Instead,
+use subsection names or variable values, like the existing variable
+branch.&lt;name&gt;.description does.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Writing Documentation:</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Most (if not all) of the documentation pages are written in the
+AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+processed into HTML and manpages (e.g. git.html and git.1 in the
+same directory).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>The documentation liberally mixes US and UK English (en_US/UK)
+norms for spelling and grammar, which is somewhat unfortunate.
+In an ideal world, it would have been better if it consistently
+used only one and not the other, and we would have picked en_US
+(if you wish to correct the English of some of the existing
+documentation, please see the documentation-related advice in the
+Documentation/SubmittingPatches file).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>In order to ensure the documentation is inclusive, avoid assuming
+that an unspecified example person is male or female, and think
+twice before using "he", "him", "she", or "her".  Here are some
+tips to avoid use of gendered pronouns:</pre>
+</div>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Prefer succinctness and matter-of-factly describing functionality
+in the abstract.  E.g.</p>
+<div class="dlist">
+<dl>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short"> <a class="anchor" href="#Documentation/CodingGuidelines---short"></a>--short </dt>
+<dd>
+<p>Emit output in the short-format.</p>
+<div class="literalblock">
+<div class="content">
+<pre>and avoid something like these overly verbose alternatives:</pre>
+</div>
+</div>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short-1"> <a class="anchor" href="#Documentation/CodingGuidelines---short-1"></a>--short </dt>
+<dd>
+<p>Use this to emit output in the short-format.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short-1-1"> <a class="anchor" href="#Documentation/CodingGuidelines---short-1-1"></a>--short </dt>
+<dd>
+<p>You can use this to get output in the short-format.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short-1-1-1"> <a class="anchor" href="#Documentation/CodingGuidelines---short-1-1-1"></a>--short </dt>
+<dd>
+<p>A user who prefers shorter output could&#8230;&#8203;.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines---short-1-1-1-1"> <a class="anchor" href="#Documentation/CodingGuidelines---short-1-1-1-1"></a>--short </dt>
+<dd>
+<p>Should a person and/or program want shorter output, he
+she/they/it can&#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>This practice often eliminates the need to involve human actors in
+your description, but it is a good practice regardless of the
+avoidance of gendered pronouns.</pre>
+</div>
+</div>
+</dd>
+</dl>
+</div>
+</li>
+<li>
+<p>When it becomes awkward to stick to this style, prefer "you" when
+addressing the hypothetical user, and possibly "we" when
+discussing how the program might react to the user.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>You can use this option instead of --xyz, but we might remove
+support for it in future versions.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while keeping in mind that you can probably be less verbose, e.g.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Use this instead of --xyz. This option might be removed in future
+versions.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>If you still need to refer to an example person that is
+third-person singular, you may resort to "singular they" to avoid
+"he/she/him/her", e.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>A contributor asks their upstream to pull from them.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Note that this sounds ungrammatical and unnatural to those who
+learned that "they" is only used for third-person plural, e.g.
+those who learn English as a second language in some parts of the
+world.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Every user-visible change should be reflected in the documentation.
+The same general rule as for code applies -- imitate the existing
+conventions.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying command usage strings and synopsis sections in the manual
+pages:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Placeholders are spelled in lowercase and enclosed in angle brackets:
+  &lt;file&gt;
+  --sort=&lt;key&gt;
+  --abbrev[=&lt;n&gt;]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If a placeholder has multiple words, they are separated by dashes:
+  &lt;new-branch-name&gt;
+  --template=&lt;template-directory&gt;</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Possibility of multiple occurrences is indicated by three dots:
+  &lt;file&gt;...
+  (One or more of &lt;file&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Optional parts are enclosed in square brackets:
+  [&lt;file&gt;...]
+  (Zero or more of &lt;file&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>--exec-path[=&lt;path&gt;]
+(Option with an optional argument.  Note that the "=" is inside the
+brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[&lt;patch&gt;...]
+(Zero or more of &lt;patch&gt;.  Note that the dots are inside, not
+outside the brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Multiple alternatives are indicated with vertical bars:
+  [-q | --quiet]
+  [--utf8 | --no-utf8]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Use spacing around "|" token(s), but not immediately after opening or
+before closing a [] or () pair:
+  Do: [-q | --quiet]
+  Don't: [-q|--quiet]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Don't use spacing around "|" tokens when they're used to separate the
+alternate arguments of an option:
+   Do: --track[=(direct|inherit)]
+   Don't: --track[=(direct | inherit)]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Parentheses are used for grouping:
+  [(&lt;rev&gt; | &lt;range&gt;)...]
+  (Any number of either &lt;rev&gt; or &lt;range&gt;.  Parens are needed to make
+  it clear that "..." pertains to both &lt;rev&gt; and &lt;range&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[(-p &lt;parent&gt;)...]
+(Any number of option -p, each with one &lt;parent&gt; argument.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>git remote set-head &lt;name&gt; (-a | -d | &lt;branch&gt;)
+(One and only one of "-a", "-d" or "&lt;branch&gt;" _must_ (no square
+brackets) be provided.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>And a somewhat more contrived example:
+  --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+  Here "=" is outside the brackets, because "--diff-filter=" is a
+  valid usage.  "*" has its own pair of brackets, because it can
+  (optionally) be specified only when one or more of the letters is
+  also provided.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A note on notation:
+ Use 'git' (all lowercase) when talking about commands i.e. something
+ the user would type into a shell and use 'Git' (uppercase first letter)
+ when talking about the version control system and its properties.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying paragraphs or option/command explanations that contain options
+or commands:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Literal examples (e.g. use of command-line options, command names,
+branch names, URLs, pathnames (files and directories), configuration and
+environment variables) must be typeset in monospace (i.e. wrapped with
+backticks):
+  `--pretty=oneline`
+  `git rev-list`
+  `remote.pushDefault`
+  `http://git.example.com`
+  `.git/config`
+  `GIT_DIR`
+  `HEAD`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>An environment variable must be prefixed with "$" only when referring to its
+value and not when referring to the variable itself, in this case there is
+nothing to add except the backticks:
+  `GIT_DIR` is specified
+  `$GIT_DIR/hooks/pre-receive`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Word phrases enclosed in `backtick characters` are rendered literally
+and will not be further expanded. The use of `backticks` to achieve the
+previous rule means that literal examples should not use AsciiDoc
+escapes.
+  Correct:
+     `--pretty=oneline`
+  Incorrect:
+     `\--pretty=oneline`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If some place in the documentation needs to typeset a command usage
+example with inline substitutions, it is fine to use +monospaced and
+inline substituted text+ instead of `monospaced literal text`, and with
+the former, the part that should not get substituted must be
+quoted/escaped.</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+</div>
+</div>
\ No newline at end of file
diff --git a/external/docs/content/docs/CodingGuidelines/2.45.0.html b/external/docs/content/docs/CodingGuidelines/2.45.0.html
new file mode 100644
index 0000000000..e0d75246af
--- /dev/null
+++ b/external/docs/content/docs/CodingGuidelines/2.45.0.html
@@ -0,0 +1,1300 @@
+---
+### DO NOT EDIT! Generated by script/update-docs.rb
+
+category: manual
+section: documentation
+subsection: manual
+title: Git - CodingGuidelines Documentation
+docname: CodingGuidelines
+version: 2.45.0
+aliases:
+- "/docs/CodingGuidelines/2.45.0/index.html"
+- "/docs/CodingGuidelines/2.45.1/index.html"
+- "/docs/CodingGuidelines/2.45.2/index.html"
+- "/docs/CodingGuidelines/2.45.3/index.html"
+- "/docs/CodingGuidelines/2.46.0/index.html"
+---
+<div id="preamble">
+<div class="sectionbody">
+<div class="paragraph">
+<p>Like other projects, we also have some guidelines for our code.  For
+Git in general, a few rough rules are:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most importantly, we never say "It&#8217;s in POSIX; we&#8217;ll happily
+ignore your needs should your system not conform to it."
+We live in the real world.</p>
+</li>
+<li>
+<p>However, we often say "Let&#8217;s stay away from that construct,
+it&#8217;s not even in POSIX".</p>
+</li>
+<li>
+<p>In spite of the above two rules, we sometimes say "Although
+this is not in POSIX, it (is so convenient | makes the code
+much more readable | has other good characteristics) and
+practically all the platforms we care about support it, so
+let&#8217;s use it".</p>
+<div class="literalblock">
+<div class="content">
+<pre>Again, we live in the real world, and it is sometimes a
+judgement call, the decision based more on real world
+constraints people face than what the paper standard says.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Fixing style violations while working on a real change as a
+preparatory clean-up step is good, but otherwise avoid useless code
+churn for the sake of conforming to the style.</p>
+<div class="literalblock">
+<div class="content">
+<pre>"Once it _is_ in the tree, it's not really worth the patch noise to
+go and fix it up."
+Cf. https://lore.kernel.org/all/20100126160632.3bdbe172.akpm@linux-foundation.org/</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Log messages to explain your changes are as important as the
+changes themselves.  Clearly written code and in-code comments
+explain how the code works and what is assumed from the surrounding
+context.  The log messages explain what the changes wanted to
+achieve and why the changes were necessary (more on this in the
+accompanying SubmittingPatches document).</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Make your code readable and sensible, and don&#8217;t try to be clever.</p>
+</div>
+<div class="paragraph">
+<p>As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the <em>local</em>
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code are expected to match the style the surrounding code already
+uses (even if it doesn&#8217;t match the overall style of existing code).</p>
+</div>
+<div class="paragraph">
+<p>But if you must have a list of rules, here are some language
+specific ones. Note that Documentation/ToolsForGit.txt document
+has a collection of tips to help you use some external tools
+to conform to these guidelines.</p>
+</div>
+<div class="paragraph">
+<p>For shell scripts specifically (not exhaustive):</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs for indentation.</p>
+</li>
+<li>
+<p>Case arms are indented at the same depth as case and esac lines,
+like this:</p>
+<div class="literalblock">
+<div class="content">
+<pre>case "$variable" in
+pattern1)
+	do this
+	;;
+pattern2)
+	do that
+	;;
+esac</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Redirection operators should be written with space before, but no
+space after them.  In other words, write <em>echo test &gt;"$file"</em>
+instead of <em>echo test&gt; $file</em> or <em>echo test &gt; $file</em>.  Note that
+even though it is not required by POSIX to double-quote the
+redirection target in a variable (as shown above), our code does so
+because some versions of bash issue a warning without the quotes.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+cat hello &gt; world &lt; universe
+echo hello &gt;$world</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+cat hello &gt;world &lt;universe
+echo hello &gt;"$world"</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer $( &#8230;&#8203; ) for command substitution; unlike ``, it
+properly nests.  It should have been the way Bourne spelled
+it from day one, but unfortunately isn&#8217;t.</p>
+</li>
+<li>
+<p>If you want to find out if a command is available on the user&#8217;s
+$PATH, you should use <em>type &lt;command&gt;</em>, instead of <em>which &lt;command&gt;</em>.
+The output of <em>which</em> is not machine parsable and its exit code
+is not reliable across platforms.</p>
+</li>
+<li>
+<p>We use POSIX compliant parameter substitutions and avoid bashisms;
+namely:</p>
+</li>
+<li>
+<p>We use ${parameter-word} and its [-=?+] siblings, and their
+colon&#8217;ed "unset or null" form.</p>
+</li>
+<li>
+<p>We use ${parameter#word} and its [#%] siblings, and their
+doubled "longest matching" form.</p>
+</li>
+<li>
+<p>No "Substring Expansion" ${parameter:offset:length}.</p>
+</li>
+<li>
+<p>No shell arrays.</p>
+</li>
+<li>
+<p>No pattern replacement ${parameter/pattern/string}.</p>
+</li>
+<li>
+<p>We use Arithmetic Expansion $&#8230;&#8203;.</p>
+</li>
+<li>
+<p>We do not use Process Substitution &lt;(list) or &gt;(list).</p>
+</li>
+<li>
+<p>Do not write control structures on a single line with semicolon.
+"then" should be on the next line for if statements, and "do"
+should be on the next line for "while" and "for".</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+if test -f hello; then
+	do this
+fi</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+if test -f hello
+then
+	do this
+fi</pre>
+</div>
+</div>
+</li>
+<li>
+<p>If a command sequence joined with &amp;&amp; or || or | spans multiple
+lines, put each command on a separate line and put &amp;&amp; and || and |
+operators at the end of each line, rather than the start. This
+means you don&#8217;t need to use \ to join lines, since the above
+operators imply the sequence isn&#8217;t finished.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+grep blob verify_pack_result \
+| awk -f print_1.awk \
+| sort &gt;actual &amp;&amp;
+...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+grep blob verify_pack_result |
+awk -f print_1.awk |
+sort &gt;actual &amp;&amp;
+...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer "test" over "[ &#8230;&#8203; ]".</p>
+</li>
+<li>
+<p>We do not write the noiseword "function" in front of shell
+functions.</p>
+</li>
+<li>
+<p>We prefer a space between the function name and the parentheses,
+and no space inside the parentheses. The opening "{" should also
+be on the same line.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+my_function(){
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+my_function () {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+[::], [==], or [..]) for portability.</p>
+</li>
+<li>
+<p>We do not use \{m,n\};</p>
+</li>
+<li>
+<p>We do not use ? or + (which are \{0,1\} and \{1,\}
+respectively in BRE) but that goes without saying as these
+are ERE elements not BRE (note that \? and \+ are not even part
+of BRE&#8201;&#8212;&#8201;making them accessible from BRE is a GNU extension).</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers in git-sh-i18n to make the user
+interface translatable. See "Marking strings for translation" in
+po/README.</p>
+</li>
+<li>
+<p>We do not write our "test" command with "-a" and "-o" and use "&amp;&amp;"
+or "||" to concatenate multiple "test" commands instead, because
+the use of "-a/-o" is often error-prone.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" -a "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is buggy and breaks when $x is "=", but</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" &amp;&amp; test "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>does not have such a problem.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Even though "local" is not part of POSIX, we make heavy use of it
+in our test suite.  We do not use it in scripted Porcelains, and
+hopefully nobody starts using "local" before they are reimplemented
+in C ;-)</p>
+</li>
+<li>
+<p>Some versions of shell do not understand "export variable=value",
+so we write "variable=value" and then "export variable" on two
+separate lines.</p>
+</li>
+<li>
+<p>Some versions of dash have broken variable assignment when prefixed
+with "local", "export", and "readonly", in that the value to be
+assigned goes through field splitting at $IFS unless quoted.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+local variable=$value
+local variable=$(command args)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+local variable="$value"
+local variable="$(command args)"</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Use octal escape sequences (e.g. "\302\242"), not hexadecimal (e.g.
+"\xc2\xa2") in printf format strings, since hexadecimal escape
+sequences are not portable.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For C programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs to indent, and interpret tabs as taking up to
+8 spaces.</p>
+</li>
+<li>
+<p>We try to keep to at most 80 characters per line.</p>
+</li>
+<li>
+<p>As a Git developer we assume you have a reasonably modern compiler
+and we recommend you to enable the DEVELOPER makefile knob to
+ensure your patch is clear of all compiler warnings we care about,
+by e.g. "echo DEVELOPER=1 &gt;&gt;config.mak".</p>
+</li>
+<li>
+<p>We try to support a wide range of C compilers to compile Git with,
+including old ones.  As of Git v2.35.0 Git requires C99 (we check
+"<em>STDC_VERSION</em>"). You should not use features from a newer C
+standard, even if your compiler groks them.</p>
+<div class="literalblock">
+<div class="content">
+<pre>New C99 features have been phased in gradually, if something's new
+in C99 but not used yet don't assume that it's safe to use, some
+compilers we target have only partial support for it. These are
+considered safe to use:</pre>
+</div>
+</div>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>since around 2007 with 2b6854c863a, we have been using
+initializer elements which are not computable at load time. E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>const char *args[] = {"constant", variable, NULL};</pre>
+</div>
+</div>
+</li>
+<li>
+<p>since early 2012 with e1327023ea, we have been using an enum
+definition whose last element is followed by a comma.  This, like
+an array initializer that ends with a trailing comma, can be used
+to reduce the patch noise when adding a new identifier at the end.</p>
+</li>
+<li>
+<p>since mid 2017 with cbc0f81d, we have been using designated
+initializers for struct (e.g. "struct t v = { .val = <em>a</em> };").</p>
+</li>
+<li>
+<p>since mid 2017 with 512f41cf, we have been using designated
+initializers for array (e.g. "int array[10] = { [5] = 2 }").</p>
+</li>
+<li>
+<p>since early 2021 with 765dc168882, we have been using variadic
+macros, mostly for printf-like trace and debug macros.</p>
+</li>
+<li>
+<p>since late 2021 with 44ba10d6, we have had variables declared in
+the for loop "for (int i = 0; i &lt; 10; i++)".</p>
+<div class="literalblock">
+<div class="content">
+<pre>New C99 features that we cannot use yet:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>%z and %zu as a printf() argument for a size_t (the %z being for
+the POSIX-specific ssize_t). Instead you should use
+printf("%"PRIuMAX, (uintmax_t)v).  These days the MSVC version we
+rely on supports %z, but the C library used by MinGW does not.</p>
+</li>
+<li>
+<p>Shorthand like ".a.b = *c" in struct initializations is known to
+trip up an older IBM XLC version, use ".a = { .b = *c }" instead.
+See the 33665d98 (reftable: make assignments portable to AIX xlc
+v12.01, 2022-03-28).</p>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>Variables have to be declared at the beginning of the block, before
+the first statement (i.e. -Wdeclaration-after-statement).</p>
+</li>
+<li>
+<p>NULL pointers shall be written as NULL, not as 0.</p>
+</li>
+<li>
+<p>When declaring pointers, the star sides with the variable
+name, i.e. "char <strong>string", not "char</strong> string" or
+"char * string".  This makes it easier to understand code
+like "char *string, c;".</p>
+</li>
+<li>
+<p>Use whitespace around operators and keywords, but not inside
+parentheses and not around functions. So:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      while (condition)
+func(bar + 1);</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>      while( condition )
+func (bar+1);</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Do not explicitly compare an integral value with constant 0 or <em>\0</em>,
+or a pointer value with constant NULL.  For instance, to validate that
+counted array &lt;ptr, cnt&gt; is initialized but has no elements, write:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (!ptr || cnt)
+	BUG("empty array expected");</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (ptr == NULL || cnt != 0);
+	BUG("empty array expected");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We avoid using braces unnecessarily.  I.e.</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (bla) {
+	x = 1;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is frowned upon. But there are a few exceptions:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When the statement extends over a few lines (e.g., a while loop
+with an embedded conditional, or a comment). E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (foo) {
+	if (x)
+		one();
+	else
+		two();
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	/*
+	 * This one requires some explanation,
+	 * so we're better off with braces to make
+	 * it obvious that the indentation is correct.
+	 */
+	doit();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When there are multiple arms to a conditional and some of them
+require braces, enclose even a single line block in braces for
+consistency. E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	doit();
+} else {
+	one();
+	two();
+	three();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments in the condition of an "if" statement.</p>
+</li>
+<li>
+<p>Try to make your code understandable.  You may put comments
+in, but comments invariably tend to stale out when the code
+they were describing changes.  Often splitting a function
+into two makes the intention of the code much clearer.</p>
+</li>
+<li>
+<p>Multi-line comments include their delimiters on separate lines from
+the text.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * A very long
+ * multi-line comment.
+ */</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Note however that a comment that explains a translatable string to
+translators uses a convention of starting with a magic token
+"TRANSLATORS: ", e.g.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * TRANSLATORS: here is a comment that explains the string to
+ * be translated, that follows immediately after it.
+ */
+_("Here is a translatable string explained by the above.");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Double negation is often harder to understand than no negation
+at all.</p>
+</li>
+<li>
+<p>There are two schools of thought when it comes to comparison,
+especially inside a loop. Some people prefer to have the less stable
+value on the left hand side and the more stable value on the right hand
+side, e.g. if you have a loop that counts variable i down to the
+lower bound,</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (i &gt; lower_bound) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Other people prefer to have the textual order of values match the
+actual order of values in their comparison, so that they can
+mentally draw a number line from left to right and place these
+values in order, i.e.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while (lower_bound &lt; i) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  However, the more "stable" the
+stable side becomes, the more we tend to prefer the former
+(comparison with a constant, "i &gt; 0", is an extreme example).
+Just do not mix styles in the same part of the code and mimic
+existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>There are two schools of thought when it comes to splitting a long
+logical line into multiple lines.  Some people push the second and
+subsequent lines far enough to the right with tabs and align them:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+              ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to align the second and the subsequent
+lines with the column immediately inside the opening parenthesis,
+with tabs and spaces, following our "tabstop is always a multiple
+of 8" convention:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+           ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  Again, just do not mix styles in
+the same part of the code and mimic existing styles in the
+neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, some people change line before
+a binary operator, so that the result looks like a parse tree when
+you turn your head 90-degrees counterclockwise:</p>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to
+|| span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to leave the operator at the end of the
+line:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, but we tend to use the latter more, unless the
+expression gets fairly complex, in which case the former tends to
+be easier to read.  Again, just do not mix styles in the same part
+of the code and mimic existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, with everything else being
+equal, it is preferable to split after the operator at higher
+level in the parse tree.  That is, this is more preferable:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable * that_is_used_in +
+    a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>than</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable *
+    that_is_used_in + a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Some clever tricks, like using the !! operator with arithmetic
+constructs, can be extremely confusing to others.  Avoid them,
+unless there is a compelling reason to use them.</p>
+</li>
+<li>
+<p>Use the API.  No, really.  We have a strbuf (variable length
+string), several arrays with the ALLOC_GROW() macro, a
+string_list for sorted string lists, a hash map (mapping struct
+objects) named "struct decorate", amongst other things.</p>
+</li>
+<li>
+<p>When you come up with an API, document its functions and structures
+in the header file that exposes the API to its callers. Use what is
+in "strbuf.h" as a model for the appropriate tone and level of
+detail.</p>
+</li>
+<li>
+<p>The first #include in C files, except in platform specific compat/
+implementations and sha1dc/, must be &lt;git-compat-util.h&gt;.  This
+header file insulates other header files and source files from
+platform differences, like which system header files must be
+included in what order, and what C preprocessor feature macros must
+be defined to trigger certain features we expect out of the system.
+A collorary to this is that C files should not directly include
+system header files themselves.</p>
+<div class="literalblock">
+<div class="content">
+<pre>There are some exceptions, because certain group of files that
+implement an API all have to include the same header file that
+defines the API and it is convenient to include &lt;git-compat-util.h&gt;
+there.  Namely:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>the implementation of the built-in commands in the "builtin/"
+directory that include "builtin.h" for the cmd_foo() prototype
+definition,</p>
+</li>
+<li>
+<p>the test helper programs in the "t/helper/" directory that include
+"t/helper/test-tool.h" for the cmd__foo() prototype definition,</p>
+</li>
+<li>
+<p>the xdiff implementation in the "xdiff/" directory that includes
+"xdiff/xinclude.h" for the xdiff machinery internals,</p>
+</li>
+<li>
+<p>the unit test programs in "t/unit-tests/" directory that include
+"t/unit-tests/test-lib.h" that gives them the unit-tests
+framework, and</p>
+</li>
+<li>
+<p>the source files that implement reftable in the "reftable/"
+directory that include "reftable/system.h" for the reftable
+internals,</p>
+<div class="literalblock">
+<div class="content">
+<pre>are allowed to assume that they do not have to include
+&lt;git-compat-util.h&gt; themselves, as it is included as the first
+'#include' in these header files.  These headers must be the first
+header file to be "#include"d in them, though.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>A C file must directly include the header files that declare the
+functions and the types it uses, except for the functions and types
+that are made available to it by including one of the header files
+it must include by the previous rule.</p>
+</li>
+<li>
+<p>If you are planning a new command, consider writing it in shell
+or perl first, so that changes in semantics can be easily
+changed and discussed.  Many Git commands started out like
+that, and a few are still scripts.</p>
+</li>
+<li>
+<p>Avoid introducing a new dependency into Git. This means you
+usually should stay away from scripting languages not already
+used in the Git core command set (unless your command is clearly
+separate from it, such as an importer to convert random-scm-X
+repositories to Git).</p>
+</li>
+<li>
+<p>When we pass &lt;string, length&gt; pair to functions, we should try to
+pass them in that order.</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers to make the user interface
+translatable. See "Marking strings for translation" in po/README.</p>
+</li>
+<li>
+<p>Variables and functions local to a given source file should be marked
+with "static". Variables that are visible to other source files
+must be declared with "extern" in header files. However, function
+declarations should not use "extern", as that is already the default.</p>
+</li>
+<li>
+<p>You can launch gdb around your program using the shorthand GIT_DEBUGGER.
+Run <code>GIT_DEBUGGER=1 ./bin-wrappers/git foo</code> to simply use gdb as is, or
+run <code>GIT_DEBUGGER="&lt;debugger&gt; &lt;debugger-args&gt;" ./bin-wrappers/git foo</code> to
+use your own debugger and arguments. Example: <code>GIT_DEBUGGER="ddd --gdb"
+./bin-wrappers/git log</code> (See <code>wrap-for-bin.sh</code>.)</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Perl programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most of the C guidelines above apply.</p>
+</li>
+<li>
+<p>We try to support Perl 5.8.1 and later ("use Perl 5.008001").</p>
+</li>
+<li>
+<p>use strict and use warnings are strongly preferred.</p>
+</li>
+<li>
+<p>Don&#8217;t overuse statement modifiers unless using them makes the
+result easier to follow.</p>
+<div class="olist lowerroman">
+<ol class="lowerroman" type="i">
+<li>
+<p>do something &#8230;&#8203;
+do_this() unless (condition);</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>is more readable than:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>do something &#8230;&#8203;
+unless (condition) {
+	do_this();
+}</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>*only* when the condition is so rare that do_this() will be almost
+always called.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments inside "if ()" conditions.</p>
+</li>
+<li>
+<p>Learn and use Git.pm if you need that functionality.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Python scripts:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We follow PEP-8 (<a href="https://peps.python.org/pep-0008/" class="bare">https://peps.python.org/pep-0008/</a>).</p>
+</li>
+<li>
+<p>As a minimum, we aim to be compatible with Python 2.7.</p>
+</li>
+<li>
+<p>Where required libraries do not restrict us to Python 2, we try to
+also be compatible with Python 3.1 and later.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Program Output</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>We make a distinction between a Git command's primary output and
+output which is merely chatty feedback (for instance, status
+messages, running transcript, or progress display), as well as error
+messages. Roughly speaking, a Git command's primary output is that
+which one might want to capture to a file or send down a pipe; its
+chatty output should not interfere with these use-cases.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>As such, primary output should be sent to the standard output stream
+(stdout), and chatty output should be sent to the standard error
+stream (stderr). Examples of commands which produce primary output
+include `git log`, `git show`, and `git branch --list` which generate
+output on the stdout stream.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Not all Git commands have primary output; this is often true of
+commands whose main function is to perform an action. Some action
+commands are silent, whereas others are chatty. An example of a
+chatty action commands is `git clone` with its "Cloning into
+'&lt;path&gt;'..." and "Checking connectivity..." status messages which it
+sends to the stderr stream.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Error messages from Git commands should always be sent to the stderr
+stream.</pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Error Messages</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Do not end error messages with a full stop.</p>
+</li>
+<li>
+<p>Do not capitalize the first word, only because it is the first word
+in the message ("unable to open %s", not "Unable to open %s").  But
+"SHA-3 not supported" is fine, because the reason the first word is
+capitalized is not because it is at the beginning of the sentence,
+but because the word would be spelled in capital letters even when
+it appeared in the middle of the sentence.</p>
+</li>
+<li>
+<p>Say what the error is first ("cannot open %s", not "%s: cannot open")</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Externally Visible Names</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>For configuration variable names, follow the existing convention:</p>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>The section name indicates the affected subsystem.</p>
+</li>
+<li>
+<p>The subsection name, if any, indicates which of an unbounded set
+of things to set the value for.</p>
+</li>
+<li>
+<p>The variable name describes the effect of tweaking this knob.</p>
+<div class="literalblock">
+<div class="content">
+<pre>The section and variable names that consist of multiple words are
+formed by concatenating the words without punctuation marks (e.g. `-`),
+and are broken using bumpyCaps in documentation as a hint to the
+reader.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>When choosing the variable namespace, do not use variable name for
+specifying possibly unbounded set of things, most notably anything
+an end user can freely come up with (e.g. branch names).  Instead,
+use subsection names or variable values, like the existing variable
+branch.&lt;name&gt;.description does.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Writing Documentation:</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Most (if not all) of the documentation pages are written in the
+AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+processed into HTML and manpages (e.g. git.html and git.1 in the
+same directory).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>The documentation liberally mixes US and UK English (en_US/UK)
+norms for spelling and grammar, which is somewhat unfortunate.
+In an ideal world, it would have been better if it consistently
+used only one and not the other, and we would have picked en_US
+(if you wish to correct the English of some of the existing
+documentation, please see the documentation-related advice in the
+Documentation/SubmittingPatches file).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>In order to ensure the documentation is inclusive, avoid assuming
+that an unspecified example person is male or female, and think
+twice before using "he", "him", "she", or "her".  Here are some
+tips to avoid use of gendered pronouns:</pre>
+</div>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Prefer succinctness and matter-of-factly describing functionality
+in the abstract.  E.g.</p>
+<div class="dlist">
+<dl>
+<dt class="hdlist1" id="Documentation/CodingGuidelines-code--shortcode"> <a class="anchor" href="#Documentation/CodingGuidelines-code--shortcode"></a><code>--short</code> </dt>
+<dd>
+<p>Emit output in the short-format.</p>
+<div class="literalblock">
+<div class="content">
+<pre>and avoid something like these overly verbose alternatives:</pre>
+</div>
+</div>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines-code--shortcode-1"> <a class="anchor" href="#Documentation/CodingGuidelines-code--shortcode-1"></a><code>--short</code> </dt>
+<dd>
+<p>Use this to emit output in the short-format.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines-code--shortcode-1-1"> <a class="anchor" href="#Documentation/CodingGuidelines-code--shortcode-1-1"></a><code>--short</code> </dt>
+<dd>
+<p>You can use this to get output in the short-format.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines-code--shortcode-1-1-1"> <a class="anchor" href="#Documentation/CodingGuidelines-code--shortcode-1-1-1"></a><code>--short</code> </dt>
+<dd>
+<p>A user who prefers shorter output could&#8230;&#8203;.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines-code--shortcode-1-1-1-1"> <a class="anchor" href="#Documentation/CodingGuidelines-code--shortcode-1-1-1-1"></a><code>--short</code> </dt>
+<dd>
+<p>Should a person and/or program want shorter output, he
+she/they/it can&#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>This practice often eliminates the need to involve human actors in
+your description, but it is a good practice regardless of the
+avoidance of gendered pronouns.</pre>
+</div>
+</div>
+</dd>
+</dl>
+</div>
+</li>
+<li>
+<p>When it becomes awkward to stick to this style, prefer "you" when
+addressing the hypothetical user, and possibly "we" when
+discussing how the program might react to the user.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>You can use this option instead of `--xyz`, but we might remove
+support for it in future versions.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while keeping in mind that you can probably be less verbose, e.g.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Use this instead of `--xyz`. This option might be removed in future
+versions.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>If you still need to refer to an example person that is
+third-person singular, you may resort to "singular they" to avoid
+"he/she/him/her", e.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>A contributor asks their upstream to pull from them.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Note that this sounds ungrammatical and unnatural to those who
+learned that "they" is only used for third-person plural, e.g.
+those who learn English as a second language in some parts of the
+world.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Every user-visible change should be reflected in the documentation.
+The same general rule as for code applies -- imitate the existing
+conventions.</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Markup:</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Literal parts (e.g. use of command-line options, command names,
+branch names, URLs, pathnames (files and directories), configuration and
+environment variables) must be typeset as verbatim (i.e. wrapped with
+backticks):
+  `--pretty=oneline`
+  `git rev-list`
+  `remote.pushDefault`
+  `http://git.example.com`
+  `.git/config`
+  `GIT_DIR`
+  `HEAD`
+  `umask`(2)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>An environment variable must be prefixed with "$" only when referring to its
+value and not when referring to the variable itself, in this case there is
+nothing to add except the backticks:
+  `GIT_DIR` is specified
+  `$GIT_DIR/hooks/pre-receive`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Word phrases enclosed in `backtick characters` are rendered literally
+and will not be further expanded. The use of `backticks` to achieve the
+previous rule means that literal examples should not use AsciiDoc
+escapes.
+  Correct:
+     `--pretty=oneline`
+  Incorrect:
+     `\--pretty=oneline`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Placeholders are spelled in lowercase and enclosed in
+angle brackets surrounded by underscores:
+  _&lt;file&gt;_
+  _&lt;commit&gt;_</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If a placeholder has multiple words, they are separated by dashes:
+  _&lt;new-branch-name&gt;_
+  _&lt;template-directory&gt;_</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A placeholder is not enclosed in backticks, as it is not a literal.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>When needed, use a distinctive identifier for placeholders, usually
+made of a qualification and a type:
+  _&lt;git-dir&gt;_
+  _&lt;key-id&gt;_</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>When literal and placeholders are mixed, each markup is applied for
+each sub-entity. If they are stuck, a special markup, called
+unconstrained formatting is required.
+Unconstrained formating for placeholders is __&lt;like-this&gt;__
+Unconstrained formatting for literal formatting is ++like this++
+  `--jobs` _&lt;n&gt;_
+  ++--sort=++__&lt;key&gt;__
+  __&lt;directory&gt;__++/.git++
+  ++remote.++__&lt;name&gt;__++.mirror++</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>caveat: ++ unconstrained format is not verbatim and may expand
+content. Use Asciidoc escapes inside them.</pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Synopsis Syntax</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Syntax grammar is formatted neither as literal nor as placeholder.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying command usage strings and synopsis sections in the manual
+pages:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Possibility of multiple occurrences is indicated by three dots:
+  _&lt;file&gt;_...
+  (One or more of &lt;file&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Optional parts are enclosed in square brackets:
+  [_&lt;file&gt;_...]
+  (Zero or more of &lt;file&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>++--exec-path++[++=++__&lt;path&gt;__]
+(Option with an optional argument.  Note that the "=" is inside the
+brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[_&lt;patch&gt;_...]
+(Zero or more of &lt;patch&gt;.  Note that the dots are inside, not
+outside the brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Multiple alternatives are indicated with vertical bars:
+  [`-q` | `--quiet`]
+  [`--utf8` | `--no-utf8`]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Use spacing around "|" token(s), but not immediately after opening or
+before closing a [] or () pair:
+  Do: [`-q` | `--quiet`]
+  Don't: [`-q`|`--quiet`]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Don't use spacing around "|" tokens when they're used to separate the
+alternate arguments of an option:
+   Do: ++--track++[++=++(`direct`|`inherit`)]`
+   Don't: ++--track++[++=++(`direct` | `inherit`)]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Parentheses are used for grouping:
+  [(_&lt;rev&gt;_ | _&lt;range&gt;_)...]
+  (Any number of either &lt;rev&gt; or &lt;range&gt;.  Parens are needed to make
+  it clear that "..." pertains to both &lt;rev&gt; and &lt;range&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[(`-p` _&lt;parent&gt;_)...]
+(Any number of option -p, each with one &lt;parent&gt; argument.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>`git remote set-head` _&lt;name&gt;_ (`-a` | `-d` | _&lt;branch&gt;_)
+(One and only one of "-a", "-d" or "&lt;branch&gt;" _must_ (no square
+brackets) be provided.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>And a somewhat more contrived example:
+  `--diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]`
+  Here "=" is outside the brackets, because "--diff-filter=" is a
+  valid usage.  "*" has its own pair of brackets, because it can
+  (optionally) be specified only when one or more of the letters is
+  also provided.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A note on notation:
+ Use 'git' (all lowercase) when talking about commands i.e. something
+ the user would type into a shell and use 'Git' (uppercase first letter)
+ when talking about the version control system and its properties.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If some place in the documentation needs to typeset a command usage
+example with inline substitutions, it is fine to use +monospaced and
+inline substituted text+ instead of `monospaced literal text`, and with
+the former, the part that should not get substituted must be
+quoted/escaped.</pre>
+</div>
+</div>
+</div>
+</div>
\ No newline at end of file
diff --git a/external/docs/content/docs/CodingGuidelines/2.46.1.html b/external/docs/content/docs/CodingGuidelines/2.46.1.html
new file mode 100644
index 0000000000..1d872dd883
--- /dev/null
+++ b/external/docs/content/docs/CodingGuidelines/2.46.1.html
@@ -0,0 +1,1352 @@
+---
+### DO NOT EDIT! Generated by script/update-docs.rb
+
+category: manual
+section: documentation
+subsection: manual
+title: Git - CodingGuidelines Documentation
+docname: CodingGuidelines
+version: 2.46.1
+aliases:
+- "/docs/CodingGuidelines/2.46.1/index.html"
+- "/docs/CodingGuidelines/2.46.2/index.html"
+- "/docs/CodingGuidelines/2.46.3/index.html"
+---
+<div id="preamble">
+<div class="sectionbody">
+<div class="paragraph">
+<p>Like other projects, we also have some guidelines for our code.  For
+Git in general, a few rough rules are:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most importantly, we never say "It&#8217;s in POSIX; we&#8217;ll happily
+ignore your needs should your system not conform to it."
+We live in the real world.</p>
+</li>
+<li>
+<p>However, we often say "Let&#8217;s stay away from that construct,
+it&#8217;s not even in POSIX".</p>
+</li>
+<li>
+<p>In spite of the above two rules, we sometimes say "Although
+this is not in POSIX, it (is so convenient | makes the code
+much more readable | has other good characteristics) and
+practically all the platforms we care about support it, so
+let&#8217;s use it".</p>
+<div class="literalblock">
+<div class="content">
+<pre>Again, we live in the real world, and it is sometimes a
+judgement call, the decision based more on real world
+constraints people face than what the paper standard says.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Fixing style violations while working on a real change as a
+preparatory clean-up step is good, but otherwise avoid useless code
+churn for the sake of conforming to the style.</p>
+<div class="literalblock">
+<div class="content">
+<pre>"Once it _is_ in the tree, it's not really worth the patch noise to
+go and fix it up."
+Cf. https://lore.kernel.org/all/20100126160632.3bdbe172.akpm@linux-foundation.org/</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Log messages to explain your changes are as important as the
+changes themselves.  Clearly written code and in-code comments
+explain how the code works and what is assumed from the surrounding
+context.  The log messages explain what the changes wanted to
+achieve and why the changes were necessary (more on this in the
+accompanying SubmittingPatches document).</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Make your code readable and sensible, and don&#8217;t try to be clever.</p>
+</div>
+<div class="paragraph">
+<p>As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the <em>local</em>
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code are expected to match the style the surrounding code already
+uses (even if it doesn&#8217;t match the overall style of existing code).</p>
+</div>
+<div class="paragraph">
+<p>But if you must have a list of rules, here are some language
+specific ones. Note that Documentation/ToolsForGit.txt document
+has a collection of tips to help you use some external tools
+to conform to these guidelines.</p>
+</div>
+<div class="paragraph">
+<p>For shell scripts specifically (not exhaustive):</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs for indentation.</p>
+</li>
+<li>
+<p>Case arms are indented at the same depth as case and esac lines,
+like this:</p>
+<div class="literalblock">
+<div class="content">
+<pre>case "$variable" in
+pattern1)
+	do this
+	;;
+pattern2)
+	do that
+	;;
+esac</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Redirection operators should be written with space before, but no
+space after them.  In other words, write <em>echo test &gt;"$file"</em>
+instead of <em>echo test&gt; $file</em> or <em>echo test &gt; $file</em>.  Note that
+even though it is not required by POSIX to double-quote the
+redirection target in a variable (as shown above), our code does so
+because some versions of bash issue a warning without the quotes.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+cat hello &gt; world &lt; universe
+echo hello &gt;$world</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+cat hello &gt;world &lt;universe
+echo hello &gt;"$world"</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer $( &#8230;&#8203; ) for command substitution; unlike ``, it
+properly nests.  It should have been the way Bourne spelled
+it from day one, but unfortunately isn&#8217;t.</p>
+</li>
+<li>
+<p>If you want to find out if a command is available on the user&#8217;s
+$PATH, you should use <em>type &lt;command&gt;</em>, instead of <em>which &lt;command&gt;</em>.
+The output of <em>which</em> is not machine parsable and its exit code
+is not reliable across platforms.</p>
+</li>
+<li>
+<p>We use POSIX compliant parameter substitutions and avoid bashisms;
+namely:</p>
+</li>
+<li>
+<p>We use ${parameter-word} and its [-=?+] siblings, and their
+colon&#8217;ed "unset or null" form.</p>
+</li>
+<li>
+<p>We use ${parameter#word} and its [#%] siblings, and their
+doubled "longest matching" form.</p>
+</li>
+<li>
+<p>No "Substring Expansion" ${parameter:offset:length}.</p>
+</li>
+<li>
+<p>No shell arrays.</p>
+</li>
+<li>
+<p>No pattern replacement ${parameter/pattern/string}.</p>
+</li>
+<li>
+<p>We use Arithmetic Expansion $&#8230;&#8203;.</p>
+</li>
+<li>
+<p>We do not use Process Substitution &lt;(list) or &gt;(list).</p>
+</li>
+<li>
+<p>Do not write control structures on a single line with semicolon.
+"then" should be on the next line for if statements, and "do"
+should be on the next line for "while" and "for".</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+if test -f hello; then
+	do this
+fi</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+if test -f hello
+then
+	do this
+fi</pre>
+</div>
+</div>
+</li>
+<li>
+<p>If a command sequence joined with &amp;&amp; or || or | spans multiple
+lines, put each command on a separate line and put &amp;&amp; and || and |
+operators at the end of each line, rather than the start. This
+means you don&#8217;t need to use \ to join lines, since the above
+operators imply the sequence isn&#8217;t finished.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+grep blob verify_pack_result \
+| awk -f print_1.awk \
+| sort &gt;actual &amp;&amp;
+...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+grep blob verify_pack_result |
+awk -f print_1.awk |
+sort &gt;actual &amp;&amp;
+...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer "test" over "[ &#8230;&#8203; ]".</p>
+</li>
+<li>
+<p>We do not write the noiseword "function" in front of shell
+functions.</p>
+</li>
+<li>
+<p>We prefer a space between the function name and the parentheses,
+and no space inside the parentheses. The opening "{" should also
+be on the same line.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+my_function(){
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+my_function () {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+[::], [==], or [..]) for portability.</p>
+</li>
+<li>
+<p>We do not use \{m,n\};</p>
+</li>
+<li>
+<p>We do not use ? or + (which are \{0,1\} and \{1,\}
+respectively in BRE) but that goes without saying as these
+are ERE elements not BRE (note that \? and \+ are not even part
+of BRE&#8201;&#8212;&#8201;making them accessible from BRE is a GNU extension).</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers in git-sh-i18n to make the user
+interface translatable. See "Marking strings for translation" in
+po/README.</p>
+</li>
+<li>
+<p>We do not write our "test" command with "-a" and "-o" and use "&amp;&amp;"
+or "||" to concatenate multiple "test" commands instead, because
+the use of "-a/-o" is often error-prone.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" -a "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is buggy and breaks when $x is "=", but</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" &amp;&amp; test "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>does not have such a problem.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Even though "local" is not part of POSIX, we make heavy use of it
+in our test suite.  We do not use it in scripted Porcelains, and
+hopefully nobody starts using "local" before all shells that matter
+support it (notably, ksh from AT&amp;T Research does not support it yet).</p>
+</li>
+<li>
+<p>Some versions of shell do not understand "export variable=value",
+so we write "variable=value" and then "export variable" on two
+separate lines.</p>
+</li>
+<li>
+<p>Some versions of dash have broken variable assignment when prefixed
+with "local", "export", and "readonly", in that the value to be
+assigned goes through field splitting at $IFS unless quoted.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+local variable=$value
+local variable=$(command args)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+local variable="$value"
+local variable="$(command args)"</pre>
+</div>
+</div>
+</li>
+<li>
+<p>The common construct</p>
+<div class="literalblock">
+<div class="content">
+<pre>VAR=VAL command args</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>to temporarily set and export environment variable VAR only while
+"command args" is running is handy, but this triggers an
+unspecified behaviour according to POSIX when used for a command
+that is not an external command (like shell functions).  Indeed,
+dash 0.5.10.2-6 on Ubuntu 20.04, /bin/sh on FreeBSD 13, and AT&amp;T
+ksh all make a temporary assignment without exporting the variable,
+in such a case.  As it does not work portably across shells, do not
+use this syntax for shell functions.  A common workaround is to do
+an explicit export in a subshell, like so:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+VAR=VAL func args</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+(
+	VAR=VAL &amp;&amp;
+	export VAR &amp;&amp;
+	func args
+)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>but be careful that the effect "func" makes to the variables in the
+current shell will be lost across the subshell boundary.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Use octal escape sequences (e.g. "\302\242"), not hexadecimal (e.g.
+"\xc2\xa2") in printf format strings, since hexadecimal escape
+sequences are not portable.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For C programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs to indent, and interpret tabs as taking up to
+8 spaces.</p>
+</li>
+<li>
+<p>We try to keep to at most 80 characters per line.</p>
+</li>
+<li>
+<p>As a Git developer we assume you have a reasonably modern compiler
+and we recommend you to enable the DEVELOPER makefile knob to
+ensure your patch is clear of all compiler warnings we care about,
+by e.g. "echo DEVELOPER=1 &gt;&gt;config.mak".</p>
+</li>
+<li>
+<p>We try to support a wide range of C compilers to compile Git with,
+including old ones.  As of Git v2.35.0 Git requires C99 (we check
+"<em>STDC_VERSION</em>"). You should not use features from a newer C
+standard, even if your compiler groks them.</p>
+<div class="literalblock">
+<div class="content">
+<pre>New C99 features have been phased in gradually, if something's new
+in C99 but not used yet don't assume that it's safe to use, some
+compilers we target have only partial support for it. These are
+considered safe to use:</pre>
+</div>
+</div>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>since around 2007 with 2b6854c863a, we have been using
+initializer elements which are not computable at load time. E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>const char *args[] = {"constant", variable, NULL};</pre>
+</div>
+</div>
+</li>
+<li>
+<p>since early 2012 with e1327023ea, we have been using an enum
+definition whose last element is followed by a comma.  This, like
+an array initializer that ends with a trailing comma, can be used
+to reduce the patch noise when adding a new identifier at the end.</p>
+</li>
+<li>
+<p>since mid 2017 with cbc0f81d, we have been using designated
+initializers for struct (e.g. "struct t v = { .val = <em>a</em> };").</p>
+</li>
+<li>
+<p>since mid 2017 with 512f41cf, we have been using designated
+initializers for array (e.g. "int array[10] = { [5] = 2 }").</p>
+</li>
+<li>
+<p>since early 2021 with 765dc168882, we have been using variadic
+macros, mostly for printf-like trace and debug macros.</p>
+</li>
+<li>
+<p>since late 2021 with 44ba10d6, we have had variables declared in
+the for loop "for (int i = 0; i &lt; 10; i++)".</p>
+<div class="literalblock">
+<div class="content">
+<pre>New C99 features that we cannot use yet:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>%z and %zu as a printf() argument for a size_t (the %z being for
+the POSIX-specific ssize_t). Instead you should use
+printf("%"PRIuMAX, (uintmax_t)v).  These days the MSVC version we
+rely on supports %z, but the C library used by MinGW does not.</p>
+</li>
+<li>
+<p>Shorthand like ".a.b = *c" in struct initializations is known to
+trip up an older IBM XLC version, use ".a = { .b = *c }" instead.
+See the 33665d98 (reftable: make assignments portable to AIX xlc
+v12.01, 2022-03-28).</p>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>Variables have to be declared at the beginning of the block, before
+the first statement (i.e. -Wdeclaration-after-statement).  It is
+encouraged to have a blank line between the end of the declarations
+and the first statement in the block.</p>
+</li>
+<li>
+<p>NULL pointers shall be written as NULL, not as 0.</p>
+</li>
+<li>
+<p>When declaring pointers, the star sides with the variable
+name, i.e. "char <strong>string", not "char</strong> string" or
+"char * string".  This makes it easier to understand code
+like "char *string, c;".</p>
+</li>
+<li>
+<p>Use whitespace around operators and keywords, but not inside
+parentheses and not around functions. So:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      while (condition)
+func(bar + 1);</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>      while( condition )
+func (bar+1);</pre>
+</div>
+</div>
+</li>
+<li>
+<p>A binary operator (other than ",") and ternary conditional "?:"
+have a space on each side of the operator to separate it from its
+operands.  E.g. "A + 1", not "A+1".</p>
+</li>
+<li>
+<p>A unary operator (other than "." and "&#8594;") have no space between it
+and its operand.  E.g. "(char *)ptr", not "(char *) ptr".</p>
+</li>
+<li>
+<p>Do not explicitly compare an integral value with constant 0 or <em>\0</em>,
+or a pointer value with constant NULL.  For instance, to validate that
+counted array &lt;ptr, cnt&gt; is initialized but has no elements, write:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (!ptr || cnt)
+	BUG("empty array expected");</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (ptr == NULL || cnt != 0);
+	BUG("empty array expected");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We avoid using braces unnecessarily.  I.e.</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (bla) {
+	x = 1;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is frowned upon. But there are a few exceptions:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When the statement extends over a few lines (e.g., a while loop
+with an embedded conditional, or a comment). E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (foo) {
+	if (x)
+		one();
+	else
+		two();
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	/*
+	 * This one requires some explanation,
+	 * so we're better off with braces to make
+	 * it obvious that the indentation is correct.
+	 */
+	doit();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When there are multiple arms to a conditional and some of them
+require braces, enclose even a single line block in braces for
+consistency. E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	doit();
+} else {
+	one();
+	two();
+	three();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments in the condition of an "if" statement.</p>
+</li>
+<li>
+<p>Try to make your code understandable.  You may put comments
+in, but comments invariably tend to stale out when the code
+they were describing changes.  Often splitting a function
+into two makes the intention of the code much clearer.</p>
+</li>
+<li>
+<p>Multi-line comments include their delimiters on separate lines from
+the text.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * A very long
+ * multi-line comment.
+ */</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Note however that a comment that explains a translatable string to
+translators uses a convention of starting with a magic token
+"TRANSLATORS: ", e.g.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * TRANSLATORS: here is a comment that explains the string to
+ * be translated, that follows immediately after it.
+ */
+_("Here is a translatable string explained by the above.");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Double negation is often harder to understand than no negation
+at all.</p>
+</li>
+<li>
+<p>There are two schools of thought when it comes to comparison,
+especially inside a loop. Some people prefer to have the less stable
+value on the left hand side and the more stable value on the right hand
+side, e.g. if you have a loop that counts variable i down to the
+lower bound,</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (i &gt; lower_bound) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Other people prefer to have the textual order of values match the
+actual order of values in their comparison, so that they can
+mentally draw a number line from left to right and place these
+values in order, i.e.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while (lower_bound &lt; i) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  However, the more "stable" the
+stable side becomes, the more we tend to prefer the former
+(comparison with a constant, "i &gt; 0", is an extreme example).
+Just do not mix styles in the same part of the code and mimic
+existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>There are two schools of thought when it comes to splitting a long
+logical line into multiple lines.  Some people push the second and
+subsequent lines far enough to the right with tabs and align them:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+              ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to align the second and the subsequent
+lines with the column immediately inside the opening parenthesis,
+with tabs and spaces, following our "tabstop is always a multiple
+of 8" convention:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+           ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  Again, just do not mix styles in
+the same part of the code and mimic existing styles in the
+neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, some people change line before
+a binary operator, so that the result looks like a parse tree when
+you turn your head 90-degrees counterclockwise:</p>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to
+|| span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to leave the operator at the end of the
+line:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, but we tend to use the latter more, unless the
+expression gets fairly complex, in which case the former tends to
+be easier to read.  Again, just do not mix styles in the same part
+of the code and mimic existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, with everything else being
+equal, it is preferable to split after the operator at higher
+level in the parse tree.  That is, this is more preferable:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable * that_is_used_in +
+    a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>than</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable *
+    that_is_used_in + a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Some clever tricks, like using the !! operator with arithmetic
+constructs, can be extremely confusing to others.  Avoid them,
+unless there is a compelling reason to use them.</p>
+</li>
+<li>
+<p>Use the API.  No, really.  We have a strbuf (variable length
+string), several arrays with the ALLOC_GROW() macro, a
+string_list for sorted string lists, a hash map (mapping struct
+objects) named "struct decorate", amongst other things.</p>
+</li>
+<li>
+<p>When you come up with an API, document its functions and structures
+in the header file that exposes the API to its callers. Use what is
+in "strbuf.h" as a model for the appropriate tone and level of
+detail.</p>
+</li>
+<li>
+<p>The first #include in C files, except in platform specific compat/
+implementations and sha1dc/, must be &lt;git-compat-util.h&gt;.  This
+header file insulates other header files and source files from
+platform differences, like which system header files must be
+included in what order, and what C preprocessor feature macros must
+be defined to trigger certain features we expect out of the system.
+A collorary to this is that C files should not directly include
+system header files themselves.</p>
+<div class="literalblock">
+<div class="content">
+<pre>There are some exceptions, because certain group of files that
+implement an API all have to include the same header file that
+defines the API and it is convenient to include &lt;git-compat-util.h&gt;
+there.  Namely:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>the implementation of the built-in commands in the "builtin/"
+directory that include "builtin.h" for the cmd_foo() prototype
+definition,</p>
+</li>
+<li>
+<p>the test helper programs in the "t/helper/" directory that include
+"t/helper/test-tool.h" for the cmd__foo() prototype definition,</p>
+</li>
+<li>
+<p>the xdiff implementation in the "xdiff/" directory that includes
+"xdiff/xinclude.h" for the xdiff machinery internals,</p>
+</li>
+<li>
+<p>the unit test programs in "t/unit-tests/" directory that include
+"t/unit-tests/test-lib.h" that gives them the unit-tests
+framework, and</p>
+</li>
+<li>
+<p>the source files that implement reftable in the "reftable/"
+directory that include "reftable/system.h" for the reftable
+internals,</p>
+<div class="literalblock">
+<div class="content">
+<pre>are allowed to assume that they do not have to include
+&lt;git-compat-util.h&gt; themselves, as it is included as the first
+'#include' in these header files.  These headers must be the first
+header file to be "#include"d in them, though.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>A C file must directly include the header files that declare the
+functions and the types it uses, except for the functions and types
+that are made available to it by including one of the header files
+it must include by the previous rule.</p>
+</li>
+<li>
+<p>If you are planning a new command, consider writing it in shell
+or perl first, so that changes in semantics can be easily
+changed and discussed.  Many Git commands started out like
+that, and a few are still scripts.</p>
+</li>
+<li>
+<p>Avoid introducing a new dependency into Git. This means you
+usually should stay away from scripting languages not already
+used in the Git core command set (unless your command is clearly
+separate from it, such as an importer to convert random-scm-X
+repositories to Git).</p>
+</li>
+<li>
+<p>When we pass &lt;string, length&gt; pair to functions, we should try to
+pass them in that order.</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers to make the user interface
+translatable. See "Marking strings for translation" in po/README.</p>
+</li>
+<li>
+<p>Variables and functions local to a given source file should be marked
+with "static". Variables that are visible to other source files
+must be declared with "extern" in header files. However, function
+declarations should not use "extern", as that is already the default.</p>
+</li>
+<li>
+<p>You can launch gdb around your program using the shorthand GIT_DEBUGGER.
+Run <code>GIT_DEBUGGER=1 ./bin-wrappers/git foo</code> to simply use gdb as is, or
+run <code>GIT_DEBUGGER="&lt;debugger&gt; &lt;debugger-args&gt;" ./bin-wrappers/git foo</code> to
+use your own debugger and arguments. Example: <code>GIT_DEBUGGER="ddd --gdb"
+./bin-wrappers/git log</code> (See <code>wrap-for-bin.sh</code>.)</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Perl programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most of the C guidelines above apply.</p>
+</li>
+<li>
+<p>We try to support Perl 5.8.1 and later ("use Perl 5.008001").</p>
+</li>
+<li>
+<p>use strict and use warnings are strongly preferred.</p>
+</li>
+<li>
+<p>Don&#8217;t overuse statement modifiers unless using them makes the
+result easier to follow.</p>
+<div class="olist lowerroman">
+<ol class="lowerroman" type="i">
+<li>
+<p>do something &#8230;&#8203;
+do_this() unless (condition);</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>is more readable than:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>do something &#8230;&#8203;
+unless (condition) {
+	do_this();
+}</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>*only* when the condition is so rare that do_this() will be almost
+always called.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments inside "if ()" conditions.</p>
+</li>
+<li>
+<p>Learn and use Git.pm if you need that functionality.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Python scripts:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We follow PEP-8 (<a href="https://peps.python.org/pep-0008/" class="bare">https://peps.python.org/pep-0008/</a>).</p>
+</li>
+<li>
+<p>As a minimum, we aim to be compatible with Python 2.7.</p>
+</li>
+<li>
+<p>Where required libraries do not restrict us to Python 2, we try to
+also be compatible with Python 3.1 and later.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Program Output</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>We make a distinction between a Git command's primary output and
+output which is merely chatty feedback (for instance, status
+messages, running transcript, or progress display), as well as error
+messages. Roughly speaking, a Git command's primary output is that
+which one might want to capture to a file or send down a pipe; its
+chatty output should not interfere with these use-cases.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>As such, primary output should be sent to the standard output stream
+(stdout), and chatty output should be sent to the standard error
+stream (stderr). Examples of commands which produce primary output
+include `git log`, `git show`, and `git branch --list` which generate
+output on the stdout stream.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Not all Git commands have primary output; this is often true of
+commands whose main function is to perform an action. Some action
+commands are silent, whereas others are chatty. An example of a
+chatty action commands is `git clone` with its "Cloning into
+'&lt;path&gt;'..." and "Checking connectivity..." status messages which it
+sends to the stderr stream.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Error messages from Git commands should always be sent to the stderr
+stream.</pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Error Messages</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Do not end error messages with a full stop.</p>
+</li>
+<li>
+<p>Do not capitalize the first word, only because it is the first word
+in the message ("unable to open %s", not "Unable to open %s").  But
+"SHA-3 not supported" is fine, because the reason the first word is
+capitalized is not because it is at the beginning of the sentence,
+but because the word would be spelled in capital letters even when
+it appeared in the middle of the sentence.</p>
+</li>
+<li>
+<p>Say what the error is first ("cannot open %s", not "%s: cannot open")</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Externally Visible Names</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>For configuration variable names, follow the existing convention:</p>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>The section name indicates the affected subsystem.</p>
+</li>
+<li>
+<p>The subsection name, if any, indicates which of an unbounded set
+of things to set the value for.</p>
+</li>
+<li>
+<p>The variable name describes the effect of tweaking this knob.</p>
+<div class="literalblock">
+<div class="content">
+<pre>The section and variable names that consist of multiple words are
+formed by concatenating the words without punctuation marks (e.g. `-`),
+and are broken using bumpyCaps in documentation as a hint to the
+reader.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>When choosing the variable namespace, do not use variable name for
+specifying possibly unbounded set of things, most notably anything
+an end user can freely come up with (e.g. branch names).  Instead,
+use subsection names or variable values, like the existing variable
+branch.&lt;name&gt;.description does.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Writing Documentation:</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Most (if not all) of the documentation pages are written in the
+AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+processed into HTML and manpages (e.g. git.html and git.1 in the
+same directory).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>The documentation liberally mixes US and UK English (en_US/UK)
+norms for spelling and grammar, which is somewhat unfortunate.
+In an ideal world, it would have been better if it consistently
+used only one and not the other, and we would have picked en_US
+(if you wish to correct the English of some of the existing
+documentation, please see the documentation-related advice in the
+Documentation/SubmittingPatches file).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>In order to ensure the documentation is inclusive, avoid assuming
+that an unspecified example person is male or female, and think
+twice before using "he", "him", "she", or "her".  Here are some
+tips to avoid use of gendered pronouns:</pre>
+</div>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Prefer succinctness and matter-of-factly describing functionality
+in the abstract.  E.g.</p>
+<div class="dlist">
+<dl>
+<dt class="hdlist1" id="Documentation/CodingGuidelines-code--shortcode"> <a class="anchor" href="#Documentation/CodingGuidelines-code--shortcode"></a><code>--short</code> </dt>
+<dd>
+<p>Emit output in the short-format.</p>
+<div class="literalblock">
+<div class="content">
+<pre>and avoid something like these overly verbose alternatives:</pre>
+</div>
+</div>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines-code--shortcode-1"> <a class="anchor" href="#Documentation/CodingGuidelines-code--shortcode-1"></a><code>--short</code> </dt>
+<dd>
+<p>Use this to emit output in the short-format.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines-code--shortcode-1-1"> <a class="anchor" href="#Documentation/CodingGuidelines-code--shortcode-1-1"></a><code>--short</code> </dt>
+<dd>
+<p>You can use this to get output in the short-format.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines-code--shortcode-1-1-1"> <a class="anchor" href="#Documentation/CodingGuidelines-code--shortcode-1-1-1"></a><code>--short</code> </dt>
+<dd>
+<p>A user who prefers shorter output could&#8230;&#8203;.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines-code--shortcode-1-1-1-1"> <a class="anchor" href="#Documentation/CodingGuidelines-code--shortcode-1-1-1-1"></a><code>--short</code> </dt>
+<dd>
+<p>Should a person and/or program want shorter output, he
+she/they/it can&#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>This practice often eliminates the need to involve human actors in
+your description, but it is a good practice regardless of the
+avoidance of gendered pronouns.</pre>
+</div>
+</div>
+</dd>
+</dl>
+</div>
+</li>
+<li>
+<p>When it becomes awkward to stick to this style, prefer "you" when
+addressing the hypothetical user, and possibly "we" when
+discussing how the program might react to the user.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>You can use this option instead of `--xyz`, but we might remove
+support for it in future versions.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while keeping in mind that you can probably be less verbose, e.g.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Use this instead of `--xyz`. This option might be removed in future
+versions.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>If you still need to refer to an example person that is
+third-person singular, you may resort to "singular they" to avoid
+"he/she/him/her", e.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>A contributor asks their upstream to pull from them.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Note that this sounds ungrammatical and unnatural to those who
+learned that "they" is only used for third-person plural, e.g.
+those who learn English as a second language in some parts of the
+world.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Every user-visible change should be reflected in the documentation.
+The same general rule as for code applies -- imitate the existing
+conventions.</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Markup:</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Literal parts (e.g. use of command-line options, command names,
+branch names, URLs, pathnames (files and directories), configuration and
+environment variables) must be typeset as verbatim (i.e. wrapped with
+backticks):
+  `--pretty=oneline`
+  `git rev-list`
+  `remote.pushDefault`
+  `http://git.example.com`
+  `.git/config`
+  `GIT_DIR`
+  `HEAD`
+  `umask`(2)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>An environment variable must be prefixed with "$" only when referring to its
+value and not when referring to the variable itself, in this case there is
+nothing to add except the backticks:
+  `GIT_DIR` is specified
+  `$GIT_DIR/hooks/pre-receive`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Word phrases enclosed in `backtick characters` are rendered literally
+and will not be further expanded. The use of `backticks` to achieve the
+previous rule means that literal examples should not use AsciiDoc
+escapes.
+  Correct:
+     `--pretty=oneline`
+  Incorrect:
+     `\--pretty=oneline`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Placeholders are spelled in lowercase and enclosed in
+angle brackets surrounded by underscores:
+  _&lt;file&gt;_
+  _&lt;commit&gt;_</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If a placeholder has multiple words, they are separated by dashes:
+  _&lt;new-branch-name&gt;_
+  _&lt;template-directory&gt;_</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A placeholder is not enclosed in backticks, as it is not a literal.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>When needed, use a distinctive identifier for placeholders, usually
+made of a qualification and a type:
+  _&lt;git-dir&gt;_
+  _&lt;key-id&gt;_</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>When literal and placeholders are mixed, each markup is applied for
+each sub-entity. If they are stuck, a special markup, called
+unconstrained formatting is required.
+Unconstrained formating for placeholders is __&lt;like-this&gt;__
+Unconstrained formatting for literal formatting is ++like this++
+  `--jobs` _&lt;n&gt;_
+  ++--sort=++__&lt;key&gt;__
+  __&lt;directory&gt;__++/.git++
+  ++remote.++__&lt;name&gt;__++.mirror++</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>caveat: ++ unconstrained format is not verbatim and may expand
+content. Use Asciidoc escapes inside them.</pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Synopsis Syntax</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Syntax grammar is formatted neither as literal nor as placeholder.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying command usage strings and synopsis sections in the manual
+pages:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Possibility of multiple occurrences is indicated by three dots:
+  _&lt;file&gt;_...
+  (One or more of &lt;file&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Optional parts are enclosed in square brackets:
+  [_&lt;file&gt;_...]
+  (Zero or more of &lt;file&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>++--exec-path++[++=++__&lt;path&gt;__]
+(Option with an optional argument.  Note that the "=" is inside the
+brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[_&lt;patch&gt;_...]
+(Zero or more of &lt;patch&gt;.  Note that the dots are inside, not
+outside the brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Multiple alternatives are indicated with vertical bars:
+  [`-q` | `--quiet`]
+  [`--utf8` | `--no-utf8`]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Use spacing around "|" token(s), but not immediately after opening or
+before closing a [] or () pair:
+  Do: [`-q` | `--quiet`]
+  Don't: [`-q`|`--quiet`]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Don't use spacing around "|" tokens when they're used to separate the
+alternate arguments of an option:
+   Do: ++--track++[++=++(`direct`|`inherit`)]`
+   Don't: ++--track++[++=++(`direct` | `inherit`)]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Parentheses are used for grouping:
+  [(_&lt;rev&gt;_ | _&lt;range&gt;_)...]
+  (Any number of either &lt;rev&gt; or &lt;range&gt;.  Parens are needed to make
+  it clear that "..." pertains to both &lt;rev&gt; and &lt;range&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[(`-p` _&lt;parent&gt;_)...]
+(Any number of option -p, each with one &lt;parent&gt; argument.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>`git remote set-head` _&lt;name&gt;_ (`-a` | `-d` | _&lt;branch&gt;_)
+(One and only one of "-a", "-d" or "&lt;branch&gt;" _must_ (no square
+brackets) be provided.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>And a somewhat more contrived example:
+  `--diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]`
+  Here "=" is outside the brackets, because "--diff-filter=" is a
+  valid usage.  "*" has its own pair of brackets, because it can
+  (optionally) be specified only when one or more of the letters is
+  also provided.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A note on notation:
+ Use 'git' (all lowercase) when talking about commands i.e. something
+ the user would type into a shell and use 'Git' (uppercase first letter)
+ when talking about the version control system and its properties.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If some place in the documentation needs to typeset a command usage
+example with inline substitutions, it is fine to use +monospaced and
+inline substituted text+ instead of `monospaced literal text`, and with
+the former, the part that should not get substituted must be
+quoted/escaped.</pre>
+</div>
+</div>
+</div>
+</div>
\ No newline at end of file
diff --git a/external/docs/content/docs/CodingGuidelines/2.47.0.html b/external/docs/content/docs/CodingGuidelines/2.47.0.html
new file mode 100644
index 0000000000..3ca164c8d8
--- /dev/null
+++ b/external/docs/content/docs/CodingGuidelines/2.47.0.html
@@ -0,0 +1,1438 @@
+---
+### DO NOT EDIT! Generated by script/update-docs.rb
+
+category: manual
+section: documentation
+subsection: manual
+title: Git - CodingGuidelines Documentation
+docname: CodingGuidelines
+version: 2.47.0
+aliases:
+- "/docs/CodingGuidelines/2.47.0/index.html"
+- "/docs/CodingGuidelines/2.47.1/index.html"
+- "/docs/CodingGuidelines/2.47.2/index.html"
+---
+<div id="preamble">
+<div class="sectionbody">
+<div class="paragraph">
+<p>Like other projects, we also have some guidelines for our code.  For
+Git in general, a few rough rules are:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most importantly, we never say "It&#8217;s in POSIX; we&#8217;ll happily
+ignore your needs should your system not conform to it."
+We live in the real world.</p>
+</li>
+<li>
+<p>However, we often say "Let&#8217;s stay away from that construct,
+it&#8217;s not even in POSIX".</p>
+</li>
+<li>
+<p>In spite of the above two rules, we sometimes say "Although
+this is not in POSIX, it (is so convenient | makes the code
+much more readable | has other good characteristics) and
+practically all the platforms we care about support it, so
+let&#8217;s use it".</p>
+<div class="literalblock">
+<div class="content">
+<pre>Again, we live in the real world, and it is sometimes a
+judgement call, the decision based more on real world
+constraints people face than what the paper standard says.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Fixing style violations while working on a real change as a
+preparatory clean-up step is good, but otherwise avoid useless code
+churn for the sake of conforming to the style.</p>
+<div class="literalblock">
+<div class="content">
+<pre>"Once it _is_ in the tree, it's not really worth the patch noise to
+go and fix it up."
+Cf. https://lore.kernel.org/all/20100126160632.3bdbe172.akpm@linux-foundation.org/</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Log messages to explain your changes are as important as the
+changes themselves.  Clearly written code and in-code comments
+explain how the code works and what is assumed from the surrounding
+context.  The log messages explain what the changes wanted to
+achieve and why the changes were necessary (more on this in the
+accompanying SubmittingPatches document).</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Make your code readable and sensible, and don&#8217;t try to be clever.</p>
+</div>
+<div class="paragraph">
+<p>As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the <em>local</em>
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code are expected to match the style the surrounding code already
+uses (even if it doesn&#8217;t match the overall style of existing code).</p>
+</div>
+<div class="paragraph">
+<p>But if you must have a list of rules, here are some language
+specific ones. Note that Documentation/ToolsForGit.txt document
+has a collection of tips to help you use some external tools
+to conform to these guidelines.</p>
+</div>
+<div class="paragraph">
+<p>For shell scripts specifically (not exhaustive):</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs for indentation.</p>
+</li>
+<li>
+<p>Case arms are indented at the same depth as case and esac lines,
+like this:</p>
+<div class="literalblock">
+<div class="content">
+<pre>case "$variable" in
+pattern1)
+	do this
+	;;
+pattern2)
+	do that
+	;;
+esac</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Redirection operators should be written with space before, but no
+space after them.  In other words, write <em>echo test &gt;"$file"</em>
+instead of <em>echo test&gt; $file</em> or <em>echo test &gt; $file</em>.  Note that
+even though it is not required by POSIX to double-quote the
+redirection target in a variable (as shown above), our code does so
+because some versions of bash issue a warning without the quotes.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+cat hello &gt; world &lt; universe
+echo hello &gt;$world</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+cat hello &gt;world &lt;universe
+echo hello &gt;"$world"</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer $( &#8230;&#8203; ) for command substitution; unlike ``, it
+properly nests.  It should have been the way Bourne spelled
+it from day one, but unfortunately isn&#8217;t.</p>
+</li>
+<li>
+<p>If you want to find out if a command is available on the user&#8217;s
+$PATH, you should use <em>type &lt;command&gt;</em>, instead of <em>which &lt;command&gt;</em>.
+The output of <em>which</em> is not machine parsable and its exit code
+is not reliable across platforms.</p>
+</li>
+<li>
+<p>We use POSIX compliant parameter substitutions and avoid bashisms;
+namely:</p>
+</li>
+<li>
+<p>We use ${parameter-word} and its [-=?+] siblings, and their
+colon&#8217;ed "unset or null" form.</p>
+</li>
+<li>
+<p>We use ${parameter#word} and its [#%] siblings, and their
+doubled "longest matching" form.</p>
+</li>
+<li>
+<p>No "Substring Expansion" ${parameter:offset:length}.</p>
+</li>
+<li>
+<p>No shell arrays.</p>
+</li>
+<li>
+<p>No pattern replacement ${parameter/pattern/string}.</p>
+</li>
+<li>
+<p>We use Arithmetic Expansion $&#8230;&#8203;.</p>
+</li>
+<li>
+<p>We do not use Process Substitution &lt;(list) or &gt;(list).</p>
+</li>
+<li>
+<p>Do not write control structures on a single line with semicolon.
+"then" should be on the next line for if statements, and "do"
+should be on the next line for "while" and "for".</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+if test -f hello; then
+	do this
+fi</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+if test -f hello
+then
+	do this
+fi</pre>
+</div>
+</div>
+</li>
+<li>
+<p>If a command sequence joined with &amp;&amp; or || or | spans multiple
+lines, put each command on a separate line and put &amp;&amp; and || and |
+operators at the end of each line, rather than the start. This
+means you don&#8217;t need to use \ to join lines, since the above
+operators imply the sequence isn&#8217;t finished.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+grep blob verify_pack_result \
+| awk -f print_1.awk \
+| sort &gt;actual &amp;&amp;
+...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+grep blob verify_pack_result |
+awk -f print_1.awk |
+sort &gt;actual &amp;&amp;
+...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer "test" over "[ &#8230;&#8203; ]".</p>
+</li>
+<li>
+<p>We do not write the noiseword "function" in front of shell
+functions.</p>
+</li>
+<li>
+<p>We prefer a space between the function name and the parentheses,
+and no space inside the parentheses. The opening "{" should also
+be on the same line.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+my_function(){
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+my_function () {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+[::], [==], or [..]) for portability.</p>
+</li>
+<li>
+<p>We do not use \{m,n\};</p>
+</li>
+<li>
+<p>We do not use ? or + (which are \{0,1\} and \{1,\}
+respectively in BRE) but that goes without saying as these
+are ERE elements not BRE (note that \? and \+ are not even part
+of BRE&#8201;&#8212;&#8201;making them accessible from BRE is a GNU extension).</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers in git-sh-i18n to make the user
+interface translatable. See "Marking strings for translation" in
+po/README.</p>
+</li>
+<li>
+<p>We do not write our "test" command with "-a" and "-o" and use "&amp;&amp;"
+or "||" to concatenate multiple "test" commands instead, because
+the use of "-a/-o" is often error-prone.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" -a "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is buggy and breaks when $x is "=", but</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" &amp;&amp; test "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>does not have such a problem.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Even though "local" is not part of POSIX, we make heavy use of it
+in our test suite.  We do not use it in scripted Porcelains, and
+hopefully nobody starts using "local" before all shells that matter
+support it (notably, ksh from AT&amp;T Research does not support it yet).</p>
+</li>
+<li>
+<p>Some versions of shell do not understand "export variable=value",
+so we write "variable=value" and then "export variable" on two
+separate lines.</p>
+</li>
+<li>
+<p>Some versions of dash have broken variable assignment when prefixed
+with "local", "export", and "readonly", in that the value to be
+assigned goes through field splitting at $IFS unless quoted.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+local variable=$value
+local variable=$(command args)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+local variable="$value"
+local variable="$(command args)"</pre>
+</div>
+</div>
+</li>
+<li>
+<p>The common construct</p>
+<div class="literalblock">
+<div class="content">
+<pre>VAR=VAL command args</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>to temporarily set and export environment variable VAR only while
+"command args" is running is handy, but this triggers an
+unspecified behaviour according to POSIX when used for a command
+that is not an external command (like shell functions).  Indeed,
+dash 0.5.10.2-6 on Ubuntu 20.04, /bin/sh on FreeBSD 13, and AT&amp;T
+ksh all make a temporary assignment without exporting the variable,
+in such a case.  As it does not work portably across shells, do not
+use this syntax for shell functions.  A common workaround is to do
+an explicit export in a subshell, like so:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+VAR=VAL func args</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+(
+	VAR=VAL &amp;&amp;
+	export VAR &amp;&amp;
+	func args
+)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>but be careful that the effect "func" makes to the variables in the
+current shell will be lost across the subshell boundary.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Use octal escape sequences (e.g. "\302\242"), not hexadecimal (e.g.
+"\xc2\xa2") in printf format strings, since hexadecimal escape
+sequences are not portable.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For C programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs to indent, and interpret tabs as taking up to
+8 spaces.</p>
+</li>
+<li>
+<p>Nested C preprocessor directives are indented after the hash by one
+space per nesting level.</p>
+<div class="literalblock">
+<div class="content">
+<pre>#if FOO
+# include &lt;foo.h&gt;
+# if BAR
+#  include &lt;bar.h&gt;
+# endif
+#endif</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We try to keep to at most 80 characters per line.</p>
+</li>
+<li>
+<p>As a Git developer we assume you have a reasonably modern compiler
+and we recommend you to enable the DEVELOPER makefile knob to
+ensure your patch is clear of all compiler warnings we care about,
+by e.g. "echo DEVELOPER=1 &gt;&gt;config.mak".</p>
+</li>
+<li>
+<p>When using DEVELOPER=1 mode, you may see warnings from the compiler
+like "error: unused parameter <em>foo</em> [-Werror=unused-parameter]",
+which indicates that a function ignores its argument. If the unused
+parameter can&#8217;t be removed (e.g., because the function is used as a
+callback and has to match a certain interface), you can annotate
+the individual parameters with the UNUSED (or MAYBE_UNUSED)
+keyword, like "int foo UNUSED".</p>
+</li>
+<li>
+<p>We try to support a wide range of C compilers to compile Git with,
+including old ones.  As of Git v2.35.0 Git requires C99 (we check
+"<em>STDC_VERSION</em>"). You should not use features from a newer C
+standard, even if your compiler groks them.</p>
+<div class="literalblock">
+<div class="content">
+<pre>New C99 features have been phased in gradually, if something's new
+in C99 but not used yet don't assume that it's safe to use, some
+compilers we target have only partial support for it. These are
+considered safe to use:</pre>
+</div>
+</div>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>since around 2007 with 2b6854c863a, we have been using
+initializer elements which are not computable at load time. E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>const char *args[] = { "constant", variable, NULL };</pre>
+</div>
+</div>
+</li>
+<li>
+<p>since early 2012 with e1327023ea, we have been using an enum
+definition whose last element is followed by a comma.  This, like
+an array initializer that ends with a trailing comma, can be used
+to reduce the patch noise when adding a new identifier at the end.</p>
+</li>
+<li>
+<p>since mid 2017 with cbc0f81d, we have been using designated
+initializers for struct (e.g. "struct t v = { .val = <em>a</em> };").</p>
+</li>
+<li>
+<p>since mid 2017 with 512f41cf, we have been using designated
+initializers for array (e.g. "int array[10] = { [5] = 2 }").</p>
+</li>
+<li>
+<p>since early 2021 with 765dc168882, we have been using variadic
+macros, mostly for printf-like trace and debug macros.</p>
+</li>
+<li>
+<p>since late 2021 with 44ba10d6, we have had variables declared in
+the for loop "for (int i = 0; i &lt; 10; i++)".</p>
+<div class="literalblock">
+<div class="content">
+<pre>New C99 features that we cannot use yet:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>%z and %zu as a printf() argument for a size_t (the %z being for
+the POSIX-specific ssize_t). Instead you should use
+printf("%"PRIuMAX, (uintmax_t)v).  These days the MSVC version we
+rely on supports %z, but the C library used by MinGW does not.</p>
+</li>
+<li>
+<p>Shorthand like ".a.b = *c" in struct initializations is known to
+trip up an older IBM XLC version, use ".a = { .b = *c }" instead.
+See the 33665d98 (reftable: make assignments portable to AIX xlc
+v12.01, 2022-03-28).</p>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>Variables have to be declared at the beginning of the block, before
+the first statement (i.e. -Wdeclaration-after-statement).  It is
+encouraged to have a blank line between the end of the declarations
+and the first statement in the block.</p>
+</li>
+<li>
+<p>NULL pointers shall be written as NULL, not as 0.</p>
+</li>
+<li>
+<p>When declaring pointers, the star sides with the variable
+name, i.e. "char <strong>string", not "char</strong> string" or
+"char * string".  This makes it easier to understand code
+like "char *string, c;".</p>
+</li>
+<li>
+<p>Use whitespace around operators and keywords, but not inside
+parentheses and not around functions. So:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      while (condition)
+func(bar + 1);</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>      while( condition )
+func (bar+1);</pre>
+</div>
+</div>
+</li>
+<li>
+<p>A binary operator (other than ",") and ternary conditional "?:"
+have a space on each side of the operator to separate it from its
+operands.  E.g. "A + 1", not "A+1".</p>
+</li>
+<li>
+<p>A unary operator (other than "." and "&#8594;") have no space between it
+and its operand.  E.g. "(char *)ptr", not "(char *) ptr".</p>
+</li>
+<li>
+<p>Do not explicitly compare an integral value with constant 0 or <em>\0</em>,
+or a pointer value with constant NULL.  For instance, to validate that
+counted array &lt;ptr, cnt&gt; is initialized but has no elements, write:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (!ptr || cnt)
+	BUG("empty array expected");</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (ptr == NULL || cnt != 0);
+	BUG("empty array expected");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We avoid using braces unnecessarily.  I.e.</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (bla) {
+	x = 1;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is frowned upon. But there are a few exceptions:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When the statement extends over a few lines (e.g., a while loop
+with an embedded conditional, or a comment). E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (foo) {
+	if (x)
+		one();
+	else
+		two();
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	/*
+	 * This one requires some explanation,
+	 * so we're better off with braces to make
+	 * it obvious that the indentation is correct.
+	 */
+	doit();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When there are multiple arms to a conditional and some of them
+require braces, enclose even a single line block in braces for
+consistency. E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	doit();
+} else {
+	one();
+	two();
+	three();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments in the condition of an "if" statement.</p>
+</li>
+<li>
+<p>Try to make your code understandable.  You may put comments
+in, but comments invariably tend to stale out when the code
+they were describing changes.  Often splitting a function
+into two makes the intention of the code much clearer.</p>
+</li>
+<li>
+<p>Multi-line comments include their delimiters on separate lines from
+the text.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * A very long
+ * multi-line comment.
+ */</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Note however that a comment that explains a translatable string to
+translators uses a convention of starting with a magic token
+"TRANSLATORS: ", e.g.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * TRANSLATORS: here is a comment that explains the string to
+ * be translated, that follows immediately after it.
+ */
+_("Here is a translatable string explained by the above.");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Double negation is often harder to understand than no negation
+at all.</p>
+</li>
+<li>
+<p>There are two schools of thought when it comes to comparison,
+especially inside a loop. Some people prefer to have the less stable
+value on the left hand side and the more stable value on the right hand
+side, e.g. if you have a loop that counts variable i down to the
+lower bound,</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (i &gt; lower_bound) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Other people prefer to have the textual order of values match the
+actual order of values in their comparison, so that they can
+mentally draw a number line from left to right and place these
+values in order, i.e.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while (lower_bound &lt; i) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  However, the more "stable" the
+stable side becomes, the more we tend to prefer the former
+(comparison with a constant, "i &gt; 0", is an extreme example).
+Just do not mix styles in the same part of the code and mimic
+existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>There are two schools of thought when it comes to splitting a long
+logical line into multiple lines.  Some people push the second and
+subsequent lines far enough to the right with tabs and align them:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+              ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to align the second and the subsequent
+lines with the column immediately inside the opening parenthesis,
+with tabs and spaces, following our "tabstop is always a multiple
+of 8" convention:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+           ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  Again, just do not mix styles in
+the same part of the code and mimic existing styles in the
+neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, some people change line before
+a binary operator, so that the result looks like a parse tree when
+you turn your head 90-degrees counterclockwise:</p>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to
+|| span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to leave the operator at the end of the
+line:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, but we tend to use the latter more, unless the
+expression gets fairly complex, in which case the former tends to
+be easier to read.  Again, just do not mix styles in the same part
+of the code and mimic existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, with everything else being
+equal, it is preferable to split after the operator at higher
+level in the parse tree.  That is, this is more preferable:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable * that_is_used_in +
+    a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>than</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable *
+    that_is_used_in + a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Some clever tricks, like using the !! operator with arithmetic
+constructs, can be extremely confusing to others.  Avoid them,
+unless there is a compelling reason to use them.</p>
+</li>
+<li>
+<p>Use the API.  No, really.  We have a strbuf (variable length
+string), several arrays with the ALLOC_GROW() macro, a
+string_list for sorted string lists, a hash map (mapping struct
+objects) named "struct decorate", amongst other things.</p>
+</li>
+<li>
+<p>When you come up with an API, document its functions and structures
+in the header file that exposes the API to its callers. Use what is
+in "strbuf.h" as a model for the appropriate tone and level of
+detail.</p>
+</li>
+<li>
+<p>The first #include in C files, except in platform specific compat/
+implementations and sha1dc/, must be &lt;git-compat-util.h&gt;.  This
+header file insulates other header files and source files from
+platform differences, like which system header files must be
+included in what order, and what C preprocessor feature macros must
+be defined to trigger certain features we expect out of the system.
+A collorary to this is that C files should not directly include
+system header files themselves.</p>
+<div class="literalblock">
+<div class="content">
+<pre>There are some exceptions, because certain group of files that
+implement an API all have to include the same header file that
+defines the API and it is convenient to include &lt;git-compat-util.h&gt;
+there.  Namely:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>the implementation of the built-in commands in the "builtin/"
+directory that include "builtin.h" for the cmd_foo() prototype
+definition,</p>
+</li>
+<li>
+<p>the test helper programs in the "t/helper/" directory that include
+"t/helper/test-tool.h" for the cmd__foo() prototype definition,</p>
+</li>
+<li>
+<p>the xdiff implementation in the "xdiff/" directory that includes
+"xdiff/xinclude.h" for the xdiff machinery internals,</p>
+</li>
+<li>
+<p>the unit test programs in "t/unit-tests/" directory that include
+"t/unit-tests/test-lib.h" that gives them the unit-tests
+framework, and</p>
+</li>
+<li>
+<p>the source files that implement reftable in the "reftable/"
+directory that include "reftable/system.h" for the reftable
+internals,</p>
+<div class="literalblock">
+<div class="content">
+<pre>are allowed to assume that they do not have to include
+&lt;git-compat-util.h&gt; themselves, as it is included as the first
+'#include' in these header files.  These headers must be the first
+header file to be "#include"d in them, though.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>A C file must directly include the header files that declare the
+functions and the types it uses, except for the functions and types
+that are made available to it by including one of the header files
+it must include by the previous rule.</p>
+</li>
+<li>
+<p>If you are planning a new command, consider writing it in shell
+or perl first, so that changes in semantics can be easily
+changed and discussed.  Many Git commands started out like
+that, and a few are still scripts.</p>
+</li>
+<li>
+<p>Avoid introducing a new dependency into Git. This means you
+usually should stay away from scripting languages not already
+used in the Git core command set (unless your command is clearly
+separate from it, such as an importer to convert random-scm-X
+repositories to Git).</p>
+</li>
+<li>
+<p>When we pass &lt;string, length&gt; pair to functions, we should try to
+pass them in that order.</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers to make the user interface
+translatable. See "Marking strings for translation" in po/README.</p>
+</li>
+<li>
+<p>Variables and functions local to a given source file should be marked
+with "static". Variables that are visible to other source files
+must be declared with "extern" in header files. However, function
+declarations should not use "extern", as that is already the default.</p>
+</li>
+<li>
+<p>You can launch gdb around your program using the shorthand GIT_DEBUGGER.
+Run <code>GIT_DEBUGGER=1 ./bin-wrappers/git foo</code> to simply use gdb as is, or
+run <code>GIT_DEBUGGER="&lt;debugger&gt; &lt;debugger-args&gt;" ./bin-wrappers/git foo</code> to
+use your own debugger and arguments. Example: <code>GIT_DEBUGGER="ddd --gdb"
+./bin-wrappers/git log</code> (See <code>wrap-for-bin.sh</code>.)</p>
+</li>
+<li>
+<p>The primary data structure that a subsystem <em>S</em> deals with is called
+<code>struct S</code>. Functions that operate on <code>struct S</code> are named
+<code>S_&lt;verb&gt;()</code> and should generally receive a pointer to <code>struct S</code> as
+first parameter. E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>struct strbuf;</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>void strbuf_add(struct strbuf *buf, ...);</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>void strbuf_reset(struct strbuf *buf);</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is preferred over:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>struct strbuf;</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>void add_string(struct strbuf *buf, ...);</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>void reset_strbuf(struct strbuf *buf);</pre>
+</div>
+</div>
+</li>
+<li>
+<p>There are several common idiomatic names for functions performing
+specific tasks on a structure <code>S</code>:</p>
+</li>
+<li>
+<p><code>S_init()</code> initializes a structure without allocating the
+structure itself.</p>
+</li>
+<li>
+<p><code>S_release()</code> releases a structure&#8217;s contents without freeing the
+structure.</p>
+</li>
+<li>
+<p><code>S_clear()</code> is equivalent to <code>S_release()</code> followed by <code>S_init()</code>
+such that the structure is directly usable after clearing it. When
+<code>S_clear()</code> is provided, <code>S_init()</code> shall not allocate resources
+that need to be released again.</p>
+</li>
+<li>
+<p><code>S_free()</code> releases a structure&#8217;s contents and frees the
+structure.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Perl programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most of the C guidelines above apply.</p>
+</li>
+<li>
+<p>We try to support Perl 5.8.1 and later ("use Perl 5.008001").</p>
+</li>
+<li>
+<p>use strict and use warnings are strongly preferred.</p>
+</li>
+<li>
+<p>Don&#8217;t overuse statement modifiers unless using them makes the
+result easier to follow.</p>
+<div class="olist lowerroman">
+<ol class="lowerroman" type="i">
+<li>
+<p>do something &#8230;&#8203;
+do_this() unless (condition);</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>is more readable than:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>do something &#8230;&#8203;
+unless (condition) {
+	do_this();
+}</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>*only* when the condition is so rare that do_this() will be almost
+always called.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments inside "if ()" conditions.</p>
+</li>
+<li>
+<p>Learn and use Git.pm if you need that functionality.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Python scripts:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We follow PEP-8 (<a href="https://peps.python.org/pep-0008/" class="bare">https://peps.python.org/pep-0008/</a>).</p>
+</li>
+<li>
+<p>As a minimum, we aim to be compatible with Python 2.7.</p>
+</li>
+<li>
+<p>Where required libraries do not restrict us to Python 2, we try to
+also be compatible with Python 3.1 and later.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Program Output</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>We make a distinction between a Git command's primary output and
+output which is merely chatty feedback (for instance, status
+messages, running transcript, or progress display), as well as error
+messages. Roughly speaking, a Git command's primary output is that
+which one might want to capture to a file or send down a pipe; its
+chatty output should not interfere with these use-cases.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>As such, primary output should be sent to the standard output stream
+(stdout), and chatty output should be sent to the standard error
+stream (stderr). Examples of commands which produce primary output
+include `git log`, `git show`, and `git branch --list` which generate
+output on the stdout stream.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Not all Git commands have primary output; this is often true of
+commands whose main function is to perform an action. Some action
+commands are silent, whereas others are chatty. An example of a
+chatty action commands is `git clone` with its "Cloning into
+'&lt;path&gt;'..." and "Checking connectivity..." status messages which it
+sends to the stderr stream.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Error messages from Git commands should always be sent to the stderr
+stream.</pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Error Messages</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Do not end error messages with a full stop.</p>
+</li>
+<li>
+<p>Do not capitalize the first word, only because it is the first word
+in the message ("unable to open %s", not "Unable to open %s").  But
+"SHA-3 not supported" is fine, because the reason the first word is
+capitalized is not because it is at the beginning of the sentence,
+but because the word would be spelled in capital letters even when
+it appeared in the middle of the sentence.</p>
+</li>
+<li>
+<p>Say what the error is first ("cannot open %s", not "%s: cannot open")</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Externally Visible Names</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>For configuration variable names, follow the existing convention:</p>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>The section name indicates the affected subsystem.</p>
+</li>
+<li>
+<p>The subsection name, if any, indicates which of an unbounded set
+of things to set the value for.</p>
+</li>
+<li>
+<p>The variable name describes the effect of tweaking this knob.</p>
+<div class="literalblock">
+<div class="content">
+<pre>The section and variable names that consist of multiple words are
+formed by concatenating the words without punctuation marks (e.g. `-`),
+and are broken using bumpyCaps in documentation as a hint to the
+reader.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>When choosing the variable namespace, do not use variable name for
+specifying possibly unbounded set of things, most notably anything
+an end user can freely come up with (e.g. branch names).  Instead,
+use subsection names or variable values, like the existing variable
+branch.&lt;name&gt;.description does.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Writing Documentation:</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Most (if not all) of the documentation pages are written in the
+AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+processed into HTML and manpages (e.g. git.html and git.1 in the
+same directory).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>The documentation liberally mixes US and UK English (en_US/UK)
+norms for spelling and grammar, which is somewhat unfortunate.
+In an ideal world, it would have been better if it consistently
+used only one and not the other, and we would have picked en_US
+(if you wish to correct the English of some of the existing
+documentation, please see the documentation-related advice in the
+Documentation/SubmittingPatches file).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>In order to ensure the documentation is inclusive, avoid assuming
+that an unspecified example person is male or female, and think
+twice before using "he", "him", "she", or "her".  Here are some
+tips to avoid use of gendered pronouns:</pre>
+</div>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Prefer succinctness and matter-of-factly describing functionality
+in the abstract.  E.g.</p>
+<div class="dlist">
+<dl>
+<dt class="hdlist1" id="Documentation/CodingGuidelines-code--shortcode"> <a class="anchor" href="#Documentation/CodingGuidelines-code--shortcode"></a><code>--short</code> </dt>
+<dd>
+<p>Emit output in the short-format.</p>
+<div class="literalblock">
+<div class="content">
+<pre>and avoid something like these overly verbose alternatives:</pre>
+</div>
+</div>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines-code--shortcode-1"> <a class="anchor" href="#Documentation/CodingGuidelines-code--shortcode-1"></a><code>--short</code> </dt>
+<dd>
+<p>Use this to emit output in the short-format.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines-code--shortcode-1-1"> <a class="anchor" href="#Documentation/CodingGuidelines-code--shortcode-1-1"></a><code>--short</code> </dt>
+<dd>
+<p>You can use this to get output in the short-format.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines-code--shortcode-1-1-1"> <a class="anchor" href="#Documentation/CodingGuidelines-code--shortcode-1-1-1"></a><code>--short</code> </dt>
+<dd>
+<p>A user who prefers shorter output could&#8230;&#8203;.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines-code--shortcode-1-1-1-1"> <a class="anchor" href="#Documentation/CodingGuidelines-code--shortcode-1-1-1-1"></a><code>--short</code> </dt>
+<dd>
+<p>Should a person and/or program want shorter output, he
+she/they/it can&#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>This practice often eliminates the need to involve human actors in
+your description, but it is a good practice regardless of the
+avoidance of gendered pronouns.</pre>
+</div>
+</div>
+</dd>
+</dl>
+</div>
+</li>
+<li>
+<p>When it becomes awkward to stick to this style, prefer "you" when
+addressing the hypothetical user, and possibly "we" when
+discussing how the program might react to the user.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>You can use this option instead of `--xyz`, but we might remove
+support for it in future versions.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while keeping in mind that you can probably be less verbose, e.g.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Use this instead of `--xyz`. This option might be removed in future
+versions.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>If you still need to refer to an example person that is
+third-person singular, you may resort to "singular they" to avoid
+"he/she/him/her", e.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>A contributor asks their upstream to pull from them.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Note that this sounds ungrammatical and unnatural to those who
+learned that "they" is only used for third-person plural, e.g.
+those who learn English as a second language in some parts of the
+world.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Every user-visible change should be reflected in the documentation.
+The same general rule as for code applies -- imitate the existing
+conventions.</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Markup:</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Literal parts (e.g. use of command-line options, command names,
+branch names, URLs, pathnames (files and directories), configuration and
+environment variables) must be typeset as verbatim (i.e. wrapped with
+backticks):
+  `--pretty=oneline`
+  `git rev-list`
+  `remote.pushDefault`
+  `http://git.example.com`
+  `.git/config`
+  `GIT_DIR`
+  `HEAD`
+  `umask`(2)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>An environment variable must be prefixed with "$" only when referring to its
+value and not when referring to the variable itself, in this case there is
+nothing to add except the backticks:
+  `GIT_DIR` is specified
+  `$GIT_DIR/hooks/pre-receive`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Word phrases enclosed in `backtick characters` are rendered literally
+and will not be further expanded. The use of `backticks` to achieve the
+previous rule means that literal examples should not use AsciiDoc
+escapes.
+  Correct:
+     `--pretty=oneline`
+  Incorrect:
+     `\--pretty=oneline`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Placeholders are spelled in lowercase and enclosed in
+angle brackets surrounded by underscores:
+  _&lt;file&gt;_
+  _&lt;commit&gt;_</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If a placeholder has multiple words, they are separated by dashes:
+  _&lt;new-branch-name&gt;_
+  _&lt;template-directory&gt;_</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A placeholder is not enclosed in backticks, as it is not a literal.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>When needed, use a distinctive identifier for placeholders, usually
+made of a qualification and a type:
+  _&lt;git-dir&gt;_
+  _&lt;key-id&gt;_</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>When literal and placeholders are mixed, each markup is applied for
+each sub-entity. If they are stuck, a special markup, called
+unconstrained formatting is required.
+Unconstrained formating for placeholders is __&lt;like-this&gt;__
+Unconstrained formatting for literal formatting is ++like this++
+  `--jobs` _&lt;n&gt;_
+  ++--sort=++__&lt;key&gt;__
+  __&lt;directory&gt;__++/.git++
+  ++remote.++__&lt;name&gt;__++.mirror++</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>caveat: ++ unconstrained format is not verbatim and may expand
+content. Use Asciidoc escapes inside them.</pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Synopsis Syntax</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Syntax grammar is formatted neither as literal nor as placeholder.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying command usage strings and synopsis sections in the manual
+pages:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Possibility of multiple occurrences is indicated by three dots:
+  _&lt;file&gt;_...
+  (One or more of &lt;file&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Optional parts are enclosed in square brackets:
+  [_&lt;file&gt;_...]
+  (Zero or more of &lt;file&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>++--exec-path++[++=++__&lt;path&gt;__]
+(Option with an optional argument.  Note that the "=" is inside the
+brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[_&lt;patch&gt;_...]
+(Zero or more of &lt;patch&gt;.  Note that the dots are inside, not
+outside the brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Multiple alternatives are indicated with vertical bars:
+  [`-q` | `--quiet`]
+  [`--utf8` | `--no-utf8`]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Use spacing around "|" token(s), but not immediately after opening or
+before closing a [] or () pair:
+  Do: [`-q` | `--quiet`]
+  Don't: [`-q`|`--quiet`]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Don't use spacing around "|" tokens when they're used to separate the
+alternate arguments of an option:
+   Do: ++--track++[++=++(`direct`|`inherit`)]`
+   Don't: ++--track++[++=++(`direct` | `inherit`)]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Parentheses are used for grouping:
+  [(_&lt;rev&gt;_ | _&lt;range&gt;_)...]
+  (Any number of either &lt;rev&gt; or &lt;range&gt;.  Parens are needed to make
+  it clear that "..." pertains to both &lt;rev&gt; and &lt;range&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[(`-p` _&lt;parent&gt;_)...]
+(Any number of option -p, each with one &lt;parent&gt; argument.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>`git remote set-head` _&lt;name&gt;_ (`-a` | `-d` | _&lt;branch&gt;_)
+(One and only one of "-a", "-d" or "&lt;branch&gt;" _must_ (no square
+brackets) be provided.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>And a somewhat more contrived example:
+  `--diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]`
+  Here "=" is outside the brackets, because "--diff-filter=" is a
+  valid usage.  "*" has its own pair of brackets, because it can
+  (optionally) be specified only when one or more of the letters is
+  also provided.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A note on notation:
+ Use 'git' (all lowercase) when talking about commands i.e. something
+ the user would type into a shell and use 'Git' (uppercase first letter)
+ when talking about the version control system and its properties.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If some place in the documentation needs to typeset a command usage
+example with inline substitutions, it is fine to use +monospaced and
+inline substituted text+ instead of `monospaced literal text`, and with
+the former, the part that should not get substituted must be
+quoted/escaped.</pre>
+</div>
+</div>
+</div>
+</div>
\ No newline at end of file
diff --git a/external/docs/content/docs/CodingGuidelines/2.48.0.html b/external/docs/content/docs/CodingGuidelines/2.48.0.html
new file mode 100644
index 0000000000..c470ce559e
--- /dev/null
+++ b/external/docs/content/docs/CodingGuidelines/2.48.0.html
@@ -0,0 +1,1479 @@
+---
+### DO NOT EDIT! Generated by script/update-docs.rb
+
+category: manual
+section: documentation
+subsection: manual
+title: Git - CodingGuidelines Documentation
+docname: CodingGuidelines
+version: 2.48.0
+aliases:
+- "/docs/CodingGuidelines/2.48.0/index.html"
+- "/docs/CodingGuidelines/2.48.1/index.html"
+---
+<div id="preamble">
+<div class="sectionbody">
+<div class="paragraph">
+<p>Like other projects, we also have some guidelines for our code.  For
+Git in general, a few rough rules are:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most importantly, we never say "It&#8217;s in POSIX; we&#8217;ll happily
+ignore your needs should your system not conform to it."
+We live in the real world.</p>
+</li>
+<li>
+<p>However, we often say "Let&#8217;s stay away from that construct,
+it&#8217;s not even in POSIX".</p>
+</li>
+<li>
+<p>In spite of the above two rules, we sometimes say "Although
+this is not in POSIX, it (is so convenient | makes the code
+much more readable | has other good characteristics) and
+practically all the platforms we care about support it, so
+let&#8217;s use it".</p>
+<div class="literalblock">
+<div class="content">
+<pre>Again, we live in the real world, and it is sometimes a
+judgement call, the decision based more on real world
+constraints people face than what the paper standard says.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Fixing style violations while working on a real change as a
+preparatory clean-up step is good, but otherwise avoid useless code
+churn for the sake of conforming to the style.</p>
+<div class="literalblock">
+<div class="content">
+<pre>"Once it _is_ in the tree, it's not really worth the patch noise to
+go and fix it up."
+Cf. https://lore.kernel.org/all/20100126160632.3bdbe172.akpm@linux-foundation.org/</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Log messages to explain your changes are as important as the
+changes themselves.  Clearly written code and in-code comments
+explain how the code works and what is assumed from the surrounding
+context.  The log messages explain what the changes wanted to
+achieve and why the changes were necessary (more on this in the
+accompanying SubmittingPatches document).</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Make your code readable and sensible, and don&#8217;t try to be clever.</p>
+</div>
+<div class="paragraph">
+<p>As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the <em>local</em>
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code are expected to match the style the surrounding code already
+uses (even if it doesn&#8217;t match the overall style of existing code).</p>
+</div>
+<div class="paragraph">
+<p>But if you must have a list of rules, here are some language
+specific ones. Note that Documentation/ToolsForGit.txt document
+has a collection of tips to help you use some external tools
+to conform to these guidelines.</p>
+</div>
+<div class="paragraph">
+<p>For shell scripts specifically (not exhaustive):</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs for indentation.</p>
+</li>
+<li>
+<p>Case arms are indented at the same depth as case and esac lines,
+like this:</p>
+<div class="literalblock">
+<div class="content">
+<pre>case "$variable" in
+pattern1)
+	do this
+	;;
+pattern2)
+	do that
+	;;
+esac</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Redirection operators should be written with space before, but no
+space after them.  In other words, write <em>echo test &gt;"$file"</em>
+instead of <em>echo test&gt; $file</em> or <em>echo test &gt; $file</em>.  Note that
+even though it is not required by POSIX to double-quote the
+redirection target in a variable (as shown above), our code does so
+because some versions of bash issue a warning without the quotes.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+cat hello &gt; world &lt; universe
+echo hello &gt;$world</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+cat hello &gt;world &lt;universe
+echo hello &gt;"$world"</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer $( &#8230;&#8203; ) for command substitution; unlike ``, it
+properly nests.  It should have been the way Bourne spelled
+it from day one, but unfortunately isn&#8217;t.</p>
+</li>
+<li>
+<p>If you want to find out if a command is available on the user&#8217;s
+$PATH, you should use <em>type &lt;command&gt;</em>, instead of <em>which &lt;command&gt;</em>.
+The output of <em>which</em> is not machine parsable and its exit code
+is not reliable across platforms.</p>
+</li>
+<li>
+<p>We use POSIX compliant parameter substitutions and avoid bashisms;
+namely:</p>
+</li>
+<li>
+<p>We use ${parameter-word} and its [-=?+] siblings, and their
+colon&#8217;ed "unset or null" form.</p>
+</li>
+<li>
+<p>We use ${parameter#word} and its [#%] siblings, and their
+doubled "longest matching" form.</p>
+</li>
+<li>
+<p>No "Substring Expansion" ${parameter:offset:length}.</p>
+</li>
+<li>
+<p>No shell arrays.</p>
+</li>
+<li>
+<p>No pattern replacement ${parameter/pattern/string}.</p>
+</li>
+<li>
+<p>We use Arithmetic Expansion $&#8230;&#8203;.</p>
+</li>
+<li>
+<p>We do not use Process Substitution &lt;(list) or &gt;(list).</p>
+</li>
+<li>
+<p>Do not write control structures on a single line with semicolon.
+"then" should be on the next line for if statements, and "do"
+should be on the next line for "while" and "for".</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+if test -f hello; then
+	do this
+fi</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+if test -f hello
+then
+	do this
+fi</pre>
+</div>
+</div>
+</li>
+<li>
+<p>If a command sequence joined with &amp;&amp; or || or | spans multiple
+lines, put each command on a separate line and put &amp;&amp; and || and |
+operators at the end of each line, rather than the start. This
+means you don&#8217;t need to use \ to join lines, since the above
+operators imply the sequence isn&#8217;t finished.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+grep blob verify_pack_result \
+| awk -f print_1.awk \
+| sort &gt;actual &amp;&amp;
+...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+grep blob verify_pack_result |
+awk -f print_1.awk |
+sort &gt;actual &amp;&amp;
+...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer "test" over "[ &#8230;&#8203; ]".</p>
+</li>
+<li>
+<p>We do not write the noiseword "function" in front of shell
+functions.</p>
+</li>
+<li>
+<p>We prefer a space between the function name and the parentheses,
+and no space inside the parentheses. The opening "{" should also
+be on the same line.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+my_function(){
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+my_function () {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+[::], [==], or [..]) for portability.</p>
+</li>
+<li>
+<p>We do not use \{m,n\};</p>
+</li>
+<li>
+<p>We do not use ? or + (which are \{0,1\} and \{1,\}
+respectively in BRE) but that goes without saying as these
+are ERE elements not BRE (note that \? and \+ are not even part
+of BRE&#8201;&#8212;&#8201;making them accessible from BRE is a GNU extension).</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers in git-sh-i18n to make the user
+interface translatable. See "Marking strings for translation" in
+po/README.</p>
+</li>
+<li>
+<p>We do not write our "test" command with "-a" and "-o" and use "&amp;&amp;"
+or "||" to concatenate multiple "test" commands instead, because
+the use of "-a/-o" is often error-prone.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" -a "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is buggy and breaks when $x is "=", but</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" &amp;&amp; test "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>does not have such a problem.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Even though "local" is not part of POSIX, we make heavy use of it
+in our test suite.  We do not use it in scripted Porcelains, and
+hopefully nobody starts using "local" before all shells that matter
+support it (notably, ksh from AT&amp;T Research does not support it yet).</p>
+</li>
+<li>
+<p>Some versions of shell do not understand "export variable=value",
+so we write "variable=value" and then "export variable" on two
+separate lines.</p>
+</li>
+<li>
+<p>Some versions of dash have broken variable assignment when prefixed
+with "local", "export", and "readonly", in that the value to be
+assigned goes through field splitting at $IFS unless quoted.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+local variable=$value
+local variable=$(command args)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+local variable="$value"
+local variable="$(command args)"</pre>
+</div>
+</div>
+</li>
+<li>
+<p>The common construct</p>
+<div class="literalblock">
+<div class="content">
+<pre>VAR=VAL command args</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>to temporarily set and export environment variable VAR only while
+"command args" is running is handy, but this triggers an
+unspecified behaviour according to POSIX when used for a command
+that is not an external command (like shell functions).  Indeed,
+dash 0.5.10.2-6 on Ubuntu 20.04, /bin/sh on FreeBSD 13, and AT&amp;T
+ksh all make a temporary assignment without exporting the variable,
+in such a case.  As it does not work portably across shells, do not
+use this syntax for shell functions.  A common workaround is to do
+an explicit export in a subshell, like so:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+VAR=VAL func args</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+(
+	VAR=VAL &amp;&amp;
+	export VAR &amp;&amp;
+	func args
+)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>but be careful that the effect "func" makes to the variables in the
+current shell will be lost across the subshell boundary.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Use octal escape sequences (e.g. "\302\242"), not hexadecimal (e.g.
+"\xc2\xa2") in printf format strings, since hexadecimal escape
+sequences are not portable.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For C programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs to indent, and interpret tabs as taking up to
+8 spaces.</p>
+</li>
+<li>
+<p>Nested C preprocessor directives are indented after the hash by one
+space per nesting level.</p>
+<div class="literalblock">
+<div class="content">
+<pre>#if FOO
+# include &lt;foo.h&gt;
+# if BAR
+#  include &lt;bar.h&gt;
+# endif
+#endif</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We try to keep to at most 80 characters per line.</p>
+</li>
+<li>
+<p>As a Git developer we assume you have a reasonably modern compiler
+and we recommend you to enable the DEVELOPER makefile knob to
+ensure your patch is clear of all compiler warnings we care about,
+by e.g. "echo DEVELOPER=1 &gt;&gt;config.mak".</p>
+</li>
+<li>
+<p>When using DEVELOPER=1 mode, you may see warnings from the compiler
+like "error: unused parameter <em>foo</em> [-Werror=unused-parameter]",
+which indicates that a function ignores its argument. If the unused
+parameter can&#8217;t be removed (e.g., because the function is used as a
+callback and has to match a certain interface), you can annotate
+the individual parameters with the UNUSED (or MAYBE_UNUSED)
+keyword, like "int foo UNUSED".</p>
+</li>
+<li>
+<p>We try to support a wide range of C compilers to compile Git with,
+including old ones.  As of Git v2.35.0 Git requires C99 (we check
+"<em>STDC_VERSION</em>"). You should not use features from a newer C
+standard, even if your compiler groks them.</p>
+<div class="literalblock">
+<div class="content">
+<pre>New C99 features have been phased in gradually, if something's new
+in C99 but not used yet don't assume that it's safe to use, some
+compilers we target have only partial support for it. These are
+considered safe to use:</pre>
+</div>
+</div>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>since around 2007 with 2b6854c863a, we have been using
+initializer elements which are not computable at load time. E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>const char *args[] = { "constant", variable, NULL };</pre>
+</div>
+</div>
+</li>
+<li>
+<p>since early 2012 with e1327023ea, we have been using an enum
+definition whose last element is followed by a comma.  This, like
+an array initializer that ends with a trailing comma, can be used
+to reduce the patch noise when adding a new identifier at the end.</p>
+</li>
+<li>
+<p>since mid 2017 with cbc0f81d, we have been using designated
+initializers for struct (e.g. "struct t v = { .val = <em>a</em> };").</p>
+</li>
+<li>
+<p>since mid 2017 with 512f41cf, we have been using designated
+initializers for array (e.g. "int array[10] = { [5] = 2 }").</p>
+</li>
+<li>
+<p>since early 2021 with 765dc168882, we have been using variadic
+macros, mostly for printf-like trace and debug macros.</p>
+</li>
+<li>
+<p>since late 2021 with 44ba10d6, we have had variables declared in
+the for loop "for (int i = 0; i &lt; 10; i++)".</p>
+<div class="literalblock">
+<div class="content">
+<pre>New C99 features that we cannot use yet:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>%z and %zu as a printf() argument for a size_t (the %z being for
+the POSIX-specific ssize_t). Instead you should use
+printf("%"PRIuMAX, (uintmax_t)v).  These days the MSVC version we
+rely on supports %z, but the C library used by MinGW does not.</p>
+</li>
+<li>
+<p>Shorthand like ".a.b = *c" in struct initializations is known to
+trip up an older IBM XLC version, use ".a = { .b = *c }" instead.
+See the 33665d98 (reftable: make assignments portable to AIX xlc
+v12.01, 2022-03-28).</p>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>Variables have to be declared at the beginning of the block, before
+the first statement (i.e. -Wdeclaration-after-statement).  It is
+encouraged to have a blank line between the end of the declarations
+and the first statement in the block.</p>
+</li>
+<li>
+<p>NULL pointers shall be written as NULL, not as 0.</p>
+</li>
+<li>
+<p>When declaring pointers, the star sides with the variable
+name, i.e. "char <strong>string", not "char</strong> string" or
+"char * string".  This makes it easier to understand code
+like "char *string, c;".</p>
+</li>
+<li>
+<p>Use whitespace around operators and keywords, but not inside
+parentheses and not around functions. So:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      while (condition)
+func(bar + 1);</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>      while( condition )
+func (bar+1);</pre>
+</div>
+</div>
+</li>
+<li>
+<p>A binary operator (other than ",") and ternary conditional "?:"
+have a space on each side of the operator to separate it from its
+operands.  E.g. "A + 1", not "A+1".</p>
+</li>
+<li>
+<p>A unary operator (other than "." and "&#8594;") have no space between it
+and its operand.  E.g. "(char *)ptr", not "(char *) ptr".</p>
+</li>
+<li>
+<p>Do not explicitly compare an integral value with constant 0 or <em>\0</em>,
+or a pointer value with constant NULL.  For instance, to validate that
+counted array &lt;ptr, cnt&gt; is initialized but has no elements, write:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (!ptr || cnt)
+	BUG("empty array expected");</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (ptr == NULL || cnt != 0);
+	BUG("empty array expected");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We avoid using braces unnecessarily.  I.e.</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (bla) {
+	x = 1;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is frowned upon. But there are a few exceptions:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When the statement extends over a few lines (e.g., a while loop
+with an embedded conditional, or a comment). E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (foo) {
+	if (x)
+		one();
+	else
+		two();
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	/*
+	 * This one requires some explanation,
+	 * so we're better off with braces to make
+	 * it obvious that the indentation is correct.
+	 */
+	doit();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When there are multiple arms to a conditional and some of them
+require braces, enclose even a single line block in braces for
+consistency. E.g.:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (foo) {
+	doit();
+} else {
+	one();
+	two();
+	three();
+}</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments in the condition of an "if" statement.</p>
+</li>
+<li>
+<p>Try to make your code understandable.  You may put comments
+in, but comments invariably tend to stale out when the code
+they were describing changes.  Often splitting a function
+into two makes the intention of the code much clearer.</p>
+</li>
+<li>
+<p>Multi-line comments include their delimiters on separate lines from
+the text.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * A very long
+ * multi-line comment.
+ */</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Note however that a comment that explains a translatable string to
+translators uses a convention of starting with a magic token
+"TRANSLATORS: ", e.g.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * TRANSLATORS: here is a comment that explains the string to
+ * be translated, that follows immediately after it.
+ */
+_("Here is a translatable string explained by the above.");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Double negation is often harder to understand than no negation
+at all.</p>
+</li>
+<li>
+<p>There are two schools of thought when it comes to comparison,
+especially inside a loop. Some people prefer to have the less stable
+value on the left hand side and the more stable value on the right hand
+side, e.g. if you have a loop that counts variable i down to the
+lower bound,</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (i &gt; lower_bound) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Other people prefer to have the textual order of values match the
+actual order of values in their comparison, so that they can
+mentally draw a number line from left to right and place these
+values in order, i.e.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while (lower_bound &lt; i) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  However, the more "stable" the
+stable side becomes, the more we tend to prefer the former
+(comparison with a constant, "i &gt; 0", is an extreme example).
+Just do not mix styles in the same part of the code and mimic
+existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>There are two schools of thought when it comes to splitting a long
+logical line into multiple lines.  Some people push the second and
+subsequent lines far enough to the right with tabs and align them:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+              ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to align the second and the subsequent
+lines with the column immediately inside the opening parenthesis,
+with tabs and spaces, following our "tabstop is always a multiple
+of 8" convention:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+           ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  Again, just do not mix styles in
+the same part of the code and mimic existing styles in the
+neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, some people change line before
+a binary operator, so that the result looks like a parse tree when
+you turn your head 90-degrees counterclockwise:</p>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to
+|| span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to leave the operator at the end of the
+line:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, but we tend to use the latter more, unless the
+expression gets fairly complex, in which case the former tends to
+be easier to read.  Again, just do not mix styles in the same part
+of the code and mimic existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, with everything else being
+equal, it is preferable to split after the operator at higher
+level in the parse tree.  That is, this is more preferable:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable * that_is_used_in +
+    a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>than</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable *
+    that_is_used_in + a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Some clever tricks, like using the !! operator with arithmetic
+constructs, can be extremely confusing to others.  Avoid them,
+unless there is a compelling reason to use them.</p>
+</li>
+<li>
+<p>Use the API.  No, really.  We have a strbuf (variable length
+string), several arrays with the ALLOC_GROW() macro, a
+string_list for sorted string lists, a hash map (mapping struct
+objects) named "struct decorate", amongst other things.</p>
+</li>
+<li>
+<p>When you come up with an API, document its functions and structures
+in the header file that exposes the API to its callers. Use what is
+in "strbuf.h" as a model for the appropriate tone and level of
+detail.</p>
+</li>
+<li>
+<p>The first #include in C files, except in platform specific compat/
+implementations and sha1dc/, must be &lt;git-compat-util.h&gt;.  This
+header file insulates other header files and source files from
+platform differences, like which system header files must be
+included in what order, and what C preprocessor feature macros must
+be defined to trigger certain features we expect out of the system.
+A collorary to this is that C files should not directly include
+system header files themselves.</p>
+<div class="literalblock">
+<div class="content">
+<pre>There are some exceptions, because certain group of files that
+implement an API all have to include the same header file that
+defines the API and it is convenient to include &lt;git-compat-util.h&gt;
+there.  Namely:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>the implementation of the built-in commands in the "builtin/"
+directory that include "builtin.h" for the cmd_foo() prototype
+definition,</p>
+</li>
+<li>
+<p>the test helper programs in the "t/helper/" directory that include
+"t/helper/test-tool.h" for the cmd__foo() prototype definition,</p>
+</li>
+<li>
+<p>the xdiff implementation in the "xdiff/" directory that includes
+"xdiff/xinclude.h" for the xdiff machinery internals,</p>
+</li>
+<li>
+<p>the unit test programs in "t/unit-tests/" directory that include
+"t/unit-tests/test-lib.h" that gives them the unit-tests
+framework, and</p>
+</li>
+<li>
+<p>the source files that implement reftable in the "reftable/"
+directory that include "reftable/system.h" for the reftable
+internals,</p>
+<div class="literalblock">
+<div class="content">
+<pre>are allowed to assume that they do not have to include
+&lt;git-compat-util.h&gt; themselves, as it is included as the first
+'#include' in these header files.  These headers must be the first
+header file to be "#include"d in them, though.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>A C file must directly include the header files that declare the
+functions and the types it uses, except for the functions and types
+that are made available to it by including one of the header files
+it must include by the previous rule.</p>
+</li>
+<li>
+<p>If you are planning a new command, consider writing it in shell
+or perl first, so that changes in semantics can be easily
+changed and discussed.  Many Git commands started out like
+that, and a few are still scripts.</p>
+</li>
+<li>
+<p>Avoid introducing a new dependency into Git. This means you
+usually should stay away from scripting languages not already
+used in the Git core command set (unless your command is clearly
+separate from it, such as an importer to convert random-scm-X
+repositories to Git).</p>
+</li>
+<li>
+<p>When we pass &lt;string, length&gt; pair to functions, we should try to
+pass them in that order.</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers to make the user interface
+translatable. See "Marking strings for translation" in po/README.</p>
+</li>
+<li>
+<p>Variables and functions local to a given source file should be marked
+with "static". Variables that are visible to other source files
+must be declared with "extern" in header files. However, function
+declarations should not use "extern", as that is already the default.</p>
+</li>
+<li>
+<p>You can launch gdb around your program using the shorthand GIT_DEBUGGER.
+Run <code>GIT_DEBUGGER=1 ./bin-wrappers/git foo</code> to simply use gdb as is, or
+run <code>GIT_DEBUGGER="&lt;debugger&gt; &lt;debugger-args&gt;" ./bin-wrappers/git foo</code> to
+use your own debugger and arguments. Example: <code>GIT_DEBUGGER="ddd --gdb"
+./bin-wrappers/git log</code> (See <code>bin-wrappers/wrap-for-bin.sh</code>.)</p>
+</li>
+<li>
+<p>The primary data structure that a subsystem <em>S</em> deals with is called
+<code>struct S</code>. Functions that operate on <code>struct S</code> are named
+<code>S_&lt;verb&gt;()</code> and should generally receive a pointer to <code>struct S</code> as
+first parameter. E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>struct strbuf;</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>void strbuf_add(struct strbuf *buf, ...);</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>void strbuf_reset(struct strbuf *buf);</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is preferred over:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>struct strbuf;</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>void add_string(struct strbuf *buf, ...);</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>void reset_strbuf(struct strbuf *buf);</pre>
+</div>
+</div>
+</li>
+<li>
+<p>There are several common idiomatic names for functions performing
+specific tasks on a structure <code>S</code>:</p>
+</li>
+<li>
+<p><code>S_init()</code> initializes a structure without allocating the
+structure itself.</p>
+</li>
+<li>
+<p><code>S_release()</code> releases a structure&#8217;s contents without freeing the
+structure.</p>
+</li>
+<li>
+<p><code>S_clear()</code> is equivalent to <code>S_release()</code> followed by <code>S_init()</code>
+such that the structure is directly usable after clearing it. When
+<code>S_clear()</code> is provided, <code>S_init()</code> shall not allocate resources
+that need to be released again.</p>
+</li>
+<li>
+<p><code>S_free()</code> releases a structure&#8217;s contents and frees the
+structure.</p>
+</li>
+<li>
+<p>Function names should be clear and descriptive, accurately reflecting
+their purpose or behavior. Arbitrary suffixes that do not add meaningful
+context can lead to confusion, particularly for newcomers to the codebase.</p>
+<div class="literalblock">
+<div class="content">
+<pre>Historically, the '_1' suffix has been used in situations where:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>A function handles one element among a group that requires similar
+processing.</p>
+</li>
+<li>
+<p>A recursive function has been separated from its setup phase.</p>
+<div class="literalblock">
+<div class="content">
+<pre>The '_1' suffix can be used as a concise way to indicate these specific
+cases. However, it is recommended to find a more descriptive name wherever
+possible to improve the readability and maintainability of the code.</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Perl programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most of the C guidelines above apply.</p>
+</li>
+<li>
+<p>We try to support Perl 5.8.1 and later ("use Perl 5.008001").</p>
+</li>
+<li>
+<p>use strict and use warnings are strongly preferred.</p>
+</li>
+<li>
+<p>Don&#8217;t overuse statement modifiers unless using them makes the
+result easier to follow.</p>
+<div class="olist lowerroman">
+<ol class="lowerroman" type="i">
+<li>
+<p>do something &#8230;&#8203;
+do_this() unless (condition);</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>is more readable than:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>do something &#8230;&#8203;
+unless (condition) {
+	do_this();
+}</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>*only* when the condition is so rare that do_this() will be almost
+always called.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments inside "if ()" conditions.</p>
+</li>
+<li>
+<p>Learn and use Git.pm if you need that functionality.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Python scripts:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We follow PEP-8 (<a href="https://peps.python.org/pep-0008/" class="bare">https://peps.python.org/pep-0008/</a>).</p>
+</li>
+<li>
+<p>As a minimum, we aim to be compatible with Python 2.7.</p>
+</li>
+<li>
+<p>Where required libraries do not restrict us to Python 2, we try to
+also be compatible with Python 3.1 and later.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Program Output</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>We make a distinction between a Git command's primary output and
+output which is merely chatty feedback (for instance, status
+messages, running transcript, or progress display), as well as error
+messages. Roughly speaking, a Git command's primary output is that
+which one might want to capture to a file or send down a pipe; its
+chatty output should not interfere with these use-cases.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>As such, primary output should be sent to the standard output stream
+(stdout), and chatty output should be sent to the standard error
+stream (stderr). Examples of commands which produce primary output
+include `git log`, `git show`, and `git branch --list` which generate
+output on the stdout stream.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Not all Git commands have primary output; this is often true of
+commands whose main function is to perform an action. Some action
+commands are silent, whereas others are chatty. An example of a
+chatty action commands is `git clone` with its "Cloning into
+'&lt;path&gt;'..." and "Checking connectivity..." status messages which it
+sends to the stderr stream.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Error messages from Git commands should always be sent to the stderr
+stream.</pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Error Messages</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Do not end a single-sentence error message with a full stop.</p>
+</li>
+<li>
+<p>Do not capitalize the first word, only because it is the first word
+in the message ("unable to open <em>%s</em>", not "Unable to open <em>%s</em>").  But
+"SHA-3 not supported" is fine, because the reason the first word is
+capitalized is not because it is at the beginning of the sentence,
+but because the word would be spelled in capital letters even when
+it appeared in the middle of the sentence.</p>
+</li>
+<li>
+<p>Say what the error is first ("cannot open <em>%s</em>", not "%s: cannot open").</p>
+</li>
+<li>
+<p>Enclose the subject of an error inside a pair of single quotes,
+e.g. <code>die(_("unable to open '%s'"), path)</code>.</p>
+</li>
+<li>
+<p>Unless there is a compelling reason not to, error messages from
+porcelain commands should be marked for translation, e.g.
+<code>die(_("bad revision %s"), revision)</code>.</p>
+</li>
+<li>
+<p>Error messages from the plumbing commands are sometimes meant for
+machine consumption and should not be marked for translation,
+e.g., <code>die("bad revision %s", revision)</code>.</p>
+</li>
+<li>
+<p>BUG("message") are for communicating the specific error to developers,
+thus should not be translated.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Externally Visible Names</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>For configuration variable names, follow the existing convention:</p>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>The section name indicates the affected subsystem.</p>
+</li>
+<li>
+<p>The subsection name, if any, indicates which of an unbounded set
+of things to set the value for.</p>
+</li>
+<li>
+<p>The variable name describes the effect of tweaking this knob.</p>
+<div class="literalblock">
+<div class="content">
+<pre>The section and variable names that consist of multiple words are
+formed by concatenating the words without punctuation marks (e.g. `-`),
+and are broken using bumpyCaps in documentation as a hint to the
+reader.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>When choosing the variable namespace, do not use variable name for
+specifying possibly unbounded set of things, most notably anything
+an end user can freely come up with (e.g. branch names).  Instead,
+use subsection names or variable values, like the existing variable
+branch.&lt;name&gt;.description does.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Writing Documentation:</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Most (if not all) of the documentation pages are written in the
+AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+processed into HTML and manpages (e.g. git.html and git.1 in the
+same directory).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>The documentation liberally mixes US and UK English (en_US/UK)
+norms for spelling and grammar, which is somewhat unfortunate.
+In an ideal world, it would have been better if it consistently
+used only one and not the other, and we would have picked en_US
+(if you wish to correct the English of some of the existing
+documentation, please see the documentation-related advice in the
+Documentation/SubmittingPatches file).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>In order to ensure the documentation is inclusive, avoid assuming
+that an unspecified example person is male or female, and think
+twice before using "he", "him", "she", or "her".  Here are some
+tips to avoid use of gendered pronouns:</pre>
+</div>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Prefer succinctness and matter-of-factly describing functionality
+in the abstract.  E.g.</p>
+<div class="dlist">
+<dl>
+<dt class="hdlist1" id="Documentation/CodingGuidelines-code--shortcode"> <a class="anchor" href="#Documentation/CodingGuidelines-code--shortcode"></a><code>--short</code> </dt>
+<dd>
+<p>Emit output in the short-format.</p>
+<div class="literalblock">
+<div class="content">
+<pre>and avoid something like these overly verbose alternatives:</pre>
+</div>
+</div>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines-code--shortcode-1"> <a class="anchor" href="#Documentation/CodingGuidelines-code--shortcode-1"></a><code>--short</code> </dt>
+<dd>
+<p>Use this to emit output in the short-format.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines-code--shortcode-1-1"> <a class="anchor" href="#Documentation/CodingGuidelines-code--shortcode-1-1"></a><code>--short</code> </dt>
+<dd>
+<p>You can use this to get output in the short-format.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines-code--shortcode-1-1-1"> <a class="anchor" href="#Documentation/CodingGuidelines-code--shortcode-1-1-1"></a><code>--short</code> </dt>
+<dd>
+<p>A user who prefers shorter output could&#8230;&#8203;.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/CodingGuidelines-code--shortcode-1-1-1-1"> <a class="anchor" href="#Documentation/CodingGuidelines-code--shortcode-1-1-1-1"></a><code>--short</code> </dt>
+<dd>
+<p>Should a person and/or program want shorter output, he
+she/they/it can&#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>This practice often eliminates the need to involve human actors in
+your description, but it is a good practice regardless of the
+avoidance of gendered pronouns.</pre>
+</div>
+</div>
+</dd>
+</dl>
+</div>
+</li>
+<li>
+<p>When it becomes awkward to stick to this style, prefer "you" when
+addressing the hypothetical user, and possibly "we" when
+discussing how the program might react to the user.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>You can use this option instead of `--xyz`, but we might remove
+support for it in future versions.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while keeping in mind that you can probably be less verbose, e.g.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Use this instead of `--xyz`. This option might be removed in future
+versions.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>If you still need to refer to an example person that is
+third-person singular, you may resort to "singular they" to avoid
+"he/she/him/her", e.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>A contributor asks their upstream to pull from them.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Note that this sounds ungrammatical and unnatural to those who
+learned that "they" is only used for third-person plural, e.g.
+those who learn English as a second language in some parts of the
+world.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Every user-visible change should be reflected in the documentation.
+The same general rule as for code applies -- imitate the existing
+conventions.</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Markup:</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Literal parts (e.g. use of command-line options, command names,
+branch names, URLs, pathnames (files and directories), configuration and
+environment variables) must be typeset as verbatim (i.e. wrapped with
+backticks):
+  `--pretty=oneline`
+  `git rev-list`
+  `remote.pushDefault`
+  `http://git.example.com`
+  `.git/config`
+  `GIT_DIR`
+  `HEAD`
+  `umask`(2)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>An environment variable must be prefixed with "$" only when referring to its
+value and not when referring to the variable itself, in this case there is
+nothing to add except the backticks:
+  `GIT_DIR` is specified
+  `$GIT_DIR/hooks/pre-receive`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Word phrases enclosed in `backtick characters` are rendered literally
+and will not be further expanded. The use of `backticks` to achieve the
+previous rule means that literal examples should not use AsciiDoc
+escapes.
+  Correct:
+     `--pretty=oneline`
+  Incorrect:
+     `\--pretty=oneline`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Placeholders are spelled in lowercase and enclosed in
+angle brackets surrounded by underscores:
+  _&lt;file&gt;_
+  _&lt;commit&gt;_</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If a placeholder has multiple words, they are separated by dashes:
+  _&lt;new-branch-name&gt;_
+  _&lt;template-directory&gt;_</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>When needed, use a distinctive identifier for placeholders, usually
+made of a qualification and a type:
+  _&lt;git-dir&gt;_
+  _&lt;key-id&gt;_</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Git's Asciidoc processor has been tailored to treat backticked text
+as complex synopsis. When literal and placeholders are mixed, you can
+use the backtick notation which will take care of correctly typesetting
+the content.
+  `--jobs &lt;n&gt;`
+  `--sort=&lt;key&gt;`
+  `&lt;directory&gt;/.git`
+  `remote.&lt;name&gt;.mirror`
+  `ssh://[&lt;user&gt;@]&lt;host&gt;[:&lt;port&gt;]/&lt;path-to-git-repo&gt;`</pre>
+</div>
+</div>
+<div class="paragraph">
+<p>As a side effect, backquoted placeholders are correctly typeset, but
+this style is not recommended.</p>
+</div>
+<div class="paragraph">
+<p>Synopsis Syntax</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>The synopsis (a paragraph with [synopsis] attribute) is automatically
+formatted by the toolchain and does not need typesetting.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying command usage strings and synopsis sections in the manual
+pages:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Possibility of multiple occurrences is indicated by three dots:
+  &lt;file&gt;...
+  (One or more of &lt;file&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Optional parts are enclosed in square brackets:
+  [&lt;file&gt;...]
+  (Zero or more of &lt;file&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>An optional parameter needs to be typeset with unconstrained pairs
+  [&lt;repository&gt;]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>--exec-path[=&lt;path&gt;]
+(Option with an optional argument.  Note that the "=" is inside the
+brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[&lt;patch&gt;...]
+(Zero or more of &lt;patch&gt;.  Note that the dots are inside, not
+outside the brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Multiple alternatives are indicated with vertical bars:
+  [-q | --quiet]
+  [--utf8 | --no-utf8]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Use spacing around "|" token(s), but not immediately after opening or
+before closing a [] or () pair:
+  Do: [-q | --quiet]
+  Don't: [-q|--quiet]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Don't use spacing around "|" tokens when they're used to separate the
+alternate arguments of an option:
+   Do: --track[=(direct|inherit)]
+   Don't: --track[=(direct | inherit)]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Parentheses are used for grouping:
+  [(&lt;rev&gt;|&lt;range&gt;)...]
+  (Any number of either &lt;rev&gt; or &lt;range&gt;.  Parens are needed to make
+  it clear that "..." pertains to both &lt;rev&gt; and &lt;range&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[(-p &lt;parent&gt;)...]
+(Any number of option -p, each with one &lt;parent&gt; argument.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>git remote set-head &lt;name&gt; (-a|-d|&lt;branch&gt;)
+(One and only one of "-a", "-d" or "&lt;branch&gt;" _must_ (no square
+brackets) be provided.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>And a somewhat more contrived example:
+  --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+  Here "=" is outside the brackets, because "--diff-filter=" is a
+  valid usage.  "*" has its own pair of brackets, because it can
+  (optionally) be specified only when one or more of the letters is
+  also provided.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A note on notation:
+ Use 'git' (all lowercase) when talking about commands i.e. something
+ the user would type into a shell and use 'Git' (uppercase first letter)
+ when talking about the version control system and its properties.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If some place in the documentation needs to typeset a command usage
+example with inline substitutions, it is fine to use +monospaced and
+inline substituted text+ instead of `monospaced literal text`, and with
+the former, the part that should not get substituted must be
+quoted/escaped.</pre>
+</div>
+</div>
+</div>
+</div>
\ No newline at end of file
diff --git a/external/docs/content/docs/CodingGuidelines/2.8.6.html b/external/docs/content/docs/CodingGuidelines/2.8.6.html
new file mode 100644
index 0000000000..2bf7acafcf
--- /dev/null
+++ b/external/docs/content/docs/CodingGuidelines/2.8.6.html
@@ -0,0 +1,872 @@
+---
+### DO NOT EDIT! Generated by script/update-docs.rb
+
+category: manual
+section: documentation
+subsection: manual
+title: Git - CodingGuidelines Documentation
+docname: CodingGuidelines
+version: 2.8.6
+aliases:
+- "/docs/CodingGuidelines/2.8.6/index.html"
+---
+<div id="preamble">
+<div class="sectionbody">
+<div class="paragraph">
+<p>Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, a few rough rules are:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most importantly, we never say "It&#8217;s in POSIX; we&#8217;ll happily
+ignore your needs should your system not conform to it."
+We live in the real world.</p>
+</li>
+<li>
+<p>However, we often say "Let&#8217;s stay away from that construct,
+it&#8217;s not even in POSIX".</p>
+</li>
+<li>
+<p>In spite of the above two rules, we sometimes say "Although
+this is not in POSIX, it (is so convenient | makes the code
+much more readable | has other good characteristics) and
+practically all the platforms we care about support it, so
+let&#8217;s use it".</p>
+<div class="literalblock">
+<div class="content">
+<pre>Again, we live in the real world, and it is sometimes a
+judgement call, the decision based more on real world
+constraints people face than what the paper standard says.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Fixing style violations while working on a real change as a
+preparatory clean-up step is good, but otherwise avoid useless code
+churn for the sake of conforming to the style.</p>
+<div class="literalblock">
+<div class="content">
+<pre>"Once it _is_ in the tree, it's not really worth the patch noise to
+go and fix it up."
+Cf. http://article.gmane.org/gmane.linux.kernel/943020</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Make your code readable and sensible, and don&#8217;t try to be clever.</p>
+</div>
+<div class="paragraph">
+<p>As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the <em>local</em>
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn&#8217;t match the overall style of existing code).</p>
+</div>
+<div class="paragraph">
+<p>But if you must have a list of rules, here they are.</p>
+</div>
+<div class="paragraph">
+<p>For shell scripts specifically (not exhaustive):</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs for indentation.</p>
+</li>
+<li>
+<p>Case arms are indented at the same depth as case and esac lines,
+like this:</p>
+<div class="literalblock">
+<div class="content">
+<pre>case "$variable" in
+pattern1)
+	do this
+	;;
+pattern2)
+	do that
+	;;
+esac</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Redirection operators should be written with space before, but no
+space after them.  In other words, write <em>echo test &gt;"$file"</em>
+instead of <em>echo test&gt; $file</em> or <em>echo test &gt; $file</em>.  Note that
+even though it is not required by POSIX to double-quote the
+redirection target in a variable (as shown above), our code does so
+because some versions of bash issue a warning without the quotes.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+cat hello &gt; world &lt; universe
+echo hello &gt;$world</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+cat hello &gt;world &lt;universe
+echo hello &gt;"$world"</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer $( &#8230;&#8203; ) for command substitution; unlike ``, it
+properly nests.  It should have been the way Bourne spelled
+it from day one, but unfortunately isn&#8217;t.</p>
+</li>
+<li>
+<p>If you want to find out if a command is available on the user&#8217;s
+$PATH, you should use <em>type &lt;command&gt;</em>, instead of <em>which &lt;command&gt;</em>.
+The output of <em>which</em> is not machine parseable and its exit code
+is not reliable across platforms.</p>
+</li>
+<li>
+<p>We use POSIX compliant parameter substitutions and avoid bashisms;
+namely:</p>
+</li>
+<li>
+<p>We use ${parameter-word} and its [-=?+] siblings, and their
+colon&#8217;ed "unset or null" form.</p>
+</li>
+<li>
+<p>We use ${parameter#word} and its [#%] siblings, and their
+doubled "longest matching" form.</p>
+</li>
+<li>
+<p>No "Substring Expansion" ${parameter:offset:length}.</p>
+</li>
+<li>
+<p>No shell arrays.</p>
+</li>
+<li>
+<p>No strlen ${#parameter}.</p>
+</li>
+<li>
+<p>No pattern replacement ${parameter/pattern/string}.</p>
+</li>
+<li>
+<p>We use Arithmetic Expansion $&#8230;&#8203;.</p>
+</li>
+<li>
+<p>Inside Arithmetic Expansion, spell shell variables with $ in front
+of them, as some shells do not grok $x while accepting $$x
+just fine (e.g. dash older than 0.5.4).</p>
+</li>
+<li>
+<p>We do not use Process Substitution &lt;(list) or &gt;(list).</p>
+</li>
+<li>
+<p>Do not write control structures on a single line with semicolon.
+"then" should be on the next line for if statements, and "do"
+should be on the next line for "while" and "for".</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+if test -f hello; then
+	do this
+fi</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+if test -f hello
+then
+	do this
+fi</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer "test" over "[ &#8230;&#8203; ]".</p>
+</li>
+<li>
+<p>We do not write the noiseword "function" in front of shell
+functions.</p>
+</li>
+<li>
+<p>We prefer a space between the function name and the parentheses,
+and no space inside the parentheses. The opening "{" should also
+be on the same line.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+my_function(){
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+my_function () {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+[::], [==], or [..]) for portability.</p>
+</li>
+<li>
+<p>We do not use \{m,n\};</p>
+</li>
+<li>
+<p>We do not use -E;</p>
+</li>
+<li>
+<p>We do not use ? or + (which are \{0,1\} and \{1,\}
+respectively in BRE) but that goes without saying as these
+are ERE elements not BRE (note that \? and \+ are not even part
+of BRE&#8201;&#8212;&#8201;making them accessible from BRE is a GNU extension).</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers in git-sh-i18n to make the user
+interface translatable. See "Marking strings for translation" in
+po/README.</p>
+</li>
+<li>
+<p>We do not write our "test" command with "-a" and "-o" and use "&amp;&amp;"
+or "||" to concatenate multiple "test" commands instead, because
+the use of "-a/-o" is often error-prone.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" -a "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is buggy and breaks when $x is "=", but</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" &amp;&amp; test "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>does not have such a problem.</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For C programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs to indent, and interpret tabs as taking up to
+8 spaces.</p>
+</li>
+<li>
+<p>We try to keep to at most 80 characters per line.</p>
+</li>
+<li>
+<p>As a Git developer we assume you have a reasonably modern compiler
+and we recommend you to enable the DEVELOPER makefile knob to
+ensure your patch is clear of all compiler warnings we care about,
+by e.g. "echo DEVELOPER=1 &gt;&gt;config.mak".</p>
+</li>
+<li>
+<p>We try to support a wide range of C compilers to compile Git with,
+including old ones. That means that you should not use C99
+initializers, even if a lot of compilers grok it.</p>
+</li>
+<li>
+<p>Variables have to be declared at the beginning of the block.</p>
+</li>
+<li>
+<p>NULL pointers shall be written as NULL, not as 0.</p>
+</li>
+<li>
+<p>When declaring pointers, the star sides with the variable
+name, i.e. "char <strong>string", not "char</strong> string" or
+"char * string".  This makes it easier to understand code
+like "char *string, c;".</p>
+</li>
+<li>
+<p>Use whitespace around operators and keywords, but not inside
+parentheses and not around functions. So:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      while (condition)
+func(bar + 1);</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>      while( condition )
+func (bar+1);</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We avoid using braces unnecessarily.  I.e.</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (bla) {
+	x = 1;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is frowned upon.  A gray area is when the statement extends
+over a few lines, and/or you have a lengthy comment atop of
+it.  Also, like in the Linux kernel, if there is a long list
+of "else if" statements, it can make sense to add braces to
+single line blocks.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments in the condition of an "if" statement.</p>
+</li>
+<li>
+<p>Try to make your code understandable.  You may put comments
+in, but comments invariably tend to stale out when the code
+they were describing changes.  Often splitting a function
+into two makes the intention of the code much clearer.</p>
+</li>
+<li>
+<p>Multi-line comments include their delimiters on separate lines from
+the text.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * A very long
+ * multi-line comment.
+ */</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Note however that a comment that explains a translatable string to
+translators uses a convention of starting with a magic token
+"TRANSLATORS: " immediately after the opening delimiter, even when
+it spans multiple lines.  We do not add an asterisk at the beginning
+of each line, either.  E.g.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>/* TRANSLATORS: here is a comment that explains the string
+   to be translated, that follows immediately after it */
+_("Here is a translatable string explained by the above.");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Double negation is often harder to understand than no negation
+at all.</p>
+</li>
+<li>
+<p>There are two schools of thought when it comes to comparison,
+especially inside a loop. Some people prefer to have the less stable
+value on the left hand side and the more stable value on the right hand
+side, e.g. if you have a loop that counts variable i down to the
+lower bound,</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (i &gt; lower_bound) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Other people prefer to have the textual order of values match the
+actual order of values in their comparison, so that they can
+mentally draw a number line from left to right and place these
+values in order, i.e.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while (lower_bound &lt; i) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  However, the more "stable" the
+stable side becomes, the more we tend to prefer the former
+(comparison with a constant, "i &gt; 0", is an extreme example).
+Just do not mix styles in the same part of the code and mimic
+existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>There are two schools of thought when it comes to splitting a long
+logical line into multiple lines.  Some people push the second and
+subsequent lines far enough to the right with tabs and align them:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+              ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to align the second and the subsequent
+lines with the column immediately inside the opening parenthesis,
+with tabs and spaces, following our "tabstop is always a multiple
+of 8" convention:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+           ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  Again, just do not mix styles in
+the same part of the code and mimic existing styles in the
+neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, some people change line before
+a binary operator, so that the result looks like a parse tree when
+you turn your head 90-degrees counterclockwise:</p>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to
+|| span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to leave the operator at the end of the
+line:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, but we tend to use the latter more, unless the
+expression gets fairly complex, in which case the former tends to
+be easier to read.  Again, just do not mix styles in the same part
+of the code and mimic existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, with everything else being
+equal, it is preferable to split after the operator at higher
+level in the parse tree.  That is, this is more preferable:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable * that_is_used_in +
+    a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>than</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable *
+    that_is_used_in + a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Some clever tricks, like using the !! operator with arithmetic
+constructs, can be extremely confusing to others.  Avoid them,
+unless there is a compelling reason to use them.</p>
+</li>
+<li>
+<p>Use the API.  No, really.  We have a strbuf (variable length
+string), several arrays with the ALLOC_GROW() macro, a
+string_list for sorted string lists, a hash map (mapping struct
+objects) named "struct decorate", amongst other things.</p>
+</li>
+<li>
+<p>When you come up with an API, document it.</p>
+</li>
+<li>
+<p>The first #include in C files, except in platform specific compat/
+implementations, must be either "git-compat-util.h", "cache.h" or
+"builtin.h".  You do not have to include more than one of these.</p>
+</li>
+<li>
+<p>A C file must directly include the header files that declare the
+functions and the types it uses, except for the functions and types
+that are made available to it by including one of the header files
+it must include by the previous rule.</p>
+</li>
+<li>
+<p>If you are planning a new command, consider writing it in shell
+or perl first, so that changes in semantics can be easily
+changed and discussed.  Many Git commands started out like
+that, and a few are still scripts.</p>
+</li>
+<li>
+<p>Avoid introducing a new dependency into Git. This means you
+usually should stay away from scripting languages not already
+used in the Git core command set (unless your command is clearly
+separate from it, such as an importer to convert random-scm-X
+repositories to Git).</p>
+</li>
+<li>
+<p>When we pass &lt;string, length&gt; pair to functions, we should try to
+pass them in that order.</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers to make the user interface
+translatable. See "Marking strings for translation" in po/README.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Perl programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most of the C guidelines above apply.</p>
+</li>
+<li>
+<p>We try to support Perl 5.8 and later ("use Perl 5.008").</p>
+</li>
+<li>
+<p>use strict and use warnings are strongly preferred.</p>
+</li>
+<li>
+<p>Don&#8217;t overuse statement modifiers unless using them makes the
+result easier to follow.</p>
+<div class="olist lowerroman">
+<ol class="lowerroman" type="i">
+<li>
+<p>do something &#8230;&#8203;
+do_this() unless (condition);</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>is more readable than:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>do something &#8230;&#8203;
+unless (condition) {
+	do_this();
+}</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>*only* when the condition is so rare that do_this() will be almost
+always called.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments inside "if ()" conditions.</p>
+</li>
+<li>
+<p>Learn and use Git.pm if you need that functionality.</p>
+</li>
+<li>
+<p>For Emacs, it&#8217;s useful to put the following in
+GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode:</p>
+<div class="literalblock">
+<div class="content">
+<pre>;; note the first part is useful for C editing, too
+((nil . ((indent-tabs-mode . t)
+              (tab-width . 8)
+              (fill-column . 80)))
+ (cperl-mode . ((cperl-indent-level . 8)
+                (cperl-extra-newline-before-brace . nil)
+                (cperl-merge-trailing-else . t))))</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Python scripts:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We follow PEP-8 (<a href="http://www.python.org/dev/peps/pep-0008/" class="bare">http://www.python.org/dev/peps/pep-0008/</a>).</p>
+</li>
+<li>
+<p>As a minimum, we aim to be compatible with Python 2.6 and 2.7.</p>
+</li>
+<li>
+<p>Where required libraries do not restrict us to Python 2, we try to
+also be compatible with Python 3.1 and later.</p>
+</li>
+<li>
+<p>When you must differentiate between Unicode literals and byte string
+literals, it is OK to use the <em>b</em> prefix.  Even though the Python
+documentation for version 2.6 does not mention this prefix, it has
+been supported since version 2.6.0.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Error Messages</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Do not end error messages with a full stop.</p>
+</li>
+<li>
+<p>Do not capitalize ("unable to open %s", not "Unable to open %s")</p>
+</li>
+<li>
+<p>Say what the error is first ("cannot open %s", not "%s: cannot open")</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Externally Visible Names</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>For configuration variable names, follow the existing convention:</p>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>The section name indicates the affected subsystem.</p>
+</li>
+<li>
+<p>The subsection name, if any, indicates which of an unbounded set
+of things to set the value for.</p>
+</li>
+<li>
+<p>The variable name describes the effect of tweaking this knob.</p>
+<div class="literalblock">
+<div class="content">
+<pre>The section and variable names that consist of multiple words are
+formed by concatenating the words without punctuations (e.g. `-`),
+and are broken using bumpyCaps in documentation as a hint to the
+reader.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>When choosing the variable namespace, do not use variable name for
+specifying possibly unbounded set of things, most notably anything
+an end user can freely come up with (e.g. branch names).  Instead,
+use subsection names or variable values, like the existing variable
+branch.&lt;name&gt;.description does.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Writing Documentation:</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Most (if not all) of the documentation pages are written in the
+AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+processed into HTML and manpages (e.g. git.html and git.1 in the
+same directory).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>The documentation liberally mixes US and UK English (en_US/UK)
+norms for spelling and grammar, which is somewhat unfortunate.
+In an ideal world, it would have been better if it consistently
+used only one and not the other, and we would have picked en_US
+(if you wish to correct the English of some of the existing
+documentation, please see the documentation-related advice in the
+Documentation/SubmittingPatches file).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Every user-visible change should be reflected in the documentation.
+The same general rule as for code applies -- imitate the existing
+conventions.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying command usage strings and synopsis sections in the manual
+pages:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Placeholders are spelled in lowercase and enclosed in angle brackets:
+  &lt;file&gt;
+  --sort=&lt;key&gt;
+  --abbrev[=&lt;n&gt;]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If a placeholder has multiple words, they are separated by dashes:
+  &lt;new-branch-name&gt;
+  --template=&lt;template-directory&gt;</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Possibility of multiple occurrences is indicated by three dots:
+  &lt;file&gt;...
+  (One or more of &lt;file&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Optional parts are enclosed in square brackets:
+  [&lt;extra&gt;]
+  (Zero or one &lt;extra&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>--exec-path[=&lt;path&gt;]
+(Option with an optional argument.  Note that the "=" is inside the
+brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[&lt;patch&gt;...]
+(Zero or more of &lt;patch&gt;.  Note that the dots are inside, not
+outside the brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Multiple alternatives are indicated with vertical bars:
+  [-q | --quiet]
+  [--utf8 | --no-utf8]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Parentheses are used for grouping:
+  [(&lt;rev&gt; | &lt;range&gt;)...]
+  (Any number of either &lt;rev&gt; or &lt;range&gt;.  Parens are needed to make
+  it clear that "..." pertains to both &lt;rev&gt; and &lt;range&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[(-p &lt;parent&gt;)...]
+(Any number of option -p, each with one &lt;parent&gt; argument.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>git remote set-head &lt;name&gt; (-a | -d | &lt;branch&gt;)
+(One and only one of "-a", "-d" or "&lt;branch&gt;" _must_ (no square
+brackets) be provided.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>And a somewhat more contrived example:
+  --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+  Here "=" is outside the brackets, because "--diff-filter=" is a
+  valid usage.  "*" has its own pair of brackets, because it can
+  (optionally) be specified only when one or more of the letters is
+  also provided.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A note on notation:
+ Use 'git' (all lowercase) when talking about commands i.e. something
+ the user would type into a shell and use 'Git' (uppercase first letter)
+ when talking about the version control system and its properties.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying paragraphs or option/command explanations that contain options
+or commands:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Literal examples (e.g. use of command-line options, command names, and
+configuration variables) are typeset in monospace, and if you can use
+`backticks around word phrases`, do so.
+  `--pretty=oneline`
+  `git rev-list`
+  `remote.pushDefault`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Word phrases enclosed in `backtick characters` are rendered literally
+and will not be further expanded. The use of `backticks` to achieve the
+previous rule means that literal examples should not use AsciiDoc
+escapes.
+  Correct:
+     `--pretty=oneline`
+  Incorrect:
+     `\--pretty=oneline`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If some place in the documentation needs to typeset a command usage
+example with inline substitutions, it is fine to use +monospaced and
+inline substituted text+ instead of `monospaced literal text`, and with
+the former, the part that should not get substituted must be
+quoted/escaped.</pre>
+</div>
+</div>
+</div>
+</div>
\ No newline at end of file
diff --git a/external/docs/content/docs/CodingGuidelines/2.9.5.html b/external/docs/content/docs/CodingGuidelines/2.9.5.html
new file mode 100644
index 0000000000..ebe57f98cf
--- /dev/null
+++ b/external/docs/content/docs/CodingGuidelines/2.9.5.html
@@ -0,0 +1,884 @@
+---
+### DO NOT EDIT! Generated by script/update-docs.rb
+
+category: manual
+section: documentation
+subsection: manual
+title: Git - CodingGuidelines Documentation
+docname: CodingGuidelines
+version: 2.9.5
+aliases:
+- "/docs/CodingGuidelines/2.9.5/index.html"
+- "/docs/CodingGuidelines/2.10.5/index.html"
+---
+<div id="preamble">
+<div class="sectionbody">
+<div class="paragraph">
+<p>Like other projects, we also have some guidelines to keep to the
+code.  For Git in general, a few rough rules are:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most importantly, we never say "It&#8217;s in POSIX; we&#8217;ll happily
+ignore your needs should your system not conform to it."
+We live in the real world.</p>
+</li>
+<li>
+<p>However, we often say "Let&#8217;s stay away from that construct,
+it&#8217;s not even in POSIX".</p>
+</li>
+<li>
+<p>In spite of the above two rules, we sometimes say "Although
+this is not in POSIX, it (is so convenient | makes the code
+much more readable | has other good characteristics) and
+practically all the platforms we care about support it, so
+let&#8217;s use it".</p>
+<div class="literalblock">
+<div class="content">
+<pre>Again, we live in the real world, and it is sometimes a
+judgement call, the decision based more on real world
+constraints people face than what the paper standard says.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Fixing style violations while working on a real change as a
+preparatory clean-up step is good, but otherwise avoid useless code
+churn for the sake of conforming to the style.</p>
+<div class="literalblock">
+<div class="content">
+<pre>"Once it _is_ in the tree, it's not really worth the patch noise to
+go and fix it up."
+Cf. http://article.gmane.org/gmane.linux.kernel/943020</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Make your code readable and sensible, and don&#8217;t try to be clever.</p>
+</div>
+<div class="paragraph">
+<p>As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are
+contributing to). It is always preferable to match the <em>local</em>
+convention. New code added to Git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn&#8217;t match the overall style of existing code).</p>
+</div>
+<div class="paragraph">
+<p>But if you must have a list of rules, here they are.</p>
+</div>
+<div class="paragraph">
+<p>For shell scripts specifically (not exhaustive):</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs for indentation.</p>
+</li>
+<li>
+<p>Case arms are indented at the same depth as case and esac lines,
+like this:</p>
+<div class="literalblock">
+<div class="content">
+<pre>case "$variable" in
+pattern1)
+	do this
+	;;
+pattern2)
+	do that
+	;;
+esac</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Redirection operators should be written with space before, but no
+space after them.  In other words, write <em>echo test &gt;"$file"</em>
+instead of <em>echo test&gt; $file</em> or <em>echo test &gt; $file</em>.  Note that
+even though it is not required by POSIX to double-quote the
+redirection target in a variable (as shown above), our code does so
+because some versions of bash issue a warning without the quotes.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+cat hello &gt; world &lt; universe
+echo hello &gt;$world</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+cat hello &gt;world &lt;universe
+echo hello &gt;"$world"</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer $( &#8230;&#8203; ) for command substitution; unlike ``, it
+properly nests.  It should have been the way Bourne spelled
+it from day one, but unfortunately isn&#8217;t.</p>
+</li>
+<li>
+<p>If you want to find out if a command is available on the user&#8217;s
+$PATH, you should use <em>type &lt;command&gt;</em>, instead of <em>which &lt;command&gt;</em>.
+The output of <em>which</em> is not machine parseable and its exit code
+is not reliable across platforms.</p>
+</li>
+<li>
+<p>We use POSIX compliant parameter substitutions and avoid bashisms;
+namely:</p>
+</li>
+<li>
+<p>We use ${parameter-word} and its [-=?+] siblings, and their
+colon&#8217;ed "unset or null" form.</p>
+</li>
+<li>
+<p>We use ${parameter#word} and its [#%] siblings, and their
+doubled "longest matching" form.</p>
+</li>
+<li>
+<p>No "Substring Expansion" ${parameter:offset:length}.</p>
+</li>
+<li>
+<p>No shell arrays.</p>
+</li>
+<li>
+<p>No strlen ${#parameter}.</p>
+</li>
+<li>
+<p>No pattern replacement ${parameter/pattern/string}.</p>
+</li>
+<li>
+<p>We use Arithmetic Expansion $&#8230;&#8203;.</p>
+</li>
+<li>
+<p>Inside Arithmetic Expansion, spell shell variables with $ in front
+of them, as some shells do not grok $x while accepting $$x
+just fine (e.g. dash older than 0.5.4).</p>
+</li>
+<li>
+<p>We do not use Process Substitution &lt;(list) or &gt;(list).</p>
+</li>
+<li>
+<p>Do not write control structures on a single line with semicolon.
+"then" should be on the next line for if statements, and "do"
+should be on the next line for "while" and "for".</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+if test -f hello; then
+	do this
+fi</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+if test -f hello
+then
+	do this
+fi</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We prefer "test" over "[ &#8230;&#8203; ]".</p>
+</li>
+<li>
+<p>We do not write the noiseword "function" in front of shell
+functions.</p>
+</li>
+<li>
+<p>We prefer a space between the function name and the parentheses,
+and no space inside the parentheses. The opening "{" should also
+be on the same line.</p>
+<div class="literalblock">
+<div class="content">
+<pre>(incorrect)
+my_function(){
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>(correct)
+my_function () {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+[::], [==], or [..]) for portability.</p>
+</li>
+<li>
+<p>We do not use \{m,n\};</p>
+</li>
+<li>
+<p>We do not use -E;</p>
+</li>
+<li>
+<p>We do not use ? or + (which are \{0,1\} and \{1,\}
+respectively in BRE) but that goes without saying as these
+are ERE elements not BRE (note that \? and \+ are not even part
+of BRE&#8201;&#8212;&#8201;making them accessible from BRE is a GNU extension).</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers in git-sh-i18n to make the user
+interface translatable. See "Marking strings for translation" in
+po/README.</p>
+</li>
+<li>
+<p>We do not write our "test" command with "-a" and "-o" and use "&amp;&amp;"
+or "||" to concatenate multiple "test" commands instead, because
+the use of "-a/-o" is often error-prone.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" -a "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is buggy and breaks when $x is "=", but</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>test -n "$x" &amp;&amp; test "$a" = "$b"</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>does not have such a problem.</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For C programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We use tabs to indent, and interpret tabs as taking up to
+8 spaces.</p>
+</li>
+<li>
+<p>We try to keep to at most 80 characters per line.</p>
+</li>
+<li>
+<p>As a Git developer we assume you have a reasonably modern compiler
+and we recommend you to enable the DEVELOPER makefile knob to
+ensure your patch is clear of all compiler warnings we care about,
+by e.g. "echo DEVELOPER=1 &gt;&gt;config.mak".</p>
+</li>
+<li>
+<p>We try to support a wide range of C compilers to compile Git with,
+including old ones. That means that you should not use C99
+initializers, even if a lot of compilers grok it.</p>
+</li>
+<li>
+<p>Variables have to be declared at the beginning of the block.</p>
+</li>
+<li>
+<p>NULL pointers shall be written as NULL, not as 0.</p>
+</li>
+<li>
+<p>When declaring pointers, the star sides with the variable
+name, i.e. "char <strong>string", not "char</strong> string" or
+"char * string".  This makes it easier to understand code
+like "char *string, c;".</p>
+</li>
+<li>
+<p>Use whitespace around operators and keywords, but not inside
+parentheses and not around functions. So:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      while (condition)
+func(bar + 1);</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>and not:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>      while( condition )
+func (bar+1);</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We avoid using braces unnecessarily.  I.e.</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (bla) {
+	x = 1;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>is frowned upon.  A gray area is when the statement extends
+over a few lines, and/or you have a lengthy comment atop of
+it.  Also, like in the Linux kernel, if there is a long list
+of "else if" statements, it can make sense to add braces to
+single line blocks.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments in the condition of an "if" statement.</p>
+</li>
+<li>
+<p>Try to make your code understandable.  You may put comments
+in, but comments invariably tend to stale out when the code
+they were describing changes.  Often splitting a function
+into two makes the intention of the code much clearer.</p>
+</li>
+<li>
+<p>Multi-line comments include their delimiters on separate lines from
+the text.  E.g.</p>
+<div class="literalblock">
+<div class="content">
+<pre>/*
+ * A very long
+ * multi-line comment.
+ */</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Note however that a comment that explains a translatable string to
+translators uses a convention of starting with a magic token
+"TRANSLATORS: " immediately after the opening delimiter, even when
+it spans multiple lines.  We do not add an asterisk at the beginning
+of each line, either.  E.g.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>/* TRANSLATORS: here is a comment that explains the string
+   to be translated, that follows immediately after it */
+_("Here is a translatable string explained by the above.");</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Double negation is often harder to understand than no negation
+at all.</p>
+</li>
+<li>
+<p>There are two schools of thought when it comes to comparison,
+especially inside a loop. Some people prefer to have the less stable
+value on the left hand side and the more stable value on the right hand
+side, e.g. if you have a loop that counts variable i down to the
+lower bound,</p>
+<div class="literalblock">
+<div class="content">
+<pre>while (i &gt; lower_bound) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Other people prefer to have the textual order of values match the
+actual order of values in their comparison, so that they can
+mentally draw a number line from left to right and place these
+values in order, i.e.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while (lower_bound &lt; i) {
+	do something;
+	i--;
+}</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  However, the more "stable" the
+stable side becomes, the more we tend to prefer the former
+(comparison with a constant, "i &gt; 0", is an extreme example).
+Just do not mix styles in the same part of the code and mimic
+existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>There are two schools of thought when it comes to splitting a long
+logical line into multiple lines.  Some people push the second and
+subsequent lines far enough to the right with tabs and align them:</p>
+<div class="literalblock">
+<div class="content">
+<pre>      if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+              ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to align the second and the subsequent
+lines with the column immediately inside the opening parenthesis,
+with tabs and spaces, following our "tabstop is always a multiple
+of 8" convention:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of ||
+the_source_text) {
+           ...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, and we use both.  Again, just do not mix styles in
+the same part of the code and mimic existing styles in the
+neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, some people change line before
+a binary operator, so that the result looks like a parse tree when
+you turn your head 90-degrees counterclockwise:</p>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to
+|| span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>while other people prefer to leave the operator at the end of the
+line:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>   if (the_beginning_of_a_very_long_expression_that_has_to ||
+span_more_than_a_single_line_of_the_source_text) {</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Both are valid, but we tend to use the latter more, unless the
+expression gets fairly complex, in which case the former tends to
+be easier to read.  Again, just do not mix styles in the same part
+of the code and mimic existing styles in the neighbourhood.</pre>
+</div>
+</div>
+</li>
+<li>
+<p>When splitting a long logical line, with everything else being
+equal, it is preferable to split after the operator at higher
+level in the parse tree.  That is, this is more preferable:</p>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable * that_is_used_in +
+    a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>than</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>if (a_very_long_variable *
+    that_is_used_in + a_very_long_expression) {
+	...</pre>
+</div>
+</div>
+</li>
+<li>
+<p>Some clever tricks, like using the !! operator with arithmetic
+constructs, can be extremely confusing to others.  Avoid them,
+unless there is a compelling reason to use them.</p>
+</li>
+<li>
+<p>Use the API.  No, really.  We have a strbuf (variable length
+string), several arrays with the ALLOC_GROW() macro, a
+string_list for sorted string lists, a hash map (mapping struct
+objects) named "struct decorate", amongst other things.</p>
+</li>
+<li>
+<p>When you come up with an API, document it.</p>
+</li>
+<li>
+<p>The first #include in C files, except in platform specific compat/
+implementations, must be either "git-compat-util.h", "cache.h" or
+"builtin.h".  You do not have to include more than one of these.</p>
+</li>
+<li>
+<p>A C file must directly include the header files that declare the
+functions and the types it uses, except for the functions and types
+that are made available to it by including one of the header files
+it must include by the previous rule.</p>
+</li>
+<li>
+<p>If you are planning a new command, consider writing it in shell
+or perl first, so that changes in semantics can be easily
+changed and discussed.  Many Git commands started out like
+that, and a few are still scripts.</p>
+</li>
+<li>
+<p>Avoid introducing a new dependency into Git. This means you
+usually should stay away from scripting languages not already
+used in the Git core command set (unless your command is clearly
+separate from it, such as an importer to convert random-scm-X
+repositories to Git).</p>
+</li>
+<li>
+<p>When we pass &lt;string, length&gt; pair to functions, we should try to
+pass them in that order.</p>
+</li>
+<li>
+<p>Use Git&#8217;s gettext wrappers to make the user interface
+translatable. See "Marking strings for translation" in po/README.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Perl programs:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Most of the C guidelines above apply.</p>
+</li>
+<li>
+<p>We try to support Perl 5.8 and later ("use Perl 5.008").</p>
+</li>
+<li>
+<p>use strict and use warnings are strongly preferred.</p>
+</li>
+<li>
+<p>Don&#8217;t overuse statement modifiers unless using them makes the
+result easier to follow.</p>
+<div class="olist lowerroman">
+<ol class="lowerroman" type="i">
+<li>
+<p>do something &#8230;&#8203;
+do_this() unless (condition);</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>is more readable than:</pre>
+</div>
+</div>
+</li>
+<li>
+<p>do something &#8230;&#8203;
+unless (condition) {
+	do_this();
+}</p>
+</li>
+<li>
+<p>do something else &#8230;&#8203;</p>
+<div class="literalblock">
+<div class="content">
+<pre>*only* when the condition is so rare that do_this() will be almost
+always called.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+<li>
+<p>We try to avoid assignments inside "if ()" conditions.</p>
+</li>
+<li>
+<p>Learn and use Git.pm if you need that functionality.</p>
+</li>
+<li>
+<p>For Emacs, it&#8217;s useful to put the following in
+GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode:</p>
+<div class="literalblock">
+<div class="content">
+<pre>;; note the first part is useful for C editing, too
+((nil . ((indent-tabs-mode . t)
+              (tab-width . 8)
+              (fill-column . 80)))
+ (cperl-mode . ((cperl-indent-level . 8)
+                (cperl-extra-newline-before-brace . nil)
+                (cperl-merge-trailing-else . t))))</pre>
+</div>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For Python scripts:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>We follow PEP-8 (<a href="http://www.python.org/dev/peps/pep-0008/" class="bare">http://www.python.org/dev/peps/pep-0008/</a>).</p>
+</li>
+<li>
+<p>As a minimum, we aim to be compatible with Python 2.6 and 2.7.</p>
+</li>
+<li>
+<p>Where required libraries do not restrict us to Python 2, we try to
+also be compatible with Python 3.1 and later.</p>
+</li>
+<li>
+<p>When you must differentiate between Unicode literals and byte string
+literals, it is OK to use the <em>b</em> prefix.  Even though the Python
+documentation for version 2.6 does not mention this prefix, it has
+been supported since version 2.6.0.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Error Messages</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Do not end error messages with a full stop.</p>
+</li>
+<li>
+<p>Do not capitalize ("unable to open %s", not "Unable to open %s")</p>
+</li>
+<li>
+<p>Say what the error is first ("cannot open %s", not "%s: cannot open")</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Externally Visible Names</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>For configuration variable names, follow the existing convention:</p>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>The section name indicates the affected subsystem.</p>
+</li>
+<li>
+<p>The subsection name, if any, indicates which of an unbounded set
+of things to set the value for.</p>
+</li>
+<li>
+<p>The variable name describes the effect of tweaking this knob.</p>
+<div class="literalblock">
+<div class="content">
+<pre>The section and variable names that consist of multiple words are
+formed by concatenating the words without punctuations (e.g. `-`),
+and are broken using bumpyCaps in documentation as a hint to the
+reader.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>When choosing the variable namespace, do not use variable name for
+specifying possibly unbounded set of things, most notably anything
+an end user can freely come up with (e.g. branch names).  Instead,
+use subsection names or variable values, like the existing variable
+branch.&lt;name&gt;.description does.</pre>
+</div>
+</div>
+</li>
+</ol>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Writing Documentation:</p>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Most (if not all) of the documentation pages are written in the
+AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+processed into HTML and manpages (e.g. git.html and git.1 in the
+same directory).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>The documentation liberally mixes US and UK English (en_US/UK)
+norms for spelling and grammar, which is somewhat unfortunate.
+In an ideal world, it would have been better if it consistently
+used only one and not the other, and we would have picked en_US
+(if you wish to correct the English of some of the existing
+documentation, please see the documentation-related advice in the
+Documentation/SubmittingPatches file).</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Every user-visible change should be reflected in the documentation.
+The same general rule as for code applies -- imitate the existing
+conventions.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying command usage strings and synopsis sections in the manual
+pages:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Placeholders are spelled in lowercase and enclosed in angle brackets:
+  &lt;file&gt;
+  --sort=&lt;key&gt;
+  --abbrev[=&lt;n&gt;]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If a placeholder has multiple words, they are separated by dashes:
+  &lt;new-branch-name&gt;
+  --template=&lt;template-directory&gt;</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Possibility of multiple occurrences is indicated by three dots:
+  &lt;file&gt;...
+  (One or more of &lt;file&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Optional parts are enclosed in square brackets:
+  [&lt;extra&gt;]
+  (Zero or one &lt;extra&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>--exec-path[=&lt;path&gt;]
+(Option with an optional argument.  Note that the "=" is inside the
+brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[&lt;patch&gt;...]
+(Zero or more of &lt;patch&gt;.  Note that the dots are inside, not
+outside the brackets.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Multiple alternatives are indicated with vertical bars:
+  [-q | --quiet]
+  [--utf8 | --no-utf8]</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Parentheses are used for grouping:
+  [(&lt;rev&gt; | &lt;range&gt;)...]
+  (Any number of either &lt;rev&gt; or &lt;range&gt;.  Parens are needed to make
+  it clear that "..." pertains to both &lt;rev&gt; and &lt;range&gt;.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>[(-p &lt;parent&gt;)...]
+(Any number of option -p, each with one &lt;parent&gt; argument.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>git remote set-head &lt;name&gt; (-a | -d | &lt;branch&gt;)
+(One and only one of "-a", "-d" or "&lt;branch&gt;" _must_ (no square
+brackets) be provided.)</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>And a somewhat more contrived example:
+  --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
+  Here "=" is outside the brackets, because "--diff-filter=" is a
+  valid usage.  "*" has its own pair of brackets, because it can
+  (optionally) be specified only when one or more of the letters is
+  also provided.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A note on notation:
+ Use 'git' (all lowercase) when talking about commands i.e. something
+ the user would type into a shell and use 'Git' (uppercase first letter)
+ when talking about the version control system and its properties.</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>A few commented examples follow to provide reference when writing or
+modifying paragraphs or option/command explanations that contain options
+or commands:</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Literal examples (e.g. use of command-line options, command names,
+branch names, configuration and environment variables) must be
+typeset in monospace (i.e. wrapped with backticks):
+  `--pretty=oneline`
+  `git rev-list`
+  `remote.pushDefault`
+  `GIT_DIR`
+  `HEAD`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>An environment variable must be prefixed with "$" only when referring to its
+value and not when referring to the variable itself, in this case there is
+nothing to add except the backticks:
+  `GIT_DIR` is specified
+  `$GIT_DIR/hooks/pre-receive`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>Word phrases enclosed in `backtick characters` are rendered literally
+and will not be further expanded. The use of `backticks` to achieve the
+previous rule means that literal examples should not use AsciiDoc
+escapes.
+  Correct:
+     `--pretty=oneline`
+  Incorrect:
+     `\--pretty=oneline`</pre>
+</div>
+</div>
+<div class="literalblock">
+<div class="content">
+<pre>If some place in the documentation needs to typeset a command usage
+example with inline substitutions, it is fine to use +monospaced and
+inline substituted text+ instead of `monospaced literal text`, and with
+the former, the part that should not get substituted must be
+quoted/escaped.</pre>
+</div>
+</div>
+</div>
+</div>
\ No newline at end of file
diff --git a/external/docs/content/docs/ReviewingGuidelines.html b/external/docs/content/docs/ReviewingGuidelines.html
new file mode 100644
index 0000000000..50663cd0f2
--- /dev/null
+++ b/external/docs/content/docs/ReviewingGuidelines.html
@@ -0,0 +1,249 @@
+---
+### DO NOT EDIT! Generated by script/update-docs.rb
+
+category: manual
+section: documentation
+subsection: manual
+title: Git - ReviewingGuidelines Documentation
+docname: ReviewingGuidelines
+version: 2.47.0
+latest-changes: 2.47.0
+aliases:
+- "/docs/ReviewingGuidelines/index.html"
+---
+<div class="sect1">
+<h2 id="_introduction"><a class="anchor" href="#_introduction"></a>Introduction</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>The Git development community is a widely distributed, diverse, ever-changing
+group of individuals. Asynchronous communication via the Git mailing list poses
+unique challenges when reviewing or discussing patches. This document contains
+some guiding principles and helpful tools you can use to make your reviews both
+more efficient for yourself and more effective for other contributors.</p>
+</div>
+<div class="paragraph">
+<p>Note that none of the recommendations here are binding or in any way a
+requirement of participation in the Git community. They are provided as a
+resource to supplement your skills as a contributor.</p>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_principles"><a class="anchor" href="#_principles"></a>Principles</h2>
+<div class="sectionbody">
+<div class="sect2">
+<h3 id="_selecting_patches_to_review"><a class="anchor" href="#_selecting_patches_to_review"></a>Selecting patch(es) to review</h3>
+<div class="paragraph">
+<p>If you are looking for a patch series in need of review, start by checking
+the latest "What&#8217;s cooking in git.git" email
+(<a href="https://lore.kernel.org/git/xmqqilm1yp3m.fsf@gitster.g/">example</a>). The "What&#8217;s
+cooking" emails &amp; replies can be found using the query <code>s:"What's cooking"</code> on
+the <a href="https://lore.kernel.org/git/"><code>lore.kernel.org</code> mailing list archive</a>;
+alternatively, you can find the contents of the "What&#8217;s cooking" email tracked
+in <code>whats-cooking.txt</code> on the <code>todo</code> branch of Git. Topics tagged with "Needs
+review" and those in the "[New Topics]" section are typically those that would
+benefit the most from additional review.</p>
+</div>
+<div class="paragraph">
+<p>Patches can also be searched manually in the mailing list archive using a query
+like <code>s:"PATCH" -s:"Re:"</code>. You can browse these results for topics relevant to
+your expertise or interest.</p>
+</div>
+<div class="paragraph">
+<p>If you&#8217;ve already contributed to Git, you may also be CC&#8217;d in another
+contributor&#8217;s patch series. These are topics where the author feels that your
+attention is warranted. This may be because their patch changes something you
+wrote previously (making you a good judge of whether the new approach does or
+doesn&#8217;t work), or because you have the expertise to provide an exceptionally
+helpful review. There is no requirement to review these patches but, in the
+spirit of open source collaboration, you should strongly consider doing so.</p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_reviewing_patches"><a class="anchor" href="#_reviewing_patches"></a>Reviewing patches</h3>
+<div class="paragraph">
+<p>While every contributor takes their own approach to reviewing patches, here are
+some general pieces of advice to make your reviews as clear and helpful as
+possible. The advice is broken into two rough categories: high-level reviewing
+guidance, and concrete tips for interacting with patches on the mailing list.</p>
+</div>
+<div class="sect3">
+<h4 id="_high_level_guidance"><a class="anchor" href="#_high_level_guidance"></a>High-level guidance</h4>
+<div class="ulist">
+<ul>
+<li>
+<p>Remember to review the content of commit messages for correctness and clarity,
+in addition to the code change in the patch&#8217;s diff. The commit message of a
+patch should accurately and fully explain the code change being made in the
+diff.</p>
+</li>
+<li>
+<p>Reviewing test coverage is an important - but easy to overlook - component of
+reviews. A patch&#8217;s changes may be covered by existing tests, or new tests may
+be introduced to exercise new behavior. Checking out a patch or series locally
+allows you to manually mutate lines of new &amp; existing tests to verify expected
+pass/fail behavior. You can use this information to verify proper coverage or
+to suggest additional tests the author could add.</p>
+</li>
+<li>
+<p>When providing a recommendation, be as clear as possible about whether you
+consider it "blocking" (the code would be broken or otherwise made worse if an
+issue isn&#8217;t fixed) or "non-blocking" (the patch could be made better by taking
+the recommendation, but acceptance of the series does not require it).
+Non-blocking recommendations can be particularly ambiguous when they are
+related to - but outside the scope of - a series ("nice-to-have"s), or when
+they represent only stylistic differences between the author and reviewer.</p>
+</li>
+<li>
+<p>When commenting on an issue, try to include suggestions for how the author
+could fix it. This not only helps the author to understand and fix the issue,
+it also deepens and improves your understanding of the topic.</p>
+</li>
+<li>
+<p>Reviews do not need to exclusively point out problems.  Positive
+reviews indicate that it is not only the original author of the
+patches who care about the issue the patches address, and are
+highly encouraged.</p>
+</li>
+<li>
+<p>Do not hesitate to give positive reviews on a series from your
+work colleague.  If your positive review is written well, it will
+not make you look as if you two are representing corporate
+interest on a series that is otherwise uninteresting to other
+community members and shoving it down their throat.</p>
+</li>
+<li>
+<p>Write a positive review in such a way that others can understand
+why you support the goal, the approach, and the implementation the
+patches took.  Make sure to demonstrate that you did thoroughly read
+the series and understood problem area well enough to be able to
+say that the patches are written well.  Feel free to "think out
+loud" in your review: describe how you read &amp; understood a complex section of
+a patch, ask a question about something that confused you, point out something
+you found exceptionally well-written, etc.</p>
+</li>
+<li>
+<p>In particular, uplifting feedback goes a long way towards
+encouraging contributors to participate more actively in the Git
+community.</p>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect3">
+<h4 id="_performing_your_review"><a class="anchor" href="#_performing_your_review"></a>Performing your review</h4>
+<div class="ulist">
+<ul>
+<li>
+<p>Provide your review comments per-patch in a plaintext "Reply-All" email to the
+relevant patch. Comments should be made inline, immediately below the relevant
+section(s).</p>
+</li>
+<li>
+<p>You may find that the limited context provided in the patch diff is sometimes
+insufficient for a thorough review. In such cases, you can review patches in
+your local tree by either applying patches with <a href='{{< relurl "docs/git-am" >}}'>git-am[1]</a> or checking
+out the associated branch from <a href="https://github.com/gitster/git" class="bare">https://github.com/gitster/git</a> once the series
+is tracked there.</p>
+</li>
+<li>
+<p>Large, complicated patch diffs are sometimes unavoidable, such as when they
+refactor existing code. If you find such a patch difficult to parse, try
+reviewing the diff produced with the <code>--color-moved</code> and/or
+<code>--ignore-space-change</code> options.</p>
+</li>
+<li>
+<p>If a patch is long, you are encouraged to delete parts of it that are
+unrelated to your review from the email reply. Make sure to leave enough
+context for readers to understand your comments!</p>
+</li>
+<li>
+<p>If you cannot complete a full review of a series all at once, consider letting
+the author know (on- or off-list) if/when you plan to review the rest of the
+series.</p>
+</li>
+</ul>
+</div>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_completing_a_review"><a class="anchor" href="#_completing_a_review"></a>Completing a review</h3>
+<div class="paragraph">
+<p>Once each patch of a series is reviewed, the author (and/or other contributors)
+may discuss the review(s). This may result in no changes being applied, or the
+author will send a new version of their patch(es).</p>
+</div>
+<div class="paragraph">
+<p>After a series is rerolled in response to your or others' review, make sure to
+re-review the updates. If you are happy with the state of the patch series,
+explicitly indicate your approval (typically with a reply to the latest
+version&#8217;s cover letter). Optionally, you can let the author know that they can
+add a "Reviewed-by: &lt;you&gt;" trailer if they resubmit the reviewed patch verbatim
+in a later iteration of the series.</p>
+</div>
+<div class="paragraph">
+<p>Finally, subsequent "What&#8217;s cooking" emails may explicitly ask whether a
+reviewed topic is ready for merging to the <code>next</code> branch (typically phrased
+"Will merge to 'next\'?"). You can help the maintainer and author by responding
+with a short description of the state of your (and others', if applicable)
+review, including the links to the relevant thread(s).</p>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_terminology"><a class="anchor" href="#_terminology"></a>Terminology</h2>
+<div class="sectionbody">
+<div class="dlist">
+<dl>
+<dt class="hdlist1" id="Documentation/ReviewingGuidelines.txt-nit"> <a class="anchor" href="#Documentation/ReviewingGuidelines.txt-nit"></a>nit:  </dt>
+<dd>
+<p>Denotes a small issue that should be fixed, such as a typographical error
+or misalignment of conditions in an <code>if()</code> statement.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/ReviewingGuidelines.txt-aside"> <a class="anchor" href="#Documentation/ReviewingGuidelines.txt-aside"></a>aside:  </dt>
+<dt class="hdlist1" id="Documentation/ReviewingGuidelines.txt-optional"> <a class="anchor" href="#Documentation/ReviewingGuidelines.txt-optional"></a>optional:  </dt>
+<dt class="hdlist1" id="Documentation/ReviewingGuidelines.txt-non-blocking"> <a class="anchor" href="#Documentation/ReviewingGuidelines.txt-non-blocking"></a>non-blocking:  </dt>
+<dd>
+<p>Indicates to the reader that the following comment should not block the
+acceptance of the patch or series. These are typically recommendations
+related to code organization &amp; style, or musings about topics related to
+the patch in question, but beyond its scope.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/ReviewingGuidelines.txt-sltbeforegtltaftergt"> <a class="anchor" href="#Documentation/ReviewingGuidelines.txt-sltbeforegtltaftergt"></a>s/&lt;before&gt;/&lt;after&gt;/ </dt>
+<dd>
+<p>Shorthand for "you wrote &lt;before&gt;, but I think you meant &lt;after&gt;," usually
+for misspellings or other typographical errors. The syntax is a reference
+to "substitute" command commonly found in Unix tools such as <code>ed</code>, <code>sed</code>,
+<code>vim</code>, and <code>perl</code>.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/ReviewingGuidelines.txt-coverletter"> <a class="anchor" href="#Documentation/ReviewingGuidelines.txt-coverletter"></a>cover letter </dt>
+<dd>
+<p>The "Patch 0" of a multi-patch series. This email describes the
+high-level intent and structure of the patch series to readers on the
+Git mailing list. It is also where the changelog notes and range-diff of
+subsequent versions are provided by the author.</p>
+<div class="paragraph">
+<p>On single-patch submissions, cover letter content is typically not sent as a
+separate email. Instead, it is inserted between the end of the patch&#8217;s commit
+message (after the <code>---</code>) and the beginning of the diff.</p>
+</div>
+</dd>
+<dt class="hdlist1" id="Documentation/ReviewingGuidelines.txt-leftoverbits"> <a class="anchor" href="#Documentation/ReviewingGuidelines.txt-leftoverbits"></a>#leftoverbits </dt>
+<dd>
+<p>Used by either an author or a reviewer to describe features or suggested
+changes that are out-of-scope of a given patch or series, but are relevant
+to the topic for the sake of discussion.</p>
+</dd>
+</dl>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_see_also"><a class="anchor" href="#_see_also"></a>See Also</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p><a href="{{< relurl "docs/MyFirstContribution" >}}">MyFirstContribution</a></p>
+</div>
+</div>
+</div>
\ No newline at end of file
diff --git a/external/docs/content/docs/ReviewingGuidelines/2.38.0.html b/external/docs/content/docs/ReviewingGuidelines/2.38.0.html
new file mode 100644
index 0000000000..0ef259a393
--- /dev/null
+++ b/external/docs/content/docs/ReviewingGuidelines/2.38.0.html
@@ -0,0 +1,253 @@
+---
+### DO NOT EDIT! Generated by script/update-docs.rb
+
+category: manual
+section: documentation
+subsection: manual
+title: Git - ReviewingGuidelines Documentation
+docname: ReviewingGuidelines
+version: 2.38.0
+aliases:
+- "/docs/ReviewingGuidelines/2.38.0/index.html"
+- "/docs/ReviewingGuidelines/2.38.1/index.html"
+- "/docs/ReviewingGuidelines/2.38.2/index.html"
+- "/docs/ReviewingGuidelines/2.38.3/index.html"
+- "/docs/ReviewingGuidelines/2.38.4/index.html"
+- "/docs/ReviewingGuidelines/2.38.5/index.html"
+- "/docs/ReviewingGuidelines/2.39.0/index.html"
+- "/docs/ReviewingGuidelines/2.39.1/index.html"
+- "/docs/ReviewingGuidelines/2.39.2/index.html"
+- "/docs/ReviewingGuidelines/2.39.3/index.html"
+- "/docs/ReviewingGuidelines/2.39.4/index.html"
+- "/docs/ReviewingGuidelines/2.39.5/index.html"
+- "/docs/ReviewingGuidelines/2.40.0/index.html"
+- "/docs/ReviewingGuidelines/2.40.1/index.html"
+- "/docs/ReviewingGuidelines/2.40.2/index.html"
+- "/docs/ReviewingGuidelines/2.40.3/index.html"
+- "/docs/ReviewingGuidelines/2.40.4/index.html"
+- "/docs/ReviewingGuidelines/2.41.0/index.html"
+- "/docs/ReviewingGuidelines/2.41.1/index.html"
+- "/docs/ReviewingGuidelines/2.41.2/index.html"
+- "/docs/ReviewingGuidelines/2.41.3/index.html"
+- "/docs/ReviewingGuidelines/2.42.0/index.html"
+- "/docs/ReviewingGuidelines/2.42.1/index.html"
+- "/docs/ReviewingGuidelines/2.42.2/index.html"
+- "/docs/ReviewingGuidelines/2.42.3/index.html"
+- "/docs/ReviewingGuidelines/2.42.4/index.html"
+---
+<div class="sect1">
+<h2 id="_introduction"><a class="anchor" href="#_introduction"></a>Introduction</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>The Git development community is a widely distributed, diverse, ever-changing
+group of individuals. Asynchronous communication via the Git mailing list poses
+unique challenges when reviewing or discussing patches. This document contains
+some guiding principles and helpful tools you can use to make your reviews both
+more efficient for yourself and more effective for other contributors.</p>
+</div>
+<div class="paragraph">
+<p>Note that none of the recommendations here are binding or in any way a
+requirement of participation in the Git community. They are provided as a
+resource to supplement your skills as a contributor.</p>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_principles"><a class="anchor" href="#_principles"></a>Principles</h2>
+<div class="sectionbody">
+<div class="sect2">
+<h3 id="_selecting_patches_to_review"><a class="anchor" href="#_selecting_patches_to_review"></a>Selecting patch(es) to review</h3>
+<div class="paragraph">
+<p>If you are looking for a patch series in need of review, start by checking
+latest "What&#8217;s cooking in git.git" email
+(<a href="https://lore.kernel.org/git/xmqqilm1yp3m.fsf@gitster.g/">example</a>). The "What&#8217;s
+cooking" emails &amp; replies can be found using the query <code>s:"What's cooking"</code> on
+the <a href="https://lore.kernel.org/git/"><code>lore.kernel.org</code> mailing list archive</a>;
+alternatively, you can find the contents of the "What&#8217;s cooking" email tracked
+in <code>whats-cooking.txt</code> on the <code>todo</code> branch of Git. Topics tagged with "Needs
+review" and those in the "[New Topics]" section are typically those that would
+benefit the most from additional review.</p>
+</div>
+<div class="paragraph">
+<p>Patches can also be searched manually in the mailing list archive using a query
+like <code>s:"PATCH" -s:"Re:"</code>. You can browse these results for topics relevant to
+your expertise or interest.</p>
+</div>
+<div class="paragraph">
+<p>If you&#8217;ve already contributed to Git, you may also be CC&#8217;d in another
+contributor&#8217;s patch series. These are topics where the author feels that your
+attention is warranted. This may be because their patch changes something you
+wrote previously (making you a good judge of whether the new approach does or
+doesn&#8217;t work), or because you have the expertise to provide an exceptionally
+helpful review. There is no requirement to review these patches but, in the
+spirit of open source collaboration, you should strongly consider doing so.</p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_reviewing_patches"><a class="anchor" href="#_reviewing_patches"></a>Reviewing patches</h3>
+<div class="paragraph">
+<p>While every contributor takes their own approach to reviewing patches, here are
+some general pieces of advice to make your reviews as clear and helpful as
+possible. The advice is broken into two rough categories: high-level reviewing
+guidance, and concrete tips for interacting with patches on the mailing list.</p>
+</div>
+<div class="sect3">
+<h4 id="_high_level_guidance"><a class="anchor" href="#_high_level_guidance"></a>High-level guidance</h4>
+<div class="ulist">
+<ul>
+<li>
+<p>Remember to review the content of commit messages for correctness and clarity,
+in addition to the code change in the patch&#8217;s diff. The commit message of a
+patch should accurately and fully explain the code change being made in the
+diff.</p>
+</li>
+<li>
+<p>Reviewing test coverage is an important - but easy to overlook - component of
+reviews. A patch&#8217;s changes may be covered by existing tests, or new tests may
+be introduced to exercise new behavior. Checking out a patch or series locally
+allows you to manually mutate lines of new &amp; existing tests to verify expected
+pass/fail behavior. You can use this information to verify proper coverage or
+to suggest additional tests the author could add.</p>
+</li>
+<li>
+<p>When providing a recommendation, be as clear as possible about whether you
+consider it "blocking" (the code would be broken or otherwise made worse if an
+issue isn&#8217;t fixed) or "non-blocking" (the patch could be made better by taking
+the recommendation, but acceptance of the series does not require it).
+Non-blocking recommendations can be particularly ambiguous when they are
+related to - but outside the scope of - a series ("nice-to-have"s), or when
+they represent only stylistic differences between the author and reviewer.</p>
+</li>
+<li>
+<p>When commenting on an issue, try to include suggestions for how the author
+could fix it. This not only helps the author to understand and fix the issue,
+it also deepens and improves your understanding of the topic.</p>
+</li>
+<li>
+<p>Reviews do not need to exclusively point out problems. Feel free to "think out
+loud" in your review: describe how you read &amp; understood a complex section of
+a patch, ask a question about something that confused you, point out something
+you found exceptionally well-written, etc. In particular, uplifting feedback
+goes a long way towards encouraging contributors to participate more actively
+in the Git community.</p>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect3">
+<h4 id="_performing_your_review"><a class="anchor" href="#_performing_your_review"></a>Performing your review</h4>
+<div class="ulist">
+<ul>
+<li>
+<p>Provide your review comments per-patch in a plaintext "Reply-All" email to the
+relevant patch. Comments should be made inline, immediately below the relevant
+section(s).</p>
+</li>
+<li>
+<p>You may find that the limited context provided in the patch diff is sometimes
+insufficient for a thorough review. In such cases, you can review patches in
+your local tree by either applying patches with <a href='{{< relurl "docs/git-am" >}}'>git-am[1]</a> or checking
+out the associated branch from <a href="https://github.com/gitster/git" class="bare">https://github.com/gitster/git</a> once the series
+is tracked there.</p>
+</li>
+<li>
+<p>Large, complicated patch diffs are sometimes unavoidable, such as when they
+refactor existing code. If you find such a patch difficult to parse, try
+reviewing the diff produced with the <code>--color-moved</code> and/or
+<code>--ignore-space-change</code> options.</p>
+</li>
+<li>
+<p>If a patch is long, you are encouraged to delete parts of it that are
+unrelated to your review from the email reply. Make sure to leave enough
+context for readers to understand your comments!</p>
+</li>
+<li>
+<p>If you cannot complete a full review of a series all at once, consider letting
+the author know (on- or off-list) if/when you plan to review the rest of the
+series.</p>
+</li>
+</ul>
+</div>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_completing_a_review"><a class="anchor" href="#_completing_a_review"></a>Completing a review</h3>
+<div class="paragraph">
+<p>Once each patch of a series is reviewed, the author (and/or other contributors)
+may discuss the review(s). This may result in no changes being applied, or the
+author will send a new version of their patch(es).</p>
+</div>
+<div class="paragraph">
+<p>After a series is rerolled in response to your or others' review, make sure to
+re-review the updates. If you are happy with the state of the patch series,
+explicitly indicate your approval (typically with a reply to the latest
+version&#8217;s cover letter). Optionally, you can let the author know that they can
+add a "Reviewed-by: &lt;you&gt;" trailer if they resubmit the reviewed patch verbatim
+in a later iteration of the series.</p>
+</div>
+<div class="paragraph">
+<p>Finally, subsequent "What&#8217;s cooking" emails may explicitly ask whether a
+reviewed topic is ready for merging to the <code>next</code> branch (typically phrased
+"Will merge to 'next\'?"). You can help the maintainer and author by responding
+with a short description of the state of your (and others', if applicable)
+review, including the links to the relevant thread(s).</p>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_terminology"><a class="anchor" href="#_terminology"></a>Terminology</h2>
+<div class="sectionbody">
+<div class="dlist">
+<dl>
+<dt class="hdlist1" id="Documentation/ReviewingGuidelines.txt-nit"> <a class="anchor" href="#Documentation/ReviewingGuidelines.txt-nit"></a>nit:  </dt>
+<dd>
+<p>Denotes a small issue that should be fixed, such as a typographical error
+or mis-alignment of conditions in an <code>if()</code> statement.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/ReviewingGuidelines.txt-aside"> <a class="anchor" href="#Documentation/ReviewingGuidelines.txt-aside"></a>aside:  </dt>
+<dt class="hdlist1" id="Documentation/ReviewingGuidelines.txt-optional"> <a class="anchor" href="#Documentation/ReviewingGuidelines.txt-optional"></a>optional:  </dt>
+<dt class="hdlist1" id="Documentation/ReviewingGuidelines.txt-non-blocking"> <a class="anchor" href="#Documentation/ReviewingGuidelines.txt-non-blocking"></a>non-blocking:  </dt>
+<dd>
+<p>Indicates to the reader that the following comment should not block the
+acceptance of the patch or series. These are typically recommendations
+related to code organization &amp; style, or musings about topics related to
+the patch in question, but beyond its scope.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/ReviewingGuidelines.txt-sltbeforegtltaftergt"> <a class="anchor" href="#Documentation/ReviewingGuidelines.txt-sltbeforegtltaftergt"></a>s/&lt;before&gt;/&lt;after&gt;/ </dt>
+<dd>
+<p>Shorthand for "you wrote &lt;before&gt;, but I think you meant &lt;after&gt;," usually
+for misspellings or other typographical errors. The syntax is a reference
+to "substitute" command commonly found in Unix tools such as <code>ed</code>, <code>sed</code>,
+<code>vim</code>, and <code>perl</code>.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/ReviewingGuidelines.txt-coverletter"> <a class="anchor" href="#Documentation/ReviewingGuidelines.txt-coverletter"></a>cover letter </dt>
+<dd>
+<p>The "Patch 0" of a multi-patch series. This email describes the
+high-level intent and structure of the patch series to readers on the
+Git mailing list. It is also where the changelog notes and range-diff of
+subsequent versions are provided by the author.</p>
+<div class="paragraph">
+<p>On single-patch submissions, cover letter content is typically not sent as a
+separate email. Instead, it is inserted between the end of the patch&#8217;s commit
+message (after the <code>---</code>) and the beginning of the diff.</p>
+</div>
+</dd>
+<dt class="hdlist1" id="Documentation/ReviewingGuidelines.txt-leftoverbits"> <a class="anchor" href="#Documentation/ReviewingGuidelines.txt-leftoverbits"></a>#leftoverbits </dt>
+<dd>
+<p>Used by either an author or a reviewer to describe features or suggested
+changes that are out-of-scope of a given patch or series, but are relevant
+to the topic for the sake of discussion.</p>
+</dd>
+</dl>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_see_also"><a class="anchor" href="#_see_also"></a>See Also</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p><a href="{{< relurl "docs/MyFirstContribution" >}}">MyFirstContribution</a></p>
+</div>
+</div>
+</div>
\ No newline at end of file
diff --git a/external/docs/content/docs/ReviewingGuidelines/2.43.0.html b/external/docs/content/docs/ReviewingGuidelines/2.43.0.html
new file mode 100644
index 0000000000..c33b26c98a
--- /dev/null
+++ b/external/docs/content/docs/ReviewingGuidelines/2.43.0.html
@@ -0,0 +1,246 @@
+---
+### DO NOT EDIT! Generated by script/update-docs.rb
+
+category: manual
+section: documentation
+subsection: manual
+title: Git - ReviewingGuidelines Documentation
+docname: ReviewingGuidelines
+version: 2.43.0
+aliases:
+- "/docs/ReviewingGuidelines/2.43.0/index.html"
+- "/docs/ReviewingGuidelines/2.43.1/index.html"
+- "/docs/ReviewingGuidelines/2.43.2/index.html"
+- "/docs/ReviewingGuidelines/2.43.3/index.html"
+- "/docs/ReviewingGuidelines/2.43.4/index.html"
+- "/docs/ReviewingGuidelines/2.43.5/index.html"
+- "/docs/ReviewingGuidelines/2.43.6/index.html"
+- "/docs/ReviewingGuidelines/2.44.0/index.html"
+- "/docs/ReviewingGuidelines/2.44.1/index.html"
+- "/docs/ReviewingGuidelines/2.44.2/index.html"
+- "/docs/ReviewingGuidelines/2.44.3/index.html"
+- "/docs/ReviewingGuidelines/2.45.0/index.html"
+- "/docs/ReviewingGuidelines/2.45.1/index.html"
+- "/docs/ReviewingGuidelines/2.45.2/index.html"
+- "/docs/ReviewingGuidelines/2.45.3/index.html"
+- "/docs/ReviewingGuidelines/2.46.0/index.html"
+- "/docs/ReviewingGuidelines/2.46.1/index.html"
+- "/docs/ReviewingGuidelines/2.46.2/index.html"
+- "/docs/ReviewingGuidelines/2.46.3/index.html"
+---
+<div class="sect1">
+<h2 id="_introduction"><a class="anchor" href="#_introduction"></a>Introduction</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>The Git development community is a widely distributed, diverse, ever-changing
+group of individuals. Asynchronous communication via the Git mailing list poses
+unique challenges when reviewing or discussing patches. This document contains
+some guiding principles and helpful tools you can use to make your reviews both
+more efficient for yourself and more effective for other contributors.</p>
+</div>
+<div class="paragraph">
+<p>Note that none of the recommendations here are binding or in any way a
+requirement of participation in the Git community. They are provided as a
+resource to supplement your skills as a contributor.</p>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_principles"><a class="anchor" href="#_principles"></a>Principles</h2>
+<div class="sectionbody">
+<div class="sect2">
+<h3 id="_selecting_patches_to_review"><a class="anchor" href="#_selecting_patches_to_review"></a>Selecting patch(es) to review</h3>
+<div class="paragraph">
+<p>If you are looking for a patch series in need of review, start by checking
+the latest "What&#8217;s cooking in git.git" email
+(<a href="https://lore.kernel.org/git/xmqqilm1yp3m.fsf@gitster.g/">example</a>). The "What&#8217;s
+cooking" emails &amp; replies can be found using the query <code>s:"What's cooking"</code> on
+the <a href="https://lore.kernel.org/git/"><code>lore.kernel.org</code> mailing list archive</a>;
+alternatively, you can find the contents of the "What&#8217;s cooking" email tracked
+in <code>whats-cooking.txt</code> on the <code>todo</code> branch of Git. Topics tagged with "Needs
+review" and those in the "[New Topics]" section are typically those that would
+benefit the most from additional review.</p>
+</div>
+<div class="paragraph">
+<p>Patches can also be searched manually in the mailing list archive using a query
+like <code>s:"PATCH" -s:"Re:"</code>. You can browse these results for topics relevant to
+your expertise or interest.</p>
+</div>
+<div class="paragraph">
+<p>If you&#8217;ve already contributed to Git, you may also be CC&#8217;d in another
+contributor&#8217;s patch series. These are topics where the author feels that your
+attention is warranted. This may be because their patch changes something you
+wrote previously (making you a good judge of whether the new approach does or
+doesn&#8217;t work), or because you have the expertise to provide an exceptionally
+helpful review. There is no requirement to review these patches but, in the
+spirit of open source collaboration, you should strongly consider doing so.</p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_reviewing_patches"><a class="anchor" href="#_reviewing_patches"></a>Reviewing patches</h3>
+<div class="paragraph">
+<p>While every contributor takes their own approach to reviewing patches, here are
+some general pieces of advice to make your reviews as clear and helpful as
+possible. The advice is broken into two rough categories: high-level reviewing
+guidance, and concrete tips for interacting with patches on the mailing list.</p>
+</div>
+<div class="sect3">
+<h4 id="_high_level_guidance"><a class="anchor" href="#_high_level_guidance"></a>High-level guidance</h4>
+<div class="ulist">
+<ul>
+<li>
+<p>Remember to review the content of commit messages for correctness and clarity,
+in addition to the code change in the patch&#8217;s diff. The commit message of a
+patch should accurately and fully explain the code change being made in the
+diff.</p>
+</li>
+<li>
+<p>Reviewing test coverage is an important - but easy to overlook - component of
+reviews. A patch&#8217;s changes may be covered by existing tests, or new tests may
+be introduced to exercise new behavior. Checking out a patch or series locally
+allows you to manually mutate lines of new &amp; existing tests to verify expected
+pass/fail behavior. You can use this information to verify proper coverage or
+to suggest additional tests the author could add.</p>
+</li>
+<li>
+<p>When providing a recommendation, be as clear as possible about whether you
+consider it "blocking" (the code would be broken or otherwise made worse if an
+issue isn&#8217;t fixed) or "non-blocking" (the patch could be made better by taking
+the recommendation, but acceptance of the series does not require it).
+Non-blocking recommendations can be particularly ambiguous when they are
+related to - but outside the scope of - a series ("nice-to-have"s), or when
+they represent only stylistic differences between the author and reviewer.</p>
+</li>
+<li>
+<p>When commenting on an issue, try to include suggestions for how the author
+could fix it. This not only helps the author to understand and fix the issue,
+it also deepens and improves your understanding of the topic.</p>
+</li>
+<li>
+<p>Reviews do not need to exclusively point out problems. Feel free to "think out
+loud" in your review: describe how you read &amp; understood a complex section of
+a patch, ask a question about something that confused you, point out something
+you found exceptionally well-written, etc. In particular, uplifting feedback
+goes a long way towards encouraging contributors to participate more actively
+in the Git community.</p>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect3">
+<h4 id="_performing_your_review"><a class="anchor" href="#_performing_your_review"></a>Performing your review</h4>
+<div class="ulist">
+<ul>
+<li>
+<p>Provide your review comments per-patch in a plaintext "Reply-All" email to the
+relevant patch. Comments should be made inline, immediately below the relevant
+section(s).</p>
+</li>
+<li>
+<p>You may find that the limited context provided in the patch diff is sometimes
+insufficient for a thorough review. In such cases, you can review patches in
+your local tree by either applying patches with <a href='{{< relurl "docs/git-am" >}}'>git-am[1]</a> or checking
+out the associated branch from <a href="https://github.com/gitster/git" class="bare">https://github.com/gitster/git</a> once the series
+is tracked there.</p>
+</li>
+<li>
+<p>Large, complicated patch diffs are sometimes unavoidable, such as when they
+refactor existing code. If you find such a patch difficult to parse, try
+reviewing the diff produced with the <code>--color-moved</code> and/or
+<code>--ignore-space-change</code> options.</p>
+</li>
+<li>
+<p>If a patch is long, you are encouraged to delete parts of it that are
+unrelated to your review from the email reply. Make sure to leave enough
+context for readers to understand your comments!</p>
+</li>
+<li>
+<p>If you cannot complete a full review of a series all at once, consider letting
+the author know (on- or off-list) if/when you plan to review the rest of the
+series.</p>
+</li>
+</ul>
+</div>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_completing_a_review"><a class="anchor" href="#_completing_a_review"></a>Completing a review</h3>
+<div class="paragraph">
+<p>Once each patch of a series is reviewed, the author (and/or other contributors)
+may discuss the review(s). This may result in no changes being applied, or the
+author will send a new version of their patch(es).</p>
+</div>
+<div class="paragraph">
+<p>After a series is rerolled in response to your or others' review, make sure to
+re-review the updates. If you are happy with the state of the patch series,
+explicitly indicate your approval (typically with a reply to the latest
+version&#8217;s cover letter). Optionally, you can let the author know that they can
+add a "Reviewed-by: &lt;you&gt;" trailer if they resubmit the reviewed patch verbatim
+in a later iteration of the series.</p>
+</div>
+<div class="paragraph">
+<p>Finally, subsequent "What&#8217;s cooking" emails may explicitly ask whether a
+reviewed topic is ready for merging to the <code>next</code> branch (typically phrased
+"Will merge to 'next\'?"). You can help the maintainer and author by responding
+with a short description of the state of your (and others', if applicable)
+review, including the links to the relevant thread(s).</p>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_terminology"><a class="anchor" href="#_terminology"></a>Terminology</h2>
+<div class="sectionbody">
+<div class="dlist">
+<dl>
+<dt class="hdlist1" id="Documentation/ReviewingGuidelines.txt-nit"> <a class="anchor" href="#Documentation/ReviewingGuidelines.txt-nit"></a>nit:  </dt>
+<dd>
+<p>Denotes a small issue that should be fixed, such as a typographical error
+or misalignment of conditions in an <code>if()</code> statement.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/ReviewingGuidelines.txt-aside"> <a class="anchor" href="#Documentation/ReviewingGuidelines.txt-aside"></a>aside:  </dt>
+<dt class="hdlist1" id="Documentation/ReviewingGuidelines.txt-optional"> <a class="anchor" href="#Documentation/ReviewingGuidelines.txt-optional"></a>optional:  </dt>
+<dt class="hdlist1" id="Documentation/ReviewingGuidelines.txt-non-blocking"> <a class="anchor" href="#Documentation/ReviewingGuidelines.txt-non-blocking"></a>non-blocking:  </dt>
+<dd>
+<p>Indicates to the reader that the following comment should not block the
+acceptance of the patch or series. These are typically recommendations
+related to code organization &amp; style, or musings about topics related to
+the patch in question, but beyond its scope.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/ReviewingGuidelines.txt-sltbeforegtltaftergt"> <a class="anchor" href="#Documentation/ReviewingGuidelines.txt-sltbeforegtltaftergt"></a>s/&lt;before&gt;/&lt;after&gt;/ </dt>
+<dd>
+<p>Shorthand for "you wrote &lt;before&gt;, but I think you meant &lt;after&gt;," usually
+for misspellings or other typographical errors. The syntax is a reference
+to "substitute" command commonly found in Unix tools such as <code>ed</code>, <code>sed</code>,
+<code>vim</code>, and <code>perl</code>.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/ReviewingGuidelines.txt-coverletter"> <a class="anchor" href="#Documentation/ReviewingGuidelines.txt-coverletter"></a>cover letter </dt>
+<dd>
+<p>The "Patch 0" of a multi-patch series. This email describes the
+high-level intent and structure of the patch series to readers on the
+Git mailing list. It is also where the changelog notes and range-diff of
+subsequent versions are provided by the author.</p>
+<div class="paragraph">
+<p>On single-patch submissions, cover letter content is typically not sent as a
+separate email. Instead, it is inserted between the end of the patch&#8217;s commit
+message (after the <code>---</code>) and the beginning of the diff.</p>
+</div>
+</dd>
+<dt class="hdlist1" id="Documentation/ReviewingGuidelines.txt-leftoverbits"> <a class="anchor" href="#Documentation/ReviewingGuidelines.txt-leftoverbits"></a>#leftoverbits </dt>
+<dd>
+<p>Used by either an author or a reviewer to describe features or suggested
+changes that are out-of-scope of a given patch or series, but are relevant
+to the topic for the sake of discussion.</p>
+</dd>
+</dl>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_see_also"><a class="anchor" href="#_see_also"></a>See Also</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p><a href="{{< relurl "docs/MyFirstContribution" >}}">MyFirstContribution</a></p>
+</div>
+</div>
+</div>
\ No newline at end of file
diff --git a/external/docs/content/docs/ReviewingGuidelines/2.47.0.html b/external/docs/content/docs/ReviewingGuidelines/2.47.0.html
new file mode 100644
index 0000000000..876bb5b1d4
--- /dev/null
+++ b/external/docs/content/docs/ReviewingGuidelines/2.47.0.html
@@ -0,0 +1,252 @@
+---
+### DO NOT EDIT! Generated by script/update-docs.rb
+
+category: manual
+section: documentation
+subsection: manual
+title: Git - ReviewingGuidelines Documentation
+docname: ReviewingGuidelines
+version: 2.47.0
+aliases:
+- "/docs/ReviewingGuidelines/2.47.0/index.html"
+- "/docs/ReviewingGuidelines/2.47.1/index.html"
+- "/docs/ReviewingGuidelines/2.47.2/index.html"
+- "/docs/ReviewingGuidelines/2.48.0/index.html"
+- "/docs/ReviewingGuidelines/2.48.1/index.html"
+---
+<div class="sect1">
+<h2 id="_introduction"><a class="anchor" href="#_introduction"></a>Introduction</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>The Git development community is a widely distributed, diverse, ever-changing
+group of individuals. Asynchronous communication via the Git mailing list poses
+unique challenges when reviewing or discussing patches. This document contains
+some guiding principles and helpful tools you can use to make your reviews both
+more efficient for yourself and more effective for other contributors.</p>
+</div>
+<div class="paragraph">
+<p>Note that none of the recommendations here are binding or in any way a
+requirement of participation in the Git community. They are provided as a
+resource to supplement your skills as a contributor.</p>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_principles"><a class="anchor" href="#_principles"></a>Principles</h2>
+<div class="sectionbody">
+<div class="sect2">
+<h3 id="_selecting_patches_to_review"><a class="anchor" href="#_selecting_patches_to_review"></a>Selecting patch(es) to review</h3>
+<div class="paragraph">
+<p>If you are looking for a patch series in need of review, start by checking
+the latest "What&#8217;s cooking in git.git" email
+(<a href="https://lore.kernel.org/git/xmqqilm1yp3m.fsf@gitster.g/">example</a>). The "What&#8217;s
+cooking" emails &amp; replies can be found using the query <code>s:"What's cooking"</code> on
+the <a href="https://lore.kernel.org/git/"><code>lore.kernel.org</code> mailing list archive</a>;
+alternatively, you can find the contents of the "What&#8217;s cooking" email tracked
+in <code>whats-cooking.txt</code> on the <code>todo</code> branch of Git. Topics tagged with "Needs
+review" and those in the "[New Topics]" section are typically those that would
+benefit the most from additional review.</p>
+</div>
+<div class="paragraph">
+<p>Patches can also be searched manually in the mailing list archive using a query
+like <code>s:"PATCH" -s:"Re:"</code>. You can browse these results for topics relevant to
+your expertise or interest.</p>
+</div>
+<div class="paragraph">
+<p>If you&#8217;ve already contributed to Git, you may also be CC&#8217;d in another
+contributor&#8217;s patch series. These are topics where the author feels that your
+attention is warranted. This may be because their patch changes something you
+wrote previously (making you a good judge of whether the new approach does or
+doesn&#8217;t work), or because you have the expertise to provide an exceptionally
+helpful review. There is no requirement to review these patches but, in the
+spirit of open source collaboration, you should strongly consider doing so.</p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_reviewing_patches"><a class="anchor" href="#_reviewing_patches"></a>Reviewing patches</h3>
+<div class="paragraph">
+<p>While every contributor takes their own approach to reviewing patches, here are
+some general pieces of advice to make your reviews as clear and helpful as
+possible. The advice is broken into two rough categories: high-level reviewing
+guidance, and concrete tips for interacting with patches on the mailing list.</p>
+</div>
+<div class="sect3">
+<h4 id="_high_level_guidance"><a class="anchor" href="#_high_level_guidance"></a>High-level guidance</h4>
+<div class="ulist">
+<ul>
+<li>
+<p>Remember to review the content of commit messages for correctness and clarity,
+in addition to the code change in the patch&#8217;s diff. The commit message of a
+patch should accurately and fully explain the code change being made in the
+diff.</p>
+</li>
+<li>
+<p>Reviewing test coverage is an important - but easy to overlook - component of
+reviews. A patch&#8217;s changes may be covered by existing tests, or new tests may
+be introduced to exercise new behavior. Checking out a patch or series locally
+allows you to manually mutate lines of new &amp; existing tests to verify expected
+pass/fail behavior. You can use this information to verify proper coverage or
+to suggest additional tests the author could add.</p>
+</li>
+<li>
+<p>When providing a recommendation, be as clear as possible about whether you
+consider it "blocking" (the code would be broken or otherwise made worse if an
+issue isn&#8217;t fixed) or "non-blocking" (the patch could be made better by taking
+the recommendation, but acceptance of the series does not require it).
+Non-blocking recommendations can be particularly ambiguous when they are
+related to - but outside the scope of - a series ("nice-to-have"s), or when
+they represent only stylistic differences between the author and reviewer.</p>
+</li>
+<li>
+<p>When commenting on an issue, try to include suggestions for how the author
+could fix it. This not only helps the author to understand and fix the issue,
+it also deepens and improves your understanding of the topic.</p>
+</li>
+<li>
+<p>Reviews do not need to exclusively point out problems.  Positive
+reviews indicate that it is not only the original author of the
+patches who care about the issue the patches address, and are
+highly encouraged.</p>
+</li>
+<li>
+<p>Do not hesitate to give positive reviews on a series from your
+work colleague.  If your positive review is written well, it will
+not make you look as if you two are representing corporate
+interest on a series that is otherwise uninteresting to other
+community members and shoving it down their throat.</p>
+</li>
+<li>
+<p>Write a positive review in such a way that others can understand
+why you support the goal, the approach, and the implementation the
+patches took.  Make sure to demonstrate that you did thoroughly read
+the series and understood problem area well enough to be able to
+say that the patches are written well.  Feel free to "think out
+loud" in your review: describe how you read &amp; understood a complex section of
+a patch, ask a question about something that confused you, point out something
+you found exceptionally well-written, etc.</p>
+</li>
+<li>
+<p>In particular, uplifting feedback goes a long way towards
+encouraging contributors to participate more actively in the Git
+community.</p>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect3">
+<h4 id="_performing_your_review"><a class="anchor" href="#_performing_your_review"></a>Performing your review</h4>
+<div class="ulist">
+<ul>
+<li>
+<p>Provide your review comments per-patch in a plaintext "Reply-All" email to the
+relevant patch. Comments should be made inline, immediately below the relevant
+section(s).</p>
+</li>
+<li>
+<p>You may find that the limited context provided in the patch diff is sometimes
+insufficient for a thorough review. In such cases, you can review patches in
+your local tree by either applying patches with <a href='{{< relurl "docs/git-am" >}}'>git-am[1]</a> or checking
+out the associated branch from <a href="https://github.com/gitster/git" class="bare">https://github.com/gitster/git</a> once the series
+is tracked there.</p>
+</li>
+<li>
+<p>Large, complicated patch diffs are sometimes unavoidable, such as when they
+refactor existing code. If you find such a patch difficult to parse, try
+reviewing the diff produced with the <code>--color-moved</code> and/or
+<code>--ignore-space-change</code> options.</p>
+</li>
+<li>
+<p>If a patch is long, you are encouraged to delete parts of it that are
+unrelated to your review from the email reply. Make sure to leave enough
+context for readers to understand your comments!</p>
+</li>
+<li>
+<p>If you cannot complete a full review of a series all at once, consider letting
+the author know (on- or off-list) if/when you plan to review the rest of the
+series.</p>
+</li>
+</ul>
+</div>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_completing_a_review"><a class="anchor" href="#_completing_a_review"></a>Completing a review</h3>
+<div class="paragraph">
+<p>Once each patch of a series is reviewed, the author (and/or other contributors)
+may discuss the review(s). This may result in no changes being applied, or the
+author will send a new version of their patch(es).</p>
+</div>
+<div class="paragraph">
+<p>After a series is rerolled in response to your or others' review, make sure to
+re-review the updates. If you are happy with the state of the patch series,
+explicitly indicate your approval (typically with a reply to the latest
+version&#8217;s cover letter). Optionally, you can let the author know that they can
+add a "Reviewed-by: &lt;you&gt;" trailer if they resubmit the reviewed patch verbatim
+in a later iteration of the series.</p>
+</div>
+<div class="paragraph">
+<p>Finally, subsequent "What&#8217;s cooking" emails may explicitly ask whether a
+reviewed topic is ready for merging to the <code>next</code> branch (typically phrased
+"Will merge to 'next\'?"). You can help the maintainer and author by responding
+with a short description of the state of your (and others', if applicable)
+review, including the links to the relevant thread(s).</p>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_terminology"><a class="anchor" href="#_terminology"></a>Terminology</h2>
+<div class="sectionbody">
+<div class="dlist">
+<dl>
+<dt class="hdlist1" id="Documentation/ReviewingGuidelines.txt-nit"> <a class="anchor" href="#Documentation/ReviewingGuidelines.txt-nit"></a>nit:  </dt>
+<dd>
+<p>Denotes a small issue that should be fixed, such as a typographical error
+or misalignment of conditions in an <code>if()</code> statement.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/ReviewingGuidelines.txt-aside"> <a class="anchor" href="#Documentation/ReviewingGuidelines.txt-aside"></a>aside:  </dt>
+<dt class="hdlist1" id="Documentation/ReviewingGuidelines.txt-optional"> <a class="anchor" href="#Documentation/ReviewingGuidelines.txt-optional"></a>optional:  </dt>
+<dt class="hdlist1" id="Documentation/ReviewingGuidelines.txt-non-blocking"> <a class="anchor" href="#Documentation/ReviewingGuidelines.txt-non-blocking"></a>non-blocking:  </dt>
+<dd>
+<p>Indicates to the reader that the following comment should not block the
+acceptance of the patch or series. These are typically recommendations
+related to code organization &amp; style, or musings about topics related to
+the patch in question, but beyond its scope.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/ReviewingGuidelines.txt-sltbeforegtltaftergt"> <a class="anchor" href="#Documentation/ReviewingGuidelines.txt-sltbeforegtltaftergt"></a>s/&lt;before&gt;/&lt;after&gt;/ </dt>
+<dd>
+<p>Shorthand for "you wrote &lt;before&gt;, but I think you meant &lt;after&gt;," usually
+for misspellings or other typographical errors. The syntax is a reference
+to "substitute" command commonly found in Unix tools such as <code>ed</code>, <code>sed</code>,
+<code>vim</code>, and <code>perl</code>.</p>
+</dd>
+<dt class="hdlist1" id="Documentation/ReviewingGuidelines.txt-coverletter"> <a class="anchor" href="#Documentation/ReviewingGuidelines.txt-coverletter"></a>cover letter </dt>
+<dd>
+<p>The "Patch 0" of a multi-patch series. This email describes the
+high-level intent and structure of the patch series to readers on the
+Git mailing list. It is also where the changelog notes and range-diff of
+subsequent versions are provided by the author.</p>
+<div class="paragraph">
+<p>On single-patch submissions, cover letter content is typically not sent as a
+separate email. Instead, it is inserted between the end of the patch&#8217;s commit
+message (after the <code>---</code>) and the beginning of the diff.</p>
+</div>
+</dd>
+<dt class="hdlist1" id="Documentation/ReviewingGuidelines.txt-leftoverbits"> <a class="anchor" href="#Documentation/ReviewingGuidelines.txt-leftoverbits"></a>#leftoverbits </dt>
+<dd>
+<p>Used by either an author or a reviewer to describe features or suggested
+changes that are out-of-scope of a given patch or series, but are relevant
+to the topic for the sake of discussion.</p>
+</dd>
+</dl>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_see_also"><a class="anchor" href="#_see_also"></a>See Also</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p><a href="{{< relurl "docs/MyFirstContribution" >}}">MyFirstContribution</a></p>
+</div>
+</div>
+</div>
\ No newline at end of file
diff --git a/external/docs/data/docs.yml b/external/docs/data/docs.yml
index a43078e588..363ed4eb30 100644
--- a/external/docs/data/docs.yml
+++ b/external/docs/data/docs.yml
@@ -74779,6 +74779,575 @@ pages:
     - name: 2.48.0
       added: 8
       removed: 0
+  CodingGuidelines:
+    version-map:
+      2.0.5: ce20a0533295750b94bd23a9cb5c67430f8503ba
+      2.1.4: d3b4cbca6a79491fc719c451995a3667cc68b397
+      2.2.3: d3b4cbca6a79491fc719c451995a3667cc68b397
+      2.3.10: ff290873af26a1047e859571a8e319da8570a23c
+      2.4.12: 7983213f3ace118da2fd286c613aba364e124b89
+      2.5.6: 7983213f3ace118da2fd286c613aba364e124b89
+      2.6.7: 7983213f3ace118da2fd286c613aba364e124b89
+      2.7.6: 7983213f3ace118da2fd286c613aba364e124b89
+      2.8.6: 55011116bc4302d7dde275723d3fb60e9bf39d8e
+      2.9.5: a3aac268363085b0e36d5392bafb6bc7c2e17d1a
+      2.10.5: a3aac268363085b0e36d5392bafb6bc7c2e17d1a
+      2.11.4: 39bbf29f884e401a43d2af98c30539f335176513
+      2.12.5: 39bbf29f884e401a43d2af98c30539f335176513
+      2.13.7: 696065291c8dcb7cbec1a8dc47a55864ddd0d808
+      2.14.6: 696065291c8dcb7cbec1a8dc47a55864ddd0d808
+      2.15.4: 696065291c8dcb7cbec1a8dc47a55864ddd0d808
+      2.16.6: 696065291c8dcb7cbec1a8dc47a55864ddd0d808
+      2.17.0: 13e8ae1a74ea153fbfe36c0a08113b8f89595b00
+      2.17.1: 13e8ae1a74ea153fbfe36c0a08113b8f89595b00
+      2.17.2: 13e8ae1a74ea153fbfe36c0a08113b8f89595b00
+      2.17.3: 13e8ae1a74ea153fbfe36c0a08113b8f89595b00
+      2.17.4: 13e8ae1a74ea153fbfe36c0a08113b8f89595b00
+      2.17.5: 13e8ae1a74ea153fbfe36c0a08113b8f89595b00
+      2.17.6: 13e8ae1a74ea153fbfe36c0a08113b8f89595b00
+      2.18.0: 13e8ae1a74ea153fbfe36c0a08113b8f89595b00
+      2.18.1: 13e8ae1a74ea153fbfe36c0a08113b8f89595b00
+      2.18.2: 13e8ae1a74ea153fbfe36c0a08113b8f89595b00
+      2.18.3: 13e8ae1a74ea153fbfe36c0a08113b8f89595b00
+      2.18.4: 13e8ae1a74ea153fbfe36c0a08113b8f89595b00
+      2.18.5: 13e8ae1a74ea153fbfe36c0a08113b8f89595b00
+      2.19.0: 13e8ae1a74ea153fbfe36c0a08113b8f89595b00
+      2.19.1: 13e8ae1a74ea153fbfe36c0a08113b8f89595b00
+      2.19.2: f8255c58b0b03311a6d37ae461d44e7522c08491
+      2.19.3: f8255c58b0b03311a6d37ae461d44e7522c08491
+      2.19.4: f8255c58b0b03311a6d37ae461d44e7522c08491
+      2.19.5: f8255c58b0b03311a6d37ae461d44e7522c08491
+      2.19.6: f8255c58b0b03311a6d37ae461d44e7522c08491
+      2.20.0: 201fe4605e6de6698b4916de3fa8b194a71c5f64
+      2.20.1: 201fe4605e6de6698b4916de3fa8b194a71c5f64
+      2.20.2: 201fe4605e6de6698b4916de3fa8b194a71c5f64
+      2.20.3: 201fe4605e6de6698b4916de3fa8b194a71c5f64
+      2.20.4: 201fe4605e6de6698b4916de3fa8b194a71c5f64
+      2.20.5: 201fe4605e6de6698b4916de3fa8b194a71c5f64
+      2.21.0: 201fe4605e6de6698b4916de3fa8b194a71c5f64
+      2.21.1: 201fe4605e6de6698b4916de3fa8b194a71c5f64
+      2.21.2: 201fe4605e6de6698b4916de3fa8b194a71c5f64
+      2.21.3: 201fe4605e6de6698b4916de3fa8b194a71c5f64
+      2.21.4: 201fe4605e6de6698b4916de3fa8b194a71c5f64
+      2.22.0: 9776886cc5f18c5859d4e3af0bc22df96113a881
+      2.22.1: f2b007745ffc33a055f437faa3f0ba54ceab087e
+      2.22.2: f2b007745ffc33a055f437faa3f0ba54ceab087e
+      2.22.3: f2b007745ffc33a055f437faa3f0ba54ceab087e
+      2.22.4: f2b007745ffc33a055f437faa3f0ba54ceab087e
+      2.22.5: f2b007745ffc33a055f437faa3f0ba54ceab087e
+      2.23.0: f2b007745ffc33a055f437faa3f0ba54ceab087e
+      2.23.1: f2b007745ffc33a055f437faa3f0ba54ceab087e
+      2.23.2: f2b007745ffc33a055f437faa3f0ba54ceab087e
+      2.23.3: f2b007745ffc33a055f437faa3f0ba54ceab087e
+      2.23.4: f2b007745ffc33a055f437faa3f0ba54ceab087e
+      2.24.0: f2b007745ffc33a055f437faa3f0ba54ceab087e
+      2.24.1: f2b007745ffc33a055f437faa3f0ba54ceab087e
+      2.24.2: f2b007745ffc33a055f437faa3f0ba54ceab087e
+      2.24.3: f2b007745ffc33a055f437faa3f0ba54ceab087e
+      2.24.4: f2b007745ffc33a055f437faa3f0ba54ceab087e
+      2.25.0: ff58baf57350f365f22ec5f7ce1e0cf50351359b
+      2.25.1: ff58baf57350f365f22ec5f7ce1e0cf50351359b
+      2.25.2: ff58baf57350f365f22ec5f7ce1e0cf50351359b
+      2.25.3: ff58baf57350f365f22ec5f7ce1e0cf50351359b
+      2.25.4: ff58baf57350f365f22ec5f7ce1e0cf50351359b
+      2.25.5: ff58baf57350f365f22ec5f7ce1e0cf50351359b
+      2.26.0: ff58baf57350f365f22ec5f7ce1e0cf50351359b
+      2.26.1: ff58baf57350f365f22ec5f7ce1e0cf50351359b
+      2.26.2: ff58baf57350f365f22ec5f7ce1e0cf50351359b
+      2.26.3: ff58baf57350f365f22ec5f7ce1e0cf50351359b
+      2.27.0: 384992bd708c35d0869455bfb756632a1ced33f2
+      2.27.1: 384992bd708c35d0869455bfb756632a1ced33f2
+      2.28.0: 77f797459e96e94e3a6014d10c0c1bda00c8768d
+      2.28.1: 77f797459e96e94e3a6014d10c0c1bda00c8768d
+      2.29.0: 77f797459e96e94e3a6014d10c0c1bda00c8768d
+      2.29.1: 77f797459e96e94e3a6014d10c0c1bda00c8768d
+      2.29.2: 77f797459e96e94e3a6014d10c0c1bda00c8768d
+      2.29.3: 77f797459e96e94e3a6014d10c0c1bda00c8768d
+      2.30.0: 77f797459e96e94e3a6014d10c0c1bda00c8768d
+      2.30.1: 77f797459e96e94e3a6014d10c0c1bda00c8768d
+      2.30.2: 77f797459e96e94e3a6014d10c0c1bda00c8768d
+      2.30.3: 77f797459e96e94e3a6014d10c0c1bda00c8768d
+      2.30.4: 77f797459e96e94e3a6014d10c0c1bda00c8768d
+      2.30.5: 77f797459e96e94e3a6014d10c0c1bda00c8768d
+      2.30.6: 77f797459e96e94e3a6014d10c0c1bda00c8768d
+      2.30.7: 77f797459e96e94e3a6014d10c0c1bda00c8768d
+      2.30.8: 77f797459e96e94e3a6014d10c0c1bda00c8768d
+      2.30.9: 77f797459e96e94e3a6014d10c0c1bda00c8768d
+      2.31.0: 77f797459e96e94e3a6014d10c0c1bda00c8768d
+      2.31.1: 77f797459e96e94e3a6014d10c0c1bda00c8768d
+      2.31.2: 77f797459e96e94e3a6014d10c0c1bda00c8768d
+      2.31.3: 77f797459e96e94e3a6014d10c0c1bda00c8768d
+      2.31.4: 77f797459e96e94e3a6014d10c0c1bda00c8768d
+      2.31.5: 77f797459e96e94e3a6014d10c0c1bda00c8768d
+      2.31.6: 77f797459e96e94e3a6014d10c0c1bda00c8768d
+      2.31.7: 77f797459e96e94e3a6014d10c0c1bda00c8768d
+      2.31.8: 77f797459e96e94e3a6014d10c0c1bda00c8768d
+      2.32.0: 8496395b740ea161bc89ea066db49eb95e228c26
+      2.32.1: 8496395b740ea161bc89ea066db49eb95e228c26
+      2.32.2: 8496395b740ea161bc89ea066db49eb95e228c26
+      2.32.3: 8496395b740ea161bc89ea066db49eb95e228c26
+      2.32.4: 8496395b740ea161bc89ea066db49eb95e228c26
+      2.32.5: 8496395b740ea161bc89ea066db49eb95e228c26
+      2.32.6: 8496395b740ea161bc89ea066db49eb95e228c26
+      2.32.7: 8496395b740ea161bc89ea066db49eb95e228c26
+      2.33.0: c1f2cd288d496192b1029e59ff7a92359e1b1198
+      2.33.1: c1f2cd288d496192b1029e59ff7a92359e1b1198
+      2.33.2: c1f2cd288d496192b1029e59ff7a92359e1b1198
+      2.33.3: c1f2cd288d496192b1029e59ff7a92359e1b1198
+      2.33.4: c1f2cd288d496192b1029e59ff7a92359e1b1198
+      2.33.5: c1f2cd288d496192b1029e59ff7a92359e1b1198
+      2.33.6: c1f2cd288d496192b1029e59ff7a92359e1b1198
+      2.33.7: c1f2cd288d496192b1029e59ff7a92359e1b1198
+      2.33.8: c1f2cd288d496192b1029e59ff7a92359e1b1198
+      2.34.0: c1f2cd288d496192b1029e59ff7a92359e1b1198
+      2.34.1: c1f2cd288d496192b1029e59ff7a92359e1b1198
+      2.34.2: c1f2cd288d496192b1029e59ff7a92359e1b1198
+      2.34.3: c1f2cd288d496192b1029e59ff7a92359e1b1198
+      2.34.4: c1f2cd288d496192b1029e59ff7a92359e1b1198
+      2.34.5: c1f2cd288d496192b1029e59ff7a92359e1b1198
+      2.34.6: c1f2cd288d496192b1029e59ff7a92359e1b1198
+      2.34.7: c1f2cd288d496192b1029e59ff7a92359e1b1198
+      2.34.8: c1f2cd288d496192b1029e59ff7a92359e1b1198
+      2.35.0: 8567155f3e546b061f4a64aee252b80ab3e27e2a
+      2.35.1: 8567155f3e546b061f4a64aee252b80ab3e27e2a
+      2.35.2: 8567155f3e546b061f4a64aee252b80ab3e27e2a
+      2.35.3: 8567155f3e546b061f4a64aee252b80ab3e27e2a
+      2.35.4: 8567155f3e546b061f4a64aee252b80ab3e27e2a
+      2.35.5: 8567155f3e546b061f4a64aee252b80ab3e27e2a
+      2.35.6: 8567155f3e546b061f4a64aee252b80ab3e27e2a
+      2.35.7: 8567155f3e546b061f4a64aee252b80ab3e27e2a
+      2.35.8: 8567155f3e546b061f4a64aee252b80ab3e27e2a
+      2.36.0: 32f7e6163d58c1215034f5d599a90e3e9fcf84b4
+      2.36.1: 32f7e6163d58c1215034f5d599a90e3e9fcf84b4
+      2.36.2: 32f7e6163d58c1215034f5d599a90e3e9fcf84b4
+      2.36.3: 32f7e6163d58c1215034f5d599a90e3e9fcf84b4
+      2.36.4: 32f7e6163d58c1215034f5d599a90e3e9fcf84b4
+      2.36.5: 32f7e6163d58c1215034f5d599a90e3e9fcf84b4
+      2.36.6: 32f7e6163d58c1215034f5d599a90e3e9fcf84b4
+      2.37.0: 69f4ac48c946a35bba57c7c8797511ee65231d47
+      2.37.1: 69f4ac48c946a35bba57c7c8797511ee65231d47
+      2.37.2: 69f4ac48c946a35bba57c7c8797511ee65231d47
+      2.37.3: 69f4ac48c946a35bba57c7c8797511ee65231d47
+      2.37.4: 69f4ac48c946a35bba57c7c8797511ee65231d47
+      2.37.5: 69f4ac48c946a35bba57c7c8797511ee65231d47
+      2.37.6: 69f4ac48c946a35bba57c7c8797511ee65231d47
+      2.37.7: 69f4ac48c946a35bba57c7c8797511ee65231d47
+      2.38.0: 71b2434bb15acfa6720c087f54107b20b61a1b0c
+      2.38.1: 71b2434bb15acfa6720c087f54107b20b61a1b0c
+      2.38.2: dcf07e945fc4ac4874475bace3a886d8ddc2064b
+      2.38.3: dcf07e945fc4ac4874475bace3a886d8ddc2064b
+      2.38.4: dcf07e945fc4ac4874475bace3a886d8ddc2064b
+      2.38.5: dcf07e945fc4ac4874475bace3a886d8ddc2064b
+      2.39.0: f485f9b050c77bb17365499faca70a6e985afbf9
+      2.39.1: f485f9b050c77bb17365499faca70a6e985afbf9
+      2.39.2: f485f9b050c77bb17365499faca70a6e985afbf9
+      2.39.3: f485f9b050c77bb17365499faca70a6e985afbf9
+      2.39.4: f485f9b050c77bb17365499faca70a6e985afbf9
+      2.39.5: f485f9b050c77bb17365499faca70a6e985afbf9
+      2.40.0: f485f9b050c77bb17365499faca70a6e985afbf9
+      2.40.1: f485f9b050c77bb17365499faca70a6e985afbf9
+      2.40.2: f485f9b050c77bb17365499faca70a6e985afbf9
+      2.40.3: f485f9b050c77bb17365499faca70a6e985afbf9
+      2.40.4: f485f9b050c77bb17365499faca70a6e985afbf9
+      2.41.0: 0317be45e7d36ce28b9d4ac17272a2d4ca57d620
+      2.41.1: 0317be45e7d36ce28b9d4ac17272a2d4ca57d620
+      2.41.2: 0317be45e7d36ce28b9d4ac17272a2d4ca57d620
+      2.41.3: 0317be45e7d36ce28b9d4ac17272a2d4ca57d620
+      2.42.0: d7fc919fc1b767d7ef6d2ca2c8f2b227c63d6df0
+      2.42.1: 975b191d029bc4676e7ea0c0223f018da61f129c
+      2.42.2: 975b191d029bc4676e7ea0c0223f018da61f129c
+      2.42.3: 975b191d029bc4676e7ea0c0223f018da61f129c
+      2.42.4: 975b191d029bc4676e7ea0c0223f018da61f129c
+      2.43.0: 32781022f7f5c49bc62c2cc3ab09bee44cc04945
+      2.43.1: d49c40b5a0969c8f9c2b9ff6cc204e92af030f8e
+      2.43.2: d49c40b5a0969c8f9c2b9ff6cc204e92af030f8e
+      2.43.3: d49c40b5a0969c8f9c2b9ff6cc204e92af030f8e
+      2.43.4: d49c40b5a0969c8f9c2b9ff6cc204e92af030f8e
+      2.43.5: d49c40b5a0969c8f9c2b9ff6cc204e92af030f8e
+      2.43.6: d49c40b5a0969c8f9c2b9ff6cc204e92af030f8e
+      2.44.0: d49c40b5a0969c8f9c2b9ff6cc204e92af030f8e
+      2.44.1: d49c40b5a0969c8f9c2b9ff6cc204e92af030f8e
+      2.44.2: d49c40b5a0969c8f9c2b9ff6cc204e92af030f8e
+      2.44.3: d49c40b5a0969c8f9c2b9ff6cc204e92af030f8e
+      2.45.0: ff51a5c73ef7c16162ab8672c3649e5fd1f93607
+      2.45.1: ff51a5c73ef7c16162ab8672c3649e5fd1f93607
+      2.45.2: ff51a5c73ef7c16162ab8672c3649e5fd1f93607
+      2.45.3: ff51a5c73ef7c16162ab8672c3649e5fd1f93607
+      2.46.0: ff51a5c73ef7c16162ab8672c3649e5fd1f93607
+      2.46.1: c6e5fb1cba5ded1146eafe7b92bfcd9d2a4ee162
+      2.46.2: c6e5fb1cba5ded1146eafe7b92bfcd9d2a4ee162
+      2.46.3: c6e5fb1cba5ded1146eafe7b92bfcd9d2a4ee162
+      2.47.0: 2e9671e52ffadcf2df658fe919633f6aba936a06
+      2.47.1: 2e9671e52ffadcf2df658fe919633f6aba936a06
+      2.47.2: 2e9671e52ffadcf2df658fe919633f6aba936a06
+      2.48.0: 9c32b5e746e13047c56b6acd89d1308b139d8cd1
+      2.48.1: 9c32b5e746e13047c56b6acd89d1308b139d8cd1
+    latest-changes: 2.48.0
+    page-versions:
+    - name: 2.48.1
+    - name: 2.48.0
+      added: 5
+      removed: 3
+    - name: 2.47.1 &rarr; 2.47.2
+    - name: 2.47.0
+      added: 8
+      removed: 0
+    - name: 2.46.2 &rarr; 2.46.3
+    - name: 2.46.1
+      added: 7
+      removed: 1
+    - name: 2.45.1 &rarr; 2.46.0
+    - name: 2.45.0
+      added: 5
+      removed: 3
+    - name: 2.43.2 &rarr; 2.44.3
+    - name: 2.43.1
+      added: 4
+      removed: 4
+    - name: 2.43.0
+      added: 3
+      removed: 3
+    - name: 2.42.2 &rarr; 2.42.4
+    - name: 2.42.1
+      added: 1
+      removed: 1
+    - name: 2.42.0
+      added: 6
+      removed: 2
+    - name: 2.41.1 &rarr; 2.41.3
+    - name: 2.41.0
+      added: 6
+      removed: 2
+    - name: 2.39.1 &rarr; 2.40.4
+    - name: 2.39.0
+      added: 6
+      removed: 2
+    - name: 2.38.3 &rarr; 2.38.5
+    - name: 2.38.2
+      added: 6
+      removed: 2
+    - name: 2.38.1
+    - name: 2.38.0
+      added: 1
+      removed: 1
+    - name: 2.37.1 &rarr; 2.37.7
+    - name: 2.37.0
+      added: 2
+      removed: 6
+    - name: 2.36.1 &rarr; 2.36.6
+    - name: 2.36.0
+      added: 7
+      removed: 1
+    - name: 2.35.1 &rarr; 2.35.8
+    - name: 2.35.0
+      added: 8
+      removed: 0
+    - name: 2.33.1 &rarr; 2.34.8
+    - name: 2.33.0
+      added: 8
+      removed: 0
+    - name: 2.32.1 &rarr; 2.32.7
+    - name: 2.32.0
+      added: 7
+      removed: 1
+    - name: 2.28.1 &rarr; 2.31.8
+    - name: 2.28.0
+      added: 1
+      removed: 6
+    - name: 2.27.1
+    - name: 2.27.0
+      added: 5
+      removed: 3
+    - name: 2.25.1 &rarr; 2.26.3
+    - name: 2.25.0
+      added: 2
+      removed: 2
+    - name: 2.22.2 &rarr; 2.24.4
+    - name: 2.22.1
+      added: 7
+      removed: 1
+    - name: 2.22.0
+      added: 5
+      removed: 2
+    - name: 2.20.1 &rarr; 2.21.4
+    - name: 2.20.0
+      added: 8
+      removed: 0
+    - name: 2.19.3 &rarr; 2.19.6
+    - name: 2.19.2
+      added: 4
+      removed: 1
+    - name: 2.17.1 &rarr; 2.19.1
+    - name: 2.17.0
+      added: 5
+      removed: 0
+    - name: 2.14.6 &rarr; 2.16.6
+    - name: 2.13.7
+      added: 4
+      removed: 4
+    - name: 2.12.5
+    - name: 2.11.4
+      added: 7
+      removed: 1
+    - name: 2.10.5
+    - name: 2.9.5
+      added: 6
+      removed: 2
+    - name: 2.8.6
+      added: 5
+      removed: 0
+    - name: 2.5.6 &rarr; 2.7.6
+    - name: 2.4.12
+      added: 6
+      removed: 2
+    - name: 2.3.10
+      added: 8
+      removed: 0
+    - name: 2.2.3
+    - name: 2.1.4
+      added: 8
+      removed: 0
+    - name: 2.0.5
+      added: 8
+      removed: 0
+    diff-cache:
+      ce20a0533295750b94bd23a9cb5c67430f8503ba..d3b4cbca6a79491fc719c451995a3667cc68b397:
+      - 8
+      - 0
+      - 0
+      d3b4cbca6a79491fc719c451995a3667cc68b397..ff290873af26a1047e859571a8e319da8570a23c:
+      - 8
+      - 0
+      - 0
+      ff290873af26a1047e859571a8e319da8570a23c..7983213f3ace118da2fd286c613aba364e124b89:
+      - 6
+      - 2
+      - 0
+      7983213f3ace118da2fd286c613aba364e124b89..55011116bc4302d7dde275723d3fb60e9bf39d8e:
+      - 5
+      - 0
+      - 3
+      55011116bc4302d7dde275723d3fb60e9bf39d8e..a3aac268363085b0e36d5392bafb6bc7c2e17d1a:
+      - 6
+      - 2
+      - 0
+      a3aac268363085b0e36d5392bafb6bc7c2e17d1a..39bbf29f884e401a43d2af98c30539f335176513:
+      - 7
+      - 1
+      - 0
+      39bbf29f884e401a43d2af98c30539f335176513..696065291c8dcb7cbec1a8dc47a55864ddd0d808:
+      - 4
+      - 4
+      - 0
+      696065291c8dcb7cbec1a8dc47a55864ddd0d808..13e8ae1a74ea153fbfe36c0a08113b8f89595b00:
+      - 5
+      - 0
+      - 3
+      13e8ae1a74ea153fbfe36c0a08113b8f89595b00..f8255c58b0b03311a6d37ae461d44e7522c08491:
+      - 4
+      - 1
+      - 3
+      f8255c58b0b03311a6d37ae461d44e7522c08491..201fe4605e6de6698b4916de3fa8b194a71c5f64:
+      - 8
+      - 0
+      - 0
+      201fe4605e6de6698b4916de3fa8b194a71c5f64..9776886cc5f18c5859d4e3af0bc22df96113a881:
+      - 5
+      - 2
+      - 1
+      9776886cc5f18c5859d4e3af0bc22df96113a881..f2b007745ffc33a055f437faa3f0ba54ceab087e:
+      - 7
+      - 1
+      - 0
+      f2b007745ffc33a055f437faa3f0ba54ceab087e..ff58baf57350f365f22ec5f7ce1e0cf50351359b:
+      - 2
+      - 2
+      - 4
+      ff58baf57350f365f22ec5f7ce1e0cf50351359b..384992bd708c35d0869455bfb756632a1ced33f2:
+      - 5
+      - 3
+      - 0
+      384992bd708c35d0869455bfb756632a1ced33f2..77f797459e96e94e3a6014d10c0c1bda00c8768d:
+      - 1
+      - 6
+      - 1
+      77f797459e96e94e3a6014d10c0c1bda00c8768d..8496395b740ea161bc89ea066db49eb95e228c26:
+      - 7
+      - 1
+      - 0
+      8496395b740ea161bc89ea066db49eb95e228c26..c1f2cd288d496192b1029e59ff7a92359e1b1198:
+      - 8
+      - 0
+      - 0
+      c1f2cd288d496192b1029e59ff7a92359e1b1198..8567155f3e546b061f4a64aee252b80ab3e27e2a:
+      - 8
+      - 0
+      - 0
+      8567155f3e546b061f4a64aee252b80ab3e27e2a..32f7e6163d58c1215034f5d599a90e3e9fcf84b4:
+      - 7
+      - 1
+      - 0
+      32f7e6163d58c1215034f5d599a90e3e9fcf84b4..69f4ac48c946a35bba57c7c8797511ee65231d47:
+      - 2
+      - 6
+      - 0
+      69f4ac48c946a35bba57c7c8797511ee65231d47..71b2434bb15acfa6720c087f54107b20b61a1b0c:
+      - 1
+      - 1
+      - 6
+      71b2434bb15acfa6720c087f54107b20b61a1b0c..dcf07e945fc4ac4874475bace3a886d8ddc2064b:
+      - 6
+      - 2
+      - 0
+      dcf07e945fc4ac4874475bace3a886d8ddc2064b..f485f9b050c77bb17365499faca70a6e985afbf9:
+      - 6
+      - 2
+      - 0
+      f485f9b050c77bb17365499faca70a6e985afbf9..0317be45e7d36ce28b9d4ac17272a2d4ca57d620:
+      - 6
+      - 2
+      - 0
+      0317be45e7d36ce28b9d4ac17272a2d4ca57d620..d7fc919fc1b767d7ef6d2ca2c8f2b227c63d6df0:
+      - 6
+      - 2
+      - 0
+      d7fc919fc1b767d7ef6d2ca2c8f2b227c63d6df0..975b191d029bc4676e7ea0c0223f018da61f129c:
+      - 1
+      - 1
+      - 6
+      975b191d029bc4676e7ea0c0223f018da61f129c..32781022f7f5c49bc62c2cc3ab09bee44cc04945:
+      - 3
+      - 3
+      - 2
+      32781022f7f5c49bc62c2cc3ab09bee44cc04945..d49c40b5a0969c8f9c2b9ff6cc204e92af030f8e:
+      - 4
+      - 4
+      - 0
+      d49c40b5a0969c8f9c2b9ff6cc204e92af030f8e..ff51a5c73ef7c16162ab8672c3649e5fd1f93607:
+      - 5
+      - 3
+      - 0
+      ff51a5c73ef7c16162ab8672c3649e5fd1f93607..c6e5fb1cba5ded1146eafe7b92bfcd9d2a4ee162:
+      - 7
+      - 1
+      - 0
+      c6e5fb1cba5ded1146eafe7b92bfcd9d2a4ee162..2e9671e52ffadcf2df658fe919633f6aba936a06:
+      - 8
+      - 0
+      - 0
+      2e9671e52ffadcf2df658fe919633f6aba936a06..9c32b5e746e13047c56b6acd89d1308b139d8cd1:
+      - 5
+      - 3
+      - 0
+  ReviewingGuidelines:
+    version-map:
+      2.38.0: 660e60c007657c8aeaaf25cc41138f04b83f15ff
+      2.38.1: 660e60c007657c8aeaaf25cc41138f04b83f15ff
+      2.38.2: 660e60c007657c8aeaaf25cc41138f04b83f15ff
+      2.38.3: 660e60c007657c8aeaaf25cc41138f04b83f15ff
+      2.38.4: 660e60c007657c8aeaaf25cc41138f04b83f15ff
+      2.38.5: 660e60c007657c8aeaaf25cc41138f04b83f15ff
+      2.39.0: 660e60c007657c8aeaaf25cc41138f04b83f15ff
+      2.39.1: 660e60c007657c8aeaaf25cc41138f04b83f15ff
+      2.39.2: 660e60c007657c8aeaaf25cc41138f04b83f15ff
+      2.39.3: 660e60c007657c8aeaaf25cc41138f04b83f15ff
+      2.39.4: 660e60c007657c8aeaaf25cc41138f04b83f15ff
+      2.39.5: 660e60c007657c8aeaaf25cc41138f04b83f15ff
+      2.40.0: 660e60c007657c8aeaaf25cc41138f04b83f15ff
+      2.40.1: 660e60c007657c8aeaaf25cc41138f04b83f15ff
+      2.40.2: 660e60c007657c8aeaaf25cc41138f04b83f15ff
+      2.40.3: 660e60c007657c8aeaaf25cc41138f04b83f15ff
+      2.40.4: 660e60c007657c8aeaaf25cc41138f04b83f15ff
+      2.41.0: 660e60c007657c8aeaaf25cc41138f04b83f15ff
+      2.41.1: 660e60c007657c8aeaaf25cc41138f04b83f15ff
+      2.41.2: 660e60c007657c8aeaaf25cc41138f04b83f15ff
+      2.41.3: 660e60c007657c8aeaaf25cc41138f04b83f15ff
+      2.42.0: 660e60c007657c8aeaaf25cc41138f04b83f15ff
+      2.42.1: 660e60c007657c8aeaaf25cc41138f04b83f15ff
+      2.42.2: 660e60c007657c8aeaaf25cc41138f04b83f15ff
+      2.42.3: 660e60c007657c8aeaaf25cc41138f04b83f15ff
+      2.42.4: 660e60c007657c8aeaaf25cc41138f04b83f15ff
+      2.43.0: 384de0c2eb9bf8e5b95cd22ef5740abd694022d6
+      2.43.1: 384de0c2eb9bf8e5b95cd22ef5740abd694022d6
+      2.43.2: 384de0c2eb9bf8e5b95cd22ef5740abd694022d6
+      2.43.3: 384de0c2eb9bf8e5b95cd22ef5740abd694022d6
+      2.43.4: 384de0c2eb9bf8e5b95cd22ef5740abd694022d6
+      2.43.5: 384de0c2eb9bf8e5b95cd22ef5740abd694022d6
+      2.43.6: 384de0c2eb9bf8e5b95cd22ef5740abd694022d6
+      2.44.0: 384de0c2eb9bf8e5b95cd22ef5740abd694022d6
+      2.44.1: 384de0c2eb9bf8e5b95cd22ef5740abd694022d6
+      2.44.2: 384de0c2eb9bf8e5b95cd22ef5740abd694022d6
+      2.44.3: 384de0c2eb9bf8e5b95cd22ef5740abd694022d6
+      2.45.0: 384de0c2eb9bf8e5b95cd22ef5740abd694022d6
+      2.45.1: 384de0c2eb9bf8e5b95cd22ef5740abd694022d6
+      2.45.2: 384de0c2eb9bf8e5b95cd22ef5740abd694022d6
+      2.45.3: 384de0c2eb9bf8e5b95cd22ef5740abd694022d6
+      2.46.0: 384de0c2eb9bf8e5b95cd22ef5740abd694022d6
+      2.46.1: 384de0c2eb9bf8e5b95cd22ef5740abd694022d6
+      2.46.2: 384de0c2eb9bf8e5b95cd22ef5740abd694022d6
+      2.46.3: 384de0c2eb9bf8e5b95cd22ef5740abd694022d6
+      2.47.0: 251eb6d9ec08d864904404e8cc131eca8ec72284
+      2.47.1: 251eb6d9ec08d864904404e8cc131eca8ec72284
+      2.47.2: 251eb6d9ec08d864904404e8cc131eca8ec72284
+      2.48.0: 251eb6d9ec08d864904404e8cc131eca8ec72284
+      2.48.1: 251eb6d9ec08d864904404e8cc131eca8ec72284
+    latest-changes: 2.47.0
+    page-versions:
+    - name: 2.47.1 &rarr; 2.48.1
+    - name: 2.47.0
+      added: 7
+      removed: 1
+    - name: 2.43.1 &rarr; 2.46.3
+    - name: 2.43.0
+      added: 2
+      removed: 2
+    - name: 2.38.1 &rarr; 2.42.4
+    - name: 2.38.0
+      added: 8
+      removed: 0
+    diff-cache:
+      660e60c007657c8aeaaf25cc41138f04b83f15ff..384de0c2eb9bf8e5b95cd22ef5740abd694022d6:
+      - 2
+      - 2
+      - 4
+      384de0c2eb9bf8e5b95cd22ef5740abd694022d6..251eb6d9ec08d864904404e8cc131eca8ec72284:
+      - 7
+      - 1
+      - 0
+  BreakingChanges:
+    version-map:
+      2.46.0: b8a56b0af0407301072e4e43a966b7a784900549
+      2.46.1: b8a56b0af0407301072e4e43a966b7a784900549
+      2.46.2: b8a56b0af0407301072e4e43a966b7a784900549
+      2.46.3: b8a56b0af0407301072e4e43a966b7a784900549
+      2.47.0: d2d2e94cbec5178624611283429cb5f21861ff74
+      2.47.1: d2d2e94cbec5178624611283429cb5f21861ff74
+      2.47.2: d2d2e94cbec5178624611283429cb5f21861ff74
+      2.48.0: ed8d63cdf8567e70f4d62c88daca3133a9142b79
+      2.48.1: ed8d63cdf8567e70f4d62c88daca3133a9142b79
+    latest-changes: 2.48.0
+    page-versions:
+    - name: 2.48.1
+    - name: 2.48.0
+      added: 8
+      removed: 0
+    - name: 2.47.1 &rarr; 2.47.2
+    - name: 2.47.0
+      added: 8
+      removed: 0
+    - name: 2.46.1 &rarr; 2.46.3
+    - name: 2.46.0
+      added: 8
+      removed: 0
+    diff-cache:
+      b8a56b0af0407301072e4e43a966b7a784900549..d2d2e94cbec5178624611283429cb5f21861ff74:
+      - 8
+      - 0
+      - 0
+      d2d2e94cbec5178624611283429cb5f21861ff74..ed8d63cdf8567e70f4d62c88daca3133a9142b79:
+      - 8
+      - 0
+      - 0
 latest-version: 2.48.1
 l10n:
   commit_sha: 58364de089a809a1ad4e3790558e6d6b5b5719da

From 18d4071fc52aa45e6cb402c5b146336711bdd3cd Mon Sep 17 00:00:00 2001
From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Sat, 1 Mar 2025 21:20:23 +0100
Subject: [PATCH 6/6] community: use a shortcode...

Only so-called "shortcodes" are supported as Hugo constructs in the
`content/` pages. I had forgottent that when I wrote 1deace4d4 (docs:
include more Git project-specific pages, 2025-03-01).

Thankfully, the `ci` build pointed it out (specifically, the link
checker step).

Normally, I would now squash the fix into the offending commit, but
there have been automated changes in the meantime (which took a bit over
a quarter hour to run) and in the interest of some convenience for
myself (and to be able to go relax instead of pouring more time into
this topic branch than I already have), and of keeping the original
commits as made by the automated workflow run, I will just leave this
fix on top of the automated changes.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 content/community/_index.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/content/community/_index.html b/content/community/_index.html
index 1d752ee8ed..815608d84e 100644
--- a/content/community/_index.html
+++ b/content/community/_index.html
@@ -101,7 +101,7 @@ <h2 id="git-rev-news"><a class="anchor" href="#git-rev-news"></a> Newsletter </h
   <h2 id="contributing"><a class="anchor" href="#contributing"></a> Contributing to Git </h2>
 
   <p>
-    The <a href="https://github.com/git/git/tree/master/Documentation">Documentation directory</a> in the Git source code has several files of interest to developers who are looking to help contribute. After reading the <a href="{{ relURL "docs/CodingGuidelines" }}">coding guidelines</a> and <a href="https://github.com/git/git/blob/master/CODE_OF_CONDUCT.md">code of conduct</a>, you can learn <a href="{{< relurl "docs/SubmittingPatches" >}}">how to submit patches</a>. If you are just starting out, you can read the <a href="{{< relurl "docs/MyFirstContribution" >}}">My First Contribution tutorial</a>. For those looking to get more deeply involved, there is a <a href="https://github.com/git/git/blob/master/Documentation/howto/maintain-git.txt">howto for Git maintainers</a>.
+    The <a href="https://github.com/git/git/tree/master/Documentation">Documentation directory</a> in the Git source code has several files of interest to developers who are looking to help contribute. After reading the <a href="{{< relurl "docs/CodingGuidelines" >}}">coding guidelines</a> and <a href="https://github.com/git/git/blob/master/CODE_OF_CONDUCT.md">code of conduct</a>, you can learn <a href="{{< relurl "docs/SubmittingPatches" >}}">how to submit patches</a>. If you are just starting out, you can read the <a href="{{< relurl "docs/MyFirstContribution" >}}">My First Contribution tutorial</a>. For those looking to get more deeply involved, there is a <a href="https://github.com/git/git/blob/master/Documentation/howto/maintain-git.txt">howto for Git maintainers</a>.
   </p>
 
   <p>