docs
Elijah Newren 2 years ago
parent 8e2d3ce4cf
commit 01ead41196

@ -1427,13 +1427,111 @@ dependencies. <code>prove</code> also makes the output nicer.</td>
</div>
</div>
<div class="sect1">
<h2 id="ready-to-share">Getting Ready to Share</h2>
<h2 id="ready-to-share">Getting Ready to Share: Anatomy of a Patch Series</h2>
<div class="sectionbody">
<div class="paragraph"><p>You may have noticed already that the Git project performs its code reviews via
emailed patches, which are then applied by the maintainer when they are ready
and approved by the community. The Git project does not accept patches from
and approved by the community. The Git project does not accept contributions from
pull requests, and the patches emailed for review need to be formatted a
specific way. At this point the tutorial diverges, in order to demonstrate two
specific way.</p></div>
<div class="paragraph"><p>Before taking a look at how to convert your commits into emailed patches,
let&#8217;s analyze what the end result, a "patch series", looks like. Here is an
<a href="https://lore.kernel.org/git/pull.1218.git.git.1645209647.gitgitgadget@gmail.com/">example</a> of the summary view for a patch series on the web interface of
the <a href="https://lore.kernel.org/git/">Git mailing list archive</a>:</p></div>
<div class="listingblock">
<div class="content">
<pre><code>2022-02-18 18:40 [PATCH 0/3] libify reflog John Cai via GitGitGadget
2022-02-18 18:40 ` [PATCH 1/3] reflog: libify delete reflog function and helpers John Cai via GitGitGadget
2022-02-18 19:10 ` Ævar Arnfjörð Bjarmason [this message]
2022-02-18 19:39 ` Taylor Blau
2022-02-18 19:48 ` Ævar Arnfjörð Bjarmason
2022-02-18 19:35 ` Taylor Blau
2022-02-21 1:43 ` John Cai
2022-02-21 1:50 ` Taylor Blau
2022-02-23 19:50 ` John Cai
2022-02-18 20:00 ` // other replies ellided
2022-02-18 18:40 ` [PATCH 2/3] reflog: call reflog_delete from reflog.c John Cai via GitGitGadget
2022-02-18 19:15 ` Ævar Arnfjörð Bjarmason
2022-02-18 20:26 ` Junio C Hamano
2022-02-18 18:40 ` [PATCH 3/3] stash: call reflog_delete from reflog.c John Cai via GitGitGadget
2022-02-18 19:20 ` Ævar Arnfjörð Bjarmason
2022-02-19 0:21 ` Taylor Blau
2022-02-22 2:36 ` John Cai
2022-02-22 10:51 ` Ævar Arnfjörð Bjarmason
2022-02-18 19:29 ` [PATCH 0/3] libify reflog Ævar Arnfjörð Bjarmason
2022-02-22 18:30 ` [PATCH v2 0/3] libify reflog John Cai via GitGitGadget
2022-02-22 18:30 ` [PATCH v2 1/3] stash: add test to ensure reflog --rewrite --updatref behavior John Cai via GitGitGadget
2022-02-23 8:54 ` Ævar Arnfjörð Bjarmason
2022-02-23 21:27 ` Junio C Hamano
// continued</code></pre>
</div></div>
<div class="paragraph"><p>We can note a few things:</p></div>
<div class="ulist"><ul>
<li>
<p>
Each commit is sent as a separate email, with the commit message title as
subject, prefixed with "[PATCH <em>i</em>/<em>n</em>]" for the <em>i</em>-th commit of an
<em>n</em>-commit series.
</p>
</li>
<li>
<p>
Each patch is sent as a reply to an introductory email called the <em>cover
letter</em> of the series, prefixed "[PATCH 0/<em>n</em>]".
</p>
</li>
<li>
<p>
Subsequent iterations of the patch series are labelled "PATCH v2", "PATCH
v3", etc. in place of "PATCH". For example, "[PATCH v2 1/3]" would be the first of
three patches in the second iteration. Each iteration is sent with a new cover
letter (like "[PATCH v2 0/3]" above), itself a reply to the cover letter of the
previous iteration (more on that below).
</p>
</li>
</ul></div>
<div class="admonitionblock">
<table><tr>
<td class="icon">
<div class="title">Note</div>
</td>
<td class="content">A single-patch topic is sent with "[PATCH]", "[PATCH v2]", etc. without
<em>i</em>/<em>n</em> numbering (in the above thread overview, no single-patch topic appears,
though).</td>
</tr></table>
</div>
<div class="sect2">
<h3 id="cover-letter">The cover letter</h3>
<div class="paragraph"><p>In addition to an email per patch, the Git community also expects your patches
to come with a cover letter. This is an important component of change
submission as it explains to the community from a high level what you&#8217;re trying
to do, and why, in a way that&#8217;s more apparent than just looking at your
patches.</p></div>
<div class="paragraph"><p>The title of your cover letter should be something which succinctly covers the
purpose of your entire topic branch. It&#8217;s often in the imperative mood, just
like our commit message titles. Here is how we&#8217;ll title our series:</p></div>
<div class="paragraph"><p>---
Add the <em>psuh</em> command
---</p></div>
<div class="paragraph"><p>The body of the cover letter is used to give additional context to reviewers.
Be sure to explain anything your patches don&#8217;t make clear on their own, but
remember that since the cover letter is not recorded in the commit history,
anything that might be useful to future readers of the repository&#8217;s history
should also be in your commit messages.</p></div>
<div class="paragraph"><p>Here&#8217;s an example body for <code>psuh</code>:</p></div>
<div class="listingblock">
<div class="content">
<pre><code>Our internal metrics indicate widespread interest in the command
git-psuh - that is, many users are trying to use it, but finding it is
unavailable, using some unknown workaround instead.
The following handful of patches add the psuh command and implement some
handy features on top of it.
This patchset is part of the MyFirstContribution tutorial and should not
be merged.</code></pre>
</div></div>
<div class="paragraph"><p>At this point the tutorial diverges, in order to demonstrate two
different methods of formatting your patchset and getting it reviewed.</p></div>
<div class="paragraph"><p>The first method to be covered is GitGitGadget, which is useful for those
already familiar with GitHub&#8217;s common pull request workflow. This method
@ -1447,6 +1545,7 @@ the same; the review process will be covered after the sections on GitGitGadget
and <code>git send-email</code>.</p></div>
</div>
</div>
</div>
<div class="sect1">
<h2 id="howto-ggg">Sending Patches via GitGitGadget</h2>
<div class="sectionbody">
@ -1511,8 +1610,27 @@ opening a Pull Request against <code>gitgitgadget/git</code>. Head to
<a href="https://github.com/gitgitgadget/git">https://github.com/gitgitgadget/git</a> and open a PR either with the "New pull
request" button or the convenient "Compare &amp; pull request" button that may
appear with the name of your newly pushed branch.</p></div>
<div class="paragraph"><p>Review the PR&#8217;s title and description, as it&#8217;s used by GitGitGadget as the cover
letter for your change. When you&#8217;re happy, submit your pull request.</p></div>
<div class="paragraph"><p>Review the PR&#8217;s title and description, as they&#8217;re used by GitGitGadget
respectively as the subject and body of the cover letter for your change. Refer
to <a href="#cover-letter">"The cover letter"</a> above for advice on how to title your
submission and what content to include in the description.</p></div>
<div class="admonitionblock">
<table><tr>
<td class="icon">
<div class="title">Note</div>
</td>
<td class="content">For single-patch contributions, your commit message should already be
meaningful and explain at a high level the purpose (what is happening and why)
of your patch, so you usually do not need any additional context. In that case,
remove the PR description that GitHub automatically generates from your commit
message (your PR description should be empty). If you do need to supply even
more context, you can do so in that space and it will be appended to the email
that GitGitGadget will send, between the three-dash line and the diffstat
(see <a href="#single-patch">Bonus Chapter: One-Patch Changes</a> for how this looks once
submitted).</td>
</tr></table>
</div>
<div class="paragraph"><p>When you&#8217;re happy, submit your pull request.</p></div>
</div>
<div class="sect2">
<h3 id="run-ci-ggg">Running CI and Getting Ready to Send</h3>
@ -1598,16 +1716,47 @@ is out of scope for the context of this tutorial.</p></div>
themselves, you&#8217;ll need to prepare the patches. Luckily, this is pretty simple:</p></div>
<div class="listingblock">
<div class="content">
<pre><code>$ git format-patch --cover-letter -o psuh/ master..psuh</code></pre>
<pre><code>$ git format-patch --cover-letter -o psuh/ --base=auto psuh@{u}..psuh</code></pre>
</div></div>
<div class="paragraph"><p>The <code>--cover-letter</code> parameter tells <code>format-patch</code> to create a cover letter
template for you. You will need to fill in the template before you&#8217;re ready
to send - but for now, the template will be next to your other patches.</p></div>
<div class="paragraph"><p>The <code>-o psuh/</code> parameter tells <code>format-patch</code> to place the patch files into a
directory. This is useful because <code>git send-email</code> can take a directory and
send out all the patches from there.</p></div>
<div class="paragraph"><p><code>master..psuh</code> tells <code>format-patch</code> to generate patches for the difference
between <code>master</code> and <code>psuh</code>. It will make one patch file per commit. After you
<div class="olist arabic"><ol class="arabic">
<li>
<p>
The <code>--cover-letter</code> option tells <code>format-patch</code> to create a
cover letter template for you. You will need to fill in the
template before you&#8217;re ready to send - but for now, the template
will be next to your other patches.
</p>
</li>
<li>
<p>
The <code>-o psuh/</code> option tells <code>format-patch</code> to place the patch
files into a directory. This is useful because <code>git send-email</code>
can take a directory and send out all the patches from there.
</p>
</li>
<li>
<p>
The <code>--base=auto</code> option tells the command to record the "base
commit", on which the recipient is expected to apply the patch
series. The <code>auto</code> value will cause <code>format-patch</code> to compute
the base commit automatically, which is the merge base of tip
commit of the remote-tracking branch and the specified revision
range.
</p>
</li>
<li>
<p>
The <code>psuh@{u}..psuh</code> option tells <code>format-patch</code> to generate
patches for the commits you created on the <code>psuh</code> branch since it
forked from its upstream (which is <code>origin/master</code> if you
followed the example in the "Set up your workspace" section). If
you are already on the <code>psuh</code> branch, you can just say <code>@{u}</code>,
which means "commits on the current branch since it forked from
its upstream", which is the same thing.
</p>
</li>
</ol></div>
<div class="paragraph"><p>The command will make one patch file per commit. After you
run, you can go have a look at each of the patches with your favorite text
editor and make sure everything looks alright; however, it&#8217;s not recommended to
make code fixups via the patch file. It&#8217;s a better idea to make the change the
@ -1633,42 +1782,23 @@ but want reviewers to look at what they have so far. You can add this flag with
directory you specified - you&#8217;re nearly ready to send out your review!</p></div>
</div>
<div class="sect2">
<h3 id="cover-letter">Preparing Email</h3>
<div class="paragraph"><p>In addition to an email per patch, the Git community also expects your patches
to come with a cover letter, typically with a subject line [PATCH 0/x] (where
x is the number of patches you&#8217;re sending). Since you invoked <code>format-patch</code>
with <code>--cover-letter</code>, you&#8217;ve already got a template ready. Open it up in your
favorite editor.</p></div>
<h3 id="preparing-cover-letter">Preparing Email</h3>
<div class="paragraph"><p>Since you invoked <code>format-patch</code> with <code>--cover-letter</code>, you&#8217;ve already got a
cover letter template ready. Open it up in your favorite editor.</p></div>
<div class="paragraph"><p>You should see a number of headers present already. Check that your <code>From:</code>
header is correct. Then modify your <code>Subject:</code> to something which succinctly
covers the purpose of your entire topic branch, for example:</p></div>
header is correct. Then modify your <code>Subject:</code> (see <a href="#cover-letter">above</a> for
how to choose good title for your patch series):</p></div>
<div class="listingblock">
<div class="content">
<pre><code>Subject: [PATCH 0/7] adding the 'psuh' command</code></pre>
<pre><code>Subject: [PATCH 0/7] Add the 'psuh' command</code></pre>
</div></div>
<div class="paragraph"><p>Make sure you retain the &#8220;[PATCH 0/X]&#8221; part; that&#8217;s what indicates to the Git
community that this email is the beginning of a review, and many reviewers
filter their email for this type of flag.</p></div>
community that this email is the beginning of a patch series, and many
reviewers filter their email for this type of flag.</p></div>
<div class="paragraph"><p>You&#8217;ll need to add some extra parameters when you invoke <code>git send-email</code> to add
the cover letter.</p></div>
<div class="paragraph"><p>Next you&#8217;ll have to fill out the body of your cover letter. This is an important
component of change submission as it explains to the community from a high level
what you&#8217;re trying to do, and why, in a way that&#8217;s more apparent than just
looking at your diff. Be sure to explain anything your diff doesn&#8217;t make clear
on its own.</p></div>
<div class="paragraph"><p>Here&#8217;s an example body for <code>psuh</code>:</p></div>
<div class="listingblock">
<div class="content">
<pre><code>Our internal metrics indicate widespread interest in the command
git-psuh - that is, many users are trying to use it, but finding it is
unavailable, using some unknown workaround instead.
The following handful of patches add the psuh command and implement some
handy features on top of it.
This patchset is part of the MyFirstContribution tutorial and should not
be merged.</code></pre>
</div></div>
<div class="paragraph"><p>Next you&#8217;ll have to fill out the body of your cover letter. Again, see
<a href="#cover-letter">above</a> for what content to include.</p></div>
<div class="paragraph"><p>The template created by <code>git format-patch --cover-letter</code> includes a diffstat.
This gives reviewers a summary of what they&#8217;re in for when reviewing your topic.
The one generated for <code>psuh</code> from the sample implementation looks like this:</p></div>
@ -1750,7 +1880,7 @@ as version "2". For instance, you may notice that your v2 patches are
all named like <code>v2-000n-my-commit-subject.patch</code>. <code>-v2</code> will also format
your patches by prefixing them with "[PATCH v2]" instead of "[PATCH]",
and your range-diff will be prefaced with "Range-diff against v1".</p></div>
<div class="paragraph"><p>Afer you run this command, <code>format-patch</code> will output the patches to the <code>psuh/</code>
<div class="paragraph"><p>After you run this command, <code>format-patch</code> will output the patches to the <code>psuh/</code>
directory, alongside the v1 patches. Using a single directory makes it easy to
refer to the old v1 patches while proofreading the v2 patches, but you will need
to be careful to send out only the v2 patches. We will use a pattern like
@ -1930,7 +2060,7 @@ should generate your diffs from <code>&lt;topic&gt;..&lt;mybranch&gt;</code> and
<div id="footer">
<div id="footer-text">
Last updated
2021-11-15 13:27:01 PST
2022-10-08 14:40:28 PDT
</div>
</div>
</body>

@ -814,15 +814,20 @@ running, enable trace output by setting the environment variable <code>GIT_TRACE
</tr></table>
</div>
<div class="paragraph"><p>Add usage text and <code>-h</code> handling, like all subcommands should consistently do
(our test suite will notice and complain if you fail to do so).</p></div>
(our test suite will notice and complain if you fail to do so).
We&#8217;ll need to include the <code>parse-options.h</code> header.</p></div>
<div class="listingblock">
<div class="content">
<pre><code>int cmd_walken(int argc, const char **argv, const char *prefix)
<pre><code>#include "parse-options.h"
...
int cmd_walken(int argc, const char **argv, const char *prefix)
{
const char * const walken_usage[] = {
N_("git walken"),
NULL,
}
};
struct option options[] = {
OPT_END()
};
@ -973,10 +978,15 @@ callback will be invoked once per each configuration value which Git knows about
<div class="paragraph"><p>Similarly to the default values, we don&#8217;t have anything to do here yet
ourselves; however, we should call <code>git_default_config()</code> if we aren&#8217;t calling
any other existing config callbacks.</p></div>
<div class="paragraph"><p>Add a new function to <code>builtin/walken.c</code>:</p></div>
<div class="paragraph"><p>Add a new function to <code>builtin/walken.c</code>.
We&#8217;ll also need to include the <code>config.h</code> header:</p></div>
<div class="listingblock">
<div class="content">
<pre><code>static int git_walken_config(const char *var, const char *value, void *cb)
<pre><code>#include "config.h"
...
static int git_walken_config(const char *var, const char *value, void *cb)
{
/*
* For now, we don't have any custom configuration, so fall back to
@ -1005,10 +1015,15 @@ initialize the <code>rev_info</code> object which we will use to perform the wal
typically done by calling <code>repo_init_revisions()</code> with the repository you intend
to target, as well as the <code>prefix</code> argument of <code>cmd_walken</code> and your <code>rev_info</code>
struct.</p></div>
<div class="paragraph"><p>Add the <code>struct rev_info</code> and the <code>repo_init_revisions()</code> call:</p></div>
<div class="paragraph"><p>Add the <code>struct rev_info</code> and the <code>repo_init_revisions()</code> call.
We&#8217;ll also need to include the <code>revision.h</code> header:</p></div>
<div class="listingblock">
<div class="content">
<pre><code>int cmd_walken(int argc, const char **argv, const char *prefix)
<pre><code>#include "revision.h"
...
int cmd_walken(int argc, const char **argv, const char *prefix)
{
/* This can go wherever you like in your declarations.*/
struct rev_info rev;
@ -1300,18 +1315,13 @@ function shows that the all-object walk is being performed by
<code>traverse_commit_list()</code> or <code>traverse_commit_list_filtered()</code>. Those two
functions reside in <code>list-objects.c</code>; examining the source shows that, despite
the name, these functions traverse all kinds of objects. Let&#8217;s have a look at
the arguments to <code>traverse_commit_list_filtered()</code>, which are a superset of the
arguments to the unfiltered version.</p></div>
the arguments to <code>traverse_commit_list()</code>.</p></div>
<div class="ulist"><ul>
<li>
<p>
<code>struct list_objects_filter_options *filter_options</code>: This is a struct which
stores a filter-spec as outlined in <code>Documentation/rev-list-options.txt</code>.
</p>
</li>
<li>
<p>
<code>struct rev_info *revs</code>: This is the <code>rev_info</code> used for the walk.
<code>struct rev_info *revs</code>: This is the <code>rev_info</code> used for the walk. If
its <code>filter</code> member is not <code>NULL</code>, then <code>filter</code> contains information for
how to filter the object list.
</p>
</li>
<li>
@ -1332,6 +1342,9 @@ arguments to the unfiltered version.</p></div>
and <code>show_object</code>.
</p>
</li>
</ul></div>
<div class="paragraph"><p>In addition, <code>traverse_commit_list_filtered()</code> has an additional parameter:</p></div>
<div class="ulist"><ul>
<li>
<p>
<code>struct oidset *omitted</code>: A linked-list of object IDs which the provided
@ -1339,9 +1352,8 @@ arguments to the unfiltered version.</p></div>
</p>
</li>
</ul></div>
<div class="paragraph"><p>It looks like this <code>traverse_commit_list_filtered()</code> uses callbacks we provide
instead of needing us to call it repeatedly ourselves. Cool! Let&#8217;s add the
callbacks first.</p></div>
<div class="paragraph"><p>It looks like these methods use callbacks we provide instead of needing us
to call it repeatedly ourselves. Cool! Let&#8217;s add the callbacks first.</p></div>
<div class="paragraph"><p>For the sake of this tutorial, we&#8217;ll simply keep track of how many of each kind
of object we find. At file scope in <code>builtin/walken.c</code> add the following
tracking variables:</p></div>
@ -1432,10 +1444,15 @@ ready to call <code>prepare_revision_walk()</code>.</p></div>
tree_count = 0;</code></pre>
</div></div>
<div class="paragraph"><p>Let&#8217;s start by calling just the unfiltered walk and reporting our counts.
Complete your implementation of <code>walken_object_walk()</code>:</p></div>
Complete your implementation of <code>walken_object_walk()</code>.
We&#8217;ll also need to include the <code>list-objects.h</code> header.</p></div>
<div class="listingblock">
<div class="content">
<pre><code> traverse_commit_list(rev, walken_show_commit, walken_show_object, NULL);
<pre><code>#include "list-objects.h"
...
traverse_commit_list(rev, walken_show_commit, walken_show_object, NULL);
printf("commits %d\nblobs %d\ntags %d\ntrees %d\n", commit_count,
blob_count, tag_count, tree_count);
@ -1512,19 +1529,9 @@ be traversed during a walk; you can imagine a breadth-first tree traversal to
help understand. In our case, that means we omit trees and blobs not directly
referenced by <code>HEAD</code> or <code>HEAD</code>'s history, because we begin the walk with only
<code>HEAD</code> in the <code>pending</code> list.)</p></div>
<div class="paragraph"><p>First, we&#8217;ll need to <code>#include "list-objects-filter-options.h"</code> and set up the
<code>struct list_objects_filter_options</code> at the top of the function.</p></div>
<div class="listingblock">
<div class="content">
<pre><code>static void walken_object_walk(struct rev_info *rev)
{
struct list_objects_filter_options filter_options = {};
...</code></pre>
</div></div>
<div class="paragraph"><p>For now, we are not going to track the omitted objects, so we&#8217;ll replace those
parameters with <code>NULL</code>. For the sake of simplicity, we&#8217;ll add a simple
build-time branch to use our filter or not. Replace the line calling
build-time branch to use our filter or not. Preface the line calling
<code>traverse_commit_list()</code> with the following, which will remind us which kind of
walk we&#8217;ve just performed:</p></div>
<div class="listingblock">
@ -1532,18 +1539,16 @@ walk we&#8217;ve just performed:</p></div>
<pre><code> if (0) {
/* Unfiltered: */
trace_printf(_("Unfiltered object walk.\n"));
traverse_commit_list(rev, walken_show_commit,
walken_show_object, NULL);
} else {
trace_printf(
_("Filtered object walk with filterspec 'tree:1'.\n"));
parse_list_objects_filter(&amp;filter_options, "tree:1");
traverse_commit_list_filtered(&amp;filter_options, rev,
walken_show_commit, walken_show_object, NULL, NULL);
}</code></pre>
CALLOC_ARRAY(rev-&gt;filter, 1);
parse_list_objects_filter(rev-&gt;filter, "tree:1");
}
traverse_commit_list(rev, walken_show_commit,
walken_show_object, NULL);</code></pre>
</div></div>
<div class="paragraph"><p><code>struct list_objects_filter_options</code> is usually built directly from a command
<div class="paragraph"><p>The <code>rev-&gt;filter</code> member is usually built directly from a command
line argument, so the module provides an easy way to build one from a string.
Even though we aren&#8217;t taking user input right now, we can still build one with
a hardcoded string using <code>parse_list_objects_filter()</code>.</p></div>
@ -1579,7 +1584,7 @@ object:</p></div>
<div class="content">
<pre><code> ...
traverse_commit_list_filtered(&amp;filter_options, rev,
traverse_commit_list_filtered(rev,
walken_show_commit, walken_show_object, NULL, &amp;omitted);
...</code></pre>
@ -1717,7 +1722,7 @@ Changed the display order of the filtered object walk
<div id="footer">
<div id="footer-text">
Last updated
2021-11-15 09:20:10 PST
2022-10-08 14:40:28 PDT
</div>
</div>
</body>

@ -0,0 +1,981 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=UTF-8" />
<meta name="generator" content="AsciiDoc 9.1.0" />
<title>Reviewing Patches in the Git Project</title>
<style type="text/css">
/* Shared CSS for AsciiDoc xhtml11 and html5 backends */
/* Default font. */
body {
font-family: Georgia,serif;
}
/* Title font. */
h1, h2, h3, h4, h5, h6,
div.title, caption.title,
thead, p.table.header,
#toctitle,
#author, #revnumber, #revdate, #revremark,
#footer {
font-family: Arial,Helvetica,sans-serif;
}
body {
margin: 1em 5% 1em 5%;
}
a {
color: blue;
text-decoration: underline;
}
a:visited {
color: fuchsia;
}
em {
font-style: italic;
color: navy;
}
strong {
font-weight: bold;
color: #083194;
}
h1, h2, h3, h4, h5, h6 {
color: #527bbd;
margin-top: 1.2em;
margin-bottom: 0.5em;
line-height: 1.3;
}
h1, h2, h3 {
border-bottom: 2px solid silver;
}
h2 {
padding-top: 0.5em;
}
h3 {
float: left;
}
h3 + * {
clear: left;
}
h5 {
font-size: 1.0em;
}
div.sectionbody {
margin-left: 0;
}
hr {
border: 1px solid silver;
}
p {
margin-top: 0.5em;
margin-bottom: 0.5em;
}
ul, ol, li > p {
margin-top: 0;
}
ul > li { color: #aaa; }
ul > li > * { color: black; }
.monospaced, code, pre {
font-family: "Courier New", Courier, monospace;
font-size: inherit;
color: navy;
padding: 0;
margin: 0;
}
pre {
white-space: pre-wrap;
}
#author {
color: #527bbd;
font-weight: bold;
font-size: 1.1em;
}
#email {
}
#revnumber, #revdate, #revremark {
}
#footer {
font-size: small;
border-top: 2px solid silver;
padding-top: 0.5em;
margin-top: 4.0em;
}
#footer-text {
float: left;
padding-bottom: 0.5em;
}
#footer-badges {
float: right;
padding-bottom: 0.5em;
}
#preamble {
margin-top: 1.5em;
margin-bottom: 1.5em;
}
div.imageblock, div.exampleblock, div.verseblock,
div.quoteblock, div.literalblock, div.listingblock, div.sidebarblock,
div.admonitionblock {
margin-top: 1.0em;
margin-bottom: 1.5em;
}
div.admonitionblock {
margin-top: 2.0em;
margin-bottom: 2.0em;
margin-right: 10%;
color: #606060;
}
div.content { /* Block element content. */
padding: 0;
}
/* Block element titles. */
div.title, caption.title {
color: #527bbd;
font-weight: bold;
text-align: left;
margin-top: 1.0em;
margin-bottom: 0.5em;
}
div.title + * {
margin-top: 0;
}
td div.title:first-child {
margin-top: 0.0em;
}
div.content div.title:first-child {
margin-top: 0.0em;
}
div.content + div.title {
margin-top: 0.0em;
}
div.sidebarblock > div.content {
background: #ffffee;
border: 1px solid #dddddd;
border-left: 4px solid #f0f0f0;
padding: 0.5em;
}
div.listingblock > div.content {
border: 1px solid #dddddd;
border-left: 5px solid #f0f0f0;
background: #f8f8f8;
padding: 0.5em;
}
div.quoteblock, div.verseblock {
padding-left: 1.0em;
margin-left: 1.0em;
margin-right: 10%;
border-left: 5px solid #f0f0f0;
color: #888;
}
div.quoteblock > div.attribution {
padding-top: 0.5em;
text-align: right;
}
div.verseblock > pre.content {
font-family: inherit;
font-size: inherit;
}
div.verseblock > div.attribution {
padding-top: 0.75em;
text-align: left;
}
/* DEPRECATED: Pre version 8.2.7 verse style literal block. */
div.verseblock + div.attribution {
text-align: left;
}
div.admonitionblock .icon {
vertical-align: top;
font-size: 1.1em;
font-weight: bold;
text-decoration: underline;
color: #527bbd;
padding-right: 0.5em;
}
div.admonitionblock td.content {
padding-left: 0.5em;
border-left: 3px solid #dddddd;
}
div.exampleblock > div.content {
border-left: 3px solid #dddddd;
padding-left: 0.5em;
}
div.imageblock div.content { padding-left: 0; }
span.image img { border-style: none; vertical-align: text-bottom; }
a.image:visited { color: white; }
dl {
margin-top: 0.8em;
margin-bottom: 0.8em;
}
dt {
margin-top: 0.5em;
margin-bottom: 0;
font-style: normal;
color: navy;
}
dd > *:first-child {
margin-top: 0.1em;
}
ul, ol {
list-style-position: outside;
}
ol.arabic {
list-style-type: decimal;
}
ol.loweralpha {
list-style-type: lower-alpha;
}
ol.upperalpha {
list-style-type: upper-alpha;
}
ol.lowerroman {
list-style-type: lower-roman;
}
ol.upperroman {
list-style-type: upper-roman;
}
div.compact ul, div.compact ol,
div.compact p, div.compact p,
div.compact div, div.compact div {
margin-top: 0.1em;
margin-bottom: 0.1em;
}
tfoot {
font-weight: bold;
}
td > div.verse {
white-space: pre;
}
div.hdlist {
margin-top: 0.8em;
margin-bottom: 0.8em;
}
div.hdlist tr {
padding-bottom: 15px;
}
dt.hdlist1.strong, td.hdlist1.strong {
font-weight: bold;
}
td.hdlist1 {
vertical-align: top;
font-style: normal;
padding-right: 0.8em;
color: navy;
}
td.hdlist2 {
vertical-align: top;
}
div.hdlist.compact tr {
margin: 0;
padding-bottom: 0;
}
.comment {
background: yellow;
}
.footnote, .footnoteref {
font-size: 0.8em;
}
span.footnote, span.footnoteref {
vertical-align: super;
}
#footnotes {
margin: 20px 0 20px 0;
padding: 7px 0 0 0;
}
#footnotes div.footnote {
margin: 0 0 5px 0;
}
#footnotes hr {
border: none;
border-top: 1px solid silver;
height: 1px;
text-align: left;
margin-left: 0;
width: 20%;
min-width: 100px;
}
div.colist td {
padding-right: 0.5em;
padding-bottom: 0.3em;
vertical-align: top;
}
div.colist td img {
margin-top: 0.3em;
}
@media print {
#footer-badges { display: none; }
}
#toc {
margin-bottom: 2.5em;
}
#toctitle {
color: #527bbd;
font-size: 1.1em;
font-weight: bold;
margin-top: 1.0em;
margin-bottom: 0.1em;
}
div.toclevel0, div.toclevel1, div.toclevel2, div.toclevel3, div.toclevel4 {
margin-top: 0;
margin-bottom: 0;
}
div.toclevel2 {
margin-left: 2em;
font-size: 0.9em;
}
div.toclevel3 {
margin-left: 4em;
font-size: 0.9em;
}
div.toclevel4 {
margin-left: 6em;
font-size: 0.9em;
}
span.aqua { color: aqua; }
span.black { color: black; }
span.blue { color: blue; }
span.fuchsia { color: fuchsia; }
span.gray { color: gray; }
span.green { color: green; }
span.lime { color: lime; }
span.maroon { color: maroon; }
span.navy { color: navy; }
span.olive { color: olive; }
span.purple { color: purple; }
span.red { color: red; }
span.silver { color: silver; }
span.teal { color: teal; }
span.white { color: white; }
span.yellow { color: yellow; }
span.aqua-background { background: aqua; }
span.black-background { background: black; }
span.blue-background { background: blue; }
span.fuchsia-background { background: fuchsia; }
span.gray-background { background: gray; }
span.green-background { background: green; }
span.lime-background { background: lime; }
span.maroon-background { background: maroon; }
span.navy-background { background: navy; }
span.olive-background { background: olive; }
span.purple-background { background: purple; }
span.red-background { background: red; }
span.silver-background { background: silver; }
span.teal-background { background: teal; }
span.white-background { background: white; }
span.yellow-background { background: yellow; }
span.big { font-size: 2em; }
span.small { font-size: 0.6em; }
span.underline { text-decoration: underline; }
span.overline { text-decoration: overline; }
span.line-through { text-decoration: line-through; }
div.unbreakable { page-break-inside: avoid; }
/*
* xhtml11 specific
*
* */
div.tableblock {
margin-top: 1.0em;
margin-bottom: 1.5em;
}
div.tableblock > table {
border: 3px solid #527bbd;
}
thead, p.table.header {
font-weight: bold;
color: #527bbd;
}
p.table {
margin-top: 0;
}
/* Because the table frame attribute is overridden by CSS in most browsers. */
div.tableblock > table[frame="void"] {
border-style: none;
}
div.tableblock > table[frame="hsides"] {
border-left-style: none;
border-right-style: none;
}
div.tableblock > table[frame="vsides"] {
border-top-style: none;
border-bottom-style: none;
}
/*
* html5 specific
*
* */
table.tableblock {
margin-top: 1.0em;
margin-bottom: 1.5em;
}
thead, p.tableblock.header {
font-weight: bold;
color: #527bbd;
}
p.tableblock {
margin-top: 0;
}
table.tableblock {
border-width: 3px;
border-spacing: 0px;
border-style: solid;
border-color: #527bbd;
border-collapse: collapse;
}
th.tableblock, td.tableblock {
border-width: 1px;
padding: 4px;
border-style: solid;
border-color: #527bbd;
}
table.tableblock.frame-topbot {
border-left-style: hidden;
border-right-style: hidden;
}
table.tableblock.frame-sides {
border-top-style: hidden;
border-bottom-style: hidden;
}
table.tableblock.frame-none {
border-style: hidden;
}
th.tableblock.halign-left, td.tableblock.halign-left {
text-align: left;
}
th.tableblock.halign-center, td.tableblock.halign-center {
text-align: center;
}
th.tableblock.halign-right, td.tableblock.halign-right {
text-align: right;
}
th.tableblock.valign-top, td.tableblock.valign-top {
vertical-align: top;
}
th.tableblock.valign-middle, td.tableblock.valign-middle {
vertical-align: middle;
}
th.tableblock.valign-bottom, td.tableblock.valign-bottom {
vertical-align: bottom;
}
/*
* manpage specific
*
* */
body.manpage h1 {
padding-top: 0.5em;
padding-bottom: 0.5em;
border-top: 2px solid silver;
border-bottom: 2px solid silver;
}
body.manpage h2 {
border-style: none;
}
body.manpage div.sectionbody {
margin-left: 3em;
}
@media print {
body.manpage div#toc { display: none; }
}
</style>
<script type="text/javascript">
/*<![CDATA[*/
var asciidoc = { // Namespace.
/////////////////////////////////////////////////////////////////////
// Table Of Contents generator
/////////////////////////////////////////////////////////////////////
/* Author: Mihai Bazon, September 2002
* http://students.infoiasi.ro/~mishoo
*
* Table Of Content generator
* Version: 0.4
*
* Feel free to use this script under the terms of the GNU General Public
* License, as long as you do not remove or alter this notice.
*/
/* modified by Troy D. Hanson, September 2006. License: GPL */
/* modified by Stuart Rackham, 2006, 2009. License: GPL */
// toclevels = 1..4.
toc: function (toclevels) {
function getText(el) {
var text = "";
for (var i = el.firstChild; i != null; i = i.nextSibling) {
if (i.nodeType == 3 /* Node.TEXT_NODE */) // IE doesn't speak constants.
text += i.data;
else if (i.firstChild != null)
text += getText(i);
}
return text;
}
function TocEntry(el, text, toclevel) {
this.element = el;
this.text = text;
this.toclevel = toclevel;
}
function tocEntries(el, toclevels) {
var result = new Array;
var re = new RegExp('[hH]([1-'+(toclevels+1)+'])');
// Function that scans the DOM tree for header elements (the DOM2
// nodeIterator API would be a better technique but not supported by all
// browsers).
var iterate = function (el) {
for (var i = el.firstChild; i != null; i = i.nextSibling) {
if (i.nodeType == 1 /* Node.ELEMENT_NODE */) {
var mo = re.exec(i.tagName);
if (mo && (i.getAttribute("class") || i.getAttribute("className")) != "float") {
result[result.length] = new TocEntry(i, getText(i), mo[1]-1);
}
iterate(i);
}
}
}
iterate(el);
return result;
}
var toc = document.getElementById("toc");
if (!toc) {
return;
}
// Delete existing TOC entries in case we're reloading the TOC.
var tocEntriesToRemove = [];
var i;
for (i = 0; i < toc.childNodes.length; i++) {
var entry = toc.childNodes[i];
if (entry.nodeName.toLowerCase() == 'div'
&& entry.getAttribute("class")
&& entry.getAttribute("class").match(/^toclevel/))
tocEntriesToRemove.push(entry);
}
for (i = 0; i < tocEntriesToRemove.length; i++) {
toc.removeChild(tocEntriesToRemove[i]);
}
// Rebuild TOC entries.
var entries = tocEntries(document.getElementById("content"), toclevels);
for (var i = 0; i < entries.length; ++i) {
var entry = entries[i];
if (entry.element.id == "")
entry.element.id = "_toc_" + i;
var a = document.createElement("a");
a.href = "#" + entry.element.id;
a.appendChild(document.createTextNode(entry.text));
var div = document.createElement("div");
div.appendChild(a);
div.className = "toclevel" + entry.toclevel;
toc.appendChild(div);
}
if (entries.length == 0)
toc.parentNode.removeChild(toc);
},
/////////////////////////////////////////////////////////////////////
// Footnotes generator
/////////////////////////////////////////////////////////////////////
/* Based on footnote generation code from:
* http://www.brandspankingnew.net/archive/2005/07/format_footnote.html
*/
footnotes: function () {
// Delete existing footnote entries in case we're reloading the footnodes.
var i;
var noteholder = document.getElementById("footnotes");
if (!noteholder) {
return;
}
var entriesToRemove = [];
for (i = 0; i < noteholder.childNodes.length; i++) {
var entry = noteholder.childNodes[i];
if (entry.nodeName.toLowerCase() == 'div' && entry.getAttribute("class") == "footnote")
entriesToRemove.push(entry);
}
for (i = 0; i < entriesToRemove.length; i++) {
noteholder.removeChild(entriesToRemove[i]);
}
// Rebuild footnote entries.
var cont = document.getElementById("content");
var spans = cont.getElementsByTagName("span");
var refs = {};
var n = 0;
for (i=0; i<spans.length; i++) {
if (spans[i].className == "footnote") {
n++;
var note = spans[i].getAttribute("data-note");
if (!note) {
// Use [\s\S] in place of . so multi-line matches work.
// Because JavaScript has no s (dotall) regex flag.
note = spans[i].innerHTML.match(/\s*\[([\s\S]*)]\s*/)[1];
spans[i].innerHTML =
"[<a id='_footnoteref_" + n + "' href='#_footnote_" + n +
"' title='View footnote' class='footnote'>" + n + "</a>]";
spans[i].setAttribute("data-note", note);
}
noteholder.innerHTML +=
"<div class='footnote' id='_footnote_" + n + "'>" +
"<a href='#_footnoteref_" + n + "' title='Return to text'>" +
n + "</a>. " + note + "</div>";
var id =spans[i].getAttribute("id");
if (id != null) refs["#"+id] = n;
}
}
if (n == 0)
noteholder.parentNode.removeChild(noteholder);
else {
// Process footnoterefs.
for (i=0; i<spans.length; i++) {
if (spans[i].className == "footnoteref") {
var href = spans[i].getElementsByTagName("a")[0].getAttribute("href");
href = href.match(/#.*/)[0]; // Because IE return full URL.
n = refs[href];
spans[i].innerHTML =
"[<a href='#_footnote_" + n +
"' title='View footnote' class='footnote'>" + n + "</a>]";
}
}
}
},
install: function(toclevels) {
var timerId;
function reinstall() {
asciidoc.footnotes();
if (toclevels) {
asciidoc.toc(toclevels);
}
}
function reinstallAndRemoveTimer() {
clearInterval(timerId);
reinstall();
}
timerId = setInterval(reinstall, 500);
if (document.addEventListener)
document.addEventListener("DOMContentLoaded", reinstallAndRemoveTimer, false);
else
window.onload = reinstallAndRemoveTimer;
}
}
asciidoc.install();
/*]]>*/
</script>
</head>
<body class="article">
<div id="header">
<h1>Reviewing Patches in the Git Project</h1>
</div>
<div id="content">
<div class="sect1">
<h2 id="_introduction">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">Principles</h2>
<div class="sectionbody">
<div class="sect2">
<h3 id="_selecting_patch_es_to_review">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">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">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">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="git-am.html">git-am(1)</a> or checking
out the associated branch from <a href="https://github.com/gitster/git">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">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 &#8216;next` branch (typically phrased
"Will merge to 'next&#8217;?"). 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">Terminology</h2>
<div class="sectionbody">
<div class="dlist"><dl>
<dt class="hdlist1">
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">
aside:
</dt>
<dt class="hdlist1">
optional:
</dt>
<dt class="hdlist1">
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">
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">
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">
#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">See Also</h2>
<div class="sectionbody">
<div class="paragraph"><p><a href="MyFirstContribution.html">MyFirstContribution</a></p></div>
</div>
</div>
</div>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
Last updated
2022-10-08 14:40:28 PDT
</div>
</div>
</body>
</html>

@ -759,8 +759,10 @@ A bugfix should be based on <code>maint</code> in general. If the bug is not
<li>
<p>
A new feature should be based on <code>master</code> in general. If the new
feature depends on a topic that is in <code>seen</code>, but not in <code>master</code>,
base your work on the tip of that topic.
feature depends on other topics that are in <code>next</code>, but not in
<code>master</code>, fork a branch from the tip of <code>master</code>, merge these topics
to the branch, and work on that branch. You can remind yourself of
how you prepared the base with <code>git log --first-parent master..</code>.
</p>
</li>
<li>
@ -774,10 +776,10 @@ Corrections and enhancements to a topic not yet in <code>master</code> should
<li>
<p>
In the exceptional case that a new feature depends on several topics
not in <code>master</code>, start working on <code>next</code> or <code>seen</code> privately and send
out patches for discussion. Before the final merge, you may have to
wait until some of the dependent topics graduate to <code>master</code>, and
rebase your work.
not in <code>master</code>, start working on <code>next</code> or <code>seen</code> privately and
send out patches only for discussion. Once your new feature starts
to stabilize, you would have to rebase it (see the "depends on other
topics" above).
</p>
</li>
<li>
@ -816,8 +818,13 @@ to have.</p></div>
<code>t/README</code> for guidance.</p></div>
<div class="paragraph" id="tests"><p>When adding a new feature, make sure that you have new tests to show
the feature triggers the new behavior when it should, and to show the
feature does not trigger when it shouldn&#8217;t. After any code change, make
sure that the entire test suite passes.</p></div>
feature does not trigger when it shouldn&#8217;t. After any code change,
make sure that the entire test suite passes. When fixing a bug, make
sure you have new tests that break if somebody else breaks what you
fixed by accident to avoid regression. Also, try merging your work to
<em>next</em> and <em>seen</em> and make sure the tests still pass; topics by others
that are still in flight may have unexpected interactions with what
you are trying to do in your topic.</p></div>
<div class="paragraph"><p>Pushing to a fork of <a href="https://github.com/git/git">https://github.com/git/git</a> will use their CI
integration to test your changes on Linux, Mac and Windows. See the
<a href="#GHCI">GitHub CI</a> section for details.</p></div>
@ -842,6 +849,41 @@ run <code>git diff --check</code> on your changes before you commit.</p></div>
</div>
<div class="sect2">
<h3 id="describe-changes">Describe your changes well.</h3>
<div class="paragraph"><p>The log message that explains your changes is just as important as the
changes themselves. Your code may be clearly written with in-code
comment to sufficiently explain how it works with the surrounding
code, but those who need to fix or enhance your code in the future
will need to know <em>why</em> your code does what it does, for a few
reasons:</p></div>
<div class="olist arabic"><ol class="arabic">
<li>
<p>
Your code may be doing something differently from what you wanted it
to do. Writing down what you actually wanted to achieve will help
them fix your code and make it do what it should have been doing
(also, you often discover your own bugs yourself, while writing the
log message to summarize the thought behind it).
</p>
</li>
<li>
<p>
Your code may be doing things that were only necessary for your
immediate needs (e.g. "do X to directories" without implementing or
even designing what is to be done on files). Writing down why you
excluded what the code does not do will help guide future developers.
Writing down "we do X to directories, because directories have
characteristic Y" would help them infer "oh, files also have the same
characteristic Y, so perhaps doing X to them would also make sense?".
Saying "we don&#8217;t do the same X to files, because &#8230;" will help them
decide if the reasoning is sound (in which case they do not waste
time extending your code to cover files), or reason differently (in
which case, they can explain why they extend your code to cover
files, too).
</p>
</li>
</ol></div>
<div class="paragraph"><p>The goal of your log message is to convey the <em>why</em> behind your
change to help future developers.</p></div>
<div class="paragraph"><p>The first line of the commit message should be a short description (50
characters is the soft limit, see DISCUSSION in <a href="git-commit.html">git-commit(1)</a>),
and should skip the full stop. It is also conventional in most cases to
@ -888,14 +930,41 @@ alternate solutions considered but discarded, if any.
</p>
</li>
</ol></div>
<div class="paragraph" id="present-tense"><p>The problem statement that describes the status quo is written in the
present tense. Write "The code does X when it is given input Y",
instead of "The code used to do Y when given input X". You do not
have to say "Currently"---the status quo in the problem statement is
about the code <em>without</em> your change, by project convention.</p></div>
<div class="paragraph" id="imperative-mood"><p>Describe your changes in imperative mood, e.g. "make xyzzy do frotz"
instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy
to do frotz", as if you are giving orders to the codebase to change
its behavior. Try to make sure your explanation can be understood
without external resources. Instead of giving a URL to a mailing list
archive, summarize the relevant points of the discussion.</p></div>
<div class="paragraph" id="commit-reference"><p>If you want to reference a previous commit in the history of a stable
branch, use the format "abbreviated hash (subject, date)", like this:</p></div>
<div class="paragraph" id="commit-reference"><p>There are a few reasons why you may want to refer to another commit in
the "more stable" part of the history (i.e. on branches like <code>maint</code>,
<code>master</code>, and <code>next</code>):</p></div>
<div class="olist arabic"><ol class="arabic">
<li>
<p>
A commit that introduced the root cause of a bug you are fixing.
</p>
</li>
<li>
<p>
A commit that introduced a feature that you are enhancing.
</p>
</li>
<li>
<p>
A commit that conflicts with your work when you made a trial merge
of your work into <code>next</code> and <code>seen</code> for testing.
</p>
</li>
</ol></div>
<div class="paragraph"><p>When you reference a commit on a more stable branch (like <code>master</code>,
<code>maint</code> and <code>next</code>), use the format "abbreviated hash (subject,
date)", like this:</p></div>
<div class="literalblock">
<div class="content">
<pre><code> Commit f86a374 (pack-bitmap.c: fix a memleak, 2015-03-30)
@ -1024,9 +1093,10 @@ receiving end can handle them just fine.</p></div>
or include any extra files which do not relate to what your patch
is trying to achieve. Make sure to review
your patch after generating it, to ensure accuracy. Before
sending out, please make sure it cleanly applies to the <code>master</code>
branch head. If you are preparing a work based on "next" branch,
that is fine, but please mark it as such.</p></div>
sending out, please make sure it cleanly applies to the base you
have chosen in the "Decide what to base your work on" section,
and unless it targets the <code>master</code> branch (which is the default),
mark your patches as such.</p></div>
</div>
<div class="sect2">
<h3 id="send-patches">Sending your patches.</h3>
@ -1116,7 +1186,10 @@ Security mailing list<span class="footnoteref"><br /><a href="#_footnote_securit
<div class="paragraph"><p>Send your patch with "To:" set to the mailing list, with "cc:" listing
people who are involved in the area you are touching (the <code>git
contacts</code> command in <code>contrib/contacts/</code> can help to
identify them), to solicit comments and reviews.</p></div>
identify them), to solicit comments and reviews. Also, when you made
trial merges of your topic to <code>next</code> and <code>seen</code>, you may have noticed
work by others conflicting with your changes. There is a good possibility
that these people may know the area you are touching well.</p></div>
<div class="paragraph"><p>After the list reached a consensus that it is a good idea to apply the
patch, re-send it with "To:" set to the maintainer<span class="footnote"><br />[The current maintainer: <a href="mailto:gitster@pobox.com">gitster@pobox.com</a>]<br /></span>
and "cc:" the list<span class="footnote"><br />[The mailing list: <a href="mailto:git@vger.kernel.org">git@vger.kernel.org</a>]<br /></span> for inclusion. This is especially relevant
@ -1149,7 +1222,12 @@ repositories.</p></div>
</p>
<div class="literalblock">
<div class="content">
<pre><code>git://ozlabs.org/~paulus/gitk</code></pre>
<pre><code>git://git.ozlabs.org/~paulus/gitk</code></pre>
</div></div>
<div class="literalblock">
<div class="content">
<pre><code>Those who are interested in improve gitk can volunteer to help Paul
in maintaining it cf. &lt;YntxL/fTplFm8lr6@cleo&gt;.</code></pre>
</div></div>
</li>
<li>
@ -1244,7 +1322,7 @@ Read the Git mailing list, the maintainer regularly posts messages
</div>
</div>
<div class="sect1">
<h2 id="_github_ci_a_id_ghci_a">GitHub CI<a id="GHCI"></a>]</h2>
<h2 id="_github_ci_a_id_ghci_a">GitHub CI<a id="GHCI"></a></h2>
<div class="sectionbody">
<div class="paragraph"><p>With an account at GitHub, you can use GitHub CI to test your changes
on Linux, Mac and Windows. See
@ -1262,7 +1340,7 @@ Fork <a href="https://github.com/git/git">https://github.com/git/git</a> to your
</ol></div>
<div class="paragraph"><p>After the initial setup, CI will run whenever you push new changes
to your fork of Git on GitHub. You can monitor the test state of all your
branches here: <a href="https://github.com/&lt;Your">https://github.com/&lt;Your</a> GitHub handle&gt;/git/actions/workflows/main.yml</p></div>
branches here: <code>https://github.com/&lt;Your GitHub handle&gt;/git/actions/workflows/main.yml</code></p></div>
<div class="paragraph"><p>If a branch did not pass all test cases then it is marked with a red
cross. In that case you can click on the failing job and navigate to
"ci/run-build-and-tests.sh" and/or "ci/print-test-failures.sh". You
@ -1366,7 +1444,7 @@ this problem around.</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2021-11-15 14:34:40 PST
2022-09-21 07:18:16 PDT
</div>
</div>
</body>

@ -0,0 +1,812 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=UTF-8" />
<meta name="generator" content="AsciiDoc 9.1.0" />
<title>Tools for developing Git</title>
<style type="text/css">
/* Shared CSS for AsciiDoc xhtml11 and html5 backends */
/* Default font. */
body {
font-family: Georgia,serif;
}
/* Title font. */
h1, h2, h3, h4, h5, h6,
div.title, caption.title,
thead, p.table.header,
#toctitle,
#author, #revnumber, #revdate, #revremark,
#footer {
font-family: Arial,Helvetica,sans-serif;
}
body {
margin: 1em 5% 1em 5%;
}
a {
color: blue;
text-decoration: underline;
}
a:visited {
color: fuchsia;
}
em {
font-style: italic;
color: navy;
}
strong {
font-weight: bold;
color: #083194;
}
h1, h2, h3, h4, h5, h6 {
color: #527bbd;
margin-top: 1.2em;
margin-bottom: 0.5em;
line-height: 1.3;
}
h1, h2, h3 {
border-bottom: 2px solid silver;
}
h2 {
padding-top: 0.5em;
}
h3 {
float: left;
}
h3 + * {
clear: left;
}
h5 {
font-size: 1.0em;
}
div.sectionbody {
margin-left: 0;
}
hr {
border: 1px solid silver;
}
p {
margin-top: 0.5em;
margin-bottom: 0.5em;
}
ul, ol, li > p {
margin-top: 0;
}
ul > li { color: #aaa; }
ul > li > * { color: black; }
.monospaced, code, pre {
font-family: "Courier New", Courier, monospace;
font-size: inherit;
color: navy;
padding: 0;
margin: 0;
}
pre {
white-space: pre-wrap;
}
#author {
color: #527bbd;
font-weight: bold;
font-size: 1.1em;
}
#email {
}
#revnumber, #revdate, #revremark {
}
#footer {
font-size: small;
border-top: 2px solid silver;
padding-top: 0.5em;
margin-top: 4.0em;
}
#footer-text {
float: left;
padding-bottom: 0.5em;
}
#footer-badges {
float: right;
padding-bottom: 0.5em;
}
#preamble {
margin-top: 1.5em;
margin-bottom: 1.5em;
}
div.imageblock, div.exampleblock, div.verseblock,
div.quoteblock, div.literalblock, div.listingblock, div.sidebarblock,
div.admonitionblock {
margin-top: 1.0em;
margin-bottom: 1.5em;
}
div.admonitionblock {
margin-top: 2.0em;
margin-bottom: 2.0em;
margin-right: 10%;
color: #606060;
}
div.content { /* Block element content. */
padding: 0;
}
/* Block element titles. */
div.title, caption.title {
color: #527bbd;
font-weight: bold;
text-align: left;
margin-top: 1.0em;
margin-bottom: 0.5em;
}
div.title + * {
margin-top: 0;
}
td div.title:first-child {
margin-top: 0.0em;
}
div.content div.title:first-child {
margin-top: 0.0em;
}
div.content + div.title {
margin-top: 0.0em;
}
div.sidebarblock > div.content {
background: #ffffee;
border: 1px solid #dddddd;
border-left: 4px solid #f0f0f0;
padding: 0.5em;
}
div.listingblock > div.content {
border: 1px solid #dddddd;
border-left: 5px solid #f0f0f0;
background: #f8f8f8;
padding: 0.5em;
}
div.quoteblock, div.verseblock {
padding-left: 1.0em;
margin-left: 1.0em;
margin-right: 10%;
border-left: 5px solid #f0f0f0;
color: #888;
}
div.quoteblock > div.attribution {
padding-top: 0.5em;
text-align: right;
}
div.verseblock > pre.content {
font-family: inherit;
font-size: inherit;
}
div.verseblock > div.attribution {
padding-top: 0.75em;
text-align: left;
}
/* DEPRECATED: Pre version 8.2.7 verse style literal block. */
div.verseblock + div.attribution {
text-align: left;
}
div.admonitionblock .icon {
vertical-align: top;
font-size: 1.1em;
font-weight: bold;
text-decoration: underline;
color: #527bbd;
padding-right: 0.5em;
}
div.admonitionblock td.content {
padding-left: 0.5em;
border-left: 3px solid #dddddd;
}
div.exampleblock > div.content {
border-left: 3px solid #dddddd;
padding-left: 0.5em;
}
div.imageblock div.content { padding-left: 0; }
span.image img { border-style: none; vertical-align: text-bottom; }
a.image:visited { color: white; }
dl {
margin-top: 0.8em;
margin-bottom: 0.8em;
}
dt {
margin-top: 0.5em;
margin-bottom: 0;
font-style: normal;
color: navy;
}
dd > *:first-child {
margin-top: 0.1em;
}
ul, ol {
list-style-position: outside;
}
ol.arabic {
list-style-type: decimal;
}
ol.loweralpha {
list-style-type: lower-alpha;
}
ol.upperalpha {
list-style-type: upper-alpha;
}
ol.lowerroman {
list-style-type: lower-roman;
}
ol.upperroman {
list-style-type: upper-roman;
}
div.compact ul, div.compact ol,
div.compact p, div.compact p,
div.compact div, div.compact div {
margin-top: 0.1em;
margin-bottom: 0.1em;
}
tfoot {
font-weight: bold;
}
td > div.verse {
white-space: pre;
}
div.hdlist {
margin-top: 0.8em;
margin-bottom: 0.8em;
}
div.hdlist tr {
padding-bottom: 15px;
}
dt.hdlist1.strong, td.hdlist1.strong {
font-weight: bold;
}
td.hdlist1 {
vertical-align: top;
font-style: normal;
padding-right: 0.8em;
color: navy;
}
td.hdlist2 {
vertical-align: top;
}
div.hdlist.compact tr {
margin: 0;
padding-bottom: 0;
}
.comment {
background: yellow;
}
.footnote, .footnoteref {
font-size: 0.8em;
}
span.footnote, span.footnoteref {
vertical-align: super;
}
#footnotes {
margin: 20px 0 20px 0;
padding: 7px 0 0 0;
}
#footnotes div.footnote {
margin: 0 0 5px 0;
}
#footnotes hr {
border: none;
border-top: 1px solid silver;
height: 1px;
text-align: left;
margin-left: 0;
width: 20%;
min-width: 100px;
}
div.colist td {
padding-right: 0.5em;
padding-bottom: 0.3em;
vertical-align: top;
}
div.colist td img {
margin-top: 0.3em;
}
@media print {
#footer-badges { display: none; }
}
#toc {
margin-bottom: 2.5em;
}
#toctitle {
color: #527bbd;
font-size: 1.1em;
font-weight: bold;
margin-top: 1.0em;
margin-bottom: 0.1em;
}
div.toclevel0, div.toclevel1, div.toclevel2, div.toclevel3, div.toclevel4 {
margin-top: 0;
margin-bottom: 0;
}
div.toclevel2 {
margin-left: 2em;
font-size: 0.9em;
}
div.toclevel3 {
margin-left: 4em;
font-size: 0.9em;
}
div.toclevel4 {
margin-left: 6em;
font-size: 0.9em;
}
span.aqua { color: aqua; }
span.black { color: black; }
span.blue { color: blue; }
span.fuchsia { color: fuchsia; }
span.gray { color: gray; }
span.green { color: green; }
span.lime { color: lime; }
span.maroon { color: maroon; }
span.navy { color: navy; }
span.olive { color: olive; }
span.purple { color: purple; }
span.red { color: red; }
span.silver { color: silver; }
span.teal { color: teal; }
span.white { color: white; }
span.yellow { color: yellow; }
span.aqua-background { background: aqua; }
span.black-background { background: black; }
span.blue-background { background: blue; }
span.fuchsia-background { background: fuchsia; }
span.gray-background { background: gray; }
span.green-background { background: green; }
span.lime-background { background: lime; }
span.maroon-background { background: maroon; }
span.navy-background { background: navy; }
span.olive-background { background: olive; }
span.purple-background { background: purple; }
span.red-background { background: red; }
span.silver-background { background: silver; }
span.teal-background { background: teal; }
span.white-background { background: white; }
span.yellow-background { background: yellow; }
span.big { font-size: 2em; }
span.small { font-size: 0.6em; }
span.underline { text-decoration: underline; }
span.overline { text-decoration: overline; }
span.line-through { text-decoration: line-through; }
div.unbreakable { page-break-inside: avoid; }
/*
* xhtml11 specific
*
* */
div.tableblock {
margin-top: 1.0em;
margin-bottom: 1.5em;
}
div.tableblock > table {
border: 3px solid #527bbd;
}
thead, p.table.header {
font-weight: bold;
color: #527bbd;
}
p.table {
margin-top: 0;
}
/* Because the table frame attribute is overridden by CSS in most browsers. */
div.tableblock > table[frame="void"] {
border-style: none;
}
div.tableblock > table[frame="hsides"] {
border-left-style: none;
border-right-style: none;
}
div.tableblock > table[frame="vsides"] {
border-top-style: none;
border-bottom-style: none;
}
/*
* html5 specific
*
* */
table.tableblock {
margin-top: 1.0em;
margin-bottom: 1.5em;
}
thead, p.tableblock.header {
font-weight: bold;
color: #527bbd;
}
p.tableblock {
margin-top: 0;
}
table.tableblock {
border-width: 3px;
border-spacing: 0px;
border-style: solid;
border-color: #527bbd;
border-collapse: collapse;
}
th.tableblock, td.tableblock {
border-width: 1px;
padding: 4px;
border-style: solid;
border-color: #527bbd;
}
table.tableblock.frame-topbot {
border-left-style: hidden;
border-right-style: hidden;
}
table.tableblock.frame-sides {
border-top-style: hidden;
border-bottom-style: hidden;
}
table.tableblock.frame-none {
border-style: hidden;
}
th.tableblock.halign-left, td.tableblock.halign-left {
text-align: left;
}
th.tableblock.halign-center, td.tableblock.halign-center {
text-align: center;
}
th.tableblock.halign-right, td.tableblock.halign-right {
text-align: right;
}
th.tableblock.valign-top, td.tableblock.valign-top {
vertical-align: top;
}
th.tableblock.valign-middle, td.tableblock.valign-middle {
vertical-align: middle;
}
th.tableblock.valign-bottom, td.tableblock.valign-bottom {
vertical-align: bottom;
}
/*
* manpage specific
*
* */
body.manpage h1 {
padding-top: 0.5em;
padding-bottom: 0.5em;
border-top: 2px solid silver;
border-bottom: 2px solid silver;
}
body.manpage h2 {
border-style: none;
}
body.manpage div.sectionbody {
margin-left: 3em;
}
@media print {
body.manpage div#toc { display: none; }
}
</style>
<script type="text/javascript">
/*<![CDATA[*/
var asciidoc = { // Namespace.
/////////////////////////////////////////////////////////////////////
// Table Of Contents generator
/////////////////////////////////////////////////////////////////////
/* Author: Mihai Bazon, September 2002
* http://students.infoiasi.ro/~mishoo
*
* Table Of Content generator
* Version: 0.4
*
* Feel free to use this script under the terms of the GNU General Public
* License, as long as you do not remove or alter this notice.
*/
/* modified by Troy D. Hanson, September 2006. License: GPL */
/* modified by Stuart Rackham, 2006, 2009. License: GPL */
// toclevels = 1..4.
toc: function (toclevels) {
function getText(el) {
var text = "";
for (var i = el.firstChild; i != null; i = i.nextSibling) {
if (i.nodeType == 3 /* Node.TEXT_NODE */) // IE doesn't speak constants.
text += i.data;
else if (i.firstChild != null)
text += getText(i);
}
return text;
}
function TocEntry(el, text, toclevel) {
this.element = el;
this.text = text;
this.toclevel = toclevel;
}
function tocEntries(el, toclevels) {
var result = new Array;
var re = new RegExp('[hH]([1-'+(toclevels+1)+'])');
// Function that scans the DOM tree for header elements (the DOM2
// nodeIterator API would be a better technique but not supported by all
// browsers).
var iterate = function (el) {
for (var i = el.firstChild; i != null; i = i.nextSibling) {
if (i.nodeType == 1 /* Node.ELEMENT_NODE */) {
var mo = re.exec(i.tagName);
if (mo && (i.getAttribute("class") || i.getAttribute("className")) != "float") {
result[result.length] = new TocEntry(i, getText(i), mo[1]-1);
}
iterate(i);
}
}
}
iterate(el);
return result;
}
var toc = document.getElementById("toc");
if (!toc) {
return;
}
// Delete existing TOC entries in case we're reloading the TOC.
var tocEntriesToRemove = [];
var i;
for (i = 0; i < toc.childNodes.length; i++) {
var entry = toc.childNodes[i];
if (entry.nodeName.toLowerCase() == 'div'
&& entry.getAttribute("class")
&& entry.getAttribute("class").match(/^toclevel/))
tocEntriesToRemove.push(entry);
}
for (i = 0; i < tocEntriesToRemove.length; i++) {
toc.removeChild(tocEntriesToRemove[i]);
}
// Rebuild TOC entries.
var entries = tocEntries(document.getElementById("content"), toclevels);
for (var i = 0; i < entries.length; ++i) {
var entry = entries[i];
if (entry.element.id == "")
entry.element.id = "_toc_" + i;
var a = document.createElement("a");
a.href = "#" + entry.element.id;
a.appendChild(document.createTextNode(entry.text));
var div = document.createElement("div");
div.appendChild(a);
div.className = "toclevel" + entry.toclevel;
toc.appendChild(div);
}
if (entries.length == 0)
toc.parentNode.removeChild(toc);
},
/////////////////////////////////////////////////////////////////////
// Footnotes generator
/////////////////////////////////////////////////////////////////////
/* Based on footnote generation code from:
* http://www.brandspankingnew.net/archive/2005/07/format_footnote.html
*/
footnotes: function () {
// Delete existing footnote entries in case we're reloading the footnodes.
var i;
var noteholder = document.getElementById("footnotes");
if (!noteholder) {
return;
}
var entriesToRemove = [];
for (i = 0; i < noteholder.childNodes.length; i++) {
var entry = noteholder.childNodes[i];
if (entry.nodeName.toLowerCase() == 'div' && entry.getAttribute("class") == "footnote")
entriesToRemove.push(entry);
}
for (i = 0; i < entriesToRemove.length; i++) {
noteholder.removeChild(entriesToRemove[i]);
}
// Rebuild footnote entries.
var cont = document.getElementById("content");
var spans = cont.getElementsByTagName("span");
var refs = {};
var n = 0;
for (i=0; i<spans.length; i++) {
if (spans[i].className == "footnote") {
n++;
var note = spans[i].getAttribute("data-note");
if (!note) {
// Use [\s\S] in place of . so multi-line matches work.
// Because JavaScript has no s (dotall) regex flag.
note = spans[i].innerHTML.match(/\s*\[([\s\S]*)]\s*/)[1];
spans[i].innerHTML =
"[<a id='_footnoteref_" + n + "' href='#_footnote_" + n +
"' title='View footnote' class='footnote'>" + n + "</a>]";
spans[i].setAttribute("data-note", note);
}
noteholder.innerHTML +=
"<div class='footnote' id='_footnote_" + n + "'>" +
"<a href='#_footnoteref_" + n + "' title='Return to text'>" +
n + "</a>. " + note + "</div>";
var id =spans[i].getAttribute("id");
if (id != null) refs["#"+id] = n;
}
}
if (n == 0)
noteholder.parentNode.removeChild(noteholder);
else {
// Process footnoterefs.
for (i=0; i<spans.length; i++) {
if (spans[i].className == "footnoteref") {
var href = spans[i].getElementsByTagName("a")[0].getAttribute("href");
href = href.match(/#.*/)[0]; // Because IE return full URL.
n = refs[href];
spans[i].innerHTML =
"[<a href='#_footnote_" + n +
"' title='View footnote' class='footnote'>" + n + "</a>]";
}
}
}
},
install: function(toclevels) {
var timerId;
function reinstall() {
asciidoc.footnotes();
if (toclevels) {
asciidoc.toc(toclevels);
}
}
function reinstallAndRemoveTimer() {
clearInterval(timerId);
reinstall();
}
timerId = setInterval(reinstall, 500);
if (document.addEventListener)
document.addEventListener("DOMContentLoaded", reinstallAndRemoveTimer, false);
else
window.onload = reinstallAndRemoveTimer;
}
}
asciidoc.install();
/*]]>*/
</script>
</head>
<body class="article">
<div id="header">
<h1>Tools for developing Git</h1>
</div>
<div id="content">
<div class="sect1">
<h2 id="summary">Summary</h2>
<div class="sectionbody">
<div class="paragraph"><p>This document gathers tips, scripts and configuration file to help people
working on Git&#8217;s codebase use their favorite tools while following Git&#8217;s
coding style.</p></div>
<div class="sect2">
<h3 id="author">Author</h3>
<div class="paragraph"><p>The Git community.</p></div>
</div>
</div>
</div>
<div class="sect1">
<h2 id="table_of_contents">Table of contents</h2>
<div class="sectionbody">
<div class="ulist"><ul>
<li>
<p>
<a href="#vscode">[vscode]</a>
</p>
</li>
<li>
<p>
<a href="#emacs">[emacs]</a>
</p>
</li>
</ul></div>
<div class="sect2">
<h3 id="vscode">Visual Studio Code (VS Code)</h3>
<div class="paragraph"><p>The contrib/vscode/init.sh script creates configuration files that enable
several valuable VS Code features. See contrib/vscode/README.md for more
information on using the script.</p></div>
</div>
<div class="sect2">
<h3 id="emacs">Emacs</h3>
<div class="paragraph"><p>This is adapted from Linux&#8217;s suggestion in its CodingStyle document:</p></div>
<div class="ulist"><ul>
<li>
<p>
To follow rules of the CodingGuideline, it&#8217;s useful to put the following in
GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode:
</p>
</li>
</ul></div>
<div class="listingblock">
<div class="content">
<pre><code>;; 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))))</code></pre>
</div></div>
<div class="paragraph"><p>For a more complete setup, since Git&#8217;s codebase uses a coding style
similar to the Linux kernel&#8217;s style, tips given in Linux&#8217;s CodingStyle
document can be applied here too.</p></div>
<div class="sect3">
<h4 id="_a_href_https_www_kernel_org_doc_html_v4_10_process_coding_style_html_you_ve_made_a_mess_of_it_https_www_kernel_org_doc_html_v4_10_process_coding_style_html_you_ve_made_a_mess_of_it_a"><a href="https://www.kernel.org/doc/html/v4.10/process/coding-style.html#you-ve-made-a-mess-of-it">https://www.kernel.org/doc/html/v4.10/process/coding-style.html#you-ve-made-a-mess-of-it</a></h4>
</div>
</div>
</div>
</div>
</div>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
Last updated
2022-08-31 14:31:31 PDT
</div>
</div>
</body>
</html>

@ -750,7 +750,7 @@ link you clicked to get here.</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2018-06-15 19:46:24 PDT
2022-01-27 18:10:56 PST
</div>
</div>
</body>

@ -1030,7 +1030,9 @@ for "git add --no-all &lt;pathspec&gt;&#8230;", i.e. ignored removed files.</p><
forcibly add them again to the index. This is useful after
changing <code>core.autocrlf</code> configuration or the <code>text</code> attribute
in order to correct files added with wrong CRLF/LF line endings.
This option implies <code>-u</code>.
This option implies <code>-u</code>. Lone CR characters are untouched, thus
while a CRLF cleans to LF, a CRCRLF sequence is only partially
cleaned to CRLF.
</p>
</dd>
<dt class="hdlist1">
@ -1366,6 +1368,41 @@ modifying the contents of context or removal lines
</div>
</div>
<div class="sect1">
<h2 id="_configuration">CONFIGURATION</h2>
<div class="sectionbody">
<div class="paragraph"><p>Everything below this line in this section is selectively included
from the <a href="git-config.html">git-config(1)</a> documentation. The content is the same
as what&#8217;s found there:</p></div>
<div class="dlist"><dl>
<dt class="hdlist1">
add.ignoreErrors
</dt>
<dt class="hdlist1">
add.ignore-errors (deprecated)
</dt>
<dd>
<p>
Tells <em>git add</em> to continue adding files when some files cannot be
added due to indexing errors. Equivalent to the <code>--ignore-errors</code>
option of <a href="git-add.html">git-add(1)</a>. <code>add.ignore-errors</code> is deprecated,
as it does not follow the usual naming convention for configuration
variables.
</p>
</dd>
<dt class="hdlist1">
add.interactive.useBuiltin
</dt>
<dd>
<p>
Set to <code>false</code> to fall back to the original Perl implementation of
the interactive version of <a href="git-add.html">git-add(1)</a> instead of the built-in
version. Is <code>true</code> by default.
</p>
</dd>
</dl></div>
</div>
</div>
<div class="sect1">
<h2 id="_see_also">SEE ALSO</h2>
<div class="sectionbody">
<div class="paragraph"><p><a href="git-status.html">git-status(1)</a>
@ -1387,7 +1424,7 @@ modifying the contents of context or removal lines
<div id="footer">
<div id="footer-text">
Last updated
2021-11-15 13:27:01 PST
2022-10-08 14:40:28 PDT
</div>
</div>
</body>

@ -756,8 +756,9 @@ git-am(1) Manual Page
[--exclude=&lt;path&gt;] [--include=&lt;path&gt;] [--reject] [-q | --quiet]
[--[no-]scissors] [-S[&lt;keyid&gt;]] [--patch-format=&lt;format&gt;]
[--quoted-cr=&lt;action&gt;]
[--empty=(stop|drop|keep)]
[(&lt;mbox&gt; | &lt;Maildir&gt;)&#8230;]
<em>git am</em> (--continue | --skip | --abort | --quit | --show-current-patch[=(diff|raw)])</pre>
<em>git am</em> (--continue | --skip | --abort | --quit | --show-current-patch[=(diff|raw)] | --allow-empty)</pre>
<div class="attribution">
</div></div>
</div>
@ -857,6 +858,19 @@ current branch.</p></div>
</p>
</dd>
<dt class="hdlist1">
--empty=(stop|drop|keep)
</dt>
<dd>
<p>
By default, or when the option is set to <em>stop</em>, the command
errors out on an input e-mail message lacking a patch
and stops into the middle of the current am session. When this
option is set to <em>drop</em>, skip such an e-mail message instead.
When this option is set to <em>keep</em>, create an empty commit,
recording the contents of the e-mail message as its log.
</p>
</dd>
<dt class="hdlist1">
-m
</dt>
<dt class="hdlist1">
@ -943,8 +957,13 @@ default. You can use <code>--no-utf8</code> to override this.</p></div>
</dt>
<dd>
<p>
Allow the rerere mechanism to update the index with the
result of auto-conflict resolution if possible.
After the rerere mechanism reuses a recorded resolution on
the current conflict to update the files in the working
tree, allow it to also update the index with the result of
resolution. <code>--no-rerere-autoupdate</code> is a good way to
double-check what <code>rerere</code> did and catch potential
mismerges, before committing the result to the index with a
separate <code>git add</code>.
</p>
</dd>
<dt class="hdlist1">
@ -1116,6 +1135,16 @@ default. You can use <code>--no-utf8</code> to override this.</p></div>
Defaults to <code>raw</code>.
</p>
</dd>
<dt class="hdlist1">
--allow-empty
</dt>
<dd>
<p>
After a patch failure on an input e-mail message lacking a patch,
create an empty commit with the contents of the e-mail message
as its log message.
</p>
</dd>
</dl></div>
</div>
</div>
@ -1193,6 +1222,41 @@ information.</p></div>
</div>
</div>
<div class="sect1">
<h2 id="_configuration">CONFIGURATION</h2>
<div class="sectionbody">
<div class="paragraph"><p>Everything below this line in this section is selectively included
from the <a href="git-config.html">git-config(1)</a> documentation. The content is the same
as what&#8217;s found there:</p></div>
<div class="dlist"><dl>
<dt class="hdlist1">
am.keepcr
</dt>
<dd>
<p>
If true, git-am will call git-mailsplit for patches in mbox format
with parameter <code>--keep-cr</code>. In this case git-mailsplit will
not remove <code>\r</code> from lines ending with <code>\r\n</code>. Can be overridden
by giving <code>--no-keep-cr</code> from the command line.
See <a href="git-am.html">git-am(1)</a>, <a href="git-mailsplit.html">git-mailsplit(1)</a>.
</p>
</dd>
<dt class="hdlist1">
am.threeWay
</dt>
<dd>
<p>
By default, <code>git am</code> will fail if the patch does not apply cleanly. When
set to true, this setting tells <code>git am</code> to fall back on 3-way merge if
the patch records the identity of blobs it is supposed to apply to and
we have those blobs available locally (equivalent to giving the <code>--3way</code>
option from the command line). Defaults to <code>false</code>.
See <a href="git-am.html">git-am(1)</a>.
</p>
</dd>
</dl></div>
</div>
</div>
<div class="sect1">
<h2 id="_see_also">SEE ALSO</h2>
<div class="sectionbody">
<div class="paragraph"><p><a href="git-apply.html">git-apply(1)</a>.</p></div>
@ -1209,7 +1273,7 @@ information.</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2021-11-15 13:27:01 PST
2022-10-08 14:40:28 PDT
</div>
</div>
</body>

@ -1091,7 +1091,7 @@ take effect.</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2021-09-30 23:04:56 PDT
2022-06-28 20:23:28 PDT
</div>
</div>
</body>

@ -756,7 +756,7 @@ git-apply(1) Manual Page
[--ignore-space-change | --ignore-whitespace]
[--whitespace=(nowarn|warn|fix|error|error-all)]
[--exclude=&lt;path&gt;] [--include=&lt;path&gt;] [--directory=&lt;root&gt;]
[--verbose] [--unsafe-paths] [&lt;patch&gt;&#8230;]</pre>
[--verbose | --quiet] [--unsafe-paths] [--allow-empty] [&lt;patch&gt;&#8230;]</pre>
<div class="attribution">
</div></div>
</div>
@ -1125,6 +1125,18 @@ behavior:</p></div>
</p>
</dd>
<dt class="hdlist1">
-q
</dt>
<dt class="hdlist1">
--quiet
</dt>
<dd>
<p>
Suppress stderr output. Messages about patch status and progress
will not be printed.
</p>
</dd>
<dt class="hdlist1">
--recount
</dt>
<dd>
@ -1160,21 +1172,36 @@ running <code>git apply --directory=modules/git-gui</code>.</p></div>
the <code>--unsafe-paths</code> option to override this safety check. This option
has no effect when <code>--index</code> or <code>--cached</code> is in use.</p></div>
</dd>
<dt class="hdlist1">
--allow-empty
</dt>
<dd>
<p>
Don&#8217;t return error for patches containing no diff. This includes
empty patches and patches with commit text only.
</p>
</dd>
</dl></div>
</div>
</div>
<div class="sect1">
<h2 id="_configuration">CONFIGURATION</h2>
<div class="sectionbody">
<div class="paragraph"><p>Everything below this line in this section is selectively included
from the <a href="git-config.html">git-config(1)</a> documentation. The content is the same
as what&#8217;s found there:</p></div>
<div class="dlist"><dl>
<dt class="hdlist1">
apply.ignoreWhitespace
</dt>
<dd>
<p>
Set to <em>change</em> if you want changes in whitespace to be ignored by default.
Set to one of: no, none, never, false if you want changes in
whitespace to be significant.
When set to <em>change</em>, tells <em>git apply</em> to ignore changes in
whitespace, in the same way as the <code>--ignore-space-change</code>
option.
When set to one of: no, none, never, false tells <em>git apply</em> to
respect all whitespace differences.
See <a href="git-apply.html">git-apply(1)</a>.
</p>
</dd>
<dt class="hdlist1">
@ -1182,8 +1209,8 @@ apply.whitespace
</dt>
<dd>
<p>
When no <code>--whitespace</code> flag is given from the command
line, this configuration item is used as the default.
Tells <em>git apply</em> how to handle whitespaces, in the same way
as the <code>--whitespace</code> option. See <a href="git-apply.html">git-apply(1)</a>.
</p>
</dd>
</dl></div>
@ -1221,7 +1248,7 @@ subdirectory is checked and (if possible) updated.</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2021-10-06 09:57:11 PDT
2022-10-08 14:40:28 PDT
</div>
</div>
</body>

@ -749,8 +749,8 @@ git-archimport(1) Manual Page
<h2 id="_synopsis">SYNOPSIS</h2>
<div class="sectionbody">
<div class="verseblock">
<pre class="content"><em>git archimport</em> [-h] [-v] [-o] [-a] [-f] [-T] [-D depth] [-t tempdir]
&lt;archive/branch&gt;[:&lt;git-branch&gt;] &#8230;</pre>
<pre class="content"><em>git archimport</em> [-h] [-v] [-o] [-a] [-f] [-T] [-D &lt;depth&gt;] [-t &lt;tempdir&gt;]
&lt;archive&gt;/&lt;branch&gt;[:&lt;git-branch&gt;]&#8230;</pre>
<div class="attribution">
</div></div>
</div>
@ -760,7 +760,7 @@ git-archimport(1) Manual Page
<div class="sectionbody">
<div class="paragraph"><p>Imports a project from one or more GNU Arch repositories.
It will follow branches
and repositories within the namespaces defined by the &lt;archive/branch&gt;
and repositories within the namespaces defined by the &lt;archive&gt;/&lt;branch&gt;
parameters supplied. If it cannot find the remote branch a merge comes from
it will just import it as a regular commit. If it can find it, it will mark it
as a merge whenever possible (see discussion below).</p></div>
@ -769,7 +769,7 @@ from an <em>initial import</em> or <em>tag</em> type of Arch commit. It will fol
import new branches within the provided roots.</p></div>
<div class="paragraph"><p>It expects to be dealing with one project only. If it sees
branches that have different roots, it will refuse to run. In that case,
edit your &lt;archive/branch&gt; parameters to define clearly the scope of the
edit your &lt;archive&gt;/&lt;branch&gt; parameters to define clearly the scope of the
import.</p></div>
<div class="paragraph"><p><em>git archimport</em> uses <code>tla</code> extensively in the background to access the
Arch repository.
@ -781,7 +781,7 @@ directory. To follow the development of a project that uses Arch, rerun
incremental imports.</p></div>
<div class="paragraph"><p>While <em>git archimport</em> will try to create sensible branch names for the
archives that it imports, it is also possible to specify Git branch names
manually. To do so, write a Git branch name after each &lt;archive/branch&gt;
manually. To do so, write a Git branch name after each &lt;archive&gt;/&lt;branch&gt;
parameter, separated by a colon. This way, you can shorten the Arch
branch names and convert Arch jargon to Git jargon, for example mapping a
"PROJECT&#45;&#45;devo&#45;&#45;VERSION" branch to "master".</p></div>
@ -884,11 +884,11 @@ patches that have been traded out-of-sequence between the branches.</p></div>
</p>
</dd>
<dt class="hdlist1">
&lt;archive/branch&gt;
&lt;archive&gt;/&lt;branch&gt;
</dt>
<dd>
<p>
Archive/branch identifier in a format that <code>tla log</code> understands.
&lt;archive&gt;/&lt;branch&gt; identifier in a format that <code>tla log</code> understands.
</p>
</dd>
</dl></div>
@ -905,7 +905,7 @@ patches that have been traded out-of-sequence between the branches.</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2021-11-15 09:20:10 PST
2022-06-28 20:23:28 PDT
</div>
</div>
</body>

@ -783,10 +783,12 @@ comment.</p></div>
</dt>
<dd>
<p>
Format of the resulting archive: <em>tar</em> or <em>zip</em>. If this option
Format of the resulting archive. Possible values are <code>tar</code>,
<code>zip</code>, <code>tar.gz</code>, <code>tgz</code>, and any format defined using the
configuration option <code>tar.&lt;format&gt;.command</code>. If <code>--format</code>
is not given, and the output file is specified, the format is
inferred from the filename if possible (e.g. writing to "foo.zip"
makes the output to be in the zip format). Otherwise the output
inferred from the filename if possible (e.g. writing to <code>foo.zip</code>
makes the output to be in the <code>zip</code> format). Otherwise the output
format is <code>tar</code>.
</p>
</dd>
@ -817,7 +819,9 @@ comment.</p></div>
</dt>
<dd>
<p>
Prepend &lt;prefix&gt;/ to each filename in the archive.
Prepend &lt;prefix&gt;/ to paths in the archive. Can be repeated; its
rightmost value is used for all tracked files. See below which
value gets used by <code>--add-file</code> and <code>--add-virtual-file</code>.
</p>
</dd>
<dt class="hdlist1">
@ -837,10 +841,30 @@ comment.</p></div>
<dd>
<p>
Add a non-tracked file to the archive. Can be repeated to add
multiple files. The path of the file in the archive is built by
concatenating the value of the last <code>--prefix</code> option (if any)
before this <code>--add-file</code> and the basename of &lt;file&gt;.
</p>
</dd>
<dt class="hdlist1">
--add-virtual-file=&lt;path&gt;:&lt;content&gt;
</dt>
<dd>
<p>
Add the specified contents to the archive. Can be repeated to add
multiple files. The path of the file in the archive is built
by concatenating the value for <code>--prefix</code> (if any) and the
basename of &lt;file&gt;.
by concatenating the value of the last <code>--prefix</code> option (if any)
before this <code>--add-virtual-file</code> and <code>&lt;path&gt;</code>.
</p>
<div class="paragraph"><p>The <code>&lt;path&gt;</code> argument can start and end with a literal double-quote
character; the contained file name is interpreted as a C-style string,
i.e. the backslash is interpreted as escape character. The path must
be quoted if it contains a colon, to avoid the colon from being
misinterpreted as the separator between the path and the contents, or
if the path begins or ends with a double-quote character.</p></div>
<div class="paragraph"><p>The file mode is limited to a regular file, and the option may be
subject to platform-dependent command-line limits. For non-trivial
cases, write an untracked file and use <code>--add-file</code> instead.</p></div>
</dd>
<dt class="hdlist1">
--worktree-attributes
@ -966,21 +990,20 @@ tar.&lt;format&gt;.command
is executed using the shell with the generated tar file on its
standard input, and should produce the final output on its
standard output. Any compression-level options will be passed
to the command (e.g., "-9"). An output file with the same
extension as <code>&lt;format&gt;</code> will be use this format if no other
format is given.
to the command (e.g., <code>-9</code>).
</p>
<div class="paragraph"><p>The "tar.gz" and "tgz" formats are defined automatically and default to
<code>gzip -cn</code>. You may override them with custom commands.</p></div>
<div class="paragraph"><p>The <code>tar.gz</code> and <code>tgz</code> formats are defined automatically and use the
magic command <code>git archive gzip</code> by default, which invokes an internal
implementation of gzip.</p></div>
</dd>
<dt class="hdlist1">
tar.&lt;format&gt;.remote
</dt>
<dd>
<p>
If true, enable <code>&lt;format&gt;</code> for use by remote clients via
If true, enable the format for use by remote clients via
<a href="git-upload-archive.html">git-upload-archive(1)</a>. Defaults to false for
user-defined formats, but true for the "tar.gz" and "tgz"
user-defined formats, but true for the <code>tar.gz</code> and <code>tgz</code>
formats.
</p>
</dd>
@ -1087,6 +1110,16 @@ while archiving any tree in your <code>$GIT_DIR/info/attributes</code> file.</p>
</p>
</dd>
<dt class="hdlist1">
<code>git archive -o latest.tar --prefix=build/ --add-file=configure --prefix= HEAD</code>
</dt>
<dd>
<p>
Creates a tar archive that contains the contents of the latest
commit on the current branch with no prefix and the untracked
file <em>configure</em> with the prefix <em>build/</em>.
</p>
</dd>
<dt class="hdlist1">
<code>git config tar.tar.xz.command "xz -c"</code>
</dt>
<dd>
@ -1116,7 +1149,7 @@ while archiving any tree in your <code>$GIT_DIR/info/attributes</code> file.</p>
<div id="footer">
<div id="footer-text">
Last updated
2021-11-15 13:27:01 PST
2022-09-16 17:50:33 PDT
</div>
</div>
</body>

@ -1983,7 +1983,7 @@ author to given a talk and for publishing this paper.</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2021-10-06 09:57:11 PDT
2022-06-28 20:23:28 PDT
</div>
</div>
</body>

@ -1240,7 +1240,7 @@ help</code> or <code>git bisect -h</code> to get a long usage description.</p></
<div id="footer">
<div id="footer-text">
Last updated
2021-10-06 09:57:11 PDT
2022-06-28 20:23:28 PDT
</div>
</div>
</body>

@ -1396,6 +1396,94 @@ commit commentary), a blame viewer will not care.</td>
</div>
</div>
<div class="sect1">
<h2 id="_configuration">CONFIGURATION</h2>
<div class="sectionbody">
<div class="paragraph"><p>Everything below this line in this section is selectively included
from the <a href="git-config.html">git-config(1)</a> documentation. The content is the same
as what&#8217;s found there:</p></div>
<div class="dlist"><dl>
<dt class="hdlist1">
blame.blankBoundary
</dt>
<dd>
<p>
Show blank commit object name for boundary commits in
<a href="git-blame.html">git-blame(1)</a>. This option defaults to false.
</p>
</dd>
<dt class="hdlist1">
blame.coloring
</dt>
<dd>
<p>
This determines the coloring scheme to be applied to blame
output. It can be <em>repeatedLines</em>, <em>highlightRecent</em>,
or <em>none</em> which is the default.
</p>
</dd>
<dt class="hdlist1">
blame.date
</dt>
<dd>
<p>
Specifies the format used to output dates in <a href="git-blame.html">git-blame(1)</a>.
If unset the iso format is used. For supported values,
see the discussion of the <code>--date</code> option at <a href="git-log.html">git-log(1)</a>.
</p>
</dd>
<dt class="hdlist1">
blame.showEmail
</dt>
<dd>
<p>
Show the author email instead of author name in <a href="git-blame.html">git-blame(1)</a>.
This option defaults to false.
</p>
</dd>
<dt class="hdlist1">
blame.showRoot
</dt>
<dd>
<p>
Do not treat root commits as boundaries in <a href="git-blame.html">git-blame(1)</a>.
This option defaults to false.
</p>
</dd>
<dt class="hdlist1">
blame.ignoreRevsFile
</dt>
<dd>
<p>
Ignore revisions listed in the file, one unabbreviated object name per
line, in <a href="git-blame.html">git-blame(1)</a>. Whitespace and comments beginning with
<code>#</code> are ignored. This option may be repeated multiple times. Empty
file names will reset the list of ignored revisions. This option will
be handled before the command line option <code>--ignore-revs-file</code>.
</p>
</dd>
<dt class="hdlist1">
blame.markUnblamableLines
</dt>
<dd>
<p>
Mark lines that were changed by an ignored revision that we could not
attribute to another commit with a <em>*</em> in the output of
<a href="git-blame.html">git-blame(1)</a>.
</p>
</dd>
<dt class="hdlist1">
blame.markIgnoredLines
</dt>
<dd>
<p>
Mark lines that were changed by an ignored revision that we attributed to
another commit with a <em>?</em> in the output of <a href="git-blame.html">git-blame(1)</a>.
</p>
</dd>
</dl></div>
</div>
</div>
<div class="sect1">
<h2 id="_see_also">SEE ALSO</h2>
<div class="sectionbody">
<div class="paragraph"><p><a href="git-annotate.html">git-annotate(1)</a></p></div>
@ -1412,7 +1500,7 @@ commit commentary), a blame viewer will not care.</td>
<div id="footer">
<div id="footer-text">
Last updated
2021-11-15 13:27:01 PST
2022-10-08 14:40:28 PDT
</div>
</div>
</body>

@ -757,7 +757,8 @@ git-branch(1) Manual Page
[--points-at &lt;object&gt;] [--format=&lt;format&gt;]
[(-r | --remotes) | (-a | --all)]
[--list] [&lt;pattern&gt;&#8230;]
<em>git branch</em> [--track | --no-track] [-f] &lt;branchname&gt; [&lt;start-point&gt;]
<em>git branch</em> [--track[=(direct|inherit)] | --no-track] [-f]
[--recurse-submodules] &lt;branchname&gt; [&lt;start-point&gt;]
<em>git branch</em> (--set-upstream-to=&lt;upstream&gt; | -u &lt;upstream&gt;) [&lt;branchname&gt;]
<em>git branch</em> --unset-upstream [&lt;branchname&gt;]
<em>git branch</em> (-m | -M) [&lt;oldbranch&gt;] &lt;newbranch&gt;
@ -1068,23 +1069,34 @@ way to clean up all obsolete remote-tracking branches.</p></div>
-t
</dt>
<dt class="hdlist1">
--track
--track[=(direct|inherit)]
</dt>
<dd>
<p>
When creating a new branch, set up <code>branch.&lt;name&gt;.remote</code> and
<code>branch.&lt;name&gt;.merge</code> configuration entries to mark the
start-point branch as "upstream" from the new branch. This
<code>branch.&lt;name&gt;.merge</code> configuration entries to set "upstream" tracking
configuration for the new branch. This
configuration will tell git to show the relationship between the
two branches in <code>git status</code> and <code>git branch -v</code>. Furthermore,
it directs <code>git pull</code> without arguments to pull from the
upstream when the new branch is checked out.
</p>
<div class="paragraph"><p>This behavior is the default when the start point is a remote-tracking branch.
Set the branch.autoSetupMerge configuration variable to <code>false</code> if you
want <code>git switch</code>, <code>git checkout</code> and <code>git branch</code> to always behave as if <code>--no-track</code>
were given. Set it to <code>always</code> if you want this behavior when the
start-point is either a local or remote-tracking branch.</p></div>
<div class="paragraph"><p>The exact upstream branch is chosen depending on the optional argument:
<code>-t</code>, <code>--track</code>, or <code>--track=direct</code> means to use the start-point branch
itself as the upstream; <code>--track=inherit</code> means to copy the upstream
configuration of the start-point branch.</p></div>
<div class="paragraph"><p>The branch.autoSetupMerge configuration variable specifies how <code>git switch</code>,
<code>git checkout</code> and <code>git branch</code> should behave when neither <code>--track</code> nor
<code>--no-track</code> are specified:</p></div>
<div class="paragraph"><p>The default option, <code>true</code>, behaves as though <code>--track=direct</code>
were given whenever the start-point is a remote-tracking branch.
<code>false</code> behaves as if <code>--no-track</code> were given. <code>always</code> behaves as though
<code>--track=direct</code> were given. <code>inherit</code> behaves as though <code>--track=inherit</code>
were given. <code>simple</code> behaves as though <code>--track=direct</code> were given only when
the start-point is a remote-tracking branch and the new branch has the same
name as the remote branch.</p></div>
<div class="paragraph"><p>See <a href="git-pull.html">git-pull(1)</a> and <a href="git-config.html">git-config(1)</a> for additional discussion on
how the <code>branch.&lt;name&gt;.remote</code> and <code>branch.&lt;name&gt;.merge</code> options are used.</p></div>
</dd>
<dt class="hdlist1">
--no-track
@ -1092,10 +1104,30 @@ start-point is either a local or remote-tracking branch.</p></div>
<dd>
<p>
Do not set up "upstream" configuration, even if the
branch.autoSetupMerge configuration variable is true.
branch.autoSetupMerge configuration variable is set.
</p>
</dd>
<dt class="hdlist1">
--recurse-submodules
</dt>
<dd>
<p>
THIS OPTION IS EXPERIMENTAL! Causes the current command to
recurse into submodules if <code>submodule.propagateBranches</code> is
enabled. See <code>submodule.propagateBranches</code> in
<a href="git-config.html">git-config(1)</a>. Currently, only branch creation is
supported.
</p>
<div class="paragraph"><p>When used in branch creation, a new branch &lt;branchname&gt; will be created
in the superproject and all of the submodules in the superproject&#8217;s
&lt;start-point&gt;. In submodules, the branch will point to the submodule
commit in the superproject&#8217;s &lt;start-point&gt; but the branch&#8217;s tracking
information will be set up based on the submodule&#8217;s branches and remotes
e.g. <code>git branch --recurse-submodules topic origin/main</code> will create the
submodule branch "topic" that points to the submodule commit in the
superproject&#8217;s "origin/main", but tracks the submodule&#8217;s "origin/main".</p></div>
</dd>
<dt class="hdlist1">
--set-upstream
</dt>
<dd>
@ -1254,6 +1286,156 @@ start-point is either a local or remote-tracking branch.</p></div>
<div class="paragraph"><p><code>pager.branch</code> is only respected when listing branches, i.e., when
<code>--list</code> is used or implied. The default is to use a pager.
See <a href="git-config.html">git-config(1)</a>.</p></div>
<div class="paragraph"><p>Everything above this line in this section isn&#8217;t included from the
<a href="git-config.html">git-config(1)</a> documentation. The content that follows is the
same as what&#8217;s found there:</p></div>
<div class="dlist"><dl>
<dt class="hdlist1">
branch.autoSetupMerge
</dt>
<dd>
<p>
Tells <em>git branch</em>, <em>git switch</em> and <em>git checkout</em> to set up new branches
so that <a href="git-pull.html">git-pull(1)</a> will appropriately merge from the
starting point branch. Note that even if this option is not set,
this behavior can be chosen per-branch using the <code>--track</code>
and <code>--no-track</code> options. The valid settings are: <code>false</code>&#8201;&#8212;&#8201;no
automatic setup is done; <code>true</code>&#8201;&#8212;&#8201;automatic setup is done when the
starting point is a remote-tracking branch; <code>always</code>&#8201;&#8212;&#8201; automatic setup is done when the starting point is either a
local branch or remote-tracking branch; <code>inherit</code>&#8201;&#8212;&#8201;if the starting point
has a tracking configuration, it is copied to the new
branch; <code>simple</code>&#8201;&#8212;&#8201;automatic setup is done only when the starting point
is a remote-tracking branch and the new branch has the same name as the
remote branch. This option defaults to true.
</p>
</dd>
<dt class="hdlist1">
branch.autoSetupRebase
</dt>
<dd>
<p>
When a new branch is created with <em>git branch</em>, <em>git switch</em> or <em>git checkout</em>
that tracks another branch, this variable tells Git to set
up pull to rebase instead of merge (see "branch.&lt;name&gt;.rebase").
When <code>never</code>, rebase is never automatically set to true.
When <code>local</code>, rebase is set to true for tracked branches of
other local branches.
When <code>remote</code>, rebase is set to true for tracked branches of
remote-tracking branches.
When <code>always</code>, rebase will be set to true for all tracking
branches.
See "branch.autoSetupMerge" for details on how to set up a
branch to track another branch.
This option defaults to never.
</p>
</dd>
<dt class="hdlist1">
branch.sort
</dt>
<dd>
<p>
This variable controls the sort ordering of branches when displayed by
<a href="git-branch.html">git-branch(1)</a>. Without the "--sort=&lt;value&gt;" option provided, the
value of this variable will be used as the default.
See <a href="git-for-each-ref.html">git-for-each-ref(1)</a> field names for valid values.
</p>
</dd>
<dt class="hdlist1">
branch.&lt;name&gt;.remote
</dt>
<dd>
<p>
When on branch &lt;name&gt;, it tells <em>git fetch</em> and <em>git push</em>
which remote to fetch from/push to. The remote to push to
may be overridden with <code>remote.pushDefault</code> (for all branches).
The remote to push to, for the current branch, may be further
overridden by <code>branch.&lt;name&gt;.pushRemote</code>. If no remote is
configured, or if you are not on any branch and there is more than
one remote defined in the repository, it defaults to <code>origin</code> for
fetching and <code>remote.pushDefault</code> for pushing.
Additionally, <code>.</code> (a period) is the current local repository
(a dot-repository), see <code>branch.&lt;name&gt;.merge</code>'s final note below.
</p>
</dd>
<dt class="hdlist1">
branch.&lt;name&gt;.pushRemote
</dt>
<dd>
<p>
When on branch &lt;name&gt;, it overrides <code>branch.&lt;name&gt;.remote</code> for
pushing. It also overrides <code>remote.pushDefault</code> for pushing
from branch &lt;name&gt;. When you pull from one place (e.g. your
upstream) and push to another place (e.g. your own publishing
repository), you would want to set <code>remote.pushDefault</code> to
specify the remote to push to for all branches, and use this
option to override it for a specific branch.
</p>
</dd>
<dt class="hdlist1">
branch.&lt;name&gt;.merge
</dt>
<dd>
<p>
Defines, together with branch.&lt;name&gt;.remote, the upstream branch
for the given branch. It tells <em>git fetch</em>/<em>git pull</em>/<em>git rebase</em> which
branch to merge and can also affect <em>git push</em> (see push.default).
When in branch &lt;name&gt;, it tells <em>git fetch</em> the default
refspec to be marked for merging in FETCH_HEAD. The value is
handled like the remote part of a refspec, and must match a
ref which is fetched from the remote given by
"branch.&lt;name&gt;.remote".
The merge information is used by <em>git pull</em> (which at first calls
<em>git fetch</em>) to lookup the default branch for merging. Without
this option, <em>git pull</em> defaults to merge the first refspec fetched.
Specify multiple values to get an octopus merge.
If you wish to setup <em>git pull</em> so that it merges into &lt;name&gt; from
another branch in the local repository, you can point
branch.&lt;name&gt;.merge to the desired branch, and use the relative path
setting <code>.</code> (a period) for branch.&lt;name&gt;.remote.
</p>
</dd>
<dt class="hdlist1">
branch.&lt;name&gt;.mergeOptions
</dt>
<dd>
<p>
Sets default options for merging into branch &lt;name&gt;. The syntax and
supported options are the same as those of <a href="git-merge.html">git-merge(1)</a>, but
option values containing whitespace characters are currently not
supported.
</p>
</dd>
<dt class="hdlist1">
branch.&lt;name&gt;.rebase
</dt>
<dd>
<p>
When true, rebase the branch &lt;name&gt; on top of the fetched branch,
instead of merging the default branch from the default remote when
"git pull" is run. See "pull.rebase" for doing this in a non
branch-specific manner.
</p>
<div class="paragraph"><p>When <code>merges</code> (or just <em>m</em>), pass the <code>--rebase-merges</code> option to <em>git rebase</em>
so that the local merge commits are included in the rebase (see
<a href="git-rebase.html">git-rebase(1)</a> for details).</p></div>
<div class="paragraph"><p>When the value is <code>interactive</code> (or just <em>i</em>), the rebase is run in interactive
mode.</p></div>
<div class="paragraph"><p><strong>NOTE</strong>: this is a possibly dangerous operation; do <strong>not</strong> use
it unless you understand the implications (see <a href="git-rebase.html">git-rebase(1)</a>
for details).</p></div>
</dd>
<dt class="hdlist1">
branch.&lt;name&gt;.description
</dt>
<dd>
<p>
Branch description, can be edited with
<code>git branch --edit-description</code>. Branch description is
automatically added in the format-patch cover letter or
request-pull summary.
</p>
</dd>
</dl></div>
</div>
</div>
<div class="sect1">
@ -1398,7 +1580,7 @@ a branch?&#8221;</a> in the Git User&#8217;s Manual.</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2021-11-15 13:27:01 PST
2022-10-08 14:40:28 PDT
</div>
</div>
</body>

@ -749,7 +749,8 @@ git-bugreport(1) Manual Page
<h2 id="_synopsis">SYNOPSIS</h2>
<div class="sectionbody">
<div class="verseblock">
<pre class="content"><em>git bugreport</em> [(-o | --output-directory) &lt;path&gt;] [(-s | --suffix) &lt;format&gt;]</pre>
<pre class="content"><em>git bugreport</em> [(-o | --output-directory) &lt;path&gt;] [(-s | --suffix) &lt;format&gt;]
[--diagnose[=&lt;mode&gt;]]</pre>
<div class="attribution">
</div></div>
</div>
@ -807,6 +808,9 @@ $SHELL
</p>
</li>
</ul></div>
<div class="paragraph"><p>Additional information may be gathered into a separate zip archive using the
<code>--diagnose</code> option, and can be attached alongside the bugreport document to
provide additional context to readers.</p></div>
<div class="paragraph"><p>This tool is invoked via the typical Git setup process, which means that in some
cases, it might not be able to launch - for example, if a relevant config file
is unreadable. In this kind of scenario, it may be helpful to manually gather
@ -842,6 +846,25 @@ the kind of information listed above when manually asking for help.</p></div>
strftime(3) format string; the current local time will be used.
</p>
</dd>
<dt class="hdlist1">
--no-diagnose
</dt>
<dt class="hdlist1">
--diagnose[=&lt;mode&gt;]
</dt>
<dd>
<p>
Create a zip archive of supplemental information about the user&#8217;s
machine, Git client, and repository state. The archive is written to the
same output directory as the bug report and is named
<em>git-diagnostics-&lt;formatted suffix&gt;</em>.
</p>
<div class="paragraph"><p>Without <code>mode</code> specified, the diagnostic archive will contain the default set of
statistics reported by <code>git diagnose</code>. An optional <code>mode</code> value may be specified
to change which information is included in the archive. See
<a href="git-diagnose.html">git-diagnose(1)</a> for the list of valid values for <code>mode</code> and details
about their usage.</p></div>
</dd>
</dl></div>
</div>
</div>
@ -856,7 +879,7 @@ the kind of information listed above when manually asking for help.</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2021-10-06 09:57:11 PDT
2022-09-16 17:50:33 PDT
</div>
</div>
</body>

@ -782,7 +782,7 @@ supported.</p></div>
<div class="sectionbody">
<div class="paragraph"><p>Bundles are <code>.pack</code> files (see <a href="git-pack-objects.html">git-pack-objects(1)</a>) with a
header indicating what references are contained within the bundle.</p></div>
<div class="paragraph"><p>Like the the packed archive format itself bundles can either be
<div class="paragraph"><p>Like the packed archive format itself bundles can either be
self-contained, or be created using exclusions.
See the "OBJECT PREREQUISITES" section below.</p></div>
<div class="paragraph"><p>Bundles created using revision exclusions are "thin packs" created
@ -793,10 +793,8 @@ exclusions, and users should not be concerned about the difference. By
using "thin packs", bundles created using exclusions are smaller in
size. That they&#8217;re "thin" under the hood is merely noted here as a
curiosity, and as a reference to other documentation.</p></div>
<div class="paragraph"><p>See <a href="technical/bundle-format.html">the <code>bundle-format</code>
documentation</a> for more details and the discussion of "thin pack" in
<a href="technical/pack-format.html">the pack format documentation</a> for
further details.</p></div>
<div class="paragraph"><p>See <a href="gitformat-bundle.html">gitformat-bundle(5)</a> for more details and the discussion of
"thin pack" in <a href="gitformat-pack.html">gitformat-pack(5)</a> for further details.</p></div>
</div>
</div>
<div class="sect1">
@ -823,8 +821,11 @@ verify &lt;file&gt;
cleanly to the current repository. This includes checks on the
bundle format itself as well as checking that the prerequisite
commits exist and are fully linked in the current repository.
<em>git bundle</em> prints a list of missing commits, if any, and exits
with a non-zero status.
Then, <em>git bundle</em> prints a list of missing commits, if any.
Finally, information about additional capabilities, such as "object
filter", is printed. See "Capabilities" in <a href="gitformat-bundle.html">gitformat-bundle(5)</a>
for more information. The exit code is zero for success, but will
be nonzero if the bundle file is invalid.
</p>
</dd>
<dt class="hdlist1">
@ -1111,6 +1112,12 @@ references when fetching:</p></div>
</div>
</div>
<div class="sect1">
<h2 id="_file_format">FILE FORMAT</h2>
<div class="sectionbody">
<div class="paragraph"><p>See <a href="gitformat-bundle.html">gitformat-bundle(5)</a>.</p></div>
</div>
</div>
<div class="sect1">
<h2 id="_git">GIT</h2>
<div class="sectionbody">
<div class="paragraph"><p>Part of the <a href="git.html">git(1)</a> suite</p></div>
@ -1121,7 +1128,7 @@ references when fetching:</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2021-11-15 13:27:01 PST
2022-10-08 14:40:28 PDT
</div>
</div>
</body>

@ -749,8 +749,14 @@ git-cat-file(1) Manual Page
<h2 id="_synopsis">SYNOPSIS</h2>
<div class="sectionbody">
<div class="verseblock">
<pre class="content"><em>git cat-file</em> (-t [--allow-unknown-type]| -s [--allow-unknown-type]| -e | -p | &lt;type&gt; | --textconv | --filters ) [--path=&lt;path&gt;] &lt;object&gt;
<em>git cat-file</em> (--batch[=&lt;format&gt;] | --batch-check[=&lt;format&gt;]) [ --textconv | --filters ] [--follow-symlinks]</pre>
<pre class="content"><em>git cat-file</em> &lt;type&gt; &lt;object&gt;
<em>git cat-file</em> (-e | -p) &lt;object&gt;
<em>git cat-file</em> (-t | -s) [--allow-unknown-type] &lt;object&gt;
<em>git cat-file</em> (--batch | --batch-check | --batch-command) [--batch-all-objects]
[--buffer] [--follow-symlinks] [--unordered]
[--textconv | --filters] [-z]
<em>git cat-file</em> (--textconv | --filters)
[&lt;rev&gt;:&lt;path|tree-ish&gt; | --path=&lt;path|tree-ish&gt; &lt;rev&gt;]</pre>
<div class="attribution">
</div></div>
</div>
@ -834,6 +840,19 @@ whitespace, so that the appropriate drivers can be determined.</p></div>
</p>
</dd>
<dt class="hdlist1">
--[no-]mailmap
</dt>
<dt class="hdlist1">
--[no-]use-mailmap
</dt>
<dd>
<p>
Use mailmap file to map author, committer and tagger names
and email addresses to canonical real names and email addresses.
See <a href="git-shortlog.html">git-shortlog(1)</a>.
</p>
</dd>
<dt class="hdlist1">
--textconv
</dt>
<dd>
@ -896,6 +915,56 @@ whitespace, so that the appropriate drivers can be determined.</p></div>
</p>
</dd>
<dt class="hdlist1">
--batch-command
</dt>
<dt class="hdlist1">
--batch-command=&lt;format&gt;
</dt>
<dd>
<p>
Enter a command mode that reads commands and arguments from stdin. May
only be combined with <code>--buffer</code>, <code>--textconv</code> or <code>--filters</code>. In the
case of <code>--textconv</code> or <code>--filters</code>, the input lines also need to specify
the path, separated by whitespace. See the section <code>BATCH OUTPUT</code> below
for details.
</p>
<div class="paragraph"><p><code>--batch-command</code> recognizes the following commands:</p></div>
<div class="openblock">
<div class="content">
<div class="dlist"><dl>
<dt class="hdlist1">
contents &lt;object&gt;
</dt>
<dd>
<p>
Print object contents for object reference <code>&lt;object&gt;</code>. This corresponds to
the output of <code>--batch</code>.
</p>
</dd>
<dt class="hdlist1">
info &lt;object&gt;
</dt>
<dd>
<p>
Print object info for object reference <code>&lt;object&gt;</code>. This corresponds to the
output of <code>--batch-check</code>.
</p>
</dd>
<dt class="hdlist1">
flush
</dt>
<dd>
<p>
Used with <code>--buffer</code> to execute all preceding commands that were issued
since the beginning or since the last flush was issued. When <code>--buffer</code>
is used, no output will come until a <code>flush</code> is issued. When <code>--buffer</code>
is not used, commands are flushed each time without issuing <code>flush</code>.
</p>
</dd>
</dl></div>
</div></div>
</dd>
<dt class="hdlist1">
--batch-all-objects
</dt>
<dd>
@ -918,7 +987,7 @@ whitespace, so that the appropriate drivers can be determined.</p></div>
that a process can interactively read and write from
<code>cat-file</code>. With this option, the output uses normal stdio
buffering; this is much more efficient when invoking
<code>--batch-check</code> on a large number of objects.
<code>--batch-check</code> or <code>--batch-command</code> on a large number of objects.
</p>
</dd>
<dt class="hdlist1">
@ -1011,6 +1080,16 @@ respectively print:</p></div>
</div></div>
</div></div>
</dd>
<dt class="hdlist1">
-z
</dt>
<dd>
<p>
Only meaningful with <code>--batch</code>, <code>--batch-check</code>, or
<code>--batch-command</code>; input is NUL-delimited instead of
newline-delimited.
</p>
</dd>
</dl></div>
</div>
</div>
@ -1032,6 +1111,12 @@ will be returned.</p></div>
from stdin, one per line, and print information about them. By default,
the whole line is considered as an object, as if it were fed to
<a href="git-rev-parse.html">git-rev-parse(1)</a>.</p></div>
<div class="paragraph"><p>When <code>--batch-command</code> is given, <code>cat-file</code> will read commands from stdin,
one per line, and print information based on the command given. With
<code>--batch-command</code>, the <code>info</code> command followed by an object will print
information about the object the same way <code>--batch-check</code> would, and the
<code>contents</code> command followed by an object prints contents in the same way
<code>--batch</code> would.</p></div>
<div class="paragraph"><p>You can specify the information shown for each object by using a custom
<code>&lt;format&gt;</code>. The <code>&lt;format&gt;</code> is copied literally to stdout for each
object, with placeholders of the form <code>%(atom)</code> expanded, followed by a
@ -1097,9 +1182,9 @@ newline. The available atoms are:</p></div>
</dl></div>
<div class="paragraph"><p>If no format is specified, the default format is <code>%(objectname)
%(objecttype) %(objectsize)</code>.</p></div>
<div class="paragraph"><p>If <code>--batch</code> is specified, the object information is followed by the
object contents (consisting of <code>%(objectsize)</code> bytes), followed by a
newline.</p></div>
<div class="paragraph"><p>If <code>--batch</code> is specified, or if <code>--batch-command</code> is used with the <code>contents</code>
command, the object information is followed by the object contents (consisting
of <code>%(objectsize)</code> bytes), followed by a newline.</p></div>
<div class="paragraph"><p>For example, <code>--batch</code> without a custom format would produce:</p></div>
<div class="listingblock">
<div class="content">
@ -1188,7 +1273,7 @@ will be reported.</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2021-11-15 13:27:01 PST
2022-09-16 17:50:33 PDT
</div>
</div>
</body>

@ -960,7 +960,7 @@ README: caveat: unspecified</code></pre>
<div id="footer">
<div id="footer-text">
Last updated
2021-09-30 23:04:56 PDT
2022-06-28 20:23:28 PDT
</div>
</div>
</body>

@ -787,7 +787,7 @@ subject to exclude rules; but see &#8216;--no-index&#8217;.</p></div>
Instead of printing the paths that are excluded, for each path
that matches an exclude pattern, print the exclude pattern
together with the path. (Matching an exclude pattern usually
means the path is excluded, but if the pattern begins with <em>!</em>
means the path is excluded, but if the pattern begins with "<code>!</code>"
then it is a negated pattern and matching it means the path is
NOT excluded.)
</p>
@ -851,7 +851,7 @@ ignored.</p></div>
<div class="paragraph"><p>&lt;pathname&gt; is the path of a file being queried, &lt;pattern&gt; is the
matching pattern, &lt;source&gt; is the pattern&#8217;s source file, and &lt;linenum&gt;
is the line number of the pattern within that source. If the pattern
contained a <code>!</code> prefix or <code>/</code> suffix, it will be preserved in the
contained a "<code>!</code>" prefix or "<code>/</code>" suffix, it will be preserved in the
output. &lt;source&gt; will be an absolute path when referring to the file
configured by <code>core.excludesFile</code>, or relative to the repository root
when referring to <code>.git/info/exclude</code> or a per-directory exclude file.</p></div>
@ -924,7 +924,7 @@ buffer.</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2021-09-30 23:04:56 PDT
2022-08-31 14:31:31 PDT
</div>
</div>
</body>

@ -811,7 +811,7 @@ to specify a custom <code>.mailmap</code> target file or object.</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2021-10-06 09:57:11 PDT
2022-06-28 20:23:28 PDT
</div>
</div>
</body>

@ -963,7 +963,7 @@ Determine the reference name to use for a new branch:
<div id="footer">
<div id="footer-text">
Last updated
2021-09-30 23:04:56 PDT
2022-06-28 20:23:28 PDT
</div>
</div>
</body>

@ -752,6 +752,7 @@ git-checkout-index(1) Manual Page
<pre class="content"><em>git checkout-index</em> [-u] [-q] [-a] [-f] [-n] [--prefix=&lt;string&gt;]
[--stage=&lt;number&gt;|all]
[--temp]
[--ignore-skip-worktree-bits]
[-z] [--stdin]
[--] [&lt;file&gt;&#8230;]</pre>
<div class="attribution">
@ -811,8 +812,9 @@ git-checkout-index(1) Manual Page
</dt>
<dd>
<p>
checks out all files in the index. Cannot be used
together with explicit filenames.
checks out all files in the index except for those with the
skip-worktree bit set (see <code>--ignore-skip-worktree-bits</code>).
Cannot be used together with explicit filenames.
</p>
</dd>
<dt class="hdlist1">
@ -857,6 +859,15 @@ git-checkout-index(1) Manual Page
</p>
</dd>
<dt class="hdlist1">
--ignore-skip-worktree-bits
</dt>
<dd>
<p>
Check out all files, including those with the skip-worktree bit
set.
</p>
</dd>
<dt class="hdlist1">
--stdin
</dt>
<dd>
@ -1009,7 +1020,7 @@ into the file <code>.merged-Makefile</code>.</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2017-12-22 18:32:40 PST
2022-08-31 14:31:31 PDT
</div>
</div>
</body>

@ -752,7 +752,7 @@ git-checkout(1) Manual Page
<pre class="content"><em>git checkout</em> [-q] [-f] [-m] [&lt;branch&gt;]
<em>git checkout</em> [-q] [-f] [-m] --detach [&lt;branch&gt;]
<em>git checkout</em> [-q] [-f] [-m] [--detach] &lt;commit&gt;
<em>git checkout</em> [-q] [-f] [-m] [[-b|-B|--orphan] &lt;new_branch&gt;] [&lt;start_point&gt;]
<em>git checkout</em> [-q] [-f] [-m] [[-b|-B|--orphan] &lt;new-branch&gt;] [&lt;start-point&gt;]
<em>git checkout</em> [-f|--ours|--theirs|-m|--conflict=&lt;style&gt;] [&lt;tree-ish&gt;] [--] &lt;pathspec&gt;&#8230;
<em>git checkout</em> [-f|--ours|--theirs|-m|--conflict=&lt;style&gt;] [&lt;tree-ish&gt;] --pathspec-from-file=&lt;file&gt; [--pathspec-file-nul]
<em>git checkout</em> (-p|--patch) [&lt;tree-ish&gt;] [--] [&lt;pathspec&gt;&#8230;]</pre>
@ -792,7 +792,7 @@ rather expensive side-effects to show only the tracking information,
if exists, for the current branch.</p></div>
</dd>
<dt class="hdlist1">
<em>git checkout</em> -b|-B &lt;new_branch&gt; [&lt;start point&gt;]
<em>git checkout</em> -b|-B &lt;new-branch&gt; [&lt;start-point&gt;]
</dt>
<dd>
<p>
@ -803,11 +803,11 @@ if exists, for the current branch.</p></div>
<code>--track</code> without <code>-b</code> implies branch creation; see the
description of <code>--track</code> below.
</p>
<div class="paragraph"><p>If <code>-B</code> is given, <code>&lt;new_branch&gt;</code> is created if it doesn&#8217;t exist; otherwise, it
<div class="paragraph"><p>If <code>-B</code> is given, <code>&lt;new-branch&gt;</code> is created if it doesn&#8217;t exist; otherwise, it
is reset. This is the transactional equivalent of</p></div>
<div class="listingblock">
<div class="content">
<pre><code>$ git branch -f &lt;branch&gt; [&lt;start point&gt;]
<pre><code>$ git branch -f &lt;branch&gt; [&lt;start-point&gt;]
$ git checkout &lt;branch&gt;</code></pre>
</div></div>
<div class="paragraph"><p>that is to say, the branch is not reset/created unless "git checkout" is
@ -940,21 +940,21 @@ on your side branch as <code>theirs</code> (i.e. "one contributor&#8217;s work o
of it").</p></div>
</dd>
<dt class="hdlist1">
-b &lt;new_branch&gt;
-b &lt;new-branch&gt;
</dt>
<dd>
<p>
Create a new branch named <code>&lt;new_branch&gt;</code> and start it at
<code>&lt;start_point&gt;</code>; see <a href="git-branch.html">git-branch(1)</a> for details.
Create a new branch named <code>&lt;new-branch&gt;</code> and start it at
<code>&lt;start-point&gt;</code>; see <a href="git-branch.html">git-branch(1)</a> for details.
</p>
</dd>
<dt class="hdlist1">
-B &lt;new_branch&gt;
-B &lt;new-branch&gt;
</dt>
<dd>
<p>
Creates the branch <code>&lt;new_branch&gt;</code> and start it at <code>&lt;start_point&gt;</code>;
if it already exists, then reset it to <code>&lt;start_point&gt;</code>. This is
Creates the branch <code>&lt;new-branch&gt;</code> and start it at <code>&lt;start-point&gt;</code>;
if it already exists, then reset it to <code>&lt;start-point&gt;</code>. This is
equivalent to running "git branch" with "-f"; see
<a href="git-branch.html">git-branch(1)</a> for details.
</p>
@ -963,7 +963,7 @@ of it").</p></div>
-t
</dt>
<dt class="hdlist1">
--track
--track[=(direct|inherit)]
</dt>
<dd>
<p>
@ -1042,19 +1042,19 @@ variable.</p></div>
</p>
</dd>
<dt class="hdlist1">
--orphan &lt;new_branch&gt;
--orphan &lt;new-branch&gt;
</dt>
<dd>
<p>
Create a new <em>orphan</em> branch, named <code>&lt;new_branch&gt;</code>, started from
<code>&lt;start_point&gt;</code> and switch to it. The first commit made on this
Create a new <em>orphan</em> branch, named <code>&lt;new-branch&gt;</code>, started from
<code>&lt;start-point&gt;</code> and switch to it. The first commit made on this
new branch will have no parents and it will be the root of a new
history totally disconnected from all the other branches and
commits.
</p>
<div class="paragraph"><p>The index and the working tree are adjusted as if you had previously run
<code>git checkout &lt;start_point&gt;</code>. This allows you to start a new history
that records a set of paths similar to <code>&lt;start_point&gt;</code> by easily running
<code>git checkout &lt;start-point&gt;</code>. This allows you to start a new history
that records a set of paths similar to <code>&lt;start-point&gt;</code> by easily running
<code>git commit -a</code> to make the root commit.</p></div>
<div class="paragraph"><p>This can be useful when you want to publish the tree from a commit
without exposing its full history. You might want to do this to publish
@ -1062,7 +1062,7 @@ an open source branch of a project whose current tree is "clean", but
whose full history contains proprietary or otherwise encumbered bits of
code.</p></div>
<div class="paragraph"><p>If you want to start a disconnected history that records a set of paths
that is totally different from the one of <code>&lt;start_point&gt;</code>, then you should
that is totally different from the one of <code>&lt;start-point&gt;</code>, then you should
clear the index and the working tree right after creating the orphan
branch by running <code>git rm -rf .</code> from the top level of the working tree.
Afterwards you will be ready to prepare your new files, repopulating the
@ -1112,8 +1112,7 @@ the conflicted merge in the specified paths.</p></div>
The same as <code>--merge</code> option above, but changes the way the
conflicting hunks are presented, overriding the
<code>merge.conflictStyle</code> configuration variable. Possible values are
"merge" (default) and "diff3" (in addition to what is shown by
"merge" style, shows the original contents).
"merge" (default), "diff3", and "zdiff3".
</p>
</dd>
<dt class="hdlist1">
@ -1233,7 +1232,7 @@ merge base of <code>A</code> and <code>B</code> if there is exactly one merge ba
leave out at most one of <code>A</code> and <code>B</code>, in which case it defaults to <code>HEAD</code>.</p></div>
</dd>
<dt class="hdlist1">
&lt;new_branch&gt;
&lt;new-branch&gt;
</dt>
<dd>
<p>
@ -1241,7 +1240,7 @@ leave out at most one of <code>A</code> and <code>B</code>, in which case it def
</p>
</dd>
<dt class="hdlist1">
&lt;start_point&gt;
&lt;start-point&gt;
</dt>
<dd>
<p>
@ -1544,6 +1543,79 @@ $ git add frotz</code></pre>
</div>
</div>
<div class="sect1">
<h2 id="_configuration">CONFIGURATION</h2>
<div class="sectionbody">
<div class="paragraph"><p>Everything below this line in this section is selectively included
from the <a href="git-config.html">git-config(1)</a> documentation. The content is the same
as what&#8217;s found there:</p></div>
<div class="dlist"><dl>
<dt class="hdlist1">
checkout.defaultRemote
</dt>
<dd>
<p>
When you run <code>git checkout &lt;something&gt;</code>
or <code>git switch &lt;something&gt;</code> and only have one
remote, it may implicitly fall back on checking out and
tracking e.g. <code>origin/&lt;something&gt;</code>. This stops working as soon
as you have more than one remote with a <code>&lt;something&gt;</code>
reference. This setting allows for setting the name of a
preferred remote that should always win when it comes to
disambiguation. The typical use-case is to set this to
<code>origin</code>.
</p>
<div class="paragraph"><p>Currently this is used by <a href="git-switch.html">git-switch(1)</a> and
<a href="git-checkout.html">git-checkout(1)</a> when <code>git checkout &lt;something&gt;</code>
or <code>git switch &lt;something&gt;</code>
will checkout the <code>&lt;something&gt;</code> branch on another remote,
and by <a href="git-worktree.html">git-worktree(1)</a> when <code>git worktree add</code> refers to a
remote branch. This setting might be used for other checkout-like
commands or functionality in the future.</p></div>
</dd>
<dt class="hdlist1">
checkout.guess
</dt>
<dd>
<p>
Provides the default value for the <code>--guess</code> or <code>--no-guess</code>
option in <code>git checkout</code> and <code>git switch</code>. See
<a href="git-switch.html">git-switch(1)</a> and <a href="git-checkout.html">git-checkout(1)</a>.
</p>
</dd>
<dt class="hdlist1">
checkout.workers
</dt>
<dd>
<p>
The number of parallel workers to use when updating the working tree.
The default is one, i.e. sequential execution. If set to a value less
than one, Git will use as many workers as the number of logical cores
available. This setting and <code>checkout.thresholdForParallelism</code> affect
all commands that perform checkout. E.g. checkout, clone, reset,
sparse-checkout, etc.
</p>
<div class="paragraph"><p>Note: parallel checkout usually delivers better performance for repositories
located on SSDs or over NFS. For repositories on spinning disks and/or machines
with a small number of cores, the default sequential checkout often performs
better. The size and compression level of a repository might also influence how
well the parallel version performs.</p></div>
</dd>
<dt class="hdlist1">
checkout.thresholdForParallelism
</dt>
<dd>
<p>
When running parallel checkout with a small number of files, the cost
of subprocess spawning and inter-process communication might outweigh
the parallelization gains. This setting allows to define the minimum
number of files for which parallel checkout should be attempted. The
default is 100.
</p>
</dd>
</dl></div>
</div>
</div>
<div class="sect1">
<h2 id="_see_also">SEE ALSO</h2>
<div class="sectionbody">
<div class="paragraph"><p><a href="git-switch.html">git-switch(1)</a>,
@ -1561,7 +1633,7 @@ $ git add frotz</code></pre>
<div id="footer">
<div id="footer-text">
Last updated
2021-11-15 13:27:01 PST
2022-10-08 14:40:28 PDT
</div>
</div>
</body>

@ -749,7 +749,7 @@ git-cherry-pick(1) Manual Page
<h2 id="_synopsis">SYNOPSIS</h2>
<div class="sectionbody">
<div class="verseblock">
<pre class="content"><em>git cherry-pick</em> [--edit] [-n] [-m parent-number] [-s] [-x] [--ff]
<pre class="content"><em>git cherry-pick</em> [--edit] [-n] [-m &lt;parent-number&gt;] [-s] [-x] [--ff]
[-S[&lt;keyid&gt;]] &lt;commit&gt;&#8230;
<em>git cherry-pick</em> (--continue | --skip | --abort | --quit)</pre>
<div class="attribution">
@ -875,10 +875,10 @@ conflicts.</p></div>
</p>
</dd>
<dt class="hdlist1">
-m parent-number
-m &lt;parent-number&gt;
</dt>
<dt class="hdlist1">
--mainline parent-number
--mainline &lt;parent-number&gt;
</dt>
<dd>
<p>
@ -1018,8 +1018,13 @@ effect to your index in a row.</p></div>
</dt>
<dd>
<p>
Allow the rerere mechanism to update the index with the
result of auto-conflict resolution if possible.
After the rerere mechanism reuses a recorded resolution on
the current conflict to update the files in the working
tree, allow it to also update the index with the result of
resolution. <code>--no-rerere-autoupdate</code> is a good way to
double-check what <code>rerere</code> did and catch potential
mismerges, before committing the result to the index with a
separate <code>git add</code>.
</p>
</dd>
</dl></div>
@ -1212,7 +1217,7 @@ try to apply the change introduced by <code>topic^</code> again,
<div id="footer">
<div id="footer-text">
Last updated
2021-11-15 09:20:10 PST
2022-09-16 17:50:33 PDT
</div>
</div>
</body>

@ -915,7 +915,7 @@ between <code>base</code> and <code>topic</code>:</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2017-12-22 18:32:40 PST
2022-01-27 18:10:56 PST
</div>
</div>
</body>

@ -776,7 +776,7 @@ See <a href="git-gui.html">git-gui(1)</a> for more details.</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2017-12-22 18:32:40 PST
2022-01-27 18:10:56 PST
</div>
</div>
</body>

@ -957,6 +957,25 @@ help
</div>
</div>
<div class="sect1">
<h2 id="_configuration">CONFIGURATION</h2>
<div class="sectionbody">
<div class="paragraph"><p>Everything below this line in this section is selectively included
from the <a href="git-config.html">git-config(1)</a> documentation. The content is the same
as what&#8217;s found there:</p></div>
<div class="dlist"><dl>
<dt class="hdlist1">
clean.requireForce
</dt>
<dd>
<p>
A boolean to make git-clean do nothing unless given -f,
-i or -n. Defaults to true.
</p>
</dd>
</dl></div>
</div>
</div>
<div class="sect1">
<h2 id="_see_also">SEE ALSO</h2>
<div class="sectionbody">
<div class="paragraph"><p><a href="gitignore.html">gitignore(5)</a></p></div>
@ -973,7 +992,7 @@ help
<div id="footer">
<div id="footer-text">
Last updated
2021-09-30 23:04:56 PDT
2022-10-08 14:40:28 PDT
</div>
</div>
</body>

@ -749,14 +749,14 @@ git-clone(1) Manual Page
<h2 id="_synopsis">SYNOPSIS</h2>
<div class="sectionbody">
<div class="verseblock">
<pre class="content"><em>git clone</em> [--template=&lt;template_directory&gt;]
<pre class="content"><em>git clone</em> [--template=&lt;template-directory&gt;]
[-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror]
[-o &lt;name&gt;] [-b &lt;name&gt;] [-u &lt;upload-pack&gt;] [--reference &lt;repository&gt;]
[--dissociate] [--separate-git-dir &lt;git dir&gt;]
[--dissociate] [--separate-git-dir &lt;git-dir&gt;]
[--depth &lt;depth&gt;] [--[no-]single-branch] [--no-tags]
[--recurse-submodules[=&lt;pathspec&gt;]] [--[no-]shallow-submodules]
[--[no-]remote-submodules] [--jobs &lt;n&gt;] [--sparse] [--[no-]reject-shallow]
[--filter=&lt;filter&gt;] [--] &lt;repository&gt;
[--filter=&lt;filter&gt; [--also-filter-submodules]] [--] &lt;repository&gt;
[&lt;directory&gt;]</pre>
<div class="attribution">
</div></div>
@ -978,10 +978,10 @@ objects from the source repository into a pack in the cloned repository.</p></di
</dt>
<dd>
<p>
Initialize the sparse-checkout file so the working
directory starts with only the files in the root
of the repository. The sparse-checkout file can be
modified to grow the working directory as needed.
Employ a sparse-checkout, with only files in the toplevel
directory initially being present. The
<a href="git-sparse-checkout.html">git-sparse-checkout(1)</a> command can be used to grow the
working directory as needed.
</p>
</dd>
<dt class="hdlist1">
@ -1000,6 +1000,16 @@ objects from the source repository into a pack in the cloned repository.</p></di
</p>
</dd>
<dt class="hdlist1">
--also-filter-submodules
</dt>
<dd>
<p>
Also apply the partial clone filter to any submodules in the repository.
Requires <code>--filter</code> and <code>--recurse-submodules</code>. This can be turned on by
default by setting the <code>clone.filterSubmodules</code> config option.
</p>
</dd>
<dt class="hdlist1">
--mirror
</dt>
<dd>
@ -1055,7 +1065,7 @@ objects from the source repository into a pack in the cloned repository.</p></di
</p>
</dd>
<dt class="hdlist1">
--template=&lt;template_directory&gt;
--template=&lt;template-directory&gt;
</dt>
<dd>
<p>
@ -1187,7 +1197,7 @@ or <code>--mirror</code> is given)</p></div>
</p>
</dd>
<dt class="hdlist1">
--separate-git-dir=&lt;git dir&gt;
--separate-git-dir=&lt;git-dir&gt;
</dt>
<dd>
<p>
@ -1232,6 +1242,18 @@ or <code>--mirror</code> is given)</p></div>
is only allowed if the directory is empty.
</p>
</dd>
<dt class="hdlist1">
--bundle-uri=&lt;uri&gt;
</dt>
<dd>
<p>
Before fetching from the remote, fetch a bundle from the given
<code>&lt;uri&gt;</code> and unbundle the data into the local repository. The refs
in the bundle will be stored under the hidden <code>refs/bundle/*</code>
namespace. This option is incompatible with <code>--depth</code>,
<code>--shallow-since</code>, and <code>--shallow-exclude</code>.
</p>
</dd>
</dl></div>
</div>
</div>
@ -1420,6 +1442,63 @@ Create a bare repository to publish your changes to the public:
</div>
</div>
<div class="sect1">
<h2 id="_configuration">CONFIGURATION</h2>
<div class="sectionbody">
<div class="paragraph"><p>Everything below this line in this section is selectively included
from the <a href="git-config.html">git-config(1)</a> documentation. The content is the same
as what&#8217;s found there:</p></div>
<div class="dlist"><dl>
<dt class="hdlist1">
init.templateDir
</dt>
<dd>
<p>
Specify the directory from which templates will be copied.
(See the "TEMPLATE DIRECTORY" section of <a href="git-init.html">git-init(1)</a>.)
</p>
</dd>
<dt class="hdlist1">
init.defaultBranch
</dt>
<dd>
<p>
Allows overriding the default branch name e.g. when initializing
a new repository.
</p>
</dd>
<dt class="hdlist1">
clone.defaultRemoteName
</dt>
<dd>
<p>
The name of the remote to create when cloning a repository. Defaults to
<code>origin</code>, and can be overridden by passing the <code>--origin</code> command-line
option to <a href="git-clone.html">git-clone(1)</a>.
</p>
</dd>
<dt class="hdlist1">
clone.rejectShallow
</dt>
<dd>
<p>
Reject to clone a repository if it is a shallow one, can be overridden by
passing option <code>--reject-shallow</code> in command line. See <a href="git-clone.html">git-clone(1)</a>
</p>
</dd>
<dt class="hdlist1">
clone.filterSubmodules
</dt>
<dd>
<p>
If a partial clone filter is provided (see <code>--filter</code> in
<a href="git-rev-list.html">git-rev-list(1)</a>) and <code>--recurse-submodules</code> is used, also apply
the filter to submodules.
</p>
</dd>
</dl></div>
</div>
</div>
<div class="sect1">
<h2 id="_git">GIT</h2>
<div class="sectionbody">
<div class="paragraph"><p>Part of the <a href="git.html">git(1)</a> suite</p></div>
@ -1430,7 +1509,7 @@ Create a bare repository to publish your changes to the public:
<div id="footer">
<div id="footer-text">
Last updated
2021-11-15 09:20:10 PST
2022-10-08 14:40:28 PDT
</div>
</div>
</body>

@ -863,6 +863,148 @@ v2.4.8 v2.4.9</code></pre>
</div>
</div>
<div class="sect1">
<h2 id="_configuration">CONFIGURATION</h2>
<div class="sectionbody">
<div class="paragraph"><p>Everything below this line in this section is selectively included
from the <a href="git-config.html">git-config(1)</a> documentation. The content is the same
as what&#8217;s found there:</p></div>
<div class="dlist"><dl>
<dt class="hdlist1">
column.ui
</dt>
<dd>
<p>
Specify whether supported commands should output in columns.
This variable consists of a list of tokens separated by spaces
or commas:
</p>
<div class="paragraph"><p>These options control when the feature should be enabled
(defaults to <em>never</em>):</p></div>
<div class="openblock">
<div class="content">
<div class="dlist"><dl>
<dt class="hdlist1">
<code>always</code>
</dt>
<dd>
<p>
always show in columns
</p>
</dd>
<dt class="hdlist1">
<code>never</code>
</dt>
<dd>
<p>
never show in columns
</p>
</dd>
<dt class="hdlist1">
<code>auto</code>
</dt>
<dd>
<p>
show in columns if the output is to the terminal
</p>
</dd>
</dl></div>
</div></div>
<div class="paragraph"><p>These options control layout (defaults to <em>column</em>). Setting any
of these implies <em>always</em> if none of <em>always</em>, <em>never</em>, or <em>auto</em> are
specified.</p></div>
<div class="openblock">
<div class="content">
<div class="dlist"><dl>
<dt class="hdlist1">
<code>column</code>
</dt>
<dd>
<p>
fill columns before rows
</p>
</dd>
<dt class="hdlist1">
<code>row</code>
</dt>
<dd>
<p>
fill rows before columns
</p>
</dd>
<dt class="hdlist1">
<code>plain</code>
</dt>
<dd>
<p>
show in one column
</p>
</dd>
</dl></div>
</div></div>
<div class="paragraph"><p>Finally, these options can be combined with a layout option (defaults
to <em>nodense</em>):</p></div>
<div class="openblock">
<div class="content">
<div class="dlist"><dl>
<dt class="hdlist1">
<code>dense</code>
</dt>
<dd>
<p>
make unequal size columns to utilize more space
</p>
</dd>
<dt class="hdlist1">
<code>nodense</code>
</dt>
<dd>
<p>
make equal size columns
</p>
</dd>
</dl></div>
</div></div>
</dd>
<dt class="hdlist1">
column.branch
</dt>
<dd>
<p>
Specify whether to output branch listing in <code>git branch</code> in columns.
See <code>column.ui</code> for details.
</p>
</dd>
<dt class="hdlist1">
column.clean
</dt>
<dd>
<p>
Specify the layout when list items in <code>git clean -i</code>, which always
shows files and directories in columns. See <code>column.ui</code> for details.
</p>
</dd>
<dt class="hdlist1">
column.status
</dt>
<dd>
<p>
Specify whether to output untracked files in <code>git status</code> in columns.
See <code>column.ui</code> for details.
</p>
</dd>
<dt class="hdlist1">
column.tag
</dt>
<dd>
<p>
Specify whether to output tag listing in <code>git tag</code> in columns.
See <code>column.ui</code> for details.
</p>
</dd>
</dl></div>
</div>
</div>
<div class="sect1">
<h2 id="_git">GIT</h2>
<div class="sectionbody">
<div class="paragraph"><p>Part of the <a href="git.html">git(1)</a> suite</p></div>
@ -873,7 +1015,7 @@ v2.4.8 v2.4.9</code></pre>
<div id="footer">
<div id="footer-text">
Last updated
2021-10-06 09:57:11 PDT
2022-10-08 14:40:28 PDT
</div>
</div>
</body>

@ -930,6 +930,52 @@ Write a commit-graph file containing all commits in the current
</div>
</div>
<div class="sect1">
<h2 id="_configuration">CONFIGURATION</h2>
<div class="sectionbody">
<div class="paragraph"><p>Everything below this line in this section is selectively included
from the <a href="git-config.html">git-config(1)</a> documentation. The content is the same
as what&#8217;s found there:</p></div>
<div class="dlist"><dl>
<dt class="hdlist1">
commitGraph.generationVersion
</dt>
<dd>
<p>
Specifies the type of generation number version to use when writing
or reading the commit-graph file. If version 1 is specified, then
the corrected commit dates will not be written or read. Defaults to
2.
</p>
</dd>
<dt class="hdlist1">
commitGraph.maxNewFilters
</dt>
<dd>
<p>
Specifies the default value for the <code>--max-new-filters</code> option of <code>git
commit-graph write</code> (c.f., <a href="git-commit-graph.html">git-commit-graph(1)</a>).
</p>
</dd>
<dt class="hdlist1">
commitGraph.readChangedPaths
</dt>
<dd>
<p>
If true, then git will use the changed-path Bloom filters in the
commit-graph file (if it exists, and they are present). Defaults to
true. See <a href="git-commit-graph.html">git-commit-graph(1)</a> for more information.
</p>
</dd>
</dl></div>
</div>
</div>
<div class="sect1">
<h2 id="_file_format">FILE FORMAT</h2>
<div class="sectionbody">
<div class="paragraph"><p>see <a href="gitformat-commit-graph.html">gitformat-commit-graph(5)</a>.</p></div>
</div>
</div>
<div class="sect1">
<h2 id="_git">GIT</h2>
<div class="sectionbody">
<div class="paragraph"><p>Part of the <a href="git.html">git(1)</a> suite</p></div>
@ -940,7 +986,7 @@ Write a commit-graph file containing all commits in the current
<div id="footer">
<div id="footer-text">
Last updated
2021-10-06 09:57:11 PDT
2022-10-08 14:40:28 PDT
</div>
</div>
</body>

@ -877,9 +877,9 @@ Git internal format
</dt>
<dd>
<p>
It is <code>&lt;unix timestamp&gt; &lt;time zone offset&gt;</code>, where <code>&lt;unix
timestamp&gt;</code> is the number of seconds since the UNIX epoch.
<code>&lt;time zone offset&gt;</code> is a positive or negative offset from UTC.
It is <code>&lt;unix-timestamp&gt; &lt;time-zone-offset&gt;</code>, where
<code>&lt;unix-timestamp&gt;</code> is the number of seconds since the UNIX epoch.
<code>&lt;time-zone-offset&gt;</code> is a positive or negative offset from UTC.
For example CET (which is 1 hour ahead of UTC) is <code>+0100</code>.
</p>
</dd>
@ -1029,7 +1029,7 @@ reversible operation.</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2021-09-30 23:04:56 PDT
2022-06-28 20:23:28 PDT
</div>
</div>
</body>

@ -1586,9 +1586,9 @@ Git internal format
</dt>
<dd>
<p>
It is <code>&lt;unix timestamp&gt; &lt;time zone offset&gt;</code>, where <code>&lt;unix
timestamp&gt;</code> is the number of seconds since the UNIX epoch.
<code>&lt;time zone offset&gt;</code> is a positive or negative offset from UTC.
It is <code>&lt;unix-timestamp&gt; &lt;time-zone-offset&gt;</code>, where
<code>&lt;unix-timestamp&gt;</code> is the number of seconds since the UNIX epoch.
<code>&lt;time-zone-offset&gt;</code> is a positive or negative offset from UTC.
For example CET (which is 1 hour ahead of UTC) is <code>+0100</code>.
</p>
</dd>
@ -1731,6 +1731,65 @@ reversible operation.</p></div>
<code>GIT_EDITOR</code> environment variable, the core.editor configuration variable, the
<code>VISUAL</code> environment variable, or the <code>EDITOR</code> environment variable (in that
order). See <a href="git-var.html">git-var(1)</a> for details.</p></div>
<div class="paragraph"><p>Everything above this line in this section isn&#8217;t included from the
<a href="git-config.html">git-config(1)</a> documentation. The content that follows is the
same as what&#8217;s found there:</p></div>
<div class="dlist"><dl>
<dt class="hdlist1">
commit.cleanup
</dt>
<dd>
<p>
This setting overrides the default of the <code>--cleanup</code> option in
<code>git commit</code>. See <a href="git-commit.html">git-commit(1)</a> for details. Changing the
default can be useful when you always want to keep lines that begin
with comment character <code>#</code> in your log message, in which case you
would do <code>git config commit.cleanup whitespace</code> (note that you will
have to remove the help lines that begin with <code>#</code> in the commit log
template yourself, if you do this).
</p>
</dd>
<dt class="hdlist1">
commit.gpgSign
</dt>
<dd>
<p>
A boolean to specify whether all commits should be GPG signed.
Use of this option when doing operations such as rebase can
result in a large number of commits being signed. It may be
convenient to use an agent to avoid typing your GPG passphrase
several times.
</p>
</dd>
<dt class="hdlist1">
commit.status
</dt>
<dd>
<p>
A boolean to enable/disable inclusion of status information in the
commit message template when using an editor to prepare the commit
message. Defaults to true.
</p>
</dd>
<dt class="hdlist1">
commit.template
</dt>
<dd>
<p>
Specify the pathname of a file to use as the template for
new commit messages.
</p>
</dd>
<dt class="hdlist1">
commit.verbose
</dt>
<dd>
<p>
A boolean or int to specify the level of verbose with <code>git commit</code>.
See <a href="git-commit.html">git-commit(1)</a>.
</p>
</dd>
</dl></div>
</div>
</div>
<div class="sect1">
@ -1781,7 +1840,7 @@ information.</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2021-11-15 14:22:31 PST
2022-10-08 14:40:28 PDT
</div>
</div>
</body>

File diff suppressed because it is too large Load Diff

@ -815,7 +815,7 @@ Print sizes in human readable format
<div id="footer">
<div id="footer-text">
Last updated
2018-06-15 19:48:09 PDT
2022-01-27 18:10:56 PST
</div>
</div>
</body>

@ -5,7 +5,7 @@
<head>
<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=UTF-8" />
<meta name="generator" content="AsciiDoc 9.1.0" />
<title>git-credential-cache&#8212;daemon(1)</title>
<title>git-credential-cache&#45;&#45;daemon(1)</title>
<style type="text/css">
/* Shared CSS for AsciiDoc xhtml11 and html5 backends */
@ -735,7 +735,7 @@ asciidoc.install();
<body class="manpage">
<div id="header">
<h1>
git-credential-cache&#8212;daemon(1) Manual Page
git-credential-cache&#45;&#45;daemon(1) Manual Page
</h1>
<h2>NAME</h2>
<div class="sectionbody">
@ -749,7 +749,7 @@ git-credential-cache&#8212;daemon(1) Manual Page
<h2 id="_synopsis">SYNOPSIS</h2>
<div class="sectionbody">
<div class="verseblock">
<pre class="content">git credential-cache&#8212;daemon [--debug] &lt;socket&gt;</pre>
<pre class="content"><em>git credential-cache&#45;&#45;daemon</em> [--debug] &lt;socket&gt;</pre>
<div class="attribution">
</div></div>
</div>
@ -786,7 +786,7 @@ begun listening for clients.</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2018-06-15 19:43:37 PDT
2022-08-31 14:31:31 PDT
</div>
</div>
</body>

@ -842,7 +842,7 @@ variable (this example drops the cache time to 5 minutes):</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2021-09-30 23:04:56 PDT
2022-06-28 20:23:28 PDT
</div>
</div>
</body>

@ -882,7 +882,7 @@ for more information.</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2021-09-30 23:04:56 PDT
2022-06-28 20:23:28 PDT
</div>
</div>
</body>

@ -750,7 +750,7 @@ git-credential(1) Manual Page
<div class="sectionbody">
<div class="listingblock">
<div class="content">
<pre><code>git credential &lt;fill|approve|reject&gt;</code></pre>
<pre><code>'git credential' (fill|approve|reject)</code></pre>
</div></div>
</div>
</div>
@ -946,7 +946,7 @@ username in the example above) will be left unset.</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2021-11-15 09:20:10 PST
2022-06-28 20:23:28 PDT
</div>
</div>
</body>

@ -749,8 +749,8 @@ git-cvsexportcommit(1) Manual Page
<h2 id="_synopsis">SYNOPSIS</h2>
<div class="sectionbody">
<div class="verseblock">
<pre class="content"><em>git cvsexportcommit</em> [-h] [-u] [-v] [-c] [-P] [-p] [-a] [-d cvsroot]
[-w cvsworkdir] [-W] [-f] [-m msgprefix] [PARENTCOMMIT] COMMITID</pre>
<pre class="content"><em>git cvsexportcommit</em> [-h] [-u] [-v] [-c] [-P] [-p] [-a] [-d &lt;cvsroot&gt;]
[-w &lt;cvs-workdir&gt;] [-W] [-f] [-m &lt;msgprefix&gt;] [&lt;parent-commit&gt;] &lt;commit-id&gt;</pre>
<div class="attribution">
</div></div>
</div>
@ -951,7 +951,7 @@ $ git cherry cvshead myhead | sed -n 's/^+ //p' | xargs -l1 git cvsexportcommit
<div id="footer">
<div id="footer-text">
Last updated
2021-11-15 09:20:10 PST
2022-06-28 20:23:28 PDT
</div>
</div>
</body>

@ -751,9 +751,9 @@ git-cvsimport(1) Manual Page
<div class="verseblock">
<pre class="content"><em>git cvsimport</em> [-o &lt;branch-for-HEAD&gt;] [-h] [-v] [-d &lt;CVSROOT&gt;]
[-A &lt;author-conv-file&gt;] [-p &lt;options-for-cvsps&gt;] [-P &lt;file&gt;]
[-C &lt;git_repository&gt;] [-z &lt;fuzz&gt;] [-i] [-k] [-u] [-s &lt;subst&gt;]
[-a] [-m] [-M &lt;regex&gt;] [-S &lt;regex&gt;] [-L &lt;commitlimit&gt;]
[-r &lt;remote&gt;] [-R] [&lt;CVS_module&gt;]</pre>
[-C &lt;git-repository&gt;] [-z &lt;fuzz&gt;] [-i] [-k] [-u] [-s &lt;subst&gt;]
[-a] [-m] [-M &lt;regex&gt;] [-S &lt;regex&gt;] [-L &lt;commit-limit&gt;]
[-r &lt;remote&gt;] [-R] [&lt;CVS-module&gt;]</pre>
<div class="attribution">
</div></div>
</div>
@ -810,7 +810,7 @@ See <a href="gitcvs-migration.html">gitcvs-migration(7)</a>.</p></div>
</p>
</dd>
<dt class="hdlist1">
&lt;CVS_module&gt;
&lt;CVS-module&gt;
</dt>
<dd>
<p>
@ -1107,7 +1107,7 @@ cvs2git (part of cvs2svn), <code>http://subversion.apache.org/</code>
<div id="footer">
<div id="footer-text">
Last updated
2021-11-15 09:20:10 PST
2022-06-28 20:23:28 PDT
</div>
</div>
</body>

@ -839,10 +839,10 @@ Print usage information and exit
</dt>
<dd>
<p>
You can specify a list of allowed directories. If no directories
are given, all are allowed. This is an additional restriction, gitcvs
access still needs to be enabled by the <code>gitcvs.enabled</code> config option
unless <code>--export-all</code> was given, too.
The remaining arguments provide a list of directories. If no directories
are given, then all are allowed. Repositories within these directories
still require the <code>gitcvs.enabled</code> config option, unless <code>--export-all</code>
is specified.
</p>
</dd>
</dl></div>
@ -1155,10 +1155,26 @@ gitcvs.dbTableNamePrefix
<div class="sectionbody">
<div class="paragraph"><p>These variables obviate the need for command-line options in some
circumstances, allowing easier restricted usage through git-shell.</p></div>
<div class="paragraph"><p>GIT_CVSSERVER_BASE_PATH takes the place of the argument to --base-path.</p></div>
<div class="paragraph"><p>GIT_CVSSERVER_ROOT specifies a single-directory whitelist. The
repository must still be configured to allow access through
git-cvsserver, as described above.</p></div>
<div class="dlist"><dl>
<dt class="hdlist1">
GIT_CVSSERVER_BASE_PATH
</dt>
<dd>
<p>
This variable replaces the argument to --base-path.
</p>
</dd>
<dt class="hdlist1">
GIT_CVSSERVER_ROOT
</dt>
<dd>
<p>
This variable specifies a single directory, replacing the
<code>&lt;directory&gt;...</code> argument list. The repository still requires the
<code>gitcvs.enabled</code> config option, unless <code>--export-all</code> is specified.
</p>
</dd>
</dl></div>
<div class="paragraph"><p>When these environment variables are set, the corresponding
command-line arguments may not be used.</p></div>
</div>
@ -1311,7 +1327,7 @@ and <code>gitcvs.allBinary</code> to "guess".</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2021-11-15 13:27:01 PST
2022-09-16 17:50:33 PDT
</div>
</div>
</body>

@ -776,8 +776,8 @@ that service if it is enabled.</p></div>
<div class="paragraph"><p>It verifies that the directory has the magic file "git-daemon-export-ok", and
it will refuse to export any Git directory that hasn&#8217;t explicitly been marked
for export this way (unless the <code>--export-all</code> parameter is specified). If you
pass some directory paths as <em>git daemon</em> arguments, you can further restrict
the offers to a whitelist comprising of those.</p></div>
pass some directory paths as <em>git daemon</em> arguments, the offers are limited to
repositories within those directories.</p></div>
<div class="paragraph"><p>By default, only <code>upload-pack</code> service is enabled, which serves
<em>git fetch-pack</em> and <em>git ls-remote</em> clients, which are invoked
from <em>git fetch</em>, <em>git pull</em>, and <em>git clone</em>.</p></div>
@ -798,7 +798,7 @@ Git repositories.</p></div>
Match paths exactly (i.e. don&#8217;t allow "/foo/repo" when the real path is
"/foo/repo.git" or "/foo/repo/.git") and don&#8217;t do user-relative paths.
<em>git daemon</em> will refuse to start when this option is enabled and no
whitelist is specified.
directory arguments are provided.
</p>
</dd>
<dt class="hdlist1">
@ -836,7 +836,7 @@ Git repositories.</p></div>
%IP for the server&#8217;s IP address, %P for the port number,
and %D for the absolute path of the named repository.
After interpolation, the path is validated against the directory
whitelist.
list.
</p>
</dd>
<dt class="hdlist1">
@ -1105,9 +1105,11 @@ it declines the service.</p></div>
</dt>
<dd>
<p>
A directory to add to the whitelist of allowed directories. Unless
--strict-paths is specified this will also include subdirectories
of each named directory.
The remaining arguments provide a list of directories. If any
directories are specified, then the <code>git-daemon</code> process will
serve a requested directory only if it is contained in one of
these directories. If <code>--strict-paths</code> is specified, then the
requested directory must match one of these directories exactly.
</p>
</dd>
</dl></div>
@ -1182,9 +1184,8 @@ git 9418/tcp # Git Version Control System</code></pre
<dd>
<p>
To set up <em>git daemon</em> as an inetd service that handles any
repository under the whitelisted set of directories, /pub/foo
and /pub/bar, place an entry like the following into
/etc/inetd all on one line:
repository within <code>/pub/foo</code> or <code>/pub/bar</code>, place an entry like
the following into <code>/etc/inetd</code> all on one line:
</p>
<div class="listingblock">
<div class="content">
@ -1280,7 +1281,7 @@ services are performed.</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2021-09-30 23:04:56 PDT
2022-09-16 17:50:33 PDT
</div>
</div>
</body>

@ -1042,7 +1042,7 @@ tag being favorable.</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2021-10-06 09:57:11 PDT
2022-06-28 20:23:28 PDT
</div>
</div>
</body>

@ -0,0 +1,865 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=UTF-8" />
<meta name="generator" content="AsciiDoc 9.1.0" />
<title>git-diagnose(1)</title>
<style type="text/css">
/* Shared CSS for AsciiDoc xhtml11 and html5 backends */
/* Default font. */
body {
font-family: Georgia,serif;
}
/* Title font. */
h1, h2, h3, h4, h5, h6,
div.title, caption.title,
thead, p.table.header,
#toctitle,
#author, #revnumber, #revdate, #revremark,
#footer {
font-family: Arial,Helvetica,sans-serif;
}
body {
margin: 1em 5% 1em 5%;
}
a {
color: blue;
text-decoration: underline;
}
a:visited {
color: fuchsia;
}
em {
font-style: italic;
color: navy;
}
strong {
font-weight: bold;
color: #083194;
}
h1, h2, h3, h4, h5, h6 {
color: #527bbd;
margin-top: 1.2em;
margin-bottom: 0.5em;
line-height: 1.3;
}
h1, h2, h3 {
border-bottom: 2px solid silver;
}
h2 {
padding-top: 0.5em;
}
h3 {
float: left;
}
h3 + * {
clear: left;
}
h5 {
font-size: 1.0em;
}
div.sectionbody {
margin-left: 0;
}
hr {
border: 1px solid silver;
}
p {
margin-top: 0.5em;
margin-bottom: 0.5em;
}
ul, ol, li > p {
margin-top: 0;
}
ul > li { color: #aaa; }
ul > li > * { color: black; }
.monospaced, code, pre {
font-family: "Courier New", Courier, monospace;
font-size: inherit;
color: navy;
padding: 0;
margin: 0;
}
pre {
white-space: pre-wrap;
}
#author {
color: #527bbd;
font-weight: bold;
font-size: 1.1em;
}
#email {
}
#revnumber, #revdate, #revremark {
}
#footer {
font-size: small;
border-top: 2px solid silver;
padding-top: 0.5em;
margin-top: 4.0em;
}
#footer-text {
float: left;
padding-bottom: 0.5em;
}
#footer-badges {
float: right;
padding-bottom: 0.5em;
}
#preamble {
margin-top: 1.5em;
margin-bottom: 1.5em;
}
div.imageblock, div.exampleblock, div.verseblock,
div.quoteblock, div.literalblock, div.listingblock, div.sidebarblock,
div.admonitionblock {
margin-top: 1.0em;
margin-bottom: 1.5em;
}
div.admonitionblock {
margin-top: 2.0em;
margin-bottom: 2.0em;
margin-right: 10%;
color: #606060;
}
div.content { /* Block element content. */
padding: 0;
}
/* Block element titles. */
div.title, caption.title {
color: #527bbd;
font-weight: bold;
text-align: left;
margin-top: 1.0em;
margin-bottom: 0.5em;
}
div.title + * {
margin-top: 0;
}
td div.title:first-child {
margin-top: 0.0em;
}
div.content div.title:first-child {
margin-top: 0.0em;
}
div.content + div.title {
margin-top: 0.0em;
}
div.sidebarblock > div.content {
background: #ffffee;
border: 1px solid #dddddd;
border-left: 4px solid #f0f0f0;
padding: 0.5em;
}
div.listingblock > div.content {
border: 1px solid #dddddd;
border-left: 5px solid #f0f0f0;
background: #f8f8f8;
padding: 0.5em;
}
div.quoteblock, div.verseblock {
padding-left: 1.0em;
margin-left: 1.0em;
margin-right: 10%;
border-left: 5px solid #f0f0f0;
color: #888;
}
div.quoteblock > div.attribution {
padding-top: 0.5em;
text-align: right;
}
div.verseblock > pre.content {
font-family: inherit;
font-size: inherit;
}
div.verseblock > div.attribution {
padding-top: 0.75em;
text-align: left;
}
/* DEPRECATED: Pre version 8.2.7 verse style literal block. */
div.verseblock + div.attribution {
text-align: left;
}
div.admonitionblock .icon {
vertical-align: top;
font-size: 1.1em;
font-weight: bold;
text-decoration: underline;
color: #527bbd;
padding-right: 0.5em;
}
div.admonitionblock td.content {
padding-left: 0.5em;
border-left: 3px solid #dddddd;
}
div.exampleblock > div.content {
border-left: 3px solid #dddddd;
padding-left: 0.5em;
}
div.imageblock div.content { padding-left: 0; }
span.image img { border-style: none; vertical-align: text-bottom; }
a.image:visited { color: white; }
dl {
margin-top: 0.8em;
margin-bottom: 0.8em;
}
dt {
margin-top: 0.5em;
margin-bottom: 0;
font-style: normal;
color: navy;
}
dd > *:first-child {
margin-top: 0.1em;
}
ul, ol {
list-style-position: outside;
}
ol.arabic {
list-style-type: decimal;
}
ol.loweralpha {
list-style-type: lower-alpha;
}
ol.upperalpha {
list-style-type: upper-alpha;
}
ol.lowerroman {
list-style-type: lower-roman;
}
ol.upperroman {
list-style-type: upper-roman;
}
div.compact ul, div.compact ol,
div.compact p, div.compact p,
div.compact div, div.compact div {
margin-top: 0.1em;
margin-bottom: 0.1em;
}
tfoot {
font-weight: bold;
}
td > div.verse {
white-space: pre;
}
div.hdlist {
margin-top: 0.8em;
margin-bottom: 0.8em;
}
div.hdlist tr {
padding-bottom: 15px;
}
dt.hdlist1.strong, td.hdlist1.strong {
font-weight: bold;
}
td.hdlist1 {
vertical-align: top;
font-style: normal;
padding-right: 0.8em;
color: navy;
}
td.hdlist2 {
vertical-align: top;
}
div.hdlist.compact tr {
margin: 0;
padding-bottom: 0;
}
.comment {
background: yellow;
}
.footnote, .footnoteref {
font-size: 0.8em;
}
span.footnote, span.footnoteref {
vertical-align: super;
}
#footnotes {
margin: 20px 0 20px 0;
padding: 7px 0 0 0;
}
#footnotes div.footnote {
margin: 0 0 5px 0;
}
#footnotes hr {
border: none;
border-top: 1px solid silver;
height: 1px;
text-align: left;
margin-left: 0;
width: 20%;
min-width: 100px;
}
div.colist td {
padding-right: 0.5em;
padding-bottom: 0.3em;
vertical-align: top;
}
div.colist td img {
margin-top: 0.3em;
}
@media print {
#footer-badges { display: none; }
}
#toc {
margin-bottom: 2.5em;
}
#toctitle {
color: #527bbd;
font-size: 1.1em;
font-weight: bold;
margin-top: 1.0em;
margin-bottom: 0.1em;
}
div.toclevel0, div.toclevel1, div.toclevel2, div.toclevel3, div.toclevel4 {
margin-top: 0;
margin-bottom: 0;
}
div.toclevel2 {
margin-left: 2em;
font-size: 0.9em;
}
div.toclevel3 {
margin-left: 4em;
font-size: 0.9em;
}
div.toclevel4 {
margin-left: 6em;
font-size: 0.9em;
}
span.aqua { color: aqua; }
span.black { color: black; }
span.blue { color: blue; }
span.fuchsia { color: fuchsia; }
span.gray { color: gray; }
span.green { color: green; }
span.lime { color: lime; }
span.maroon { color: maroon; }
span.navy { color: navy; }
span.olive { color: olive; }
span.purple { color: purple; }
span.red { color: red; }
span.silver { color: silver; }
span.teal { color: teal; }
span.white { color: white; }
span.yellow { color: yellow; }
span.aqua-background { background: aqua; }
span.black-background { background: black; }
span.blue-background { background: blue; }
span.fuchsia-background { background: fuchsia; }
span.gray-background { background: gray; }
span.green-background { background: green; }
span.lime-background { background: lime; }
span.maroon-background { background: maroon; }
span.navy-background { background: navy; }
span.olive-background { background: olive; }
span.purple-background { background: purple; }
span.red-background { background: red; }
span.silver-background { background: silver; }
span.teal-background { background: teal; }
span.white-background { background: white; }
span.yellow-background { background: yellow; }
span.big { font-size: 2em; }
span.small { font-size: 0.6em; }
span.underline { text-decoration: underline; }
span.overline { text-decoration: overline; }
span.line-through { text-decoration: line-through; }
div.unbreakable { page-break-inside: avoid; }
/*
* xhtml11 specific
*
* */
div.tableblock {
margin-top: 1.0em;
margin-bottom: 1.5em;
}
div.tableblock > table {
border: 3px solid #527bbd;
}
thead, p.table.header {
font-weight: bold;
color: #527bbd;
}
p.table {
margin-top: 0;
}
/* Because the table frame attribute is overridden by CSS in most browsers. */
div.tableblock > table[frame="void"] {
border-style: none;
}
div.tableblock > table[frame="hsides"] {
border-left-style: none;
border-right-style: none;
}
div.tableblock > table[frame="vsides"] {
border-top-style: none;
border-bottom-style: none;
}
/*
* html5 specific
*
* */
table.tableblock {
margin-top: 1.0em;
margin-bottom: 1.5em;
}
thead, p.tableblock.header {
font-weight: bold;
color: #527bbd;
}
p.tableblock {
margin-top: 0;
}
table.tableblock {
border-width: 3px;
border-spacing: 0px;
border-style: solid;
border-color: #527bbd;
border-collapse: collapse;
}
th.tableblock, td.tableblock {
border-width: 1px;
padding: 4px;
border-style: solid;
border-color: #527bbd;
}
table.tableblock.frame-topbot {
border-left-style: hidden;
border-right-style: hidden;
}
table.tableblock.frame-sides {
border-top-style: hidden;
border-bottom-style: hidden;
}
table.tableblock.frame-none {
border-style: hidden;
}
th.tableblock.halign-left, td.tableblock.halign-left {
text-align: left;
}
th.tableblock.halign-center, td.tableblock.halign-center {
text-align: center;
}
th.tableblock.halign-right, td.tableblock.halign-right {
text-align: right;
}
th.tableblock.valign-top, td.tableblock.valign-top {
vertical-align: top;
}
th.tableblock.valign-middle, td.tableblock.valign-middle {
vertical-align: middle;
}
th.tableblock.valign-bottom, td.tableblock.valign-bottom {
vertical-align: bottom;
}
/*
* manpage specific
*
* */
body.manpage h1 {
padding-top: 0.5em;
padding-bottom: 0.5em;
border-top: 2px solid silver;
border-bottom: 2px solid silver;
}
body.manpage h2 {
border-style: none;
}
body.manpage div.sectionbody {
margin-left: 3em;
}
@media print {
body.manpage div#toc { display: none; }
}
</style>
<script type="text/javascript">
/*<![CDATA[*/
var asciidoc = { // Namespace.
/////////////////////////////////////////////////////////////////////
// Table Of Contents generator
/////////////////////////////////////////////////////////////////////
/* Author: Mihai Bazon, September 2002
* http://students.infoiasi.ro/~mishoo
*
* Table Of Content generator
* Version: 0.4
*
* Feel free to use this script under the terms of the GNU General Public
* License, as long as you do not remove or alter this notice.
*/
/* modified by Troy D. Hanson, September 2006. License: GPL */
/* modified by Stuart Rackham, 2006, 2009. License: GPL */
// toclevels = 1..4.
toc: function (toclevels) {
function getText(el) {
var text = "";
for (var i = el.firstChild; i != null; i = i.nextSibling) {
if (i.nodeType == 3 /* Node.TEXT_NODE */) // IE doesn't speak constants.
text += i.data;
else if (i.firstChild != null)
text += getText(i);
}
return text;
}
function TocEntry(el, text, toclevel) {
this.element = el;
this.text = text;
this.toclevel = toclevel;
}
function tocEntries(el, toclevels) {
var result = new Array;
var re = new RegExp('[hH]([1-'+(toclevels+1)+'])');
// Function that scans the DOM tree for header elements (the DOM2
// nodeIterator API would be a better technique but not supported by all
// browsers).
var iterate = function (el) {
for (var i = el.firstChild; i != null; i = i.nextSibling) {
if (i.nodeType == 1 /* Node.ELEMENT_NODE */) {
var mo = re.exec(i.tagName);
if (mo && (i.getAttribute("class") || i.getAttribute("className")) != "float") {
result[result.length] = new TocEntry(i, getText(i), mo[1]-1);
}
iterate(i);
}
}
}
iterate(el);
return result;
}
var toc = document.getElementById("toc");
if (!toc) {
return;
}
// Delete existing TOC entries in case we're reloading the TOC.
var tocEntriesToRemove = [];
var i;
for (i = 0; i < toc.childNodes.length; i++) {
var entry = toc.childNodes[i];
if (entry.nodeName.toLowerCase() == 'div'
&& entry.getAttribute("class")
&& entry.getAttribute("class").match(/^toclevel/))
tocEntriesToRemove.push(entry);
}
for (i = 0; i < tocEntriesToRemove.length; i++) {
toc.removeChild(tocEntriesToRemove[i]);
}
// Rebuild TOC entries.
var entries = tocEntries(document.getElementById("content"), toclevels);
for (var i = 0; i < entries.length; ++i) {
var entry = entries[i];
if (entry.element.id == "")
entry.element.id = "_toc_" + i;
var a = document.createElement("a");
a.href = "#" + entry.element.id;
a.appendChild(document.createTextNode(entry.text));
var div = document.createElement("div");
div.appendChild(a);
div.className = "toclevel" + entry.toclevel;
toc.appendChild(div);
}
if (entries.length == 0)
toc.parentNode.removeChild(toc);
},
/////////////////////////////////////////////////////////////////////
// Footnotes generator
/////////////////////////////////////////////////////////////////////
/* Based on footnote generation code from:
* http://www.brandspankingnew.net/archive/2005/07/format_footnote.html
*/
footnotes: function () {
// Delete existing footnote entries in case we're reloading the footnodes.
var i;
var noteholder = document.getElementById("footnotes");
if (!noteholder) {
return;
}
var entriesToRemove = [];
for (i = 0; i < noteholder.childNodes.length; i++) {
var entry = noteholder.childNodes[i];
if (entry.nodeName.toLowerCase() == 'div' && entry.getAttribute("class") == "footnote")
entriesToRemove.push(entry);
}
for (i = 0; i < entriesToRemove.length; i++) {
noteholder.removeChild(entriesToRemove[i]);
}
// Rebuild footnote entries.
var cont = document.getElementById("content");
var spans = cont.getElementsByTagName("span");
var refs = {};
var n = 0;
for (i=0; i<spans.length; i++) {
if (spans[i].className == "footnote") {
n++;
var note = spans[i].getAttribute("data-note");
if (!note) {
// Use [\s\S] in place of . so multi-line matches work.
// Because JavaScript has no s (dotall) regex flag.
note = spans[i].innerHTML.match(/\s*\[([\s\S]*)]\s*/)[1];
spans[i].innerHTML =
"[<a id='_footnoteref_" + n + "' href='#_footnote_" + n +
"' title='View footnote' class='footnote'>" + n + "</a>]";
spans[i].setAttribute("data-note", note);
}
noteholder.innerHTML +=
"<div class='footnote' id='_footnote_" + n + "'>" +
"<a href='#_footnoteref_" + n + "' title='Return to text'>" +
n + "</a>. " + note + "</div>";
var id =spans[i].getAttribute("id");
if (id != null) refs["#"+id] = n;
}
}
if (n == 0)
noteholder.parentNode.removeChild(noteholder);
else {
// Process footnoterefs.
for (i=0; i<spans.length; i++) {
if (spans[i].className == "footnoteref") {
var href = spans[i].getElementsByTagName("a")[0].getAttribute("href");
href = href.match(/#.*/)[0]; // Because IE return full URL.
n = refs[href];
spans[i].innerHTML =
"[<a href='#_footnote_" + n +
"' title='View footnote' class='footnote'>" + n + "</a>]";
}
}
}
},
install: function(toclevels) {
var timerId;
function reinstall() {
asciidoc.footnotes();
if (toclevels) {
asciidoc.toc(toclevels);
}
}
function reinstallAndRemoveTimer() {
clearInterval(timerId);
reinstall();
}
timerId = setInterval(reinstall, 500);
if (document.addEventListener)
document.addEventListener("DOMContentLoaded", reinstallAndRemoveTimer, false);
else
window.onload = reinstallAndRemoveTimer;
}
}
asciidoc.install();
/*]]>*/
</script>
</head>
<body class="manpage">
<div id="header">
<h1>
git-diagnose(1) Manual Page
</h1>
<h2>NAME</h2>
<div class="sectionbody">
<p>git-diagnose -
Generate a zip archive of diagnostic information
</p>
</div>
</div>
<div id="content">
<div class="sect1">
<h2 id="_synopsis">SYNOPSIS</h2>
<div class="sectionbody">
<div class="verseblock">
<pre class="content"><em>git diagnose</em> [(-o | --output-directory) &lt;path&gt;] [(-s | --suffix) &lt;format&gt;]
[--mode=&lt;mode&gt;]</pre>
<div class="attribution">
</div></div>
</div>
</div>
<div class="sect1">
<h2 id="_description">DESCRIPTION</h2>
<div class="sectionbody">
<div class="paragraph"><p>Collects detailed information about the user&#8217;s machine, Git client, and
repository state and packages that information into a zip archive. The
generated archive can then, for example, be shared with the Git mailing list to
help debug an issue or serve as a reference for independent debugging.</p></div>
<div class="paragraph"><p>By default, the following information is captured in the archive:</p></div>
<div class="ulist"><ul>
<li>
<p>
<em>git version --build-options</em>
</p>
</li>
<li>
<p>
The path to the repository root
</p>
</li>
<li>
<p>
The available disk space on the filesystem
</p>
</li>
<li>
<p>
The name and size of each packfile, including those in alternate object
stores
</p>
</li>
<li>
<p>
The total count of loose objects, as well as counts broken down by
<code>.git/objects</code> subdirectory
</p>
</li>
</ul></div>
<div class="paragraph"><p>Additional information can be collected by selecting a different diagnostic mode
using the <code>--mode</code> option.</p></div>
<div class="paragraph"><p>This tool differs from <a href="git-bugreport.html">git-bugreport(1)</a> in that it collects much more
detailed information with a greater focus on reporting the size and data shape
of repository contents.</p></div>
</div>
</div>
<div class="sect1">
<h2 id="_options">OPTIONS</h2>
<div class="sectionbody">
<div class="dlist"><dl>
<dt class="hdlist1">
-o &lt;path&gt;
</dt>
<dt class="hdlist1">
--output-directory &lt;path&gt;
</dt>
<dd>
<p>
Place the resulting diagnostics archive in <code>&lt;path&gt;</code> instead of the
current directory.
</p>
</dd>
<dt class="hdlist1">
-s &lt;format&gt;
</dt>
<dt class="hdlist1">
--suffix &lt;format&gt;
</dt>
<dd>
<p>
Specify an alternate suffix for the diagnostics archive name, to create
a file named <em>git-diagnostics-&lt;formatted suffix&gt;</em>. This should take the
form of a strftime(3) format string; the current local time will be
used.
</p>
</dd>
<dt class="hdlist1">
--mode=(stats|all)
</dt>
<dd>
<p>
Specify the type of diagnostics that should be collected. The default behavior
of <em>git diagnose</em> is equivalent to <code>--mode=stats</code>.
</p>
<div class="paragraph"><p>The <code>--mode=all</code> option collects everything included in <code>--mode=stats</code>, as well
as copies of <code>.git</code>, <code>.git/hooks</code>, <code>.git/info</code>, <code>.git/logs</code>, and
<code>.git/objects/info</code> directories. This additional information may be sensitive,
as it can be used to reconstruct the full contents of the diagnosed repository.
Users should exercise caution when sharing an archive generated with
<code>--mode=all</code>.</p></div>
</dd>
</dl></div>
</div>
</div>
<div class="sect1">
<h2 id="_git">GIT</h2>
<div class="sectionbody">
<div class="paragraph"><p>Part of the <a href="git.html">git(1)</a> suite</p></div>
</div>
</div>
</div>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
Last updated
2022-09-16 17:50:33 PDT
</div>
</div>
</body>
</html>

@ -749,7 +749,7 @@ git-diff-files(1) Manual Page
<h2 id="_synopsis">SYNOPSIS</h2>
<div class="sectionbody">
<div class="verseblock">
<pre class="content"><em>git diff-files</em> [-q] [-0|-1|-2|-3|-c|--cc] [&lt;common diff options&gt;] [&lt;path&gt;&#8230;]</pre>
<pre class="content"><em>git diff-files</em> [-q] [-0|-1|-2|-3|-c|--cc] [&lt;common-diff-options&gt;] [&lt;path&gt;&#8230;]</pre>
<div class="attribution">
</div></div>
</div>
@ -1652,11 +1652,8 @@ of a delete/create pair.</p></div>
</p>
<div class="paragraph"><p>Also, these upper-case letters can be downcased to exclude. E.g.
<code>--diff-filter=ad</code> excludes added and deleted paths.</p></div>
<div class="paragraph"><p>Note that not all diffs can feature all types. For instance, diffs
from the index to the working tree can never have Added entries
(because the set of paths included in the diff is limited by what is in
the index). Similarly, copied and renamed entries cannot appear if
detection for those types is disabled.</p></div>
<div class="paragraph"><p>Note that not all diffs can feature all types. For instance, copied and
renamed entries cannot appear if detection for those types is disabled.</p></div>
</dd>
<dt class="hdlist1">
-S&lt;string&gt;
@ -2183,7 +2180,7 @@ a space.
</li>
<li>
<p>
sha1 for "dst"; 0{40} if creation, unmerged or "look at work tree".
sha1 for "dst"; 0{40} if deletion, unmerged or "work tree out of sync with the index".
</p>
</li>
<li>
@ -2270,8 +2267,8 @@ X: "unknown" change type (most probably a bug, please report it)
percentage of similarity between the source and target of the move or
copy). Status letter M may be followed by a score (denoting the
percentage of dissimilarity) for file rewrites.</p></div>
<div class="paragraph"><p>&lt;sha1&gt; is shown as all 0&#8217;s if a file is new on the filesystem
and it is out of sync with the index.</p></div>
<div class="paragraph"><p>The sha1 for "dst" is shown as all 0&#8217;s if a file on the filesystem
is out of sync with the index.</p></div>
<div class="paragraph"><p>Example:</p></div>
<div class="listingblock">
<div class="content">
@ -2706,7 +2703,7 @@ the pathname, but if that is <code>NUL</code>, the record will show two paths.</
<div id="footer">
<div id="footer-text">
Last updated
2021-11-15 09:20:10 PST
2022-06-28 20:23:28 PDT
</div>
</div>
</body>

@ -749,7 +749,7 @@ git-diff-index(1) Manual Page
<h2 id="_synopsis">SYNOPSIS</h2>
<div class="sectionbody">
<div class="verseblock">
<pre class="content"><em>git diff-index</em> [-m] [--cached] [--merge-base] [&lt;common diff options&gt;] &lt;tree-ish&gt; [&lt;path&gt;&#8230;]</pre>
<pre class="content"><em>git diff-index</em> [-m] [--cached] [--merge-base] [&lt;common-diff-options&gt;] &lt;tree-ish&gt; [&lt;path&gt;&#8230;]</pre>
<div class="attribution">
</div></div>
</div>
@ -1653,11 +1653,8 @@ of a delete/create pair.</p></div>
</p>
<div class="paragraph"><p>Also, these upper-case letters can be downcased to exclude. E.g.
<code>--diff-filter=ad</code> excludes added and deleted paths.</p></div>
<div class="paragraph"><p>Note that not all diffs can feature all types. For instance, diffs
from the index to the working tree can never have Added entries
(because the set of paths included in the diff is limited by what is in
the index). Similarly, copied and renamed entries cannot appear if
detection for those types is disabled.</p></div>
<div class="paragraph"><p>Note that not all diffs can feature all types. For instance, copied and
renamed entries cannot appear if detection for those types is disabled.</p></div>
</dd>
<dt class="hdlist1">
-S&lt;string&gt;
@ -2177,7 +2174,7 @@ a space.
</li>
<li>
<p>
sha1 for "dst"; 0{40} if creation, unmerged or "look at work tree".
sha1 for "dst"; 0{40} if deletion, unmerged or "work tree out of sync with the index".
</p>
</li>
<li>
@ -2264,8 +2261,8 @@ X: "unknown" change type (most probably a bug, please report it)
percentage of similarity between the source and target of the move or
copy). Status letter M may be followed by a score (denoting the
percentage of dissimilarity) for file rewrites.</p></div>
<div class="paragraph"><p>&lt;sha1&gt; is shown as all 0&#8217;s if a file is new on the filesystem
and it is out of sync with the index.</p></div>
<div class="paragraph"><p>The sha1 for "dst" is shown as all 0&#8217;s if a file on the filesystem
is out of sync with the index.</p></div>
<div class="paragraph"><p>Example:</p></div>
<div class="listingblock">
<div class="content">
@ -2722,8 +2719,8 @@ matches my working directory. But doing a <em>git diff-index</em> does:</p></div
<div class="literalblock">
<div class="content">
<pre><code>torvalds@ppc970:~/git&gt; git diff-index --cached HEAD
-100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74 commit.c
+100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74 git-commit.c</code></pre>
:100644 000000 4161aecc6700a2eb579e842af0b7f22b98443f74 0000000000000000000000000000000000000000 D commit.c
:000000 100644 0000000000000000000000000000000000000000 4161aecc6700a2eb579e842af0b7f22b98443f74 A git-commit.c</code></pre>
</div></div>
<div class="paragraph"><p>You can see easily that the above is a rename.</p></div>
<div class="paragraph"><p>In fact, <code>git diff-index --cached</code> <strong>should</strong> always be entirely equivalent to
@ -2757,7 +2754,7 @@ have not actually done a <em>git update-index</em> on it yet - there is no
<div class="literalblock">
<div class="content">
<pre><code>torvalds@ppc970:~/v2.6/linux&gt; git diff-index --abbrev HEAD
:100644 100664 7476bb... 000000... kernel/sched.c</code></pre>
:100644 100644 7476bb5ba 000000000 M kernel/sched.c</code></pre>
</div></div>
<div class="paragraph"><p>i.e., it shows that the tree has changed, and that <code>kernel/sched.c</code> is
not up to date and may contain new stuff. The all-zero sha1 means that to
@ -2800,7 +2797,7 @@ always have the special all-zero sha1.</td>
<div id="footer">
<div id="footer-text">
Last updated
2021-11-15 09:20:10 PST
2022-09-16 17:50:33 PDT
</div>
</div>
</body>

@ -751,7 +751,7 @@ git-diff-tree(1) Manual Page
<div class="verseblock">
<pre class="content"><em>git diff-tree</em> [--stdin] [-m] [-s] [-v] [--no-commit-id] [--pretty]
[-t] [-r] [-c | --cc] [--combined-all-paths] [--root] [--merge-base]
[&lt;common diff options&gt;] &lt;tree-ish&gt; [&lt;tree-ish&gt;] [&lt;path&gt;&#8230;]</pre>
[&lt;common-diff-options&gt;] &lt;tree-ish&gt; [&lt;tree-ish&gt;] [&lt;path&gt;&#8230;]</pre>
<div class="attribution">
</div></div>
</div>
@ -1654,11 +1654,8 @@ of a delete/create pair.</p></div>
</p>
<div class="paragraph"><p>Also, these upper-case letters can be downcased to exclude. E.g.
<code>--diff-filter=ad</code> excludes added and deleted paths.</p></div>
<div class="paragraph"><p>Note that not all diffs can feature all types. For instance, diffs
from the index to the working tree can never have Added entries
(because the set of paths included in the diff is limited by what is in
the index). Similarly, copied and renamed entries cannot appear if
detection for those types is disabled.</p></div>
<div class="paragraph"><p>Note that not all diffs can feature all types. For instance, copied and
renamed entries cannot appear if detection for those types is disabled.</p></div>
</dd>
<dt class="hdlist1">
-S&lt;string&gt;
@ -2385,7 +2382,7 @@ built-in formats:</p></div>
</p>
<div class="literalblock">
<div class="content">
<pre><code>&lt;hash&gt; &lt;title line&gt;</code></pre>
<pre><code>&lt;hash&gt; &lt;title-line&gt;</code></pre>
</div></div>
<div class="paragraph"><p>This is designed to be as compact as possible.</p></div>
</li>
@ -2400,7 +2397,7 @@ Author: &lt;author&gt;</code></pre>
</div></div>
<div class="literalblock">
<div class="content">
<pre><code>&lt;title line&gt;</code></pre>
<pre><code>&lt;title-line&gt;</code></pre>
</div></div>
</li>
<li>
@ -2411,15 +2408,15 @@ Author: &lt;author&gt;</code></pre>
<div class="content">
<pre><code>commit &lt;hash&gt;
Author: &lt;author&gt;
Date: &lt;author date&gt;</code></pre>
Date: &lt;author-date&gt;</code></pre>
</div></div>
<div class="literalblock">
<div class="content">
<pre><code>&lt;title line&gt;</code></pre>
<pre><code>&lt;title-line&gt;</code></pre>
</div></div>
<div class="literalblock">
<div class="content">
<pre><code>&lt;full commit message&gt;</code></pre>
<pre><code>&lt;full-commit-message&gt;</code></pre>
</div></div>
</li>
<li>
@ -2434,11 +2431,11 @@ Commit: &lt;committer&gt;</code></pre>
</div></div>
<div class="literalblock">
<div class="content">
<pre><code>&lt;title line&gt;</code></pre>
<pre><code>&lt;title-line&gt;</code></pre>
</div></div>
<div class="literalblock">
<div class="content">
<pre><code>&lt;full commit message&gt;</code></pre>
<pre><code>&lt;full-commit-message&gt;</code></pre>
</div></div>
</li>
<li>
@ -2449,17 +2446,17 @@ Commit: &lt;committer&gt;</code></pre>
<div class="content">
<pre><code>commit &lt;hash&gt;
Author: &lt;author&gt;
AuthorDate: &lt;author date&gt;
AuthorDate: &lt;author-date&gt;
Commit: &lt;committer&gt;
CommitDate: &lt;committer date&gt;</code></pre>
CommitDate: &lt;committer-date&gt;</code></pre>
</div></div>
<div class="literalblock">
<div class="content">
<pre><code>&lt;title line&gt;</code></pre>
<pre><code>&lt;title-line&gt;</code></pre>
</div></div>
<div class="literalblock">
<div class="content">
<pre><code>&lt;full commit message&gt;</code></pre>
<pre><code>&lt;full-commit-message&gt;</code></pre>
</div></div>
</li>
<li>
@ -2468,7 +2465,7 @@ CommitDate: &lt;committer date&gt;</code></pre>
</p>
<div class="literalblock">
<div class="content">
<pre><code>&lt;abbrev hash&gt; (&lt;title line&gt;, &lt;short author date&gt;)</code></pre>
<pre><code>&lt;abbrev-hash&gt; (&lt;title-line&gt;, &lt;short-author-date&gt;)</code></pre>
</div></div>
<div class="paragraph"><p>This format is used to refer to another commit in a commit message and
is the same as <code>--pretty='format:%C(auto)%h (%s, %ad)'</code>. By default,
@ -2485,12 +2482,12 @@ placeholders, its output is not affected by other options like
<div class="content">
<pre><code>From &lt;hash&gt; &lt;date&gt;
From: &lt;author&gt;
Date: &lt;author date&gt;
Subject: [PATCH] &lt;title line&gt;</code></pre>
Date: &lt;author-date&gt;
Subject: [PATCH] &lt;title-line&gt;</code></pre>
</div></div>
<div class="literalblock">
<div class="content">
<pre><code>&lt;full commit message&gt;</code></pre>
<pre><code>&lt;full-commit-message&gt;</code></pre>
</div></div>
</li>
<li>
@ -2517,9 +2514,9 @@ use <code>--no-abbrev</code>.</p></div>
</li>
<li>
<p>
<em>format:&lt;string&gt;</em>
<em>format:&lt;format-string&gt;</em>
</p>
<div class="paragraph"><p>The <em>format:&lt;string&gt;</em> format allows you to specify which information
<div class="paragraph"><p>The <em>format:&lt;format-string&gt;</em> format allows you to specify which information
you want to show. It works a little bit like printf format,
with the notable exception that you get a newline with <em>%n</em>
instead of <em>\n</em>.</p></div>
@ -3012,6 +3009,20 @@ human-readable name, like
<div class="ulist"><ul>
<li>
<p>
<em>tags[=&lt;bool-value&gt;]</em>: Instead of only considering annotated tags,
consider lightweight tags as well.
</p>
</li>
<li>
<p>
<em>abbrev=&lt;number&gt;</em>: Instead of using the default number of hexadecimal digits
(which will vary according to the number of objects in the repository with a
default of 7) of the abbreviated object name, use &lt;number&gt; digits, or as many
digits as needed to form a unique object name.
</p>
</li>
<li>
<p>
<em>match=&lt;pattern&gt;</em>: Only consider tags matching the given
<code>glob(7)</code> pattern, excluding the "refs/tags/" prefix.
</p>
@ -3222,14 +3233,10 @@ display the trailers of the body as
If any option is provided multiple times the
last occurrence wins.
</p>
<div class="paragraph"><p>The boolean options accept an optional value <code>[=&lt;BOOL&gt;]</code>. The values
<code>true</code>, <code>false</code>, <code>on</code>, <code>off</code> etc. are all accepted. See the "boolean"
sub-section in "EXAMPLES" in <a href="git-config.html">git-config(1)</a>. If a boolean
option is given with no value, it&#8217;s enabled.</p></div>
<div class="ulist"><ul>
<li>
<p>
<em>key=&lt;K&gt;</em>: only show trailers with specified key. Matching is done
<em>key=&lt;key&gt;</em>: only show trailers with specified &lt;key&gt;. Matching is done
case-insensitively and trailing colon is optional. If option is
given multiple times trailer lines matching any of the keys are
shown. This option automatically enables the <code>only</code> option so that
@ -3241,15 +3248,15 @@ option is given with no value, it&#8217;s enabled.</p></div>
</li>
<li>
<p>
<em>only[=&lt;BOOL&gt;]</em>: select whether non-trailer lines from the trailer
<em>only[=&lt;bool&gt;]</em>: select whether non-trailer lines from the trailer
block should be included.
</p>
</li>
<li>
<p>
<em>separator=&lt;SEP&gt;</em>: specify a separator inserted between trailer
<em>separator=&lt;sep&gt;</em>: specify a separator inserted between trailer
lines. When this option is not given each trailer line is
terminated with a line feed character. The string SEP may contain
terminated with a line feed character. The string &lt;sep&gt; may contain
the literal formatting codes described above. To use comma as
separator one must use <code>%x2C</code> as it would otherwise be parsed as
next option. E.g., <code>%(trailers:key=Ticket,separator=%x2C )</code>
@ -3259,27 +3266,27 @@ option is given with no value, it&#8217;s enabled.</p></div>
</li>
<li>
<p>
<em>unfold[=&lt;BOOL&gt;]</em>: make it behave as if interpret-trailer&#8217;s <code>--unfold</code>
<em>unfold[=&lt;bool&gt;]</em>: make it behave as if interpret-trailer&#8217;s <code>--unfold</code>
option was given. E.g.,
<code>%(trailers:only,unfold=true)</code> unfolds and shows all trailer lines.
</p>
</li>
<li>
<p>
<em>keyonly[=&lt;BOOL&gt;]</em>: only show the key part of the trailer.
<em>keyonly[=&lt;bool&gt;]</em>: only show the key part of the trailer.
</p>
</li>
<li>
<p>
<em>valueonly[=&lt;BOOL&gt;]</em>: only show the value part of the trailer.
<em>valueonly[=&lt;bool&gt;]</em>: only show the value part of the trailer.
</p>
</li>
<li>
<p>
<em>key_value_separator=&lt;SEP&gt;</em>: specify a separator inserted between
<em>key_value_separator=&lt;sep&gt;</em>: specify a separator inserted between
trailer lines. When this option is not given each trailer key-value
pair is separated by ": ". Otherwise it shares the same semantics
as <em>separator=&lt;SEP&gt;</em> above.
as <em>separator=&lt;sep&gt;</em> above.
</p>
</li>
</ul></div>
@ -3302,6 +3309,10 @@ decoration format if <code>--decorate</code> was not already provided on the com
line.</td>
</tr></table>
</div>
<div class="paragraph"><p>The boolean options accept an optional value <code>[=&lt;bool-value&gt;]</code>. The values
<code>true</code>, <code>false</code>, <code>on</code>, <code>off</code> etc. are all accepted. See the "boolean"
sub-section in "EXAMPLES" in <a href="git-config.html">git-config(1)</a>. If a boolean
option is given with no value, it&#8217;s enabled.</p></div>
<div class="paragraph"><p>If you add a <code>+</code> (plus sign) after <em>%</em> of a placeholder, a line-feed
is inserted immediately before the expansion if and only if the
placeholder expands to a non-empty string.</p></div>
@ -3440,7 +3451,7 @@ a space.
</li>
<li>
<p>
sha1 for "dst"; 0{40} if creation, unmerged or "look at work tree".
sha1 for "dst"; 0{40} if deletion, unmerged or "work tree out of sync with the index".
</p>
</li>
<li>
@ -3527,8 +3538,8 @@ X: "unknown" change type (most probably a bug, please report it)
percentage of similarity between the source and target of the move or
copy). Status letter M may be followed by a score (denoting the
percentage of dissimilarity) for file rewrites.</p></div>
<div class="paragraph"><p>&lt;sha1&gt; is shown as all 0&#8217;s if a file is new on the filesystem
and it is out of sync with the index.</p></div>
<div class="paragraph"><p>The sha1 for "dst" is shown as all 0&#8217;s if a file on the filesystem
is out of sync with the index.</p></div>
<div class="paragraph"><p>Example:</p></div>
<div class="listingblock">
<div class="content">
@ -3963,7 +3974,7 @@ the pathname, but if that is <code>NUL</code>, the record will show two paths.</
<div id="footer">
<div id="footer-text">
Last updated
2021-11-15 09:20:10 PST
2022-06-28 20:23:28 PDT
</div>
</div>
</body>

@ -1790,11 +1790,8 @@ of a delete/create pair.</p></div>
</p>
<div class="paragraph"><p>Also, these upper-case letters can be downcased to exclude. E.g.
<code>--diff-filter=ad</code> excludes added and deleted paths.</p></div>
<div class="paragraph"><p>Note that not all diffs can feature all types. For instance, diffs
from the index to the working tree can never have Added entries
(because the set of paths included in the diff is limited by what is in
the index). Similarly, copied and renamed entries cannot appear if
detection for those types is disabled.</p></div>
<div class="paragraph"><p>Note that not all diffs can feature all types. For instance, copied and
renamed entries cannot appear if detection for those types is disabled.</p></div>
</dd>
<dt class="hdlist1">
-S&lt;string&gt;
@ -2315,7 +2312,7 @@ a space.
</li>
<li>
<p>
sha1 for "dst"; 0{40} if creation, unmerged or "look at work tree".
sha1 for "dst"; 0{40} if deletion, unmerged or "work tree out of sync with the index".
</p>
</li>
<li>
@ -2402,8 +2399,8 @@ X: "unknown" change type (most probably a bug, please report it)
percentage of similarity between the source and target of the move or
copy). Status letter M may be followed by a score (denoting the
percentage of dissimilarity) for file rewrites.</p></div>
<div class="paragraph"><p>&lt;sha1&gt; is shown as all 0&#8217;s if a file is new on the filesystem
and it is out of sync with the index.</p></div>
<div class="paragraph"><p>The sha1 for "dst" is shown as all 0&#8217;s if a file on the filesystem
is out of sync with the index.</p></div>
<div class="paragraph"><p>Example:</p></div>
<div class="listingblock">
<div class="content">
@ -2978,6 +2975,655 @@ Output diff in reverse.
</div>
</div>
<div class="sect1">
<h2 id="_configuration">CONFIGURATION</h2>
<div class="sectionbody">
<div class="paragraph"><p>Everything below this line in this section is selectively included
from the <a href="git-config.html">git-config(1)</a> documentation. The content is the same
as what&#8217;s found there:</p></div>
<div class="dlist"><dl>
<dt class="hdlist1">
diff.autoRefreshIndex
</dt>
<dd>
<p>
When using <em>git diff</em> to compare with work tree
files, do not consider stat-only change as changed.
Instead, silently run <code>git update-index --refresh</code> to
update the cached stat information for paths whose
contents in the work tree match the contents in the
index. This option defaults to true. Note that this
affects only <em>git diff</em> Porcelain, and not lower level
<em>diff</em> commands such as <em>git diff-files</em>.
</p>
</dd>
<dt class="hdlist1">
diff.dirstat
</dt>
<dd>
<p>
A comma separated list of <code>--dirstat</code> parameters specifying the
default behavior of the <code>--dirstat</code> option to <a href="git-diff.html">git-diff(1)</a>
and friends. The defaults can be overridden on the command line
(using <code>--dirstat=&lt;param1,param2,...&gt;</code>). The fallback defaults
(when not changed by <code>diff.dirstat</code>) are <code>changes,noncumulative,3</code>.
The following parameters are available:
</p>
<div class="openblock">
<div class="content">
<div class="dlist"><dl>
<dt class="hdlist1">
<code>changes</code>
</dt>
<dd>
<p>
Compute the dirstat numbers by counting the lines that have been
removed from the source, or added to the destination. This ignores
the amount of pure code movements within a file. In other words,
rearranging lines in a file is not counted as much as other changes.
This is the default behavior when no parameter is given.
</p>
</dd>
<dt class="hdlist1">
<code>lines</code>
</dt>
<dd>
<p>
Compute the dirstat numbers by doing the regular line-based diff
analysis, and summing the removed/added line counts. (For binary
files, count 64-byte chunks instead, since binary files have no
natural concept of lines). This is a more expensive <code>--dirstat</code>
behavior than the <code>changes</code> behavior, but it does count rearranged
lines within a file as much as other changes. The resulting output
is consistent with what you get from the other <code>--*stat</code> options.
</p>
</dd>
<dt class="hdlist1">
<code>files</code>
</dt>
<dd>
<p>
Compute the dirstat numbers by counting the number of files changed.
Each changed file counts equally in the dirstat analysis. This is
the computationally cheapest <code>--dirstat</code> behavior, since it does
not have to look at the file contents at all.
</p>
</dd>
<dt class="hdlist1">
<code>cumulative</code>
</dt>
<dd>
<p>
Count changes in a child directory for the parent directory as well.
Note that when using <code>cumulative</code>, the sum of the percentages
reported may exceed 100%. The default (non-cumulative) behavior can
be specified with the <code>noncumulative</code> parameter.
</p>
</dd>
<dt class="hdlist1">
&lt;limit&gt;
</dt>
<dd>
<p>
An integer parameter specifies a cut-off percent (3% by default).
Directories contributing less than this percentage of the changes
are not shown in the output.
</p>
</dd>
</dl></div>
</div></div>
<div class="paragraph"><p>Example: The following will count changed files, while ignoring
directories with less than 10% of the total amount of changed files,
and accumulating child directory counts in the parent directories:
<code>files,10,cumulative</code>.</p></div>
</dd>
<dt class="hdlist1">
diff.statGraphWidth
</dt>
<dd>
<p>
Limit the width of the graph part in --stat output. If set, applies
to all commands generating --stat output except format-patch.
</p>
</dd>
<dt class="hdlist1">
diff.context
</dt>
<dd>
<p>
Generate diffs with &lt;n&gt; lines of context instead of the default
of 3. This value is overridden by the -U option.
</p>
</dd>
<dt class="hdlist1">
diff.interHunkContext
</dt>
<dd>
<p>
Show the context between diff hunks, up to the specified number
of lines, thereby fusing the hunks that are close to each other.
This value serves as the default for the <code>--inter-hunk-context</code>
command line option.
</p>
</dd>
<dt class="hdlist1">
diff.external
</dt>
<dd>
<p>
If this config variable is set, diff generation is not
performed using the internal diff machinery, but using the
given command. Can be overridden with the &#8216;GIT_EXTERNAL_DIFF&#8217;
environment variable. The command is called with parameters
as described under "git Diffs" in <a href="git.html">git(1)</a>. Note: if
you want to use an external diff program only on a subset of
your files, you might want to use <a href="gitattributes.html">gitattributes(5)</a> instead.
</p>
</dd>
<dt class="hdlist1">
diff.ignoreSubmodules
</dt>
<dd>
<p>
Sets the default value of --ignore-submodules. Note that this
affects only <em>git diff</em> Porcelain, and not lower level <em>diff</em>
commands such as <em>git diff-files</em>. <em>git checkout</em>
and <em>git switch</em> also honor
this setting when reporting uncommitted changes. Setting it to
<em>all</em> disables the submodule summary normally shown by <em>git commit</em>
and <em>git status</em> when <code>status.submoduleSummary</code> is set unless it is
overridden by using the --ignore-submodules command-line option.
The <em>git submodule</em> commands are not affected by this setting.
By default this is set to untracked so that any untracked
submodules are ignored.
</p>
</dd>
<dt class="hdlist1">
diff.mnemonicPrefix
</dt>
<dd>
<p>
If set, <em>git diff</em> uses a prefix pair that is different from the
standard "a/" and "b/" depending on what is being compared. When
this configuration is in effect, reverse diff output also swaps
the order of the prefixes:
</p>
<div class="dlist"><dl>
<dt class="hdlist1">
<code>git diff</code>
</dt>
<dd>
<p>
compares the (i)ndex and the (w)ork tree;
</p>
</dd>
<dt class="hdlist1">
<code>git diff HEAD</code>
</dt>
<dd>
<p>
compares a (c)ommit and the (w)ork tree;
</p>
</dd>
<dt class="hdlist1">
<code>git diff --cached</code>
</dt>
<dd>
<p>
compares a (c)ommit and the (i)ndex;
</p>
</dd>
<dt class="hdlist1">
<code>git diff HEAD:file1 file2</code>
</dt>
<dd>
<p>
compares an (o)bject and a (w)ork tree entity;
</p>
</dd>
<dt class="hdlist1">
<code>git diff --no-index a b</code>
</dt>
<dd>
<p>
compares two non-git things (1) and (2).
</p>
</dd>
</dl></div>
</dd>
<dt class="hdlist1">
diff.noprefix
</dt>
<dd>
<p>
If set, <em>git diff</em> does not show any source or destination prefix.
</p>
</dd>
<dt class="hdlist1">
diff.relative
</dt>
<dd>
<p>
If set to <em>true</em>, <em>git diff</em> does not show changes outside of the directory
and show pathnames relative to the current directory.
</p>
</dd>
<dt class="hdlist1">
diff.orderFile
</dt>
<dd>
<p>
File indicating how to order files within a diff.
See the <em>-O</em> option to <a href="git-diff.html">git-diff(1)</a> for details.
If <code>diff.orderFile</code> is a relative pathname, it is treated as
relative to the top of the working tree.
</p>
</dd>
<dt class="hdlist1">
diff.renameLimit
</dt>
<dd>
<p>
The number of files to consider in the exhaustive portion of
copy/rename detection; equivalent to the <em>git diff</em> option
<code>-l</code>. If not set, the default value is currently 1000. This
setting has no effect if rename detection is turned off.
</p>
</dd>
<dt class="hdlist1">
diff.renames
</dt>
<dd>
<p>
Whether and how Git detects renames. If set to "false",
rename detection is disabled. If set to "true", basic rename
detection is enabled. If set to "copies" or "copy", Git will
detect copies, as well. Defaults to true. Note that this
affects only <em>git diff</em> Porcelain like <a href="git-diff.html">git-diff(1)</a> and
<a href="git-log.html">git-log(1)</a>, and not lower level commands such as
<a href="git-diff-files.html">git-diff-files(1)</a>.
</p>
</dd>
<dt class="hdlist1">
diff.suppressBlankEmpty
</dt>
<dd>
<p>
A boolean to inhibit the standard behavior of printing a space
before each empty output line. Defaults to false.
</p>
</dd>
<dt class="hdlist1">
diff.submodule
</dt>
<dd>
<p>
Specify the format in which differences in submodules are
shown. The "short" format just shows the names of the commits
at the beginning and end of the range. The "log" format lists
the commits in the range like <a href="git-submodule.html">git-submodule(1)</a> <code>summary</code>
does. The "diff" format shows an inline diff of the changed
contents of the submodule. Defaults to "short".
</p>
</dd>
<dt class="hdlist1">
diff.wordRegex
</dt>
<dd>
<p>
A POSIX Extended Regular Expression used to determine what is a "word"
when performing word-by-word difference calculations. Character
sequences that match the regular expression are "words", all other
characters are <strong>ignorable</strong> whitespace.
</p>
</dd>
<dt class="hdlist1">
diff.&lt;driver&gt;.command
</dt>
<dd>
<p>
The custom diff driver command. See <a href="gitattributes.html">gitattributes(5)</a>
for details.
</p>
</dd>
<dt class="hdlist1">
diff.&lt;driver&gt;.xfuncname
</dt>
<dd>
<p>
The regular expression that the diff driver should use to
recognize the hunk header. A built-in pattern may also be used.
See <a href="gitattributes.html">gitattributes(5)</a> for details.
</p>
</dd>
<dt class="hdlist1">
diff.&lt;driver&gt;.binary
</dt>
<dd>
<p>
Set this option to true to make the diff driver treat files as
binary. See <a href="gitattributes.html">gitattributes(5)</a> for details.
</p>
</dd>
<dt class="hdlist1">
diff.&lt;driver&gt;.textconv
</dt>
<dd>
<p>
The command that the diff driver should call to generate the
text-converted version of a file. The result of the
conversion is used to generate a human-readable diff. See
<a href="gitattributes.html">gitattributes(5)</a> for details.
</p>
</dd>
<dt class="hdlist1">
diff.&lt;driver&gt;.wordRegex
</dt>
<dd>
<p>
The regular expression that the diff driver should use to
split words in a line. See <a href="gitattributes.html">gitattributes(5)</a> for
details.
</p>
</dd>
<dt class="hdlist1">
diff.&lt;driver&gt;.cachetextconv
</dt>
<dd>
<p>
Set this option to true to make the diff driver cache the text
conversion outputs. See <a href="gitattributes.html">gitattributes(5)</a> for details.
</p>
<div class="dlist"><dl>
<dt class="hdlist1">
<code>araxis</code>
</dt>
<dd>
<p>
Use Araxis Merge (requires a graphical session)
</p>
</dd>
<dt class="hdlist1">
<code>bc</code>
</dt>
<dd>
<p>
Use Beyond Compare (requires a graphical session)
</p>
</dd>
<dt class="hdlist1">
<code>bc3</code>
</dt>
<dd>
<p>
Use Beyond Compare (requires a graphical session)
</p>
</dd>
<dt class="hdlist1">
<code>bc4</code>
</dt>
<dd>
<p>
Use Beyond Compare (requires a graphical session)
</p>
</dd>
<dt class="hdlist1">
<code>codecompare</code>
</dt>
<dd>
<p>
Use Code Compare (requires a graphical session)
</p>
</dd>
<dt class="hdlist1">
<code>deltawalker</code>
</dt>
<dd>
<p>
Use DeltaWalker (requires a graphical session)
</p>
</dd>
<dt class="hdlist1">
<code>diffmerge</code>
</dt>
<dd>
<p>
Use DiffMerge (requires a graphical session)
</p>
</dd>
<dt class="hdlist1">
<code>diffuse</code>
</dt>
<dd>
<p>
Use Diffuse (requires a graphical session)
</p>
</dd>
<dt class="hdlist1">
<code>ecmerge</code>
</dt>
<dd>
<p>
Use ECMerge (requires a graphical session)
</p>
</dd>
<dt class="hdlist1">
<code>emerge</code>
</dt>
<dd>
<p>
Use Emacs' Emerge
</p>
</dd>
<dt class="hdlist1">
<code>examdiff</code>
</dt>
<dd>
<p>
Use ExamDiff Pro (requires a graphical session)
</p>
</dd>
<dt class="hdlist1">
<code>guiffy</code>
</dt>
<dd>
<p>
Use Guiffy&#8217;s Diff Tool (requires a graphical session)
</p>
</dd>
<dt class="hdlist1">
<code>gvimdiff</code>
</dt>
<dd>
<p>
Use gVim (requires a graphical session)
</p>
</dd>
<dt class="hdlist1">
<code>kdiff3</code>
</dt>
<dd>
<p>
Use KDiff3 (requires a graphical session)
</p>
</dd>
<dt class="hdlist1">
<code>kompare</code>
</dt>
<dd>
<p>
Use Kompare (requires a graphical session)
</p>
</dd>
<dt class="hdlist1">
<code>meld</code>
</dt>
<dd>
<p>
Use Meld (requires a graphical session)
</p>
</dd>
<dt class="hdlist1">
<code>nvimdiff</code>
</dt>
<dd>
<p>
Use Neovim
</p>
</dd>
<dt class="hdlist1">
<code>opendiff</code>
</dt>
<dd>
<p>
Use FileMerge (requires a graphical session)
</p>
</dd>
<dt class="hdlist1">
<code>p4merge</code>
</dt>
<dd>
<p>
Use HelixCore P4Merge (requires a graphical session)
</p>
</dd>
<dt class="hdlist1">
<code>smerge</code>
</dt>
<dd>
<p>
Use Sublime Merge (requires a graphical session)
</p>
</dd>
<dt class="hdlist1">
<code>tkdiff</code>
</dt>
<dd>
<p>
Use TkDiff (requires a graphical session)
</p>
</dd>
<dt class="hdlist1">
<code>vimdiff</code>
</dt>
<dd>
<p>
Use Vim
</p>
</dd>
<dt class="hdlist1">
<code>winmerge</code>
</dt>
<dd>
<p>
Use WinMerge (requires a graphical session)
</p>
</dd>
<dt class="hdlist1">
<code>xxdiff</code>
</dt>
<dd>
<p>
Use xxdiff (requires a graphical session)
</p>
</dd>
</dl></div>
</dd>
<dt class="hdlist1">
diff.indentHeuristic
</dt>
<dd>
<p>
Set this option to <code>false</code> to disable the default heuristics
that shift diff hunk boundaries to make patches easier to read.
</p>
</dd>
<dt class="hdlist1">
diff.algorithm
</dt>
<dd>
<p>
Choose a diff algorithm. The variants are as follows:
</p>
<div class="openblock">
<div class="content">
<div class="dlist"><dl>
<dt class="hdlist1">
<code>default</code>, <code>myers</code>
</dt>
<dd>
<p>
The basic greedy diff algorithm. Currently, this is the default.
</p>
</dd>
<dt class="hdlist1">
<code>minimal</code>
</dt>
<dd>
<p>
Spend extra time to make sure the smallest possible diff is
produced.
</p>
</dd>
<dt class="hdlist1">
<code>patience</code>
</dt>
<dd>
<p>
Use "patience diff" algorithm when generating patches.
</p>
</dd>
<dt class="hdlist1">
<code>histogram</code>
</dt>
<dd>
<p>
This algorithm extends the patience algorithm to "support
low-occurrence common elements".
</p>
</dd>
</dl></div>
</div></div>
</dd>
<dt class="hdlist1">
diff.wsErrorHighlight
</dt>
<dd>
<p>
Highlight whitespace errors in the <code>context</code>, <code>old</code> or <code>new</code>
lines of the diff. Multiple values are separated by comma,
<code>none</code> resets previous values, <code>default</code> reset the list to
<code>new</code> and <code>all</code> is a shorthand for <code>old,new,context</code>. The
whitespace errors are colored with <code>color.diff.whitespace</code>.
The command line option <code>--ws-error-highlight=&lt;kind&gt;</code>
overrides this setting.
</p>
</dd>
<dt class="hdlist1">
diff.colorMoved
</dt>
<dd>
<p>
If set to either a valid <code>&lt;mode&gt;</code> or a true value, moved lines
in a diff are colored differently, for details of valid modes
see <em>--color-moved</em> in <a href="git-diff.html">git-diff(1)</a>. If simply set to
true the default color mode will be used. When set to false,
moved lines are not colored.
</p>
</dd>
<dt class="hdlist1">
diff.colorMovedWS
</dt>
<dd>
<p>
When moved lines are colored using e.g. the <code>diff.colorMoved</code> setting,
this option controls the <code>&lt;mode&gt;</code> how spaces are treated
for details of valid modes see <em>--color-moved-ws</em> in <a href="git-diff.html">git-diff(1)</a>.
</p>
</dd>
</dl></div>
</div>
</div>
<div class="sect1">
<h2 id="_see_also">SEE ALSO</h2>
<div class="sectionbody">
<div class="paragraph"><p>diff(1),
@ -3000,7 +3646,7 @@ Output diff in reverse.
<div id="footer">
<div id="footer-text">
Last updated
2021-10-06 09:57:11 PDT
2022-10-08 14:40:28 PDT
</div>
</div>
</body>

@ -923,17 +923,24 @@ instead. <code>--no-symlinks</code> is the default on Windows.</p></div>
</div>
</div>
<div class="sect1">
<h2 id="_config_variables">CONFIG VARIABLES</h2>
<h2 id="_configuration">CONFIGURATION</h2>
<div class="sectionbody">
<div class="paragraph"><p><em>git difftool</em> falls back to <em>git mergetool</em> config variables when the
difftool equivalents have not been defined.</p></div>
<div class="paragraph"><p>Everything above this line in this section isn&#8217;t included from the
<a href="git-config.html">git-config(1)</a> documentation. The content that follows is the
same as what&#8217;s found there:</p></div>
<div class="dlist"><dl>
<dt class="hdlist1">
diff.tool
</dt>
<dd>
<p>
The default diff tool to use.
Controls which diff tool is used by <a href="git-difftool.html">git-difftool(1)</a>.
This variable overrides the value configured in <code>merge.tool</code>.
The list below shows the valid built-in values.
Any other value is treated as a custom diff tool and requires
that a corresponding difftool.&lt;tool&gt;.cmd variable is defined.
</p>
</dd>
<dt class="hdlist1">
@ -941,43 +948,53 @@ diff.guitool
</dt>
<dd>
<p>
The default diff tool to use when <code>--gui</code> is specified.
Controls which diff tool is used by <a href="git-difftool.html">git-difftool(1)</a> when
the -g/--gui flag is specified. This variable overrides the value
configured in <code>merge.guitool</code>. The list below shows the valid
built-in values. Any other value is treated as a custom diff tool
and requires that a corresponding difftool.&lt;guitool&gt;.cmd variable
is defined.
</p>
</dd>
<dt class="hdlist1">
difftool.&lt;tool&gt;.path
difftool.&lt;tool&gt;.cmd
</dt>
<dd>
<p>
Override the path for the given tool. This is useful in case
your tool is not in the PATH.
Specify the command to invoke the specified diff tool.
The specified command is evaluated in shell with the following
variables available: <em>LOCAL</em> is set to the name of the temporary
file containing the contents of the diff pre-image and <em>REMOTE</em>
is set to the name of the temporary file containing the contents
of the diff post-image.
</p>
<div class="paragraph"><p>See the <code>--tool=&lt;tool&gt;</code> option in <a href="git-difftool.html">git-difftool(1)</a> for more details.</p></div>
</dd>
<dt class="hdlist1">
difftool.&lt;tool&gt;.cmd
difftool.&lt;tool&gt;.path
</dt>
<dd>
<p>
Specify the command to invoke the specified diff tool.
Override the path for the given tool. This is useful in case
your tool is not in the PATH.
</p>
<div class="paragraph"><p>See the <code>--tool=&lt;tool&gt;</code> option above for more details.</p></div>
</dd>
<dt class="hdlist1">
difftool.prompt
difftool.trustExitCode
</dt>
<dd>
<p>
Prompt before each invocation of the diff tool.
Exit difftool if the invoked diff tool returns a non-zero exit status.
</p>
<div class="paragraph"><p>See the <code>--trust-exit-code</code> option in <a href="git-difftool.html">git-difftool(1)</a> for more details.</p></div>
</dd>
<dt class="hdlist1">
difftool.trustExitCode
difftool.prompt
</dt>
<dd>
<p>
Exit difftool if the invoked diff tool returns a non-zero exit status.
Prompt before each invocation of the diff tool.
</p>
<div class="paragraph"><p>See the <code>--trust-exit-code</code> option above for more details.</p></div>
</dd>
</dl></div>
</div>
@ -1024,7 +1041,7 @@ difftool.trustExitCode
<div id="footer">
<div id="footer-text">
Last updated
2021-10-06 09:57:11 PDT
2022-10-08 14:40:28 PDT
</div>
</div>
</body>

@ -1120,7 +1120,7 @@ a tag referencing a tree instead of a commit.</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2021-10-06 09:57:11 PDT
2022-06-28 20:23:28 PDT
</div>
</div>
</body>

@ -2600,6 +2600,30 @@ compression.</p></div>
</div>
</div>
<div class="sect1">
<h2 id="_configuration">CONFIGURATION</h2>
<div class="sectionbody">
<div class="paragraph"><p>Everything below this line in this section is selectively included
from the <a href="git-config.html">git-config(1)</a> documentation. The content is the same
as what&#8217;s found there:</p></div>
<div class="dlist"><dl>
<dt class="hdlist1">
fastimport.unpackLimit
</dt>
<dd>
<p>
If the number of objects imported by <a href="git-fast-import.html">git-fast-import(1)</a>
is below this limit, then the objects will be unpacked into
loose object files. However if the number of imported objects
equals or exceeds this limit then the pack will be stored as a
pack. Storing the pack from a fast-import can make the import
operation complete faster, especially on slow filesystems. If
not set, the value of <code>transfer.unpackLimit</code> is used instead.
</p>
</dd>
</dl></div>
</div>
</div>
<div class="sect1">
<h2 id="_see_also">SEE ALSO</h2>
<div class="sectionbody">
<div class="paragraph"><p><a href="git-fast-export.html">git-fast-export(1)</a></p></div>
@ -2616,7 +2640,7 @@ compression.</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2021-10-06 09:57:11 PDT
2022-10-08 14:40:28 PDT
</div>
</div>
</body>

@ -909,6 +909,15 @@ be in a separate packet, and the list must end with a flush packet.</p></div>
</p>
</dd>
<dt class="hdlist1">
--refetch
</dt>
<dd>
<p>
Skips negotiating commits with the server in order to fetch all matching
objects. Use to reapply a new partial clone blob/tree filter.
</p>
</dd>
<dt class="hdlist1">
--no-progress
</dt>
<dd>
@ -974,7 +983,7 @@ they may alternatively be 40-hex sha1s present on the remote.</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2021-09-30 23:04:56 PDT
2022-08-31 14:31:31 PDT
</div>
</div>
</body>

@ -911,7 +911,8 @@ configuration variables documented in <a href="git-config.html">git-config(1)</a
ancestors of the provided <code>--negotiation-tip=*</code> arguments,
which we have in common with the server.
</p>
<div class="paragraph"><p>Internally this is used to implement the <code>push.negotiate</code> option, see
<div class="paragraph"><p>This is incompatible with <code>--recurse-submodules=[yes|on-demand]</code>.
Internally this is used to implement the <code>push.negotiate</code> option, see
<a href="git-config.html">git-config(1)</a>.</p></div>
</dd>
<dt class="hdlist1">
@ -1053,6 +1054,19 @@ configuration variables documented in <a href="git-config.html">git-config(1)</a
</p>
</dd>
<dt class="hdlist1">
--refetch
</dt>
<dd>
<p>
Instead of negotiating with the server to avoid transferring commits and
associated objects that are already present locally, this option fetches
all objects as a fresh clone would. Use this to reapply a partial clone
filter from configuration or using <code>--filter=</code> when the filter
definition has changed. Automatic post-fetch maintenance will perform
object database pack consolidation to remove any duplicate objects.
</p>
</dd>
<dt class="hdlist1">
--refmap=&lt;refspec&gt;
</dt>
<dd>
@ -1090,16 +1104,22 @@ configuration variables documented in <a href="git-config.html">git-config(1)</a
<dd>
<p>
This option controls if and under what conditions new commits of
populated submodules should be fetched too. It can be used as a
boolean option to completely disable recursion when set to <em>no</em> or to
unconditionally recurse into all populated submodules when set to
<em>yes</em>, which is the default when this option is used without any
value. Use <em>on-demand</em> to only recurse into a populated submodule
when the superproject retrieves a commit that updates the submodule&#8217;s
reference to a commit that isn&#8217;t already in the local submodule
clone. By default, <em>on-demand</em> is used, unless
<code>fetch.recurseSubmodules</code> is set (see <a href="git-config.html">git-config(1)</a>).
</p>
submodules should be fetched too. When recursing through submodules,
<code>git fetch</code> always attempts to fetch "changed" submodules, that is, a
submodule that has commits that are referenced by a newly fetched
superproject commit but are missing in the local submodule clone. A
changed submodule can be fetched as long as it is present locally e.g.
in <code>$GIT_DIR/modules/</code> (see <a href="gitsubmodules.html">gitsubmodules(7)</a>); if the upstream
adds a new submodule, that submodule cannot be fetched until it is
cloned e.g. by <code>git submodule update</code>.
</p>
<div class="paragraph"><p>When set to <em>on-demand</em>, only changed submodules are fetched. When set
to <em>yes</em>, all populated submodules are fetched and submodules that are
both unpopulated and changed are fetched. When set to <em>no</em>, submodules
are never fetched.</p></div>
<div class="paragraph"><p>When unspecified, this uses the value of <code>fetch.recurseSubmodules</code> if it
is set (see <a href="git-config.html">git-config(1)</a>), defaulting to <em>on-demand</em> if unset.
When this option is used without any value, it defaults to <em>yes</em>.</p></div>
</dd>
<dt class="hdlist1">
-j
@ -1569,13 +1589,13 @@ config file would appear like this:</p></div>
<div class="listingblock">
<div class="content">
<pre><code> [remote "&lt;name&gt;"]
url = &lt;url&gt;
url = &lt;URL&gt;
pushurl = &lt;pushurl&gt;
push = &lt;refspec&gt;
fetch = &lt;refspec&gt;</code></pre>
</div></div>
<div class="paragraph"><p>The <code>&lt;pushurl&gt;</code> is used for pushes only. It is optional and defaults
to <code>&lt;url&gt;</code>.</p></div>
to <code>&lt;URL&gt;</code>.</p></div>
</div>
<div class="sect2">
<h3 id="_named_file_in_code_git_dir_remotes_code">Named file in <code>$GIT_DIR/remotes</code></h3>
@ -1604,9 +1624,9 @@ The URL in this file will be used to access the repository.
This file should have the following format:</p></div>
<div class="listingblock">
<div class="content">
<pre><code> &lt;url&gt;#&lt;head&gt;</code></pre>
<pre><code> &lt;URL&gt;#&lt;head&gt;</code></pre>
</div></div>
<div class="paragraph"><p><code>&lt;url&gt;</code> is required; <code>#&lt;head&gt;</code> is optional.</p></div>
<div class="paragraph"><p><code>&lt;URL&gt;</code> is required; <code>#&lt;head&gt;</code> is optional.</p></div>
<div class="paragraph"><p>Depending on the operation, git will use one of the following
refspecs, if you don&#8217;t provide one on the command line.
<code>&lt;branch&gt;</code> is the name of this file in <code>$GIT_DIR/branches</code> and
@ -1973,14 +1993,178 @@ As in #1, the attacker chooses an object ID X to steal. The victim sends
</div>
</div>
<div class="sect1">
<h2 id="_configuration">CONFIGURATION</h2>
<div class="sectionbody">
<div class="paragraph"><p>Everything below this line in this section is selectively included
from the <a href="git-config.html">git-config(1)</a> documentation. The content is the same
as what&#8217;s found there:</p></div>
<div class="dlist"><dl>
<dt class="hdlist1">
fetch.recurseSubmodules
</dt>
<dd>
<p>
This option controls whether <code>git fetch</code> (and the underlying fetch
in <code>git pull</code>) will recursively fetch into populated submodules.
This option can be set either to a boolean value or to <em>on-demand</em>.
Setting it to a boolean changes the behavior of fetch and pull to
recurse unconditionally into submodules when set to true or to not
recurse at all when set to false. When set to <em>on-demand</em>, fetch and
pull will only recurse into a populated submodule when its
superproject retrieves a commit that updates the submodule&#8217;s
reference.
Defaults to <em>on-demand</em>, or to the value of <em>submodule.recurse</em> if set.
</p>
</dd>
<dt class="hdlist1">
fetch.fsckObjects
</dt>
<dd>
<p>
If it is set to true, git-fetch-pack will check all fetched
objects. See <code>transfer.fsckObjects</code> for what&#8217;s
checked. Defaults to false. If not set, the value of
<code>transfer.fsckObjects</code> is used instead.
</p>
</dd>
<dt class="hdlist1">
fetch.fsck.&lt;msg-id&gt;
</dt>
<dd>
<p>
Acts like <code>fsck.&lt;msg-id&gt;</code>, but is used by
<a href="git-fetch-pack.html">git-fetch-pack(1)</a> instead of <a href="git-fsck.html">git-fsck(1)</a>. See
the <code>fsck.&lt;msg-id&gt;</code> documentation for details.
</p>
</dd>
<dt class="hdlist1">
fetch.fsck.skipList
</dt>
<dd>
<p>
Acts like <code>fsck.skipList</code>, but is used by
<a href="git-fetch-pack.html">git-fetch-pack(1)</a> instead of <a href="git-fsck.html">git-fsck(1)</a>. See
the <code>fsck.skipList</code> documentation for details.
</p>
</dd>
<dt class="hdlist1">
fetch.unpackLimit
</dt>
<dd>
<p>
If the number of objects fetched over the Git native
transfer is below this
limit, then the objects will be unpacked into loose object
files. However if the number of received objects equals or
exceeds this limit then the received pack will be stored as
a pack, after adding any missing delta bases. Storing the
pack from a push can make the push operation complete faster,
especially on slow filesystems. If not set, the value of
<code>transfer.unpackLimit</code> is used instead.
</p>
</dd>
<dt class="hdlist1">
fetch.prune
</dt>
<dd>
<p>
If true, fetch will automatically behave as if the <code>--prune</code>
option was given on the command line. See also <code>remote.&lt;name&gt;.prune</code>
and the PRUNING section of <a href="git-fetch.html">git-fetch(1)</a>.
</p>
</dd>
<dt class="hdlist1">
fetch.pruneTags
</dt>
<dd>
<p>
If true, fetch will automatically behave as if the
<code>refs/tags/*:refs/tags/*</code> refspec was provided when pruning,
if not set already. This allows for setting both this option
and <code>fetch.prune</code> to maintain a 1=1 mapping to upstream
refs. See also <code>remote.&lt;name&gt;.pruneTags</code> and the PRUNING
section of <a href="git-fetch.html">git-fetch(1)</a>.
</p>
</dd>
<dt class="hdlist1">
fetch.output
</dt>
<dd>
<p>
Control how ref update status is printed. Valid values are
<code>full</code> and <code>compact</code>. Default value is <code>full</code>. See section
OUTPUT in <a href="git-fetch.html">git-fetch(1)</a> for detail.
</p>
</dd>
<dt class="hdlist1">
fetch.negotiationAlgorithm
</dt>
<dd>
<p>
Control how information about the commits in the local repository
is sent when negotiating the contents of the packfile to be sent by
the server. Set to "consecutive" to use an algorithm that walks
over consecutive commits checking each one. Set to "skipping" to
use an algorithm that skips commits in an effort to converge
faster, but may result in a larger-than-necessary packfile; or set
to "noop" to not send any information at all, which will almost
certainly result in a larger-than-necessary packfile, but will skip
the negotiation step. Set to "default" to override settings made
previously and use the default behaviour. The default is normally
"consecutive", but if <code>feature.experimental</code> is true, then the
default is "skipping". Unknown values will cause <em>git fetch</em> to
error out.
</p>
<div class="paragraph"><p>See also the <code>--negotiate-only</code> and <code>--negotiation-tip</code> options to
<a href="git-fetch.html">git-fetch(1)</a>.</p></div>
</dd>
<dt class="hdlist1">
fetch.showForcedUpdates
</dt>
<dd>
<p>
Set to false to enable <code>--no-show-forced-updates</code> in
<a href="git-fetch.html">git-fetch(1)</a> and <a href="git-pull.html">git-pull(1)</a> commands.
Defaults to true.
</p>
</dd>
<dt class="hdlist1">
fetch.parallel
</dt>
<dd>
<p>
Specifies the maximal number of fetch operations to be run in parallel
at a time (submodules, or remotes when the <code>--multiple</code> option of
<a href="git-fetch.html">git-fetch(1)</a> is in effect).
</p>
<div class="paragraph"><p>A value of 0 will give some reasonable default. If unset, it defaults to 1.</p></div>
<div class="paragraph"><p>For submodules, this setting can be overridden using the <code>submodule.fetchJobs</code>
config setting.</p></div>
</dd>
<dt class="hdlist1">
fetch.writeCommitGraph
</dt>
<dd>
<p>
Set to true to write a commit-graph after every <code>git fetch</code> command
that downloads a pack-file from a remote. Using the <code>--split</code> option,
most executions will create a very small commit-graph file on top of
the existing commit-graph file(s). Occasionally, these files will
merge and the write may take longer. Having an updated commit-graph
file helps performance of many Git commands, including <code>git merge-base</code>,
<code>git push -f</code>, and <code>git log --graph</code>. Defaults to false.
</p>
</dd>
</dl></div>
</div>
</div>
<div class="sect1">
<h2 id="_bugs">BUGS</h2>
<div class="sectionbody">
<div class="paragraph"><p>Using --recurse-submodules can only fetch new commits in already checked
out submodules right now. When e.g. upstream added a new submodule in the
just fetched commits of the superproject the submodule itself cannot be
fetched, making it impossible to check out that submodule later without
having to do a fetch again. This is expected to be fixed in a future Git
version.</p></div>
<div class="paragraph"><p>Using --recurse-submodules can only fetch new commits in submodules that are
present locally e.g. in <code>$GIT_DIR/modules/</code>. If the upstream adds a new
submodule, that submodule cannot be fetched until it is cloned e.g. by <code>git
submodule update</code>. This is expected to be fixed in a future Git version.</p></div>
</div>
</div>
<div class="sect1">
@ -2000,7 +2184,7 @@ version.</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2021-10-06 09:57:11 PDT
2022-10-08 14:40:28 PDT
</div>
</div>
</body>

@ -1626,7 +1626,7 @@ To top it all off, even when users finally find working commands,
<div id="footer">
<div id="footer-text">
Last updated
2021-10-06 09:57:11 PDT
2022-06-28 20:23:28 PDT
</div>
</div>
</body>

@ -1409,7 +1409,7 @@ since the old and new histories are in different repositories.</td>
<h2 id="_output">OUTPUT</h2>
<div class="sectionbody">
<div class="paragraph"><p>Every time filter-repo is run, files are created in the <code>.git/filter-repo/</code>
directory. These files overwritten unconditionally on every run.</p></div>
directory. These files are overwritten unconditionally on every run.</p></div>
<div class="sect2">
<h3 id="_commit_map">Commit map</h3>
<div class="paragraph"><p>The <code>.git/filter-repo/commit-map</code> file contains a mapping of how all
@ -1434,7 +1434,7 @@ All commits in range of the rewrite will be listed, even commits
</li>
<li>
<p>
An all-zeros hash, or null SHA, represents a non-existant object.
An all-zeros hash, or null SHA, represents a non-existent object.
When in the "new" column, this means the commit was removed
entirely.
</p>
@ -1448,7 +1448,7 @@ references were changed.</p></div>
<div class="ulist"><ul>
<li>
<p>
A header is the first line with the text "old" and "new"
A header is the first line with the text "old", "new" and "ref"
</p>
</li>
<li>
@ -1458,7 +1458,7 @@ Reference mappings are in no particular order
</li>
<li>
<p>
An all-zeros hash, or null SHA, represents a non-existant object.
An all-zeros hash, or null SHA, represents a non-existent object.
When in the "new" column, this means the ref was removed entirely.
</p>
</li>
@ -2167,7 +2167,7 @@ that filter-repo uses bytestrings (see
instead of strings.</p></div>
<div class="paragraph"><p>There are four callbacks that allow you to operate directly on raw
objects that contain data that&#8217;s easy to write in
<a href="fast-import.html">fast-import(1)</a> format:</p></div>
<a href="git-fast-import.html">git-fast-import(1)</a> format:</p></div>
<div class="listingblock">
<div class="content">
<pre><code>--blob-callback
@ -2643,7 +2643,7 @@ Partial-repo filtering, while supported, runs counter to filter-repo&#8217;s
</div>
<div class="sect3">
<h4 id="_comments_on_reversibility">Comments on reversibility</h4>
<div class="paragraph"><p>Some people are interested in reversibility of of a rewrite; e.g. rewrite
<div class="paragraph"><p>Some people are interested in reversibility of a rewrite; e.g. rewrite
history, possibly add some commits, then unrewrite and get the original
history back plus a few new "unrewritten" commits. Obviously this is
impossible if your rewrite involves throwing away information
@ -2672,10 +2672,10 @@ rewriting of commit hashes will probably be reversible, but it is
</li>
<li>
<p>
filter-repo defaults to several forms of unreversible rewriting that
filter-repo defaults to several forms of irreversible rewriting that
you may need to turn off (e.g. the last two bullet points above or
reencoding commit messages into UTF-8); it&#8217;s possible that additional
forms of unreversible rewrites will be added in the future.
forms of irreversible rewrites will be added in the future.
</p>
</li>
<li>
@ -2709,7 +2709,7 @@ I assume that people use filter-repo for one-shot conversions, not
<div id="footer">
<div id="footer-text">
Last updated
2021-11-09 09:48:35 PST
2022-10-04 21:51:55 PDT
</div>
</div>
</body>

@ -749,7 +749,7 @@ git-fmt-merge-msg(1) Manual Page
<h2 id="_synopsis">SYNOPSIS</h2>
<div class="sectionbody">
<div class="verseblock">
<pre class="content"><em>git fmt-merge-msg</em> [-m &lt;message&gt;] [--log[=&lt;n&gt;] | --no-log]
<pre class="content"><em>git fmt-merge-msg</em> [-m &lt;message&gt;] [--into-name &lt;branch&gt;] [--log[=&lt;n&gt;] | --no-log]
<em>git fmt-merge-msg</em> [-m &lt;message&gt;] [--log[=&lt;n&gt;] | --no-log] -F &lt;file&gt;</pre>
<div class="attribution">
</div></div>
@ -812,6 +812,15 @@ automatically invoking <em>git merge</em>.</p></div>
</p>
</dd>
<dt class="hdlist1">
--into-name &lt;branch&gt;
</dt>
<dd>
<p>
Prepare the merge message as if merging to the branch <code>&lt;branch&gt;</code>,
instead of the name of the real branch to which the merge is made.
</p>
</dd>
<dt class="hdlist1">
-F &lt;file&gt;
</dt>
<dt class="hdlist1">
@ -908,7 +917,7 @@ the "origin" remote.</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2021-09-30 23:04:56 PDT
2022-06-28 20:23:28 PDT
</div>
</div>
</body>

@ -1338,7 +1338,7 @@ commits and from none of the <code>--no-merged</code> commits are shown.</p></di
<div id="footer">
<div id="footer-text">
Last updated
2021-10-06 09:57:11 PDT
2022-06-28 20:23:28 PDT
</div>
</div>
</body>

@ -812,7 +812,7 @@ descriptors <code>stdin</code>, <code>stdout</code>, and <code>stderr</code>.</p
<div id="footer">
<div id="footer-text">
Last updated
2021-10-06 09:57:11 PDT
2022-06-28 20:23:28 PDT
</div>
</div>
</body>

@ -758,7 +758,7 @@ git-format-patch(1) Manual Page
[-n | --numbered | -N | --no-numbered]
[--start-number &lt;n&gt;] [--numbered-files]
[--in-reply-to=&lt;message id&gt;] [--suffix=.&lt;sfx&gt;]
[--ignore-if-in-upstream]
[--ignore-if-in-upstream] [--always]
[--cover-from-description=&lt;mode&gt;]
[--rfc] [--subject-prefix=&lt;subject prefix&gt;]
[(--reroll-count|-v) &lt;n&gt;]
@ -1794,6 +1794,15 @@ will want to ensure that threading is disabled for <code>git send-email</code>.<
</p>
</dd>
<dt class="hdlist1">
--always
</dt>
<dd>
<p>
Include patches for commits that do not introduce any change,
which are omitted by default.
</p>
</dd>
<dt class="hdlist1">
--cover-from-description=&lt;mode&gt;
</dt>
<dd>
@ -1912,6 +1921,22 @@ transformation for you, and this option should not be used if you are
feeding the result to <code>git send-email</code>.</p></div>
</dd>
<dt class="hdlist1">
--[no-]force-in-body-from
</dt>
<dd>
<p>
With the e-mail sender specified via the <code>--from</code> option, by
default, an in-body "From:" to identify the real author of
the commit is added at the top of the commit log message if
the sender is different from the author. With this option,
the in-body "From:" is added even when the sender and the
author have the same name and address, which may help if the
mailing list software mangles the sender&#8217;s identity.
Defaults to the value of the <code>format.forceInBodyFrom</code>
configuration variable.
</p>
</dd>
<dt class="hdlist1">
--add-header=&lt;header&gt;
</dt>
<dd>
@ -2569,7 +2594,7 @@ merge commit.</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2021-11-15 14:22:31 PST
2022-10-08 14:40:28 PDT
</div>
</div>
</body>

@ -772,7 +772,7 @@ documentation of that command.</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2017-12-22 18:32:40 PST
2022-01-27 18:10:56 PST
</div>
</div>
</body>

@ -752,7 +752,7 @@ git-fsck(1) Manual Page
<pre class="content"><em>git fsck</em> [--tags] [--root] [--unreachable] [--cache] [--no-reflogs]
[--[no-]full] [--strict] [--verbose] [--lost-found]
[--[no-]dangling] [--[no-]progress] [--connectivity-only]
[--[no-]name-objects] [&lt;object&gt;*]</pre>
[--[no-]name-objects] [&lt;object&gt;&#8230;]</pre>
<div class="attribution">
</div></div>
</div>
@ -925,6 +925,9 @@ care about this output and want to speed it up further.</p></div>
<div class="sect1">
<h2 id="_configuration">CONFIGURATION</h2>
<div class="sectionbody">
<div class="paragraph"><p>Everything below this line in this section is selectively included
from the <a href="git-config.html">git-config(1)</a> documentation. The content is the same
as what&#8217;s found there:</p></div>
<div class="dlist"><dl>
<dt class="hdlist1">
fsck.&lt;msg-id&gt;
@ -1103,7 +1106,7 @@ GIT_ALTERNATE_OBJECT_DIRECTORIES
<div id="footer">
<div id="footer-text">
Last updated
2021-11-15 09:20:10 PST
2022-10-08 14:40:28 PDT
</div>
</div>
</body>

@ -0,0 +1,855 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=UTF-8" />
<meta name="generator" content="AsciiDoc 9.1.0" />
<title>git-fsmonitor&#45;&#45;daemon(1)</title>
<style type="text/css">
/* Shared CSS for AsciiDoc xhtml11 and html5 backends */
/* Default font. */
body {
font-family: Georgia,serif;
}
/* Title font. */
h1, h2, h3, h4, h5, h6,
div.title, caption.title,
thead, p.table.header,
#toctitle,
#author, #revnumber, #revdate, #revremark,
#footer {
font-family: Arial,Helvetica,sans-serif;
}
body {
margin: 1em 5% 1em 5%;
}
a {
color: blue;
text-decoration: underline;
}
a:visited {
color: fuchsia;
}
em {
font-style: italic;
color: navy;
}
strong {
font-weight: bold;
color: #083194;
}
h1, h2, h3, h4, h5, h6 {
color: #527bbd;
margin-top: 1.2em;
margin-bottom: 0.5em;
line-height: 1.3;
}
h1, h2, h3 {
border-bottom: 2px solid silver;
}
h2 {
padding-top: 0.5em;
}
h3 {
float: left;
}
h3 + * {
clear: left;
}
h5 {
font-size: 1.0em;
}
div.sectionbody {
margin-left: 0;
}
hr {
border: 1px solid silver;
}
p {
margin-top: 0.5em;
margin-bottom: 0.5em;
}
ul, ol, li > p {
margin-top: 0;
}
ul > li { color: #aaa; }
ul > li > * { color: black; }
.monospaced, code, pre {
font-family: "Courier New", Courier, monospace;
font-size: inherit;
color: navy;
padding: 0;
margin: 0;
}
pre {
white-space: pre-wrap;
}
#author {
color: #527bbd;
font-weight: bold;
font-size: 1.1em;
}
#email {
}
#revnumber, #revdate, #revremark {
}
#footer {
font-size: small;
border-top: 2px solid silver;
padding-top: 0.5em;
margin-top: 4.0em;
}
#footer-text {
float: left;
padding-bottom: 0.5em;
}
#footer-badges {
float: right;
padding-bottom: 0.5em;
}
#preamble {
margin-top: 1.5em;
margin-bottom: 1.5em;
}
div.imageblock, div.exampleblock, div.verseblock,
div.quoteblock, div.literalblock, div.listingblock, div.sidebarblock,
div.admonitionblock {
margin-top: 1.0em;
margin-bottom: 1.5em;
}
div.admonitionblock {
margin-top: 2.0em;
margin-bottom: 2.0em;
margin-right: 10%;
color: #606060;
}
div.content { /* Block element content. */
padding: 0;
}
/* Block element titles. */
div.title, caption.title {
color: #527bbd;
font-weight: bold;
text-align: left;
margin-top: 1.0em;
margin-bottom: 0.5em;
}
div.title + * {
margin-top: 0;
}
td div.title:first-child {
margin-top: 0.0em;
}
div.content div.title:first-child {
margin-top: 0.0em;
}
div.content + div.title {
margin-top: 0.0em;
}
div.sidebarblock > div.content {
background: #ffffee;
border: 1px solid #dddddd;
border-left: 4px solid #f0f0f0;
padding: 0.5em;
}
div.listingblock > div.content {
border: 1px solid #dddddd;
border-left: 5px solid #f0f0f0;
background: #f8f8f8;
padding: 0.5em;
}
div.quoteblock, div.verseblock {
padding-left: 1.0em;
margin-left: 1.0em;
margin-right: 10%;
border-left: 5px solid #f0f0f0;
color: #888;
}
div.quoteblock > div.attribution {
padding-top: 0.5em;
text-align: right;
}
div.verseblock > pre.content {
font-family: inherit;
font-size: inherit;
}
div.verseblock > div.attribution {
padding-top: 0.75em;
text-align: left;
}
/* DEPRECATED: Pre version 8.2.7 verse style literal block. */
div.verseblock + div.attribution {
text-align: left;
}
div.admonitionblock .icon {
vertical-align: top;
font-size: 1.1em;
font-weight: bold;
text-decoration: underline;
color: #527bbd;
padding-right: 0.5em;
}
div.admonitionblock td.content {
padding-left: 0.5em;
border-left: 3px solid #dddddd;
}
div.exampleblock > div.content {
border-left: 3px solid #dddddd;
padding-left: 0.5em;
}
div.imageblock div.content { padding-left: 0; }
span.image img { border-style: none; vertical-align: text-bottom; }
a.image:visited { color: white; }
dl {
margin-top: 0.8em;
margin-bottom: 0.8em;
}
dt {
margin-top: 0.5em;
margin-bottom: 0;
font-style: normal;
color: navy;
}
dd > *:first-child {
margin-top: 0.1em;
}
ul, ol {
list-style-position: outside;
}
ol.arabic {
list-style-type: decimal;
}
ol.loweralpha {
list-style-type: lower-alpha;
}
ol.upperalpha {
list-style-type: upper-alpha;
}
ol.lowerroman {
list-style-type: lower-roman;
}
ol.upperroman {
list-style-type: upper-roman;
}
div.compact ul, div.compact ol,
div.compact p, div.compact p,
div.compact div, div.compact div {
margin-top: 0.1em;
margin-bottom: 0.1em;
}
tfoot {
font-weight: bold;
}
td > div.verse {
white-space: pre;
}
div.hdlist {
margin-top: 0.8em;
margin-bottom: 0.8em;
}
div.hdlist tr {
padding-bottom: 15px;
}
dt.hdlist1.strong, td.hdlist1.strong {
font-weight: bold;
}
td.hdlist1 {
vertical-align: top;
font-style: normal;
padding-right: 0.8em;
color: navy;
}
td.hdlist2 {
vertical-align: top;
}
div.hdlist.compact tr {
margin: 0;
padding-bottom: 0;
}
.comment {
background: yellow;
}
.footnote, .footnoteref {
font-size: 0.8em;
}
span.footnote, span.footnoteref {
vertical-align: super;
}
#footnotes {
margin: 20px 0 20px 0;
padding: 7px 0 0 0;
}
#footnotes div.footnote {
margin: 0 0 5px 0;
}
#footnotes hr {
border: none;
border-top: 1px solid silver;
height: 1px;
text-align: left;
margin-left: 0;
width: 20%;
min-width: 100px;
}
div.colist td {
padding-right: 0.5em;
padding-bottom: 0.3em;
vertical-align: top;
}
div.colist td img {
margin-top: 0.3em;
}
@media print {
#footer-badges { display: none; }
}
#toc {
margin-bottom: 2.5em;
}
#toctitle {
color: #527bbd;
font-size: 1.1em;
font-weight: bold;
margin-top: 1.0em;
margin-bottom: 0.1em;
}
div.toclevel0, div.toclevel1, div.toclevel2, div.toclevel3, div.toclevel4 {
margin-top: 0;
margin-bottom: 0;
}
div.toclevel2 {
margin-left: 2em;
font-size: 0.9em;
}
div.toclevel3 {
margin-left: 4em;
font-size: 0.9em;
}
div.toclevel4 {
margin-left: 6em;
font-size: 0.9em;
}
span.aqua { color: aqua; }
span.black { color: black; }
span.blue { color: blue; }
span.fuchsia { color: fuchsia; }
span.gray { color: gray; }
span.green { color: green; }
span.lime { color: lime; }
span.maroon { color: maroon; }
span.navy { color: navy; }
span.olive { color: olive; }
span.purple { color: purple; }
span.red { color: red; }
span.silver { color: silver; }
span.teal { color: teal; }
span.white { color: white; }
span.yellow { color: yellow; }
span.aqua-background { background: aqua; }
span.black-background { background: black; }
span.blue-background { background: blue; }
span.fuchsia-background { background: fuchsia; }
span.gray-background { background: gray; }
span.green-background { background: green; }
span.lime-background { background: lime; }
span.maroon-background { background: maroon; }
span.navy-background { background: navy; }
span.olive-background { background: olive; }
span.purple-background { background: purple; }
span.red-background { background: red; }
span.silver-background { background: silver; }
span.teal-background { background: teal; }
span.white-background { background: white; }
span.yellow-background { background: yellow; }
span.big { font-size: 2em; }
span.small { font-size: 0.6em; }
span.underline { text-decoration: underline; }
span.overline { text-decoration: overline; }
span.line-through { text-decoration: line-through; }
div.unbreakable { page-break-inside: avoid; }
/*
* xhtml11 specific
*
* */
div.tableblock {
margin-top: 1.0em;
margin-bottom: 1.5em;
}
div.tableblock > table {
border: 3px solid #527bbd;
}
thead, p.table.header {
font-weight: bold;
color: #527bbd;
}
p.table {
margin-top: 0;
}
/* Because the table frame attribute is overridden by CSS in most browsers. */
div.tableblock > table[frame="void"] {
border-style: none;
}
div.tableblock > table[frame="hsides"] {
border-left-style: none;
border-right-style: none;
}
div.tableblock > table[frame="vsides"] {
border-top-style: none;
border-bottom-style: none;
}
/*
* html5 specific
*
* */
table.tableblock {
margin-top: 1.0em;
margin-bottom: 1.5em;
}
thead, p.tableblock.header {
font-weight: bold;
color: #527bbd;
}
p.tableblock {
margin-top: 0;
}
table.tableblock {
border-width: 3px;
border-spacing: 0px;
border-style: solid;
border-color: #527bbd;
border-collapse: collapse;
}
th.tableblock, td.tableblock {
border-width: 1px;
padding: 4px;
border-style: solid;
border-color: #527bbd;
}
table.tableblock.frame-topbot {
border-left-style: hidden;
border-right-style: hidden;
}
table.tableblock.frame-sides {
border-top-style: hidden;
border-bottom-style: hidden;
}
table.tableblock.frame-none {
border-style: hidden;
}
th.tableblock.halign-left, td.tableblock.halign-left {
text-align: left;
}
th.tableblock.halign-center, td.tableblock.halign-center {
text-align: center;
}
th.tableblock.halign-right, td.tableblock.halign-right {
text-align: right;
}
th.tableblock.valign-top, td.tableblock.valign-top {
vertical-align: top;
}
th.tableblock.valign-middle, td.tableblock.valign-middle {
vertical-align: middle;
}
th.tableblock.valign-bottom, td.tableblock.valign-bottom {
vertical-align: bottom;
}
/*
* manpage specific
*
* */
body.manpage h1 {
padding-top: 0.5em;
padding-bottom: 0.5em;
border-top: 2px solid silver;
border-bottom: 2px solid silver;
}
body.manpage h2 {
border-style: none;
}
body.manpage div.sectionbody {
margin-left: 3em;
}
@media print {
body.manpage div#toc { display: none; }
}
</style>
<script type="text/javascript">
/*<![CDATA[*/
var asciidoc = { // Namespace.
/////////////////////////////////////////////////////////////////////
// Table Of Contents generator
/////////////////////////////////////////////////////////////////////
/* Author: Mihai Bazon, September 2002
* http://students.infoiasi.ro/~mishoo
*
* Table Of Content generator
* Version: 0.4
*
* Feel free to use this script under the terms of the GNU General Public
* License, as long as you do not remove or alter this notice.
*/
/* modified by Troy D. Hanson, September 2006. License: GPL */
/* modified by Stuart Rackham, 2006, 2009. License: GPL */
// toclevels = 1..4.
toc: function (toclevels) {
function getText(el) {
var text = "";
for (var i = el.firstChild; i != null; i = i.nextSibling) {
if (i.nodeType == 3 /* Node.TEXT_NODE */) // IE doesn't speak constants.
text += i.data;
else if (i.firstChild != null)
text += getText(i);
}
return text;
}
function TocEntry(el, text, toclevel) {
this.element = el;
this.text = text;
this.toclevel = toclevel;
}
function tocEntries(el, toclevels) {
var result = new Array;
var re = new RegExp('[hH]([1-'+(toclevels+1)+'])');
// Function that scans the DOM tree for header elements (the DOM2
// nodeIterator API would be a better technique but not supported by all
// browsers).
var iterate = function (el) {
for (var i = el.firstChild; i != null; i = i.nextSibling) {
if (i.nodeType == 1 /* Node.ELEMENT_NODE */) {
var mo = re.exec(i.tagName);
if (mo && (i.getAttribute("class") || i.getAttribute("className")) != "float") {
result[result.length] = new TocEntry(i, getText(i), mo[1]-1);
}
iterate(i);
}
}
}
iterate(el);
return result;
}
var toc = document.getElementById("toc");
if (!toc) {
return;
}
// Delete existing TOC entries in case we're reloading the TOC.
var tocEntriesToRemove = [];
var i;
for (i = 0; i < toc.childNodes.length; i++) {
var entry = toc.childNodes[i];
if (entry.nodeName.toLowerCase() == 'div'
&& entry.getAttribute("class")
&& entry.getAttribute("class").match(/^toclevel/))
tocEntriesToRemove.push(entry);
}
for (i = 0; i < tocEntriesToRemove.length; i++) {
toc.removeChild(tocEntriesToRemove[i]);
}
// Rebuild TOC entries.
var entries = tocEntries(document.getElementById("content"), toclevels);
for (var i = 0; i < entries.length; ++i) {
var entry = entries[i];
if (entry.element.id == "")
entry.element.id = "_toc_" + i;
var a = document.createElement("a");
a.href = "#" + entry.element.id;
a.appendChild(document.createTextNode(entry.text));
var div = document.createElement("div");
div.appendChild(a);
div.className = "toclevel" + entry.toclevel;
toc.appendChild(div);
}
if (entries.length == 0)
toc.parentNode.removeChild(toc);
},
/////////////////////////////////////////////////////////////////////
// Footnotes generator
/////////////////////////////////////////////////////////////////////
/* Based on footnote generation code from:
* http://www.brandspankingnew.net/archive/2005/07/format_footnote.html
*/
footnotes: function () {
// Delete existing footnote entries in case we're reloading the footnodes.
var i;
var noteholder = document.getElementById("footnotes");
if (!noteholder) {
return;
}
var entriesToRemove = [];
for (i = 0; i < noteholder.childNodes.length; i++) {
var entry = noteholder.childNodes[i];
if (entry.nodeName.toLowerCase() == 'div' && entry.getAttribute("class") == "footnote")
entriesToRemove.push(entry);
}
for (i = 0; i < entriesToRemove.length; i++) {
noteholder.removeChild(entriesToRemove[i]);
}
// Rebuild footnote entries.
var cont = document.getElementById("content");
var spans = cont.getElementsByTagName("span");
var refs = {};
var n = 0;
for (i=0; i<spans.length; i++) {
if (spans[i].className == "footnote") {
n++;
var note = spans[i].getAttribute("data-note");
if (!note) {
// Use [\s\S] in place of . so multi-line matches work.
// Because JavaScript has no s (dotall) regex flag.
note = spans[i].innerHTML.match(/\s*\[([\s\S]*)]\s*/)[1];
spans[i].innerHTML =
"[<a id='_footnoteref_" + n + "' href='#_footnote_" + n +
"' title='View footnote' class='footnote'>" + n + "</a>]";
spans[i].setAttribute("data-note", note);
}
noteholder.innerHTML +=
"<div class='footnote' id='_footnote_" + n + "'>" +
"<a href='#_footnoteref_" + n + "' title='Return to text'>" +
n + "</a>. " + note + "</div>";
var id =spans[i].getAttribute("id");
if (id != null) refs["#"+id] = n;
}
}
if (n == 0)
noteholder.parentNode.removeChild(noteholder);
else {
// Process footnoterefs.
for (i=0; i<spans.length; i++) {
if (spans[i].className == "footnoteref") {
var href = spans[i].getElementsByTagName("a")[0].getAttribute("href");
href = href.match(/#.*/)[0]; // Because IE return full URL.
n = refs[href];
spans[i].innerHTML =
"[<a href='#_footnote_" + n +
"' title='View footnote' class='footnote'>" + n + "</a>]";
}
}
}
},
install: function(toclevels) {
var timerId;
function reinstall() {
asciidoc.footnotes();
if (toclevels) {
asciidoc.toc(toclevels);
}
}
function reinstallAndRemoveTimer() {
clearInterval(timerId);
reinstall();
}
timerId = setInterval(reinstall, 500);
if (document.addEventListener)
document.addEventListener("DOMContentLoaded", reinstallAndRemoveTimer, false);
else
window.onload = reinstallAndRemoveTimer;
}
}
asciidoc.install();
/*]]>*/
</script>
</head>
<body class="manpage">
<div id="header">
<h1>
git-fsmonitor&#45;&#45;daemon(1) Manual Page
</h1>
<h2>NAME</h2>
<div class="sectionbody">
<p>git-fsmonitor--daemon -
A Built-in File System Monitor
</p>
</div>
</div>
<div id="content">
<div class="sect1">
<h2 id="_synopsis">SYNOPSIS</h2>
<div class="sectionbody">
<div class="verseblock">
<pre class="content"><em>git fsmonitor&#45;&#45;daemon</em> start
<em>git fsmonitor&#45;&#45;daemon</em> run
<em>git fsmonitor&#45;&#45;daemon</em> stop
<em>git fsmonitor&#45;&#45;daemon</em> status</pre>
<div class="attribution">
</div></div>
</div>
</div>
<div class="sect1">
<h2 id="_description">DESCRIPTION</h2>
<div class="sectionbody">
<div class="paragraph"><p>A daemon to watch the working directory for file and directory
changes using platform-specific file system notification facilities.</p></div>
<div class="paragraph"><p>This daemon communicates directly with commands like <code>git status</code>
using the <a href="technical/api-simple-ipc.html">simple IPC</a> interface
instead of the slower <a href="githooks.html">githooks(5)</a> interface.</p></div>
<div class="paragraph"><p>This daemon is built into Git so that no third-party tools are
required.</p></div>
</div>
</div>
<div class="sect1">
<h2 id="_options">OPTIONS</h2>
<div class="sectionbody">
<div class="dlist"><dl>
<dt class="hdlist1">
start
</dt>
<dd>
<p>
Starts a daemon in the background.
</p>
</dd>
<dt class="hdlist1">
run
</dt>
<dd>
<p>
Runs a daemon in the foreground.
</p>
</dd>
<dt class="hdlist1">
stop
</dt>
<dd>
<p>
Stops the daemon running in the current working
directory, if present.
</p>
</dd>
<dt class="hdlist1">
status
</dt>
<dd>
<p>
Exits with zero status if a daemon is watching the
current working directory.
</p>
</dd>
</dl></div>
</div>
</div>
<div class="sect1">
<h2 id="_remarks">REMARKS</h2>
<div class="sectionbody">
<div class="paragraph"><p>This daemon is a long running process used to watch a single working
directory and maintain a list of the recently changed files and
directories. Performance of commands such as <code>git status</code> can be
increased if they just ask for a summary of changes to the working
directory and can avoid scanning the disk.</p></div>
<div class="paragraph"><p>When <code>core.fsmonitor</code> is set to <code>true</code> (see <a href="git-config.html">git-config(1)</a>)
commands, such as <code>git status</code>, will ask the daemon for changes and
automatically start it (if necessary).</p></div>
<div class="paragraph"><p>For more information see the "File System Monitor" section in
<a href="git-update-index.html">git-update-index(1)</a>.</p></div>
</div>
</div>
<div class="sect1">
<h2 id="_caveats">CAVEATS</h2>
<div class="sectionbody">
<div class="paragraph"><p>The fsmonitor daemon does not currently know about submodules and does
not know to filter out file system events that happen within a
submodule. If fsmonitor daemon is watching a super repo and a file is
modified within the working directory of a submodule, it will report
the change (as happening against the super repo). However, the client
will properly ignore these extra events, so performance may be affected
but it will not cause an incorrect result.</p></div>
</div>
</div>
<div class="sect1">
<h2 id="_git">GIT</h2>
<div class="sectionbody">
<div class="paragraph"><p>Part of the <a href="git.html">git(1)</a> suite</p></div>
</div>
</div>
</div>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
Last updated
2022-08-31 14:31:31 PDT
</div>
</div>
</body>
</html>

@ -806,6 +806,15 @@ other housekeeping tasks (e.g. rerere, working trees, reflog&#8230;) will
be performed as well.</p></div>
</dd>
<dt class="hdlist1">
--cruft
</dt>
<dd>
<p>
When expiring unreachable objects, pack them separately into a
cruft pack instead of storing them as loose objects.
</p>
</dd>
<dt class="hdlist1">
--prune=&lt;date&gt;
</dt>
<dd>
@ -883,8 +892,9 @@ users and their repositories.</p></div>
<div class="sect1">
<h2 id="_configuration">CONFIGURATION</h2>
<div class="sectionbody">
<div class="paragraph"><p>The below documentation is the same as what&#8217;s found in
<a href="git-config.html">git-config(1)</a>:</p></div>
<div class="paragraph"><p>Everything below this line in this section is selectively included
from the <a href="git-config.html">git-config(1)</a> documentation. The content is the same
as what&#8217;s found there:</p></div>
<div class="dlist"><dl>
<dt class="hdlist1">
gc.aggressiveDepth
@ -1009,17 +1019,29 @@ gc.packRefs
</p>
</dd>
<dt class="hdlist1">
gc.cruftPacks
</dt>
<dd>
<p>
Store unreachable objects in a cruft pack (see
<a href="git-repack.html">git-repack(1)</a>) instead of as loose objects. The default
is <code>false</code>.
</p>
</dd>
<dt class="hdlist1">
gc.pruneExpire
</dt>
<dd>
<p>
When <em>git gc</em> is run, it will call <em>prune --expire 2.weeks.ago</em>.
Override the grace period with this config variable. The value
"now" may be used to disable this grace period and always prune
unreachable objects immediately, or "never" may be used to
suppress pruning. This feature helps prevent corruption when
<em>git gc</em> runs concurrently with another process writing to the
repository; see the "NOTES" section of <a href="git-gc.html">git-gc(1)</a>.
When <em>git gc</em> is run, it will call <em>prune --expire 2.weeks.ago</em>
(and <em>repack --cruft --cruft-expiration 2.weeks.ago</em> if using
cruft packs via <code>gc.cruftPacks</code> or <code>--cruft</code>). Override the
grace period with this config variable. The value "now" may be
used to disable this grace period and always prune unreachable
objects immediately, or "never" may be used to suppress pruning.
This feature helps prevent corruption when <em>git gc</em> runs
concurrently with another process writing to the repository; see
the "NOTES" section of <a href="git-gc.html">git-gc(1)</a>.
</p>
</dd>
<dt class="hdlist1">
@ -1165,7 +1187,7 @@ seems to be low in practice).</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2021-10-06 09:57:11 PDT
2022-10-08 14:40:28 PDT
</div>
</div>
</body>

@ -778,7 +778,7 @@ a tree ID instead of a commit ID or tag.</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2018-06-15 19:45:01 PDT
2022-01-27 18:10:56 PST
</div>
</div>
</body>

@ -763,6 +763,7 @@ git-grep(1) Manual Page
[--break] [--heading] [-p | --show-function]
[-A &lt;post-context&gt;] [-B &lt;pre-context&gt;] [-C &lt;context&gt;]
[-W | --function-context]
[(-m | --max-count) &lt;num&gt;]
[--threads &lt;num&gt;]
[-f &lt;file&gt;] [-e] &lt;pattern&gt;
[--and|--or|--not|(|)|-e &lt;pattern&gt;&#8230;]
@ -1221,6 +1222,21 @@ providing this option will cause it to die.</p></div>
</p>
</dd>
<dt class="hdlist1">
-m &lt;num&gt;
</dt>
<dt class="hdlist1">
--max-count &lt;num&gt;
</dt>
<dd>
<p>
Limit the amount of matches per file. When using the <code>-v</code> or
<code>--invert-match</code> option, the search stops after the specified
number of non-matches. A value of -1 will return unlimited
results (the default). A value of 0 will exit immediately with
a non-zero status.
</p>
</dd>
<dt class="hdlist1">
--threads &lt;num&gt;
</dt>
<dd>
@ -1391,6 +1407,9 @@ performance in this case, it might be desirable to use <code>--threads=1</code>.
<div class="sect1">
<h2 id="_configuration">CONFIGURATION</h2>
<div class="sectionbody">
<div class="paragraph"><p>Everything below this line in this section is selectively included
from the <a href="git-config.html">git-config(1)</a> documentation. The content is the same
as what&#8217;s found there:</p></div>
<div class="dlist"><dl>
<dt class="hdlist1">
grep.lineNumber
@ -1416,7 +1435,8 @@ grep.patternType
Set the default matching behavior. Using a value of <em>basic</em>, <em>extended</em>,
<em>fixed</em>, or <em>perl</em> will enable the <code>--basic-regexp</code>, <code>--extended-regexp</code>,
<code>--fixed-strings</code>, or <code>--perl-regexp</code> option accordingly, while the
value <em>default</em> will return to the default matching behavior.
value <em>default</em> will use the <code>grep.extendedRegexp</code> option to choose
between <em>basic</em> and <em>extended</em>.
</p>
</dd>
<dt class="hdlist1">
@ -1469,7 +1489,7 @@ grep.fallbackToNoIndex
<div id="footer">
<div id="footer-text">
Last updated
2021-10-06 09:57:11 PDT
2022-10-08 14:40:28 PDT
</div>
</div>
</body>

@ -749,7 +749,7 @@ git-gui(1) Manual Page
<h2 id="_synopsis">SYNOPSIS</h2>
<div class="sectionbody">
<div class="verseblock">
<pre class="content"><em>git gui</em> [&lt;command&gt;] [arguments]</pre>
<pre class="content"><em>git gui</em> [&lt;command&gt;] [&lt;arguments&gt;]</pre>
<div class="attribution">
</div></div>
</div>
@ -945,7 +945,7 @@ of end users.</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2021-11-15 09:20:10 PST
2022-06-28 20:23:28 PDT
</div>
</div>
</body>

@ -853,7 +853,7 @@ When &lt;type&gt; is not specified, it defaults to "blob".</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2021-09-30 23:04:56 PDT
2022-06-28 20:23:28 PDT
</div>
</div>
</body>

@ -749,10 +749,12 @@ git-help(1) Manual Page
<h2 id="_synopsis">SYNOPSIS</h2>
<div class="sectionbody">
<div class="verseblock">
<pre class="content"><em>git help</em> [-a|--all [--[no-]verbose]]
[[-i|--info] [-m|--man] [-w|--web]] [COMMAND|GUIDE]
<pre class="content"><em>git help</em> [-a|--all] [--[no-]verbose] [--[no-]external-commands] [--[no-]aliases]
<em>git help</em> [[-i|--info] [-m|--man] [-w|--web]] [&lt;command&gt;|&lt;doc&gt;]
<em>git help</em> [-g|--guides]
<em>git help</em> [-c|--config]</pre>
<em>git help</em> [-c|--config]
<em>git help</em> [--user-interfaces]
<em>git help</em> [--developer-interfaces]</pre>
<div class="attribution">
</div></div>
</div>
@ -760,20 +762,20 @@ git-help(1) Manual Page
<div class="sect1">
<h2 id="_description">DESCRIPTION</h2>
<div class="sectionbody">
<div class="paragraph"><p>With no options and no COMMAND or GUIDE given, the synopsis of the <em>git</em>
<div class="paragraph"><p>With no options and no <em>&lt;command&gt;</em> or <em>&lt;doc&gt;</em> given, the synopsis of the <em>git</em>
command and a list of the most commonly used Git commands are printed
on the standard output.</p></div>
<div class="paragraph"><p>If the option <code>--all</code> or <code>-a</code> is given, all available commands are
printed on the standard output.</p></div>
<div class="paragraph"><p>If the option <code>--guides</code> or <code>-g</code> is given, a list of the
Git concept guides is also printed on the standard output.</p></div>
<div class="paragraph"><p>If a command, or a guide, is given, a manual page for that command or
guide is brought up. The <em>man</em> program is used by default for this
<div class="paragraph"><p>If a command or other documentation is given, the relevant manual page
will be brought up. The <em>man</em> program is used by default for this
purpose, but this can be overridden by other options or configuration
variables.</p></div>
<div class="paragraph"><p>If an alias is given, git shows the definition of the alias on
standard output. To get the manual page for the aliased command, use
<code>git COMMAND --help</code>.</p></div>
<code>git &lt;command&gt; --help</code>.</p></div>
<div class="paragraph"><p>Note that <code>git --help ...</code> is identical to <code>git help ...</code> because the
former is internally converted into the latter.</p></div>
<div class="paragraph"><p>To display the <a href="git.html">git(1)</a> man page, use <code>git help git</code>.</p></div>
@ -792,8 +794,25 @@ former is internally converted into the latter.</p></div>
</dt>
<dd>
<p>
Prints all the available commands on the standard output. This
option overrides any given command or guide name.
Prints all the available commands on the standard output.
</p>
</dd>
<dt class="hdlist1">
--no-external-commands
</dt>
<dd>
<p>
When used with <code>--all</code>, exclude the listing of external "git-*"
commands found in the <code>$PATH</code>.
</p>
</dd>
<dt class="hdlist1">
--no-aliases
</dt>
<dd>
<p>
When used with <code>--all</code>, exclude the listing of configured
aliases.
</p>
</dd>
<dt class="hdlist1">
@ -829,6 +848,31 @@ former is internally converted into the latter.</p></div>
</p>
</dd>
<dt class="hdlist1">
--user-interfaces
</dt>
<dd>
<p>
Prints a list of the repository, command and file interfaces
documentation on the standard output.
</p>
<div class="paragraph"><p>In-repository file interfaces such as <code>.git/info/exclude</code> are
documented here (see <a href="gitrepository-layout.html">gitrepository-layout(5)</a>), as well as
in-tree configuration such as <code>.mailmap</code> (see <a href="gitmailmap.html">gitmailmap(5)</a>).</p></div>
<div class="paragraph"><p>This section of the documentation also covers general or widespread
user-interface conventions (e.g. <a href="gitcli.html">gitcli(7)</a>), and
pseudo-configuration such as the file-based <code>.git/hooks/*</code> interface
described in <a href="githooks.html">githooks(5)</a>.</p></div>
</dd>
<dt class="hdlist1">
--developer-interfaces
</dt>
<dd>
<p>
Print list of file formats, protocols and other developer
interfaces documentation on the standard output.
</p>
</dd>
<dt class="hdlist1">
-i
</dt>
<dt class="hdlist1">
@ -1012,7 +1056,7 @@ See <a href="git-config.html">git-config(1)</a> for more information about this.
<div id="footer">
<div id="footer-text">
Last updated
2021-11-15 13:27:01 PST
2022-09-16 17:50:33 PDT
</div>
</div>
</body>

@ -0,0 +1,821 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=UTF-8" />
<meta name="generator" content="AsciiDoc 9.1.0" />
<title>git-hook(1)</title>
<style type="text/css">
/* Shared CSS for AsciiDoc xhtml11 and html5 backends */
/* Default font. */
body {
font-family: Georgia,serif;
}
/* Title font. */
h1, h2, h3, h4, h5, h6,
div.title, caption.title,
thead, p.table.header,
#toctitle,
#author, #revnumber, #revdate, #revremark,
#footer {
font-family: Arial,Helvetica,sans-serif;
}
body {
margin: 1em 5% 1em 5%;
}
a {
color: blue;
text-decoration: underline;
}
a:visited {
color: fuchsia;
}
em {
font-style: italic;
color: navy;
}
strong {
font-weight: bold;
color: #083194;
}
h1, h2, h3, h4, h5, h6 {
color: #527bbd;
margin-top: 1.2em;
margin-bottom: 0.5em;
line-height: 1.3;
}
h1, h2, h3 {
border-bottom: 2px solid silver;
}
h2 {
padding-top: 0.5em;
}
h3 {
float: left;
}
h3 + * {
clear: left;
}
h5 {
font-size: 1.0em;
}
div.sectionbody {
margin-left: 0;
}
hr {
border: 1px solid silver;
}
p {
margin-top: 0.5em;
margin-bottom: 0.5em;
}
ul, ol, li > p {
margin-top: 0;
}
ul > li { color: #aaa; }
ul > li > * { color: black; }
.monospaced, code, pre {
font-family: "Courier New", Courier, monospace;
font-size: inherit;
color: navy;
padding: 0;
margin: 0;
}
pre {
white-space: pre-wrap;
}
#author {
color: #527bbd;
font-weight: bold;
font-size: 1.1em;
}
#email {
}
#revnumber, #revdate, #revremark {
}
#footer {
font-size: small;
border-top: 2px solid silver;
padding-top: 0.5em;
margin-top: 4.0em;
}
#footer-text {
float: left;
padding-bottom: 0.5em;
}
#footer-badges {
float: right;
padding-bottom: 0.5em;
}
#preamble {
margin-top: 1.5em;
margin-bottom: 1.5em;
}
div.imageblock, div.exampleblock, div.verseblock,
div.quoteblock, div.literalblock, div.listingblock, div.sidebarblock,
div.admonitionblock {
margin-top: 1.0em;
margin-bottom: 1.5em;
}
div.admonitionblock {
margin-top: 2.0em;
margin-bottom: 2.0em;
margin-right: 10%;
color: #606060;
}
div.content { /* Block element content. */
padding: 0;
}
/* Block element titles. */
div.title, caption.title {
color: #527bbd;
font-weight: bold;
text-align: left;
margin-top: 1.0em;
margin-bottom: 0.5em;
}
div.title + * {
margin-top: 0;
}
td div.title:first-child {
margin-top: 0.0em;
}
div.content div.title:first-child {
margin-top: 0.0em;
}
div.content + div.title {
margin-top: 0.0em;
}
div.sidebarblock > div.content {
background: #ffffee;
border: 1px solid #dddddd;
border-left: 4px solid #f0f0f0;
padding: 0.5em;
}
div.listingblock > div.content {
border: 1px solid #dddddd;
border-left: 5px solid #f0f0f0;
background: #f8f8f8;
padding: 0.5em;
}
div.quoteblock, div.verseblock {
padding-left: 1.0em;
margin-left: 1.0em;
margin-right: 10%;
border-left: 5px solid #f0f0f0;
color: #888;
}
div.quoteblock > div.attribution {
padding-top: 0.5em;
text-align: right;
}
div.verseblock > pre.content {
font-family: inherit;
font-size: inherit;
}
div.verseblock > div.attribution {
padding-top: 0.75em;
text-align: left;
}
/* DEPRECATED: Pre version 8.2.7 verse style literal block. */
div.verseblock + div.attribution {
text-align: left;
}
div.admonitionblock .icon {
vertical-align: top;
font-size: 1.1em;
font-weight: bold;
text-decoration: underline;
color: #527bbd;
padding-right: 0.5em;
}
div.admonitionblock td.content {
padding-left: 0.5em;
border-left: 3px solid #dddddd;
}
div.exampleblock > div.content {
border-left: 3px solid #dddddd;
padding-left: 0.5em;
}
div.imageblock div.content { padding-left: 0; }
span.image img { border-style: none; vertical-align: text-bottom; }
a.image:visited { color: white; }
dl {
margin-top: 0.8em;
margin-bottom: 0.8em;
}
dt {
margin-top: 0.5em;
margin-bottom: 0;
font-style: normal;
color: navy;
}
dd > *:first-child {
margin-top: 0.1em;
}
ul, ol {
list-style-position: outside;
}
ol.arabic {
list-style-type: decimal;
}
ol.loweralpha {
list-style-type: lower-alpha;
}
ol.upperalpha {
list-style-type: upper-alpha;
}
ol.lowerroman {
list-style-type: lower-roman;
}
ol.upperroman {
list-style-type: upper-roman;
}
div.compact ul, div.compact ol,
div.compact p, div.compact p,
div.compact div, div.compact div {
margin-top: 0.1em;
margin-bottom: 0.1em;
}
tfoot {
font-weight: bold;
}
td > div.verse {
white-space: pre;
}
div.hdlist {
margin-top: 0.8em;
margin-bottom: 0.8em;
}
div.hdlist tr {
padding-bottom: 15px;
}
dt.hdlist1.strong, td.hdlist1.strong {
font-weight: bold;
}
td.hdlist1 {
vertical-align: top;
font-style: normal;
padding-right: 0.8em;
color: navy;
}
td.hdlist2 {
vertical-align: top;
}
div.hdlist.compact tr {
margin: 0;
padding-bottom: 0;
}
.comment {
background: yellow;
}
.footnote, .footnoteref {
font-size: 0.8em;
}
span.footnote, span.footnoteref {
vertical-align: super;
}
#footnotes {
margin: 20px 0 20px 0;
padding: 7px 0 0 0;
}
#footnotes div.footnote {
margin: 0 0 5px 0;
}
#footnotes hr {
border: none;
border-top: 1px solid silver;
height: 1px;
text-align: left;
margin-left: 0;
width: 20%;
min-width: 100px;
}
div.colist td {
padding-right: 0.5em;
padding-bottom: 0.3em;
vertical-align: top;
}
div.colist td img {
margin-top: 0.3em;
}
@media print {
#footer-badges { display: none; }
}
#toc {
margin-bottom: 2.5em;
}
#toctitle {
color: #527bbd;
font-size: 1.1em;
font-weight: bold;
margin-top: 1.0em;
margin-bottom: 0.1em;
}
div.toclevel0, div.toclevel1, div.toclevel2, div.toclevel3, div.toclevel4 {
margin-top: 0;
margin-bottom: 0;
}
div.toclevel2 {
margin-left: 2em;
font-size: 0.9em;
}
div.toclevel3 {
margin-left: 4em;
font-size: 0.9em;
}
div.toclevel4 {
margin-left: 6em;
font-size: 0.9em;
}
span.aqua { color: aqua; }
span.black { color: black; }
span.blue { color: blue; }
span.fuchsia { color: fuchsia; }
span.gray { color: gray; }
span.green { color: green; }
span.lime { color: lime; }
span.maroon { color: maroon; }
span.navy { color: navy; }
span.olive { color: olive; }
span.purple { color: purple; }
span.red { color: red; }
span.silver { color: silver; }
span.teal { color: teal; }
span.white { color: white; }
span.yellow { color: yellow; }
span.aqua-background { background: aqua; }
span.black-background { background: black; }
span.blue-background { background: blue; }
span.fuchsia-background { background: fuchsia; }
span.gray-background { background: gray; }
span.green-background { background: green; }
span.lime-background { background: lime; }
span.maroon-background { background: maroon; }
span.navy-background { background: navy; }
span.olive-background { background: olive; }
span.purple-background { background: purple; }
span.red-background { background: red; }
span.silver-background { background: silver; }
span.teal-background { background: teal; }
span.white-background { background: white; }
span.yellow-background { background: yellow; }
span.big { font-size: 2em; }
span.small { font-size: 0.6em; }
span.underline { text-decoration: underline; }
span.overline { text-decoration: overline; }
span.line-through { text-decoration: line-through; }
div.unbreakable { page-break-inside: avoid; }
/*
* xhtml11 specific
*
* */
div.tableblock {
margin-top: 1.0em;
margin-bottom: 1.5em;
}
div.tableblock > table {
border: 3px solid #527bbd;
}
thead, p.table.header {
font-weight: bold;
color: #527bbd;
}
p.table {
margin-top: 0;
}
/* Because the table frame attribute is overridden by CSS in most browsers. */
div.tableblock > table[frame="void"] {
border-style: none;
}
div.tableblock > table[frame="hsides"] {
border-left-style: none;
border-right-style: none;
}
div.tableblock > table[frame="vsides"] {
border-top-style: none;
border-bottom-style: none;
}
/*
* html5 specific
*
* */
table.tableblock {
margin-top: 1.0em;
margin-bottom: 1.5em;
}
thead, p.tableblock.header {
font-weight: bold;
color: #527bbd;
}
p.tableblock {
margin-top: 0;
}
table.tableblock {
border-width: 3px;
border-spacing: 0px;
border-style: solid;
border-color: #527bbd;
border-collapse: collapse;
}
th.tableblock, td.tableblock {
border-width: 1px;
padding: 4px;
border-style: solid;
border-color: #527bbd;
}
table.tableblock.frame-topbot {
border-left-style: hidden;
border-right-style: hidden;
}
table.tableblock.frame-sides {
border-top-style: hidden;
border-bottom-style: hidden;
}
table.tableblock.frame-none {
border-style: hidden;
}
th.tableblock.halign-left, td.tableblock.halign-left {
text-align: left;
}
th.tableblock.halign-center, td.tableblock.halign-center {
text-align: center;
}
th.tableblock.halign-right, td.tableblock.halign-right {
text-align: right;
}
th.tableblock.valign-top, td.tableblock.valign-top {
vertical-align: top;
}
th.tableblock.valign-middle, td.tableblock.valign-middle {
vertical-align: middle;
}
th.tableblock.valign-bottom, td.tableblock.valign-bottom {
vertical-align: bottom;
}
/*
* manpage specific
*
* */
body.manpage h1 {
padding-top: 0.5em;
padding-bottom: 0.5em;
border-top: 2px solid silver;
border-bottom: 2px solid silver;
}
body.manpage h2 {
border-style: none;
}
body.manpage div.sectionbody {
margin-left: 3em;
}
@media print {
body.manpage div#toc { display: none; }
}
</style>
<script type="text/javascript">
/*<![CDATA[*/
var asciidoc = { // Namespace.
/////////////////////////////////////////////////////////////////////
// Table Of Contents generator
/////////////////////////////////////////////////////////////////////
/* Author: Mihai Bazon, September 2002
* http://students.infoiasi.ro/~mishoo
*
* Table Of Content generator
* Version: 0.4
*
* Feel free to use this script under the terms of the GNU General Public
* License, as long as you do not remove or alter this notice.
*/
/* modified by Troy D. Hanson, September 2006. License: GPL */
/* modified by Stuart Rackham, 2006, 2009. License: GPL */
// toclevels = 1..4.
toc: function (toclevels) {
function getText(el) {
var text = "";
for (var i = el.firstChild; i != null; i = i.nextSibling) {
if (i.nodeType == 3 /* Node.TEXT_NODE */) // IE doesn't speak constants.
text += i.data;
else if (i.firstChild != null)
text += getText(i);
}
return text;
}
function TocEntry(el, text, toclevel) {
this.element = el;
this.text = text;
this.toclevel = toclevel;
}
function tocEntries(el, toclevels) {
var result = new Array;
var re = new RegExp('[hH]([1-'+(toclevels+1)+'])');
// Function that scans the DOM tree for header elements (the DOM2
// nodeIterator API would be a better technique but not supported by all
// browsers).
var iterate = function (el) {
for (var i = el.firstChild; i != null; i = i.nextSibling) {
if (i.nodeType == 1 /* Node.ELEMENT_NODE */) {
var mo = re.exec(i.tagName);
if (mo && (i.getAttribute("class") || i.getAttribute("className")) != "float") {
result[result.length] = new TocEntry(i, getText(i), mo[1]-1);
}
iterate(i);
}
}
}
iterate(el);
return result;
}
var toc = document.getElementById("toc");
if (!toc) {
return;
}
// Delete existing TOC entries in case we're reloading the TOC.
var tocEntriesToRemove = [];
var i;
for (i = 0; i < toc.childNodes.length; i++) {
var entry = toc.childNodes[i];
if (entry.nodeName.toLowerCase() == 'div'
&& entry.getAttribute("class")
&& entry.getAttribute("class").match(/^toclevel/))
tocEntriesToRemove.push(entry);
}
for (i = 0; i < tocEntriesToRemove.length; i++) {
toc.removeChild(tocEntriesToRemove[i]);
}
// Rebuild TOC entries.
var entries = tocEntries(document.getElementById("content"), toclevels);
for (var i = 0; i < entries.length; ++i) {
var entry = entries[i];
if (entry.element.id == "")
entry.element.id = "_toc_" + i;
var a = document.createElement("a");
a.href = "#" + entry.element.id;
a.appendChild(document.createTextNode(entry.text));
var div = document.createElement("div");
div.appendChild(a);
div.className = "toclevel" + entry.toclevel;
toc.appendChild(div);
}
if (entries.length == 0)
toc.parentNode.removeChild(toc);
},
/////////////////////////////////////////////////////////////////////
// Footnotes generator
/////////////////////////////////////////////////////////////////////
/* Based on footnote generation code from:
* http://www.brandspankingnew.net/archive/2005/07/format_footnote.html
*/
footnotes: function () {
// Delete existing footnote entries in case we're reloading the footnodes.
var i;
var noteholder = document.getElementById("footnotes");
if (!noteholder) {
return;
}
var entriesToRemove = [];
for (i = 0; i < noteholder.childNodes.length; i++) {
var entry = noteholder.childNodes[i];
if (entry.nodeName.toLowerCase() == 'div' && entry.getAttribute("class") == "footnote")
entriesToRemove.push(entry);
}
for (i = 0; i < entriesToRemove.length; i++) {
noteholder.removeChild(entriesToRemove[i]);
}
// Rebuild footnote entries.
var cont = document.getElementById("content");
var spans = cont.getElementsByTagName("span");
var refs = {};
var n = 0;
for (i=0; i<spans.length; i++) {
if (spans[i].className == "footnote") {
n++;
var note = spans[i].getAttribute("data-note");
if (!note) {
// Use [\s\S] in place of . so multi-line matches work.
// Because JavaScript has no s (dotall) regex flag.
note = spans[i].innerHTML.match(/\s*\[([\s\S]*)]\s*/)[1];
spans[i].innerHTML =
"[<a id='_footnoteref_" + n + "' href='#_footnote_" + n +
"' title='View footnote' class='footnote'>" + n + "</a>]";
spans[i].setAttribute("data-note", note);
}
noteholder.innerHTML +=
"<div class='footnote' id='_footnote_" + n + "'>" +
"<a href='#_footnoteref_" + n + "' title='Return to text'>" +
n + "</a>. " + note + "</div>";
var id =spans[i].getAttribute("id");
if (id != null) refs["#"+id] = n;
}
}
if (n == 0)
noteholder.parentNode.removeChild(noteholder);
else {
// Process footnoterefs.
for (i=0; i<spans.length; i++) {
if (spans[i].className == "footnoteref") {
var href = spans[i].getElementsByTagName("a")[0].getAttribute("href");
href = href.match(/#.*/)[0]; // Because IE return full URL.
n = refs[href];
spans[i].innerHTML =
"[<a href='#_footnote_" + n +
"' title='View footnote' class='footnote'>" + n + "</a>]";
}
}
}
},
install: function(toclevels) {
var timerId;
function reinstall() {
asciidoc.footnotes();
if (toclevels) {
asciidoc.toc(toclevels);
}
}
function reinstallAndRemoveTimer() {
clearInterval(timerId);
reinstall();
}
timerId = setInterval(reinstall, 500);
if (document.addEventListener)
document.addEventListener("DOMContentLoaded", reinstallAndRemoveTimer, false);
else
window.onload = reinstallAndRemoveTimer;
}
}
asciidoc.install();
/*]]>*/
</script>
</head>
<body class="manpage">
<div id="header">
<h1>
git-hook(1) Manual Page
</h1>
<h2>NAME</h2>
<div class="sectionbody">
<p>git-hook -
Run git hooks
</p>
</div>
</div>
<div id="content">
<div class="sect1">
<h2 id="_synopsis">SYNOPSIS</h2>
<div class="sectionbody">
<div class="verseblock">
<pre class="content"><em>git hook</em> run [--ignore-missing] &lt;hook-name&gt; [-- &lt;hook-args&gt;]</pre>
<div class="attribution">
</div></div>
</div>
</div>
<div class="sect1">
<h2 id="_description">DESCRIPTION</h2>
<div class="sectionbody">
<div class="paragraph"><p>A command interface to running git hooks (see <a href="githooks.html">githooks(5)</a>),
for use by other scripted git commands.</p></div>
</div>
</div>
<div class="sect1">
<h2 id="_subcommands">SUBCOMMANDS</h2>
<div class="sectionbody">
<div class="dlist"><dl>
<dt class="hdlist1">
run
</dt>
<dd>
<p>
Run the <code>&lt;hook-name&gt;</code> hook. See <a href="githooks.html">githooks(5)</a> for
supported hook names.
</p>
<div class="paragraph"><p>Any positional arguments to the hook should be passed after a
mandatory <code>--</code> (or <code>--end-of-options</code>, see <a href="gitcli.html">gitcli(7)</a>). See
<a href="githooks.html">githooks(5)</a> for arguments hooks might expect (if any).</p></div>
</dd>
</dl></div>
</div>
</div>
<div class="sect1">
<h2 id="_options">OPTIONS</h2>
<div class="sectionbody">
<div class="dlist"><dl>
<dt class="hdlist1">
--ignore-missing
</dt>
<dd>
<p>
Ignore any missing hook by quietly returning zero. Used for
tools that want to do a blind one-shot run of a hook that may
or may not be present.
</p>
</dd>
</dl></div>
</div>
</div>
<div class="sect1">
<h2 id="_see_also">SEE ALSO</h2>
<div class="sectionbody">
<div class="paragraph"><p><a href="githooks.html">githooks(5)</a></p></div>
</div>
</div>
<div class="sect1">
<h2 id="_git">GIT</h2>
<div class="sectionbody">
<div class="paragraph"><p>Part of the <a href="git.html">git(1)</a> suite</p></div>
</div>
</div>
</div>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
Last updated
2022-08-31 14:31:31 PDT
</div>
</div>
</body>
</html>

@ -1102,7 +1102,7 @@ invoked by the <em>git-receive-pack</em>.</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2021-11-15 13:27:01 PST
2022-06-28 20:23:28 PDT
</div>
</div>
</body>

@ -749,7 +749,7 @@ git-http-fetch(1) Manual Page
<h2 id="_synopsis">SYNOPSIS</h2>
<div class="sectionbody">
<div class="verseblock">
<pre class="content"><em>git http-fetch</em> [-c] [-t] [-a] [-d] [-v] [-w filename] [--recover] [--stdin | --packfile=&lt;hash&gt; | &lt;commit&gt;] &lt;url&gt;</pre>
<pre class="content"><em>git http-fetch</em> [-c] [-t] [-a] [-d] [-v] [-w &lt;filename&gt;] [--recover] [--stdin | --packfile=&lt;hash&gt; | &lt;commit&gt;] &lt;URL&gt;</pre>
<div class="attribution">
</div></div>
</div>
@ -860,7 +860,7 @@ commit-id
<div id="footer">
<div id="footer-text">
Last updated
2021-11-15 09:20:10 PST
2022-06-28 20:23:28 PDT
</div>
</div>
</body>

@ -749,7 +749,7 @@ git-http-push(1) Manual Page
<h2 id="_synopsis">SYNOPSIS</h2>
<div class="sectionbody">
<div class="verseblock">
<pre class="content"><em>git http-push</em> [--all] [--dry-run] [--force] [--verbose] &lt;url&gt; &lt;ref&gt; [&lt;ref&gt;&#8230;]</pre>
<pre class="content"><em>git http-push</em> [--all] [--dry-run] [--force] [--verbose] &lt;URL&gt; &lt;ref&gt; [&lt;ref&gt;&#8230;]</pre>
<div class="attribution">
</div></div>
</div>
@ -855,21 +855,20 @@ Specified branch is an ancestor of the remote HEAD
of such patterns separated by a colon ":" (this means that a ref name
cannot have a colon in it). A single pattern <em>&lt;name&gt;</em> is just a
shorthand for <em>&lt;name&gt;:&lt;name&gt;</em>.</p></div>
<div class="paragraph"><p>Each pattern pair consists of the source side (before the colon)
and the destination side (after the colon). The ref to be
pushed is determined by finding a match that matches the source
side, and where it is pushed is determined by using the
destination side.</p></div>
<div class="paragraph"><p>Each pattern pair <em>&lt;src&gt;:&lt;dst&gt;</em> consists of the source side (before
the colon) and the destination side (after the colon). The ref to be
pushed is determined by finding a match that matches the source side,
and where it is pushed is determined by using the destination side.</p></div>
<div class="ulist"><ul>
<li>
<p>
It is an error if &lt;src&gt; does not match exactly one of the
It is an error if <em>&lt;src&gt;</em> does not match exactly one of the
local refs.
</p>
</li>
<li>
<p>
If &lt;dst&gt; does not match any remote ref, either
If <em>&lt;dst&gt;</em> does not match any remote ref, either
</p>
<div class="ulist"><ul>
<li>
@ -909,7 +908,7 @@ to disable the fast-forward check only on that ref.</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2021-11-15 09:20:10 PST
2022-06-28 20:23:28 PDT
</div>
</div>
</body>

@ -821,6 +821,9 @@ that order.</p></div>
<div class="sectionbody">
<div class="paragraph"><p>To use the tool, <code>imap.folder</code> and either <code>imap.tunnel</code> or <code>imap.host</code> must be set
to appropriate values.</p></div>
<div class="paragraph"><p>Everything above this line in this section isn&#8217;t included from the
<a href="git-config.html">git-config(1)</a> documentation. The content that follows is the
same as what&#8217;s found there:</p></div>
<div class="dlist"><dl>
<dt class="hdlist1">
imap.folder
@ -1025,7 +1028,7 @@ users may wish to visit this web page for more information:
<div id="footer">
<div id="footer-text">
Last updated
2021-10-06 09:57:11 PDT
2022-10-08 14:40:28 PDT
</div>
</div>
</body>

@ -943,6 +943,19 @@ that, e.g., Git internal file formats in relation to SHA-256
repositories may change in backwards-incompatible ways. Only use
<code>--object-format=sha256</code> for testing purposes.</p></div>
</dd>
<dt class="hdlist1">
--promisor[=&lt;message&gt;]
</dt>
<dd>
<p>
Before committing the pack-index, create a .promisor file for this
pack. Particularly helpful when writing a promisor pack with --fix-thin
since the name of the pack is not final until the pack has been fully
written. If a <code>&lt;message&gt;</code> is provided, then that content will be
written to the .promisor file for future reference. See
<a href="technical/partial-clone.html">partial clone</a> for more information.
</p>
</dd>
</dl></div>
</div>
</div>
@ -968,7 +981,7 @@ mentioned above.</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2021-11-15 13:27:01 PST
2022-08-31 14:31:31 PDT
</div>
</div>
</body>

@ -749,7 +749,7 @@ git-init-db(1) Manual Page
<h2 id="_synopsis">SYNOPSIS</h2>
<div class="sectionbody">
<div class="verseblock">
<pre class="content"><em>git init-db</em> [-q | --quiet] [--bare] [--template=&lt;template_directory&gt;] [--separate-git-dir &lt;git dir&gt;] [--shared[=&lt;permissions&gt;]]</pre>
<pre class="content"><em>git init-db</em> [-q | --quiet] [--bare] [--template=&lt;template-directory&gt;] [--separate-git-dir &lt;git-dir&gt;] [--shared[=&lt;permissions&gt;]]</pre>
<div class="attribution">
</div></div>
</div>
@ -772,7 +772,7 @@ documentation of that command.</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2021-11-15 09:20:10 PST
2022-06-28 20:23:28 PDT
</div>
</div>
</body>

@ -749,10 +749,10 @@ git-init(1) Manual Page
<h2 id="_synopsis">SYNOPSIS</h2>
<div class="sectionbody">
<div class="verseblock">
<pre class="content"><em>git init</em> [-q | --quiet] [--bare] [--template=&lt;template_directory&gt;]
[--separate-git-dir &lt;git dir&gt;] [--object-format=&lt;format&gt;]
<pre class="content"><em>git init</em> [-q | --quiet] [--bare] [--template=&lt;template-directory&gt;]
[--separate-git-dir &lt;git-dir&gt;] [--object-format=&lt;format&gt;]
[-b &lt;branch-name&gt; | --initial-branch=&lt;branch-name&gt;]
[--shared[=&lt;permissions&gt;]] [directory]</pre>
[--shared[=&lt;permissions&gt;]] [&lt;directory&gt;]</pre>
<div class="attribution">
</div></div>
</div>
@ -817,7 +817,7 @@ repositories may change in backwards-incompatible ways. Only use
<code>--object-format=sha256</code> for testing purposes.</p></div>
</dd>
<dt class="hdlist1">
--template=&lt;template_directory&gt;
--template=&lt;template-directory&gt;
</dt>
<dd>
<p>
@ -826,7 +826,7 @@ DIRECTORY" section below.)
</p>
</dd>
<dt class="hdlist1">
--separate-git-dir=&lt;git dir&gt;
--separate-git-dir=&lt;git-dir&gt;
</dt>
<dd>
<p>
@ -852,7 +852,7 @@ customized via the <code>init.defaultBranch</code> configuration variable).
</p>
</dd>
<dt class="hdlist1">
--shared[=(false|true|umask|group|all|world|everybody|0xxx)]
--shared[=(false|true|umask|group|all|world|everybody|&lt;perm&gt;)]
</dt>
<dd>
<p>
@ -899,15 +899,18 @@ Same as <em>group</em>, but make the repository readable by all users.
</p>
</dd>
<dt class="hdlist1">
<em>0xxx</em>
<em>&lt;perm&gt;</em>
</dt>
<dd>
<p>
<em>0xxx</em> is an octal number and each file will have mode <em>0xxx</em>. <em>0xxx</em> will
override users' umask(2) value (and not only loosen permissions as <em>group</em> and
<em>all</em> does). <em>0640</em> will create a repository which is group-readable, but not
group-writable or accessible to others. <em>0660</em> will create a repo that is
readable and writable to the current user and group, but inaccessible to others.
<em>&lt;perm&gt;</em> is a 3-digit octal number prefixed with &#8216;0` and each file
will have mode <em>&lt;perm&gt;</em>. <em>&lt;perm&gt;</em> will override users&#8217; umask(2)
value (and not only loosen permissions as <em>group</em> and <em>all</em>
does). <em>0640</em> will create a repository which is group-readable, but
not group-writable or accessible to others. <em>0660</em> will create a repo
that is readable and writable to the current user and group, but
inaccessible to others (directories and executable files get their
<code>x</code> bit from the <code>r</code> bit for corresponding classes of users).
</p>
</dd>
</dl></div>
@ -993,6 +996,34 @@ Record the pristine state as the first commit in the history.
</div>
</div>
<div class="sect1">
<h2 id="_configuration">CONFIGURATION</h2>
<div class="sectionbody">
<div class="paragraph"><p>Everything below this line in this section is selectively included
from the <a href="git-config.html">git-config(1)</a> documentation. The content is the same
as what&#8217;s found there:</p></div>
<div class="dlist"><dl>
<dt class="hdlist1">
init.templateDir
</dt>
<dd>
<p>
Specify the directory from which templates will be copied.
(See the "TEMPLATE DIRECTORY" section of <a href="git-init.html">git-init(1)</a>.)
</p>
</dd>
<dt class="hdlist1">
init.defaultBranch
</dt>
<dd>
<p>
Allows overriding the default branch name e.g. when initializing
a new repository.
</p>
</dd>
</dl></div>
</div>
</div>
<div class="sect1">
<h2 id="_git">GIT</h2>
<div class="sectionbody">
<div class="paragraph"><p>Part of the <a href="git.html">git(1)</a> suite</p></div>
@ -1003,7 +1034,7 @@ Record the pristine state as the first commit in the history.
<div id="footer">
<div id="footer-text">
Last updated
2021-11-15 09:20:10 PST
2022-10-08 14:40:28 PDT
</div>
</div>
</body>

@ -907,7 +907,7 @@ restart
<div id="footer">
<div id="footer-text">
Last updated
2021-09-30 23:04:56 PDT
2022-06-28 20:23:28 PDT
</div>
</div>
</body>

@ -797,10 +797,12 @@ The group must either be at the end of the message or be the last
non-whitespace lines before a line that starts with <em>---</em> (followed by a
space or the end of the line). Such three minus signs start the patch
part of the message. See also <code>--no-divider</code> below.</p></div>
<div class="paragraph"><p>When reading trailers, there can be whitespaces after the
token, the separator and the value. There can also be whitespaces
inside the token and the value. The value may be split over multiple lines with
each subsequent line starting with whitespace, like the "folding" in RFC 822.</p></div>
<div class="paragraph"><p>When reading trailers, there can be no whitespace before or inside the
token, but any number of regular space and tab characters are allowed
between the token and the separator. There can be whitespaces before,
inside or after the value. The value may be split over multiple lines
with each subsequent line starting with at least one whitespace, like
the "folding" in RFC 822.</p></div>
<div class="paragraph"><p>Note that <em>trailers</em> do not follow and are not intended to follow many
rules for RFC 822 headers. For example they do not follow
the encoding rules and probably many other rules.</p></div>
@ -1327,7 +1329,7 @@ $ chmod +x .git/hooks/commit-msg</code></pre>
<div id="footer">
<div id="footer-text">
Last updated
2021-10-06 09:57:11 PDT
2022-10-08 14:40:28 PDT
</div>
</div>
</body>

@ -749,7 +749,7 @@ git-log(1) Manual Page
<h2 id="_synopsis">SYNOPSIS</h2>
<div class="sectionbody">
<div class="verseblock">
<pre class="content"><em>git log</em> [&lt;options&gt;] [&lt;revision range&gt;] [[--] &lt;path&gt;&#8230;]</pre>
<pre class="content"><em>git log</em> [&lt;options&gt;] [&lt;revision-range&gt;] [[--] &lt;path&gt;&#8230;]</pre>
<div class="attribution">
</div></div>
</div>
@ -837,14 +837,28 @@ each commit introduces are shown.</p></div>
</dt>
<dd>
<p>
If no <code>--decorate-refs</code> is given, pretend as if all refs were
included. For each candidate, do not use it for decoration if it
For each candidate reference, do not use it for decoration if it
matches any patterns given to <code>--decorate-refs-exclude</code> or if it
doesn&#8217;t match any of the patterns given to <code>--decorate-refs</code>. The
<code>log.excludeDecoration</code> config option allows excluding refs from
the decorations, but an explicit <code>--decorate-refs</code> pattern will
override a match in <code>log.excludeDecoration</code>.
</p>
<div class="paragraph"><p>If none of these options or config settings are given, then references are
used as decoration if they match <code>HEAD</code>, <code>refs/heads/</code>, <code>refs/remotes/</code>,
<code>refs/stash/</code>, or <code>refs/tags/</code>.</p></div>
</dd>
<dt class="hdlist1">
--clear-decorations
</dt>
<dd>
<p>
When specified, this option clears all previous <code>--decorate-refs</code>
or <code>--decorate-refs-exclude</code> options and relaxes the default
decoration filter to include all references. This option is
assumed if the config value <code>log.initialDecorationSet</code> is set to
<code>all</code>.
</p>
</dd>
<dt class="hdlist1">
--source
@ -950,16 +964,16 @@ works out patch hunk headers (see <em>Defining a custom hunk-header</em>
in <a href="gitattributes.html">gitattributes(5)</a>).</p></div>
</dd>
<dt class="hdlist1">
&lt;revision range&gt;
&lt;revision-range&gt;
</dt>
<dd>
<p>
Show only commits in the specified revision range. When no
&lt;revision range&gt; is specified, it defaults to <code>HEAD</code> (i.e. the
&lt;revision-range&gt; is specified, it defaults to <code>HEAD</code> (i.e. the
whole history leading to the current commit). <code>origin..HEAD</code>
specifies all the commits reachable from the current commit
(i.e. <code>HEAD</code>), but not from <code>origin</code>. For a complete list of
ways to spell &lt;revision range&gt;, see the <em>Specifying Ranges</em>
ways to spell &lt;revision-range&gt;, see the <em>Specifying Ranges</em>
section of <a href="gitrevisions.html">gitrevisions(7)</a>.
</p>
</dd>
@ -1023,6 +1037,16 @@ ordering and formatting options, such as <code>--reverse</code>.</p></div>
</p>
</dd>
<dt class="hdlist1">
--since-as-filter=&lt;date&gt;
</dt>
<dd>
<p>
Show all commits more recent than a specific date. This visits
all commits in the range, rather than stopping at the first commit which
is older than a specific date.
</p>
</dd>
<dt class="hdlist1">
--until=&lt;date&gt;
</dt>
<dt class="hdlist1">
@ -1205,18 +1229,31 @@ parents) and <code>--max-parents=-1</code> (negative numbers denote no upper lim
</dt>
<dd>
<p>
Follow only the first parent commit upon seeing a merge
commit. This option can give a better overview when
viewing the evolution of a particular topic branch,
because merges into a topic branch tend to be only about
adjusting to updated upstream from time to time, and
this option allows you to ignore the individual commits
brought in to your history by such a merge.
When finding commits to include, follow only the first
parent commit upon seeing a merge commit. This option
can give a better overview when viewing the evolution of
a particular topic branch, because merges into a topic
branch tend to be only about adjusting to updated upstream
from time to time, and this option allows you to ignore
the individual commits brought in to your history by such
a merge.
</p>
<div class="paragraph"><p>This option also changes default diff format for merge commits
to <code>first-parent</code>, see <code>--diff-merges=first-parent</code> for details.</p></div>
</dd>
<dt class="hdlist1">
--exclude-first-parent-only
</dt>
<dd>
<p>
When finding commits to exclude (with a <em>&#94;</em>), follow only
the first parent commit upon seeing a merge commit.
This can be used to find the set of changes in a topic branch
from the point where it diverged from the remote branch, given
that arbitrary merges can be valid topic branch changes.
</p>
</dd>
<dt class="hdlist1">
--not
</dt>
<dd>
@ -1578,15 +1615,17 @@ Default mode
</p>
</dd>
<dt class="hdlist1">
--ancestry-path
--ancestry-path[=&lt;commit&gt;]
</dt>
<dd>
<p>
When given a range of commits to display (e.g. <em>commit1..commit2</em>
or <em>commit2 &#94;commit1</em>), only display commits that exist
directly on the ancestry chain between the <em>commit1</em> and
<em>commit2</em>, i.e. commits that are both descendants of <em>commit1</em>,
and ancestors of <em>commit2</em>.
or <em>commit2 &#94;commit1</em>), only display commits in that range
that are ancestors of &lt;commit&gt;, descendants of &lt;commit&gt;, or
&lt;commit&gt; itself. If no commit is specified, use <em>commit1</em> (the
excluded part of the range) as &lt;commit&gt;. Can be passed multiple
times; if so, a commit is included if it is any of the commits
given or if it is an ancestor or descendant of one of them.
</p>
</dd>
</dl></div>
@ -1829,14 +1868,13 @@ If after this parent rewriting, <code>C'</code> is a root or merge commit (has
<div class="paragraph"><p>There is another simplification mode available:</p></div>
<div class="dlist"><dl>
<dt class="hdlist1">
--ancestry-path
--ancestry-path[=&lt;commit&gt;]
</dt>
<dd>
<p>
Limit the displayed commits to those directly on the ancestry
chain between the &#8220;from&#8221; and &#8220;to&#8221; commits in the given commit
range. I.e. only display commits that are ancestor of the &#8220;to&#8221;
commit and descendants of the &#8220;from&#8221; commit.
Limit the displayed commits to those which are an ancestor of
&lt;commit&gt;, or which are a descendant of &lt;commit&gt;, or are &lt;commit&gt;
itself.
</p>
<div class="paragraph"><p>As an example use case, consider the following commit history:</p></div>
<div class="listingblock">
@ -1866,6 +1904,26 @@ option does. Applied to the <em>D..M</em> range, it results in:</p></div>
\
L--M</code></pre>
</div></div>
<div class="paragraph"><p>We can also use <code>--ancestry-path=D</code> instead of <code>--ancestry-path</code> which
means the same thing when applied to the <em>D..M</em> range but is just more
explicit.</p></div>
<div class="paragraph"><p>If we instead are interested in a given topic within this range, and all
commits affected by that topic, we may only want to view the subset of
<code>D..M</code> which contain that topic in their ancestry path. So, using
<code>--ancestry-path=H D..M</code> for example would result in:</p></div>
<div class="listingblock">
<div class="content">
<pre><code> E
\
G---H---I---J
\
L--M</code></pre>
</div></div>
<div class="paragraph"><p>Whereas <code>--ancestry-path=K D..M</code> would result in</p></div>
<div class="listingblock">
<div class="content">
<pre><code> K---------------L--M</code></pre>
</div></div>
</dd>
</dl></div>
<div class="paragraph"><p>Before discussing another option, <code>--show-pulls</code>, we need to
@ -1917,7 +1975,7 @@ merge commits <code>O</code> and <code>P</code>. With parent rewriting, the resu
not actually contribute a change to <code>file.txt</code>. They only merged a topic
that was based on an older version of <code>file.txt</code>. This is a common
issue in repositories using a workflow where many contributors work in
parallel and merge their topic branches along a single trunk: manu
parallel and merge their topic branches along a single trunk: many
unrelated merges appear in the <code>--full-history</code> results.</p></div>
<div class="paragraph"><p>When using the <code>--simplify-merges</code> option, the commits <code>O</code> and <code>P</code>
disappear from the results. This is because the rewritten second parents
@ -2302,7 +2360,7 @@ omitted.</p></div>
1970). As with <code>--raw</code>, this is always in UTC and therefore <code>-local</code>
has no effect.</p></div>
<div class="paragraph"><p><code>--date=format:...</code> feeds the format <code>...</code> to your system <code>strftime</code>,
except for %z and %Z, which are handled internally.
except for %s, %z, and %Z, which are handled internally.
Use <code>--date=format:%c</code> to show the date in your system locale&#8217;s
preferred format. See the <code>strftime</code> manual for a complete list of
format placeholders. When using <code>-local</code>, the correct syntax is
@ -2429,7 +2487,7 @@ built-in formats:</p></div>
</p>
<div class="literalblock">
<div class="content">
<pre><code>&lt;hash&gt; &lt;title line&gt;</code></pre>
<pre><code>&lt;hash&gt; &lt;title-line&gt;</code></pre>
</div></div>
<div class="paragraph"><p>This is designed to be as compact as possible.</p></div>
</li>
@ -2444,7 +2502,7 @@ Author: &lt;author&gt;</code></pre>
</div></div>
<div class="literalblock">
<div class="content">
<pre><code>&lt;title line&gt;</code></pre>
<pre><code>&lt;title-line&gt;</code></pre>
</div></div>
</li>
<li>
@ -2455,15 +2513,15 @@ Author: &lt;author&gt;</code></pre>
<div class="content">
<pre><code>commit &lt;hash&gt;
Author: &lt;author&gt;
Date: &lt;author date&gt;</code></pre>
Date: &lt;author-date&gt;</code></pre>
</div></div>
<div class="literalblock">
<div class="content">
<pre><code>&lt;title line&gt;</code></pre>
<pre><code>&lt;title-line&gt;</code></pre>
</div></div>
<div class="literalblock">
<div class="content">
<pre><code>&lt;full commit message&gt;</code></pre>
<pre><code>&lt;full-commit-message&gt;</code></pre>
</div></div>
</li>
<li>
@ -2478,11 +2536,11 @@ Commit: &lt;committer&gt;</code></pre>
</div></div>
<div class="literalblock">
<div class="content">
<pre><code>&lt;title line&gt;</code></pre>
<pre><code>&lt;title-line&gt;</code></pre>
</div></div>
<div class="literalblock">
<div class="content">
<pre><code>&lt;full commit message&gt;</code></pre>
<pre><code>&lt;full-commit-message&gt;</code></pre>
</div></div>
</li>
<li>
@ -2493,17 +2551,17 @@ Commit: &lt;committer&gt;</code></pre>
<div class="content">
<pre><code>commit &lt;hash&gt;
Author: &lt;author&gt;
AuthorDate: &lt;author date&gt;
AuthorDate: &lt;author-date&gt;
Commit: &lt;committer&gt;
CommitDate: &lt;committer date&gt;</code></pre>
CommitDate: &lt;committer-date&gt;</code></pre>
</div></div>
<div class="literalblock">
<div class="content">
<pre><code>&lt;title line&gt;</code></pre>
<pre><code>&lt;title-line&gt;</code></pre>
</div></div>
<div class="literalblock">
<div class="content">
<pre><code>&lt;full commit message&gt;</code></pre>
<pre><code>&lt;full-commit-message&gt;</code></pre>
</div></div>
</li>
<li>
@ -2512,7 +2570,7 @@ CommitDate: &lt;committer date&gt;</code></pre>
</p>
<div class="literalblock">
<div class="content">
<pre><code>&lt;abbrev hash&gt; (&lt;title line&gt;, &lt;short author date&gt;)</code></pre>
<pre><code>&lt;abbrev-hash&gt; (&lt;title-line&gt;, &lt;short-author-date&gt;)</code></pre>
</div></div>
<div class="paragraph"><p>This format is used to refer to another commit in a commit message and
is the same as <code>--pretty='format:%C(auto)%h (%s, %ad)'</code>. By default,
@ -2529,12 +2587,12 @@ placeholders, its output is not affected by other options like
<div class="content">
<pre><code>From &lt;hash&gt; &lt;date&gt;
From: &lt;author&gt;
Date: &lt;author date&gt;
Subject: [PATCH] &lt;title line&gt;</code></pre>
Date: &lt;author-date&gt;
Subject: [PATCH] &lt;title-line&gt;</code></pre>
</div></div>
<div class="literalblock">
<div class="content">
<pre><code>&lt;full commit message&gt;</code></pre>
<pre><code>&lt;full-commit-message&gt;</code></pre>
</div></div>
</li>
<li>
@ -2561,9 +2619,9 @@ use <code>--no-abbrev</code>.</p></div>
</li>
<li>
<p>
<em>format:&lt;string&gt;</em>
<em>format:&lt;format-string&gt;</em>
</p>
<div class="paragraph"><p>The <em>format:&lt;string&gt;</em> format allows you to specify which information
<div class="paragraph"><p>The <em>format:&lt;format-string&gt;</em> format allows you to specify which information
you want to show. It works a little bit like printf format,
with the notable exception that you get a newline with <em>%n</em>
instead of <em>\n</em>.</p></div>
@ -3056,6 +3114,20 @@ human-readable name, like
<div class="ulist"><ul>
<li>
<p>
<em>tags[=&lt;bool-value&gt;]</em>: Instead of only considering annotated tags,
consider lightweight tags as well.
</p>
</li>
<li>
<p>
<em>abbrev=&lt;number&gt;</em>: Instead of using the default number of hexadecimal digits
(which will vary according to the number of objects in the repository with a
default of 7) of the abbreviated object name, use &lt;number&gt; digits, or as many
digits as needed to form a unique object name.
</p>
</li>
<li>
<p>
<em>match=&lt;pattern&gt;</em>: Only consider tags matching the given
<code>glob(7)</code> pattern, excluding the "refs/tags/" prefix.
</p>
@ -3266,14 +3338,10 @@ display the trailers of the body as
If any option is provided multiple times the
last occurrence wins.
</p>
<div class="paragraph"><p>The boolean options accept an optional value <code>[=&lt;BOOL&gt;]</code>. The values
<code>true</code>, <code>false</code>, <code>on</code>, <code>off</code> etc. are all accepted. See the "boolean"
sub-section in "EXAMPLES" in <a href="git-config.html">git-config(1)</a>. If a boolean
option is given with no value, it&#8217;s enabled.</p></div>
<div class="ulist"><ul>
<li>
<p>
<em>key=&lt;K&gt;</em>: only show trailers with specified key. Matching is done
<em>key=&lt;key&gt;</em>: only show trailers with specified &lt;key&gt;. Matching is done
case-insensitively and trailing colon is optional. If option is
given multiple times trailer lines matching any of the keys are
shown. This option automatically enables the <code>only</code> option so that
@ -3285,15 +3353,15 @@ option is given with no value, it&#8217;s enabled.</p></div>
</li>
<li>
<p>
<em>only[=&lt;BOOL&gt;]</em>: select whether non-trailer lines from the trailer
<em>only[=&lt;bool&gt;]</em>: select whether non-trailer lines from the trailer
block should be included.
</p>
</li>
<li>
<p>
<em>separator=&lt;SEP&gt;</em>: specify a separator inserted between trailer
<em>separator=&lt;sep&gt;</em>: specify a separator inserted between trailer
lines. When this option is not given each trailer line is
terminated with a line feed character. The string SEP may contain
terminated with a line feed character. The string &lt;sep&gt; may contain
the literal formatting codes described above. To use comma as
separator one must use <code>%x2C</code> as it would otherwise be parsed as
next option. E.g., <code>%(trailers:key=Ticket,separator=%x2C )</code>
@ -3303,27 +3371,27 @@ option is given with no value, it&#8217;s enabled.</p></div>
</li>
<li>
<p>
<em>unfold[=&lt;BOOL&gt;]</em>: make it behave as if interpret-trailer&#8217;s <code>--unfold</code>
<em>unfold[=&lt;bool&gt;]</em>: make it behave as if interpret-trailer&#8217;s <code>--unfold</code>
option was given. E.g.,
<code>%(trailers:only,unfold=true)</code> unfolds and shows all trailer lines.
</p>
</li>
<li>
<p>
<em>keyonly[=&lt;BOOL&gt;]</em>: only show the key part of the trailer.
<em>keyonly[=&lt;bool&gt;]</em>: only show the key part of the trailer.
</p>
</li>
<li>
<p>
<em>valueonly[=&lt;BOOL&gt;]</em>: only show the value part of the trailer.
<em>valueonly[=&lt;bool&gt;]</em>: only show the value part of the trailer.
</p>
</li>
<li>
<p>
<em>key_value_separator=&lt;SEP&gt;</em>: specify a separator inserted between
<em>key_value_separator=&lt;sep&gt;</em>: specify a separator inserted between
trailer lines. When this option is not given each trailer key-value
pair is separated by ": ". Otherwise it shares the same semantics
as <em>separator=&lt;SEP&gt;</em> above.
as <em>separator=&lt;sep&gt;</em> above.
</p>
</li>
</ul></div>
@ -3346,6 +3414,10 @@ decoration format if <code>--decorate</code> was not already provided on the com
line.</td>
</tr></table>
</div>
<div class="paragraph"><p>The boolean options accept an optional value <code>[=&lt;bool-value&gt;]</code>. The values
<code>true</code>, <code>false</code>, <code>on</code>, <code>off</code> etc. are all accepted. See the "boolean"
sub-section in "EXAMPLES" in <a href="git-config.html">git-config(1)</a>. If a boolean
option is given with no value, it&#8217;s enabled.</p></div>
<div class="paragraph"><p>If you add a <code>+</code> (plus sign) after <em>%</em> of a placeholder, a line-feed
is inserted immediately before the expansion if and only if the
placeholder expands to a non-empty string.</p></div>
@ -3430,7 +3502,7 @@ the default format.</p></div>
</p>
</dd>
<dt class="hdlist1">
--diff-merges=(off|none|on|first-parent|1|separate|m|combined|c|dense-combined|cc)
--diff-merges=(off|none|on|first-parent|1|separate|m|combined|c|dense-combined|cc|remerge|r)
</dt>
<dt class="hdlist1">
--no-diff-merges
@ -3495,6 +3567,26 @@ the default format.</p></div>
</p>
</dd>
<dt class="hdlist1">
--diff-merges=remerge
</dt>
<dt class="hdlist1">
--diff-merges=r
</dt>
<dt class="hdlist1">
--remerge-diff
</dt>
<dd>
<p>
With this option, two-parent merge commits are remerged to
create a temporary tree object&#8201;&#8212;&#8201;potentially containing files
with conflict markers and such. A diff is then shown between
that temporary tree and the actual merge commit.
</p>
<div class="paragraph"><p>The output emitted when this option is used is subject to change, and
so is its interaction with other options (unless explicitly
documented).</p></div>
</dd>
<dt class="hdlist1">
--diff-merges=combined
</dt>
<dt class="hdlist1">
@ -4418,11 +4510,8 @@ of a delete/create pair.</p></div>
</p>
<div class="paragraph"><p>Also, these upper-case letters can be downcased to exclude. E.g.
<code>--diff-filter=ad</code> excludes added and deleted paths.</p></div>
<div class="paragraph"><p>Note that not all diffs can feature all types. For instance, diffs
from the index to the working tree can never have Added entries
(because the set of paths included in the diff is limited by what is in
the index). Similarly, copied and renamed entries cannot appear if
detection for those types is disabled.</p></div>
<div class="paragraph"><p>Note that not all diffs can feature all types. For instance, copied and
renamed entries cannot appear if detection for those types is disabled.</p></div>
</dd>
<dt class="hdlist1">
-S&lt;string&gt;
@ -5247,20 +5336,81 @@ i18n.logOutputEncoding
otherwise.
</p>
</dd>
</dl></div>
<div class="paragraph"><p>Everything above this line in this section isn&#8217;t included from the
<a href="git-config.html">git-config(1)</a> documentation. The content that follows is the
same as what&#8217;s found there:</p></div>
<div class="dlist"><dl>
<dt class="hdlist1">
log.abbrevCommit
</dt>
<dd>
<p>
If true, makes <a href="git-log.html">git-log(1)</a>, <a href="git-show.html">git-show(1)</a>, and
<a href="git-whatchanged.html">git-whatchanged(1)</a> assume <code>--abbrev-commit</code>. You may
override this option with <code>--no-abbrev-commit</code>.
</p>
</dd>
<dt class="hdlist1">
log.date
</dt>
<dd>
<p>
Default format for human-readable dates. (Compare the
<code>--date</code> option.) Defaults to "default", which means to write
dates like <code>Sat May 8 19:35:34 2010 -0500</code>.
Set the default date-time mode for the <em>log</em> command.
Setting a value for log.date is similar to using <em>git log</em>'s
<code>--date</code> option. See <a href="git-log.html">git-log(1)</a> for details.
</p>
<div class="paragraph"><p>If the format is set to "auto:foo" and the pager is in use, format
"foo" will be the used for the date format. Otherwise "default" will
be used.</p></div>
</dd>
<dt class="hdlist1">
log.decorate
</dt>
<dd>
<p>
Print out the ref names of any commits that are shown by the log
command. If <em>short</em> is specified, the ref name prefixes <em>refs/heads/</em>,
<em>refs/tags/</em> and <em>refs/remotes/</em> will not be printed. If <em>full</em> is
specified, the full ref name (including prefix) will be printed.
If <em>auto</em> is specified, then if the output is going to a terminal,
the ref names are shown as if <em>short</em> were given, otherwise no ref
names are shown. This is the same as the <code>--decorate</code> option
of the <code>git log</code>.
</p>
</dd>
<dt class="hdlist1">
log.initialDecorationSet
</dt>
<dd>
<p>
By default, <code>git log</code> only shows decorations for certain known ref
namespaces. If <em>all</em> is specified, then show all refs as
decorations.
</p>
</dd>
<dt class="hdlist1">
log.excludeDecoration
</dt>
<dd>
<p>
Exclude the specified patterns from the log decorations. This is
similar to the <code>--decorate-refs-exclude</code> command-line option, but
the config option can be overridden by the <code>--decorate-refs</code>
option.
</p>
</dd>
<dt class="hdlist1">
log.diffMerges
</dt>
<dd>
<p>
Set default diff format to be used for merge commits. See
<code>--diff-merges</code> in <a href="git-log.html">git-log(1)</a> for details.
Defaults to <code>separate</code>.
</p>
</dd>
<dt class="hdlist1">
log.follow
</dt>
<dd>
@ -5272,14 +5422,23 @@ log.follow
</p>
</dd>
<dt class="hdlist1">
log.graphColors
</dt>
<dd>
<p>
A list of colors, separated by commas, that can be used to draw
history lines in <code>git log --graph</code>.
</p>
</dd>
<dt class="hdlist1">
log.showRoot
</dt>
<dd>
<p>
If <code>false</code>, <code>git log</code> and related commands will not treat the
initial commit as a big creation event. Any root commits in
<code>git log -p</code> output would be shown without a diff attached.
The default is <code>true</code>.
If true, the initial commit will be shown as a big creation event.
This is equivalent to a diff against an empty tree.
Tools like <a href="git-log.html">git-log(1)</a> or <a href="git-whatchanged.html">git-whatchanged(1)</a>, which
normally hide the root commit will now show it. True by default.
</p>
</dd>
<dt class="hdlist1">
@ -5287,16 +5446,42 @@ log.showSignature
</dt>
<dd>
<p>
If <code>true</code>, <code>git log</code> and related commands will act as if the
<code>--show-signature</code> option was passed to them.
If true, makes <a href="git-log.html">git-log(1)</a>, <a href="git-show.html">git-show(1)</a>, and
<a href="git-whatchanged.html">git-whatchanged(1)</a> assume <code>--show-signature</code>.
</p>
</dd>
<dt class="hdlist1">
mailmap.*
log.mailmap
</dt>
<dd>
<p>
See <a href="git-shortlog.html">git-shortlog(1)</a>.
If true, makes <a href="git-log.html">git-log(1)</a>, <a href="git-show.html">git-show(1)</a>, and
<a href="git-whatchanged.html">git-whatchanged(1)</a> assume <code>--use-mailmap</code>, otherwise
assume <code>--no-use-mailmap</code>. True by default.
</p>
</dd>
<dt class="hdlist1">
notes.mergeStrategy
</dt>
<dd>
<p>
Which merge strategy to choose by default when resolving notes
conflicts. Must be one of <code>manual</code>, <code>ours</code>, <code>theirs</code>, <code>union</code>, or
<code>cat_sort_uniq</code>. Defaults to <code>manual</code>. See "NOTES MERGE STRATEGIES"
section of <a href="git-notes.html">git-notes(1)</a> for more information on each strategy.
</p>
<div class="paragraph"><p>This setting can be overridden by passing the <code>--strategy</code> option to
<a href="git-notes.html">git-notes(1)</a>.</p></div>
</dd>
<dt class="hdlist1">
notes.&lt;name&gt;.mergeStrategy
</dt>
<dd>
<p>
Which merge strategy to choose when doing a notes merge into
refs/notes/&lt;name&gt;. This overrides the more general
"notes.mergeStrategy". See the "NOTES MERGE STRATEGIES" section in
<a href="git-notes.html">git-notes(1)</a> for more information on the available strategies.
</p>
</dd>
<dt class="hdlist1">
@ -5304,17 +5489,66 @@ notes.displayRef
</dt>
<dd>
<p>
Which refs, in addition to the default set by <code>core.notesRef</code>
or <code>GIT_NOTES_REF</code>, to read notes from when showing commit
messages with the <code>log</code> family of commands. See
<a href="git-notes.html">git-notes(1)</a>.
Which ref (or refs, if a glob or specified more than once), in
addition to the default set by <code>core.notesRef</code> or
<code>GIT_NOTES_REF</code>, to read notes from when showing commit
messages with the <em>git log</em> family of commands.
</p>
<div class="paragraph"><p>May be an unabbreviated ref name or a glob and may be specified
multiple times. A warning will be issued for refs that do not exist,
<div class="paragraph"><p>This setting can be overridden with the <code>GIT_NOTES_DISPLAY_REF</code>
environment variable, which must be a colon separated list of refs or
globs.</p></div>
<div class="paragraph"><p>A warning will be issued for refs that do not exist,
but a glob that does not match any refs is silently ignored.</p></div>
<div class="paragraph"><p>This setting can be disabled by the <code>--no-notes</code> option,
overridden by the <code>GIT_NOTES_DISPLAY_REF</code> environment variable,
and overridden by the <code>--notes=&lt;ref&gt;</code> option.</p></div>
<div class="paragraph"><p>This setting can be disabled by the <code>--no-notes</code> option to the <em>git
log</em> family of commands, or by the <code>--notes=&lt;ref&gt;</code> option accepted by
those commands.</p></div>
<div class="paragraph"><p>The effective value of "core.notesRef" (possibly overridden by
GIT_NOTES_REF) is also implicitly added to the list of refs to be
displayed.</p></div>
</dd>
<dt class="hdlist1">
notes.rewrite.&lt;command&gt;
</dt>
<dd>
<p>
When rewriting commits with &lt;command&gt; (currently <code>amend</code> or
<code>rebase</code>), if this variable is <code>false</code>, git will not copy
notes from the original to the rewritten commit. Defaults to
<code>true</code>. See also "<code>notes.rewriteRef</code>" below.
</p>
<div class="paragraph"><p>This setting can be overridden with the <code>GIT_NOTES_REWRITE_REF</code>
environment variable, which must be a colon separated list of refs or
globs.</p></div>
</dd>
<dt class="hdlist1">
notes.rewriteMode
</dt>
<dd>
<p>
When copying notes during a rewrite (see the
"notes.rewrite.&lt;command&gt;" option), determines what to do if
the target commit already has a note. Must be one of
<code>overwrite</code>, <code>concatenate</code>, <code>cat_sort_uniq</code>, or <code>ignore</code>.
Defaults to <code>concatenate</code>.
</p>
<div class="paragraph"><p>This setting can be overridden with the <code>GIT_NOTES_REWRITE_MODE</code>
environment variable.</p></div>
</dd>
<dt class="hdlist1">
notes.rewriteRef
</dt>
<dd>
<p>
When copying notes during a rewrite, specifies the (fully
qualified) ref whose notes should be copied. May be a glob,
in which case notes in all matching refs will be copied. You
may also specify this configuration several times.
</p>
<div class="paragraph"><p>Does not have a default value; you must configure this variable to
enable note rewriting. Set it to <code>refs/notes/commits</code> to enable
rewriting for the default commit notes.</p></div>
<div class="paragraph"><p>Can be overridden with the <code>GIT_NOTES_REWRITE_REF</code> environment variable.
See <code>notes.rewrite.&lt;command&gt;</code> above for a further description of its format.</p></div>
</dd>
</dl></div>
</div>
@ -5330,7 +5564,7 @@ and overridden by the <code>--notes=&lt;ref&gt;</code> option.</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2021-11-15 09:20:10 PST
2022-10-08 14:40:28 PDT
</div>
</div>
</body>

@ -750,9 +750,9 @@ git-ls-files(1) Manual Page
<div class="sectionbody">
<div class="verseblock">
<pre class="content"><em>git ls-files</em> [-z] [-t] [-v] [-f]
(--[cached|deleted|others|ignored|stage|unmerged|killed|modified])*
(-[c|d|o|i|s|u|k|m])*
[--eol]
[-c|--cached] [-d|--deleted] [-o|--others] [-i|--|ignored]
[-s|--stage] [-u|--unmerged] [-k|--|killed] [-m|--modified]
[--directory [--no-empty-directory]] [--eol]
[--deduplicate]
[-x &lt;pattern&gt;|--exclude=&lt;pattern&gt;]
[-X &lt;file&gt;|--exclude-from=&lt;file&gt;]
@ -760,7 +760,7 @@ git-ls-files(1) Manual Page
[--exclude-standard]
[--error-unmatch] [--with-tree=&lt;tree-ish&gt;]
[--full-name] [--recurse-submodules]
[--abbrev[=&lt;n&gt;]] [--] [&lt;file&gt;&#8230;]</pre>
[--abbrev[=&lt;n&gt;]] [--format=&lt;format&gt;] [--] [&lt;file&gt;&#8230;]</pre>
<div class="attribution">
</div></div>
</div>
@ -1086,7 +1086,7 @@ other
<dd>
<p>
Recursively calls ls-files on each active submodule in the repository.
Currently there is only support for the --cached mode.
Currently there is only support for the --cached and --stage modes.
</p>
</dd>
<dt class="hdlist1">
@ -1131,6 +1131,29 @@ and in the working tree ("w/&lt;eolinfo&gt;") are shown for regular files,
followed by the ("attr/&lt;eolattr&gt;").</p></div>
</dd>
<dt class="hdlist1">
--sparse
</dt>
<dd>
<p>
If the index is sparse, show the sparse directories without expanding
to the contained files. Sparse directories will be shown with a
trailing slash, such as "x/" for a sparse directory "x".
</p>
</dd>
<dt class="hdlist1">
--format=&lt;format&gt;
</dt>
<dd>
<p>
A string that interpolates <code>%(fieldname)</code> from the result being shown.
It also interpolates <code>%%</code> to <code>%</code>, and <code>%xx</code> where <code>xx</code> are hex digits
interpolates to character with hex code <code>xx</code>; for example <code>%00</code>
interpolates to <code>\0</code> (NUL), <code>%09</code> to <code>\t</code> (TAB) and %0a to <code>\n</code> (LF).
--format cannot be combined with <code>-s</code>, <code>-o</code>, <code>-k</code>, <code>-t</code>, <code>--resolve-undo</code>
and <code>--eol</code>.
</p>
</dd>
<dt class="hdlist1">
--
</dt>
<dd>
@ -1172,6 +1195,79 @@ path. (see <a href="git-read-tree.html">git-read-tree(1)</a> for more informatio
quoted as explained for the configuration variable <code>core.quotePath</code>
(see <a href="git-config.html">git-config(1)</a>). Using <code>-z</code> the filename is output
verbatim and the line is terminated by a NUL byte.</p></div>
<div class="paragraph"><p>It is possible to print in a custom format by using the <code>--format</code>
option, which is able to interpolate different fields using
a <code>%(fieldname)</code> notation. For example, if you only care about the
"objectname" and "path" fields, you can execute with a specific
"--format" like</p></div>
<div class="literalblock">
<div class="content">
<pre><code>git ls-files --format='%(objectname) %(path)'</code></pre>
</div></div>
</div>
</div>
<div class="sect1">
<h2 id="_field_names">FIELD NAMES</h2>
<div class="sectionbody">
<div class="paragraph"><p>The way each path is shown can be customized by using the
<code>--format=&lt;format&gt;</code> option, where the %(fieldname) in the
&lt;format&gt; string for various aspects of the index entry are
interpolated. The following "fieldname" are understood:</p></div>
<div class="dlist"><dl>
<dt class="hdlist1">
objectmode
</dt>
<dd>
<p>
The mode of the file which is recorded in the index.
</p>
</dd>
<dt class="hdlist1">
objectname
</dt>
<dd>
<p>
The name of the file which is recorded in the index.
</p>
</dd>
<dt class="hdlist1">
stage
</dt>
<dd>
<p>
The stage of the file which is recorded in the index.
</p>
</dd>
<dt class="hdlist1">
eolinfo:index
</dt>
<dt class="hdlist1">
eolinfo:worktree
</dt>
<dd>
<p>
The &lt;eolinfo&gt; (see the description of the <code>--eol</code> option) of
the contents in the index or in the worktree for the path.
</p>
</dd>
<dt class="hdlist1">
eolattr
</dt>
<dd>
<p>
The &lt;eolattr&gt; (see the description of the <code>--eol</code> option)
that applies to the path.
</p>
</dd>
<dt class="hdlist1">
path
</dt>
<dd>
<p>
The pathname of the file which is recorded in the index.
</p>
</dd>
</dl></div>
</div>
</div>
<div class="sect1">
@ -1231,7 +1327,7 @@ pattern file appears in.</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2021-11-15 09:20:10 PST
2022-09-16 17:50:33 PDT
</div>
</div>
</body>

@ -945,7 +945,7 @@ c5db5456ae3b0873fc659c19fafdde22313cc441 refs/tags/v0.99.2
<div id="footer">
<div id="footer-text">
Last updated
2021-10-06 09:57:11 PDT
2022-06-28 20:23:28 PDT
</div>
</div>
</body>

@ -750,7 +750,7 @@ git-ls-tree(1) Manual Page
<div class="sectionbody">
<div class="verseblock">
<pre class="content"><em>git ls-tree</em> [-d] [-r] [-t] [-l] [-z]
[--name-only] [--name-status] [--full-name] [--full-tree] [--abbrev[=&lt;n&gt;]]
[--name-only] [--name-status] [--object-only] [--full-name] [--full-tree] [--abbrev[=&lt;n&gt;]] [--format=&lt;format&gt;]
&lt;tree-ish&gt; [&lt;path&gt;&#8230;]</pre>
<div class="attribution">
</div></div>
@ -852,6 +852,20 @@ the behaviour is similar to that of "/bin/ls" in that the <em>&lt;path&gt;</em>
<dd>
<p>
List only filenames (instead of the "long" output), one per line.
Cannot be combined with <code>--object-only</code>.
</p>
</dd>
<dt class="hdlist1">
--object-only
</dt>
<dd>
<p>
List only names of the objects, one per line. Cannot be combined
with <code>--name-only</code> or <code>--name-status</code>.
This is equivalent to specifying <code>--format='%(objectname)'</code>, but
for both this option and that exact format the command takes a
hand-optimized codepath instead of going through the generic
formatting mechanism.
</p>
</dd>
<dt class="hdlist1">
@ -884,6 +898,21 @@ the behaviour is similar to that of "/bin/ls" in that the <em>&lt;path&gt;</em>
</p>
</dd>
<dt class="hdlist1">
--format=&lt;format&gt;
</dt>
<dd>
<p>
A string that interpolates <code>%(fieldname)</code> from the result
being shown. It also interpolates <code>%%</code> to <code>%</code>, and
<code>%xx</code> where <code>xx</code> are hex digits interpolates to character
with hex code <code>xx</code>; for example <code>%00</code> interpolates to
<code>\0</code> (NUL), <code>%09</code> to <code>\t</code> (TAB) and <code>%0a</code> to <code>\n</code> (LF).
When specified, <code>--format</code> cannot be combined with other
format-altering options, including <code>--long</code>, <code>--name-only</code>
and <code>--object-only</code>.
</p>
</dd>
<dt class="hdlist1">
[&lt;path&gt;&#8230;]
</dt>
<dd>
@ -899,24 +928,93 @@ the behaviour is similar to that of "/bin/ls" in that the <em>&lt;path&gt;</em>
<div class="sect1">
<h2 id="_output_format">Output Format</h2>
<div class="sectionbody">
<div class="paragraph"><p>The output format of <code>ls-tree</code> is determined by either the <code>--format</code>
option, or other format-altering options such as <code>--name-only</code> etc.
(see <code>--format</code> above).</p></div>
<div class="paragraph"><p>The use of certain <code>--format</code> directives is equivalent to using those
options, but invoking the full formatting machinery can be slower than
using an appropriate formatting option.</p></div>
<div class="paragraph"><p>In cases where the <code>--format</code> would exactly map to an existing option
<code>ls-tree</code> will use the appropriate faster path. Thus the default format
is equivalent to:</p></div>
<div class="literalblock">
<div class="content">
<pre><code>&lt;mode&gt; SP &lt;type&gt; SP &lt;object&gt; TAB &lt;file&gt;</code></pre>
<pre><code>%(objectmode) %(objecttype) %(objectname)%x09%(path)</code></pre>
</div></div>
<div class="paragraph"><p>This output format is compatible with what <code>--index-info --stdin</code> of
<em>git update-index</em> expects.</p></div>
<div class="paragraph"><p>When the <code>-l</code> option is used, format changes to</p></div>
<div class="literalblock">
<div class="content">
<pre><code>&lt;mode&gt; SP &lt;type&gt; SP &lt;object&gt; SP &lt;object size&gt; TAB &lt;file&gt;</code></pre>
<pre><code>%(objectmode) %(objecttype) %(objectname) %(objectsize:padded)%x09%(path)</code></pre>
</div></div>
<div class="paragraph"><p>Object size identified by &lt;object&gt; is given in bytes, and right-justified
<div class="paragraph"><p>Object size identified by &lt;objectname&gt; is given in bytes, and right-justified
with minimum width of 7 characters. Object size is given only for blobs
(file) entries; for other entries <code>-</code> character is used in place of size.</p></div>
<div class="paragraph"><p>Without the <code>-z</code> option, pathnames with "unusual" characters are
quoted as explained for the configuration variable <code>core.quotePath</code>
(see <a href="git-config.html">git-config(1)</a>). Using <code>-z</code> the filename is output
verbatim and the line is terminated by a NUL byte.</p></div>
<div class="paragraph"><p>Customized format:</p></div>
<div class="paragraph"><p>It is possible to print in a custom format by using the <code>--format</code> option,
which is able to interpolate different fields using a <code>%(fieldname)</code> notation.
For example, if you only care about the "objectname" and "path" fields, you
can execute with a specific "--format" like</p></div>
<div class="literalblock">
<div class="content">
<pre><code>git ls-tree --format='%(objectname) %(path)' &lt;tree-ish&gt;</code></pre>
</div></div>
</div>
</div>
<div class="sect1">
<h2 id="_field_names">FIELD NAMES</h2>
<div class="sectionbody">
<div class="paragraph"><p>Various values from structured fields can be used to interpolate
into the resulting output. For each outputing line, the following
names can be used:</p></div>
<div class="dlist"><dl>
<dt class="hdlist1">
objectmode
</dt>
<dd>
<p>
The mode of the object.
</p>
</dd>
<dt class="hdlist1">
objecttype
</dt>
<dd>
<p>
The type of the object (<code>commit</code>, <code>blob</code> or <code>tree</code>).
</p>
</dd>
<dt class="hdlist1">
objectname
</dt>
<dd>
<p>
The name of the object.
</p>
</dd>
<dt class="hdlist1">
objectsize[:padded]
</dt>
<dd>
<p>
The size of a <code>blob</code> object ("-" if it&#8217;s a <code>commit</code> or <code>tree</code>).
It also supports a padded format of size with "%(objectsize:padded)".
</p>
</dd>
<dt class="hdlist1">
path
</dt>
<dd>
<p>
The pathname of the object.
</p>
</dd>
</dl></div>
</div>
</div>
<div class="sect1">
@ -930,7 +1028,7 @@ verbatim and the line is terminated by a NUL byte.</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2021-10-06 09:57:11 PDT
2022-08-31 14:31:31 PDT
</div>
</div>
</body>

@ -940,6 +940,28 @@ If no such configuration option has been set, <code>warn</code> will be used.</p
</div>
</div>
<div class="sect1">
<h2 id="_configuration">CONFIGURATION</h2>
<div class="sectionbody">
<div class="paragraph"><p>Everything below this line in this section is selectively included
from the <a href="git-config.html">git-config(1)</a> documentation. The content is the same
as what&#8217;s found there:</p></div>
<div class="dlist"><dl>
<dt class="hdlist1">
mailinfo.scissors
</dt>
<dd>
<p>
If true, makes <a href="git-mailinfo.html">git-mailinfo(1)</a> (and therefore
<a href="git-am.html">git-am(1)</a>) act by default as if the --scissors option
was provided on the command-line. When active, this features
removes everything from the message body before a scissors
line (i.e. consisting mainly of "&gt;8", "8&lt;" and "-").
</p>
</dd>
</dl></div>
</div>
</div>
<div class="sect1">
<h2 id="_git">GIT</h2>
<div class="sectionbody">
<div class="paragraph"><p>Part of the <a href="git.html">git(1)</a> suite</p></div>
@ -950,7 +972,7 @@ If no such configuration option has been set, <code>warn</code> will be used.</p
<div id="footer">
<div id="footer-text">
Last updated
2021-10-06 09:57:11 PDT
2022-10-08 14:40:28 PDT
</div>
</div>
</body>

@ -860,7 +860,7 @@ patches in the correct order.</td>
<div id="footer">
<div id="footer-text">
Last updated
2018-06-15 19:46:24 PDT
2022-01-27 18:10:56 PST
</div>
</div>
</body>

@ -749,7 +749,9 @@ git-maintenance(1) Manual Page
<h2 id="_synopsis">SYNOPSIS</h2>
<div class="sectionbody">
<div class="verseblock">
<pre class="content"><em>git maintenance</em> run [&lt;options&gt;]</pre>
<pre class="content"><em>git maintenance</em> run [&lt;options&gt;]
<em>git maintenance</em> start [--scheduler=&lt;scheduler&gt;]
<em>git maintenance</em> (stop|register|unregister)</pre>
<div class="attribution">
</div></div>
</div>
@ -773,6 +775,39 @@ Git repository.</p></div>
<div class="sectionbody">
<div class="dlist"><dl>
<dt class="hdlist1">
run
</dt>
<dd>
<p>
Run one or more maintenance tasks. If one or more <code>--task</code> options
are specified, then those tasks are run in that order. Otherwise,
the tasks are determined by which <code>maintenance.&lt;task&gt;.enabled</code>
config options are true. By default, only <code>maintenance.gc.enabled</code>
is true.
</p>
</dd>
<dt class="hdlist1">
start
</dt>
<dd>
<p>
Start running maintenance on the current repository. This performs
the same config updates as the <code>register</code> subcommand, then updates
the background scheduler to run <code>git maintenance run --scheduled</code>
on an hourly basis.
</p>
</dd>
<dt class="hdlist1">
stop
</dt>
<dd>
<p>
Halt the background maintenance schedule. The current repository
is not removed from the list of maintained repositories, in case
the background maintenance is restarted later.
</p>
</dd>
<dt class="hdlist1">
register
</dt>
<dd>
@ -824,39 +859,6 @@ setting <code>maintenance.auto = false</code> in the current repository. This co
setting will remain after a <code>git maintenance unregister</code> command.</p></div>
</dd>
<dt class="hdlist1">
run
</dt>
<dd>
<p>
Run one or more maintenance tasks. If one or more <code>--task</code> options
are specified, then those tasks are run in that order. Otherwise,
the tasks are determined by which <code>maintenance.&lt;task&gt;.enabled</code>
config options are true. By default, only <code>maintenance.gc.enabled</code>
is true.
</p>
</dd>
<dt class="hdlist1">
start
</dt>
<dd>
<p>
Start running maintenance on the current repository. This performs
the same config updates as the <code>register</code> subcommand, then updates
the background scheduler to run <code>git maintenance run --scheduled</code>
on an hourly basis.
</p>
</dd>
<dt class="hdlist1">
stop
</dt>
<dd>
<p>
Halt the background maintenance schedule. The current repository
is not removed from the list of maintained repositories, in case
the background maintenance is restarted later.
</p>
</dd>
<dt class="hdlist1">
unregister
</dt>
<dd>
@ -1229,6 +1231,121 @@ custom tasks.</p></div>
</div>
</div>
<div class="sect1">
<h2 id="_configuration">CONFIGURATION</h2>
<div class="sectionbody">
<div class="paragraph"><p>Everything below this line in this section is selectively included
from the <a href="git-config.html">git-config(1)</a> documentation. The content is the same
as what&#8217;s found there:</p></div>
<div class="dlist"><dl>
<dt class="hdlist1">
maintenance.auto
</dt>
<dd>
<p>
This boolean config option controls whether some commands run
<code>git maintenance run --auto</code> after doing their normal work. Defaults
to true.
</p>
</dd>
<dt class="hdlist1">
maintenance.strategy
</dt>
<dd>
<p>
This string config option provides a way to specify one of a few
recommended schedules for background maintenance. This only affects
which tasks are run during <code>git maintenance run --schedule=X</code>
commands, provided no <code>--task=&lt;task&gt;</code> arguments are provided.
Further, if a <code>maintenance.&lt;task&gt;.schedule</code> config value is set,
then that value is used instead of the one provided by
<code>maintenance.strategy</code>. The possible strategy strings are:
</p>
<div class="ulist"><ul>
<li>
<p>
<code>none</code>: This default setting implies no task are run at any schedule.
</p>
</li>
<li>
<p>
<code>incremental</code>: This setting optimizes for performing small maintenance
activities that do not delete any data. This does not schedule the <code>gc</code>
task, but runs the <code>prefetch</code> and <code>commit-graph</code> tasks hourly, the
<code>loose-objects</code> and <code>incremental-repack</code> tasks daily, and the <code>pack-refs</code>
task weekly.
</p>
</li>
</ul></div>
</dd>
<dt class="hdlist1">
maintenance.&lt;task&gt;.enabled
</dt>
<dd>
<p>
This boolean config option controls whether the maintenance task
with name <code>&lt;task&gt;</code> is run when no <code>--task</code> option is specified to
<code>git maintenance run</code>. These config values are ignored if a
<code>--task</code> option exists. By default, only <code>maintenance.gc.enabled</code>
is true.
</p>
</dd>
<dt class="hdlist1">
maintenance.&lt;task&gt;.schedule
</dt>
<dd>
<p>
This config option controls whether or not the given <code>&lt;task&gt;</code> runs
during a <code>git maintenance run --schedule=&lt;frequency&gt;</code> command. The
value must be one of "hourly", "daily", or "weekly".
</p>
</dd>
<dt class="hdlist1">
maintenance.commit-graph.auto
</dt>
<dd>
<p>
This integer config option controls how often the <code>commit-graph</code> task
should be run as part of <code>git maintenance run --auto</code>. If zero, then
the <code>commit-graph</code> task will not run with the <code>--auto</code> option. A
negative value will force the task to run every time. Otherwise, a
positive value implies the command should run when the number of
reachable commits that are not in the commit-graph file is at least
the value of <code>maintenance.commit-graph.auto</code>. The default value is
100.
</p>
</dd>
<dt class="hdlist1">
maintenance.loose-objects.auto
</dt>
<dd>
<p>
This integer config option controls how often the <code>loose-objects</code> task
should be run as part of <code>git maintenance run --auto</code>. If zero, then
the <code>loose-objects</code> task will not run with the <code>--auto</code> option. A
negative value will force the task to run every time. Otherwise, a
positive value implies the command should run when the number of
loose objects is at least the value of <code>maintenance.loose-objects.auto</code>.
The default value is 100.
</p>
</dd>
<dt class="hdlist1">
maintenance.incremental-repack.auto
</dt>
<dd>
<p>
This integer config option controls how often the <code>incremental-repack</code>
task should be run as part of <code>git maintenance run --auto</code>. If zero,
then the <code>incremental-repack</code> task will not run with the <code>--auto</code>
option. A negative value will force the task to run every time.
Otherwise, a positive value implies the command should run when the
number of pack-files not in the multi-pack-index is at least the value
of <code>maintenance.incremental-repack.auto</code>. The default value is 10.
</p>
</dd>
</dl></div>
</div>
</div>
<div class="sect1">
<h2 id="_git">GIT</h2>
<div class="sectionbody">
<div class="paragraph"><p>Part of the <a href="git.html">git(1)</a> suite</p></div>
@ -1239,7 +1356,7 @@ custom tasks.</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2021-11-15 13:27:01 PST
2022-10-08 14:40:28 PDT
</div>
</div>
</body>

@ -1017,7 +1017,7 @@ commits that used to be at the tip of origin/master).</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2021-09-30 23:04:56 PDT
2022-06-28 20:23:28 PDT
</div>
</div>
</body>

@ -833,6 +833,14 @@ implements all of RCS <em>merge</em>'s functionality which is needed by
</p>
</dd>
<dt class="hdlist1">
--zdiff3
</dt>
<dd>
<p>
Show conflicts in "zdiff3" style.
</p>
</dd>
<dt class="hdlist1">
--ours
</dt>
<dt class="hdlist1">
@ -886,7 +894,7 @@ implements all of RCS <em>merge</em>'s functionality which is needed by
<div id="footer">
<div id="footer-text">
Last updated
2021-11-15 13:27:01 PST
2022-06-28 20:23:28 PDT
</div>
</div>
</body>

@ -749,7 +749,7 @@ git-merge-index(1) Manual Page
<h2 id="_synopsis">SYNOPSIS</h2>
<div class="sectionbody">
<div class="verseblock">
<pre class="content"><em>git merge-index</em> [-o] [-q] &lt;merge-program&gt; (-a | [--] &lt;file&gt;*)</pre>
<pre class="content"><em>git merge-index</em> [-o] [-q] &lt;merge-program&gt; (-a | ( [--] &lt;file&gt;&#8230;) )</pre>
<div class="attribution">
</div></div>
</div>
@ -852,7 +852,7 @@ for the AA file, because it didn&#8217;t exist in the original, and thus
<div id="footer">
<div id="footer-text">
Last updated
2021-11-15 09:20:10 PST
2022-08-25 09:55:18 PDT
</div>
</div>
</body>

@ -772,7 +772,7 @@ to resolve a merge after the trivial merge done with <em>git read-tree -m</em>.<
<div id="footer">
<div id="footer-text">
Last updated
2017-12-22 18:32:40 PST
2022-01-27 18:10:56 PST
</div>
</div>
</body>

@ -740,7 +740,7 @@ git-merge-tree(1) Manual Page
<h2>NAME</h2>
<div class="sectionbody">
<p>git-merge-tree -
Show three-way merge without touching index
Perform merge without touching index or working tree
</p>
</div>
</div>
@ -749,23 +749,296 @@ git-merge-tree(1) Manual Page
<h2 id="_synopsis">SYNOPSIS</h2>
<div class="sectionbody">
<div class="verseblock">
<pre class="content"><em>git merge-tree</em> &lt;base-tree&gt; &lt;branch1&gt; &lt;branch2&gt;</pre>
<pre class="content"><em>git merge-tree</em> [--write-tree] [&lt;options&gt;] &lt;branch1&gt; &lt;branch2&gt;
<em>git merge-tree</em> [--trivial-merge] &lt;base-tree&gt; &lt;branch1&gt; &lt;branch2&gt; (deprecated)</pre>
<div class="attribution">
</div></div>
</div>
</div>
<div class="sect1">
<h2 id="_description">DESCRIPTION</h2>
<h2 id="NEWMERGE">DESCRIPTION</h2>
<div class="sectionbody">
<div class="paragraph"><p>Reads three tree-ish, and output trivial merge results and
conflicting stages to the standard output. This is similar to
what three-way <em>git read-tree -m</em> does, but instead of storing the
results in the index, the command outputs the entries to the
standard output.</p></div>
<div class="paragraph"><p>This is meant to be used by higher level scripts to compute
merge results outside of the index, and stuff the results back into the
index. For this reason, the output from the command omits
entries that match the &lt;branch1&gt; tree.</p></div>
<div class="paragraph"><p>This command has a modern <code>--write-tree</code> mode and a deprecated
<code>--trivial-merge</code> mode. With the exception of the
<a href="#DEPMERGE">DEPRECATED DESCRIPTION</a> section at the end, the rest of
this documentation describes modern <code>--write-tree</code> mode.</p></div>
<div class="paragraph"><p>Performs a merge, but does not make any new commits and does not read
from or write to either the working tree or index.</p></div>
<div class="paragraph"><p>The performed merge will use the same feature as the "real"
<a href="git-merge.html">git-merge(1)</a>, including:</p></div>
<div class="ulist"><ul>
<li>
<p>
three way content merges of individual files
</p>
</li>
<li>
<p>
rename detection
</p>
</li>
<li>
<p>
proper directory/file conflict handling
</p>
</li>
<li>
<p>
recursive ancestor consolidation (i.e. when there is more than one
merge base, creating a virtual merge base by merging the merge bases)
</p>
</li>
<li>
<p>
etc.
</p>
</li>
</ul></div>
<div class="paragraph"><p>After the merge completes, a new toplevel tree object is created. See
<code>OUTPUT</code> below for details.</p></div>
</div>
</div>
<div class="sect1">
<h2 id="_options">OPTIONS</h2>
<div class="sectionbody">
<div class="dlist"><dl>
<dt class="hdlist1">
-z
</dt>
<dd>
<p>
Do not quote filenames in the &lt;Conflicted file info&gt; section,
and end each filename with a NUL character rather than
newline. Also begin the messages section with a NUL character
instead of a newline. See <a href="#OUTPUT">[OUTPUT]</a> below for more information.
</p>
</dd>
<dt class="hdlist1">
--name-only
</dt>
<dd>
<p>
In the Conflicted file info section, instead of writing a list
of (mode, oid, stage, path) tuples to output for conflicted
files, just provide a list of filenames with conflicts (and
do not list filenames multiple times if they have multiple
conflicting stages).
</p>
</dd>
<dt class="hdlist1">
--[no-]messages
</dt>
<dd>
<p>
Write any informational messages such as "Auto-merging &lt;path&gt;"
or CONFLICT notices to the end of stdout. If unspecified, the
default is to include these messages if there are merge
conflicts, and to omit them otherwise.
</p>
</dd>
<dt class="hdlist1">
--allow-unrelated-histories
</dt>
<dd>
<p>
merge-tree will by default error out if the two branches specified
share no common history. This flag can be given to override that
check and make the merge proceed anyway.
</p>
</dd>
</dl></div>
</div>
</div>
<div class="sect1">
<h2 id="OUTPUT">OUTPUT</h2>
<div class="sectionbody">
<div class="paragraph"><p>For a successful merge, the output from git-merge-tree is simply one
line:</p></div>
<div class="literalblock">
<div class="content">
<pre><code>&lt;OID of toplevel tree&gt;</code></pre>
</div></div>
<div class="paragraph"><p>Whereas for a conflicted merge, the output is by default of the form:</p></div>
<div class="literalblock">
<div class="content">
<pre><code>&lt;OID of toplevel tree&gt;
&lt;Conflicted file info&gt;
&lt;Informational messages&gt;</code></pre>
</div></div>
<div class="paragraph"><p>These are discussed individually below.</p></div>
<div class="sect2">
<h3 id="OIDTLT">OID of toplevel tree</h3>
<div class="paragraph"><p>This is a tree object that represents what would be checked out in the
working tree at the end of <code>git merge</code>. If there were conflicts, then
files within this tree may have embedded conflict markers. This section
is always followed by a newline (or NUL if <code>-z</code> is passed).</p></div>
</div>
<div class="sect2">
<h3 id="CFI">Conflicted file info</h3>
<div class="paragraph"><p>This is a sequence of lines with the format</p></div>
<div class="literalblock">
<div class="content">
<pre><code>&lt;mode&gt; &lt;object&gt; &lt;stage&gt; &lt;filename&gt;</code></pre>
</div></div>
<div class="paragraph"><p>The filename will be quoted as explained for the configuration
variable <code>core.quotePath</code> (see <a href="git-config.html">git-config(1)</a>). However, if
the <code>--name-only</code> option is passed, the mode, object, and stage will
be omitted. If <code>-z</code> is passed, the "lines" are terminated by a NUL
character instead of a newline character.</p></div>
</div>
<div class="sect2">
<h3 id="IM">Informational messages</h3>
<div class="paragraph"><p>This always starts with a blank line (or NUL if <code>-z</code> is passed) to
separate it from the previous sections, and then has free-form
messages about the merge, such as:</p></div>
<div class="ulist"><ul>
<li>
<p>
"Auto-merging &lt;file&gt;"
</p>
</li>
<li>
<p>
"CONFLICT (rename/delete): &lt;oldfile&gt; renamed&#8230;but deleted in&#8230;"
</p>
</li>
<li>
<p>
"Failed to merge submodule &lt;submodule&gt; (&lt;reason&gt;)"
</p>
</li>
<li>
<p>
"Warning: cannot merge binary files: &lt;filename&gt;"
</p>
</li>
</ul></div>
<div class="paragraph"><p>Note that these free-form messages will never have a NUL character
in or between them, even if -z is passed. It is simply a large block
of text taking up the remainder of the output.</p></div>
</div>
</div>
</div>
<div class="sect1">
<h2 id="_exit_status">EXIT STATUS</h2>
<div class="sectionbody">
<div class="paragraph"><p>For a successful, non-conflicted merge, the exit status is 0. When the
merge has conflicts, the exit status is 1. If the merge is not able to
complete (or start) due to some kind of error, the exit status is
something other than 0 or 1 (and the output is unspecified).</p></div>
</div>
</div>
<div class="sect1">
<h2 id="_usage_notes">USAGE NOTES</h2>
<div class="sectionbody">
<div class="paragraph"><p>This command is intended as low-level plumbing, similar to
<a href="git-hash-object.html">git-hash-object(1)</a>, <a href="git-mktree.html">git-mktree(1)</a>,
<a href="git-commit-tree.html">git-commit-tree(1)</a>, <a href="git-write-tree.html">git-write-tree(1)</a>,
<a href="git-update-ref.html">git-update-ref(1)</a>, and <a href="git-mktag.html">git-mktag(1)</a>. Thus, it can be
used as a part of a series of steps such as:</p></div>
<div class="literalblock">
<div class="content">
<pre><code>NEWTREE=$(git merge-tree --write-tree $BRANCH1 $BRANCH2)
test $? -eq 0 || die "There were conflicts..."
NEWCOMMIT=$(git commit-tree $NEWTREE -p $BRANCH1 -p $BRANCH2)
git update-ref $BRANCH1 $NEWCOMMIT</code></pre>
</div></div>
<div class="paragraph"><p>Note that when the exit status is non-zero, <code>NEWTREE</code> in this sequence
will contain a lot more output than just a tree.</p></div>
<div class="paragraph"><p>For conflicts, the output includes the same information that you&#8217;d get
with <a href="git-merge.html">git-merge(1)</a>:</p></div>
<div class="ulist"><ul>
<li>
<p>
what would be written to the working tree (the
<a href="#OIDTLT">OID of toplevel tree</a>)
</p>
</li>
<li>
<p>
the higher order stages that would be written to the index (the
<a href="#CFI">Conflicted file info</a>)
</p>
</li>
<li>
<p>
any messages that would have been printed to stdout (the
<a href="#IM">Informational messages</a>)
</p>
</li>
</ul></div>
</div>
</div>
<div class="sect1">
<h2 id="_mistakes_to_avoid">MISTAKES TO AVOID</h2>
<div class="sectionbody">
<div class="paragraph"><p>Do NOT look through the resulting toplevel tree to try to find which
files conflict; parse the <a href="#CFI">Conflicted file info</a> section instead.
Not only would parsing an entire tree be horrendously slow in large
repositories, there are numerous types of conflicts not representable by
conflict markers (modify/delete, mode conflict, binary file changed on
both sides, file/directory conflicts, various rename conflict
permutations, etc.)</p></div>
<div class="paragraph"><p>Do NOT interpret an empty <a href="#CFI">Conflicted file info</a> list as a clean
merge; check the exit status. A merge can have conflicts without having
individual files conflict (there are a few types of directory rename
conflicts that fall into this category, and others might also be added
in the future).</p></div>
<div class="paragraph"><p>Do NOT attempt to guess or make the user guess the conflict types from
the <a href="#CFI">Conflicted file info</a> list. The information there is
insufficient to do so. For example: Rename/rename(1to2) conflicts (both
sides renamed the same file differently) will result in three different
file having higher order stages (but each only has one higher order
stage), with no way (short of the <a href="#IM">Informational messages</a> section)
to determine which three files are related. File/directory conflicts
also result in a file with exactly one higher order stage.
Possibly-involved-in-directory-rename conflicts (when
"merge.directoryRenames" is unset or set to "conflicts") also result in
a file with exactly one higher order stage. In all cases, the
<a href="#IM">Informational messages</a> section has the necessary info, though it
is not designed to be machine parseable.</p></div>
<div class="paragraph"><p>Do NOT assume that each paths from <a href="#CFI">Conflicted file info</a>, and
the logical conflicts in the <a href="#IM">Informational messages</a> have a
one-to-one mapping, nor that there is a one-to-many mapping, nor a
many-to-one mapping. Many-to-many mappings exist, meaning that each
path can have many logical conflict types in a single merge, and each
logical conflict type can affect many paths.</p></div>
<div class="paragraph"><p>Do NOT assume all filenames listed in the <a href="#IM">Informational messages</a>
section had conflicts. Messages can be included for files that have no
conflicts, such as "Auto-merging &lt;file&gt;".</p></div>
<div class="paragraph"><p>AVOID taking the OIDS from the <a href="#CFI">Conflicted file info</a> and
re-merging them to present the conflicts to the user. This will lose
information. Instead, look up the version of the file found within the
<a href="#OIDTLT">OID of toplevel tree</a> and show that instead. In particular,
the latter will have conflict markers annotated with the original
branch/commit being merged and, if renames were involved, the original
filename. While you could include the original branch/commit in the
conflict marker annotations when re-merging, the original filename is
not available from the <a href="#CFI">Conflicted file info</a> and thus you would
be losing information that might help the user resolve the conflict.</p></div>
</div>
</div>
<div class="sect1">
<h2 id="DEPMERGE">DEPRECATED DESCRIPTION</h2>
<div class="sectionbody">
<div class="paragraph"><p>Per the <a href="#NEWMERGE">DESCRIPTION</a> and unlike the rest of this
documentation, this section describes the deprecated <code>--trivial-merge</code>
mode.</p></div>
<div class="paragraph"><p>Other than the optional <code>--trivial-merge</code>, this mode accepts no
options.</p></div>
<div class="paragraph"><p>This mode reads three tree-ish, and outputs trivial merge results and
conflicting stages to the standard output in a semi-diff format.
Since this was designed for higher level scripts to consume and merge
the results back into the index, it omits entries that match
&lt;branch1&gt;. The result of this second form is similar to what
three-way <em>git read-tree -m</em> does, but instead of storing the results
in the index, the command outputs the entries to the standard output.</p></div>
<div class="paragraph"><p>This form not only has limited applicability (a trivial merge cannot
handle content merges of individual files, rename detection, proper
directory/file conflict handling, etc.), the output format is also
difficult to work with, and it will generally be less performant than
the first form even on successful merges (especially if working in
large repositories).</p></div>
</div>
</div>
<div class="sect1">
@ -779,7 +1052,7 @@ entries that match the &lt;branch1&gt; tree.</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2017-12-22 18:32:40 PST
2022-09-21 11:12:12 PDT
</div>
</div>
</body>

@ -752,7 +752,8 @@ git-merge(1) Manual Page
<pre class="content"><em>git merge</em> [-n] [--stat] [--no-commit] [--squash] [--[no-]edit]
[--no-verify] [-s &lt;strategy&gt;] [-X &lt;strategy-option&gt;] [-S[&lt;keyid&gt;]]
[--[no-]allow-unrelated-histories]
[--[no-]rerere-autoupdate] [-m &lt;msg&gt;] [-F &lt;file&gt;] [&lt;commit&gt;&#8230;]
[--[no-]rerere-autoupdate] [-m &lt;msg&gt;] [-F &lt;file&gt;]
[--into-name &lt;branch&gt;] [&lt;commit&gt;&#8230;]
<em>git merge</em> (--continue | --abort | --quit)</pre>
<div class="attribution">
</div></div>
@ -1122,6 +1123,16 @@ used to give a good default for automated <em>git merge</em>
invocations. The automated message can include the branch description.</p></div>
</dd>
<dt class="hdlist1">
--into-name &lt;branch&gt;
</dt>
<dd>
<p>
Prepare the default merge message as if merging to the branch
<code>&lt;branch&gt;</code>, instead of the name of the real branch to which
the merge is made.
</p>
</dd>
<dt class="hdlist1">
-F &lt;file&gt;
</dt>
<dt class="hdlist1">
@ -1143,8 +1154,13 @@ will be appended to the specified message.</p></div>
</dt>
<dd>
<p>
Allow the rerere mechanism to update the index with the
result of auto-conflict resolution if possible.
After the rerere mechanism reuses a recorded resolution on
the current conflict to update the files in the working
tree, allow it to also update the index with the result of
resolution. <code>--no-rerere-autoupdate</code> is a good way to
double-check what <code>rerere</code> did and catch potential
mismerges, before committing the result to the index with a
separate <code>git add</code>.
</p>
</dd>
<dt class="hdlist1">
@ -1338,7 +1354,8 @@ from the RCS suite to present such a conflicted hunk, like this:</p></div>
<div class="listingblock">
<div class="content">
<pre><code>Here are lines that are either unchanged from the common
ancestor, or cleanly resolved because only one side changed.
ancestor, or cleanly resolved because only one side changed,
or cleanly resolved because both sides changed the same way.
&lt;&lt;&lt;&lt;&lt;&lt;&lt; yours:sample.txt
Conflict resolution is hard;
let's go shopping.
@ -1356,16 +1373,36 @@ Barbie&#8217;s remark on your side. The only thing you can tell is that your
side wants to say it is hard and you&#8217;d prefer to go shopping, while the
other side wants to claim it is easy.</p></div>
<div class="paragraph"><p>An alternative style can be used by setting the "merge.conflictStyle"
configuration variable to "diff3". In "diff3" style, the above conflict
may look like this:</p></div>
configuration variable to either "diff3" or "zdiff3". In "diff3"
style, the above conflict may look like this:</p></div>
<div class="listingblock">
<div class="content">
<pre><code>Here are lines that are either unchanged from the common
ancestor, or cleanly resolved because only one side changed.
ancestor, or cleanly resolved because only one side changed,
&lt;&lt;&lt;&lt;&lt;&lt;&lt; yours:sample.txt
or cleanly resolved because both sides changed the same way.
Conflict resolution is hard;
let's go shopping.
|||||||
||||||| base:sample.txt
or cleanly resolved because both sides changed identically.
Conflict resolution is hard.
=======
or cleanly resolved because both sides changed the same way.
Git makes conflict resolution easy.
&gt;&gt;&gt;&gt;&gt;&gt;&gt; theirs:sample.txt
And here is another line that is cleanly resolved or unmodified.</code></pre>
</div></div>
<div class="paragraph"><p>while in "zdiff3" style, it may look like this:</p></div>
<div class="listingblock">
<div class="content">
<pre><code>Here are lines that are either unchanged from the common
ancestor, or cleanly resolved because only one side changed,
or cleanly resolved because both sides changed the same way.
&lt;&lt;&lt;&lt;&lt;&lt;&lt; yours:sample.txt
Conflict resolution is hard;
let's go shopping.
||||||| base:sample.txt
or cleanly resolved because both sides changed identically.
Conflict resolution is hard.
=======
Git makes conflict resolution easy.
@ -1745,6 +1782,21 @@ substitutes the changed version instead.</p></div>
<div class="sectionbody">
<div class="dlist"><dl>
<dt class="hdlist1">
branch.&lt;name&gt;.mergeOptions
</dt>
<dd>
<p>
Sets default options for merging into branch &lt;name&gt;. The syntax and
supported options are the same as those of <em>git merge</em>, but option
values containing whitespace characters are currently not supported.
</p>
</dd>
</dl></div>
<div class="paragraph"><p>Everything above this line in this section isn&#8217;t included from the
<a href="git-config.html">git-config(1)</a> documentation. The content that follows is the
same as what&#8217;s found there:</p></div>
<div class="dlist"><dl>
<dt class="hdlist1">
merge.conflictStyle
</dt>
<dd>
@ -1754,7 +1806,14 @@ merge.conflictStyle
shows a <code>&lt;&lt;&lt;&lt;&lt;&lt;&lt;</code> conflict marker, changes made by one side,
a <code>=======</code> marker, changes made by the other side, and then
a <code>&gt;&gt;&gt;&gt;&gt;&gt;&gt;</code> marker. An alternate style, "diff3", adds a <code>|||||||</code>
marker and the original text before the <code>=======</code> marker.
marker and the original text before the <code>=======</code> marker. The
"merge" style tends to produce smaller conflict regions than diff3,
both because of the exclusion of the original text, and because
when a subset of lines match on the two sides they are just pulled
out of the conflict region. Another alternate style, "zdiff3", is
similar to diff3 but removes matching lines on the two sides from
the conflict region when those matching lines appear near either
the beginning or end of a conflict region.
</p>
</dd>
<dt class="hdlist1">
@ -1934,173 +1993,272 @@ merge.guitool
Any other value is treated as a custom merge tool and requires that a
corresponding mergetool.&lt;guitool&gt;.cmd variable is defined.
</p>
<div class="ulist"><ul>
<li>
<div class="dlist"><dl>
<dt class="hdlist1">
<code>araxis</code>
</dt>
<dd>
<p>
araxis
Use Araxis Merge (requires a graphical session)
</p>
</li>
<li>
</dd>
<dt class="hdlist1">
<code>bc</code>
</dt>
<dd>
<p>
bc
Use Beyond Compare (requires a graphical session)
</p>
</li>
<li>
</dd>
<dt class="hdlist1">
<code>bc3</code>
</dt>
<dd>
<p>
bc3
Use Beyond Compare (requires a graphical session)
</p>
</li>
<li>
</dd>
<dt class="hdlist1">
<code>bc4</code>
</dt>
<dd>
<p>
bc4
Use Beyond Compare (requires a graphical session)
</p>
</li>
<li>
</dd>
<dt class="hdlist1">
<code>codecompare</code>
</dt>
<dd>
<p>
codecompare
Use Code Compare (requires a graphical session)
</p>
</li>
<li>
</dd>
<dt class="hdlist1">
<code>deltawalker</code>
</dt>
<dd>
<p>
deltawalker
Use DeltaWalker (requires a graphical session)
</p>
</li>
<li>
</dd>
<dt class="hdlist1">
<code>diffmerge</code>
</dt>
<dd>
<p>
diffmerge
Use DiffMerge (requires a graphical session)
</p>
</li>
<li>
</dd>
<dt class="hdlist1">
<code>diffuse</code>
</dt>
<dd>
<p>
diffuse
Use Diffuse (requires a graphical session)
</p>
</li>
<li>
</dd>
<dt class="hdlist1">
<code>ecmerge</code>
</dt>
<dd>
<p>
ecmerge
Use ECMerge (requires a graphical session)
</p>
</li>
<li>
</dd>
<dt class="hdlist1">
<code>emerge</code>
</dt>
<dd>
<p>
emerge
Use Emacs' Emerge
</p>
</li>
<li>
</dd>
<dt class="hdlist1">
<code>examdiff</code>
</dt>
<dd>
<p>
examdiff
Use ExamDiff Pro (requires a graphical session)
</p>
</li>
<li>
</dd>
<dt class="hdlist1">
<code>guiffy</code>
</dt>
<dd>
<p>
guiffy
Use Guiffy&#8217;s Diff Tool (requires a graphical session)
</p>
</li>
<li>
</dd>
<dt class="hdlist1">
<code>gvimdiff</code>
</dt>
<dd>
<p>
gvimdiff
Use gVim (requires a graphical session) with a custom layout (see <code>git help mergetool</code>'s <code>BACKEND SPECIFIC HINTS</code> section)
</p>
</li>
<li>
</dd>
<dt class="hdlist1">
<code>gvimdiff1</code>
</dt>
<dd>
<p>
gvimdiff1
Use gVim (requires a graphical session) with a 2 panes layout (LOCAL and REMOTE)
</p>
</li>
<li>
</dd>
<dt class="hdlist1">
<code>gvimdiff2</code>
</dt>
<dd>
<p>
gvimdiff2
Use gVim (requires a graphical session) with a 3 panes layout (LOCAL, MERGED and REMOTE)
</p>
</li>
<li>
</dd>
<dt class="hdlist1">
<code>gvimdiff3</code>
</dt>
<dd>
<p>
gvimdiff3
Use gVim (requires a graphical session) where only the MERGED file is shown
</p>
</li>
<li>
</dd>
<dt class="hdlist1">
<code>kdiff3</code>
</dt>
<dd>
<p>
kdiff3
Use KDiff3 (requires a graphical session)
</p>
</li>
<li>
</dd>
<dt class="hdlist1">
<code>meld</code>
</dt>
<dd>
<p>
meld
Use Meld (requires a graphical session) with optional <code>auto merge</code> (see <code>git help mergetool</code>'s <code>CONFIGURATION</code> section)
</p>
</li>
<li>
</dd>
<dt class="hdlist1">
<code>nvimdiff</code>
</dt>
<dd>
<p>
nvimdiff
Use Neovim with a custom layout (see <code>git help mergetool</code>'s <code>BACKEND SPECIFIC HINTS</code> section)
</p>
</li>
<li>
</dd>
<dt class="hdlist1">
<code>nvimdiff1</code>
</dt>
<dd>
<p>
nvimdiff1
Use Neovim with a 2 panes layout (LOCAL and REMOTE)
</p>
</li>
<li>
</dd>
<dt class="hdlist1">
<code>nvimdiff2</code>
</dt>
<dd>
<p>
nvimdiff2
Use Neovim with a 3 panes layout (LOCAL, MERGED and REMOTE)
</p>
</li>
<li>
</dd>
<dt class="hdlist1">
<code>nvimdiff3</code>
</dt>
<dd>
<p>
nvimdiff3
Use Neovim where only the MERGED file is shown
</p>
</li>
<li>
</dd>
<dt class="hdlist1">
<code>opendiff</code>
</dt>
<dd>
<p>
opendiff
Use FileMerge (requires a graphical session)
</p>
</li>
<li>
</dd>
<dt class="hdlist1">
<code>p4merge</code>
</dt>
<dd>
<p>
p4merge
Use HelixCore P4Merge (requires a graphical session)
</p>
</li>
<li>
</dd>
<dt class="hdlist1">
<code>smerge</code>
</dt>
<dd>
<p>
smerge
Use Sublime Merge (requires a graphical session)
</p>
</li>
<li>
</dd>
<dt class="hdlist1">
<code>tkdiff</code>
</dt>
<dd>
<p>
tkdiff
Use TkDiff (requires a graphical session)
</p>
</li>
<li>
</dd>
<dt class="hdlist1">
<code>tortoisemerge</code>
</dt>
<dd>
<p>
tortoisemerge
Use TortoiseMerge (requires a graphical session)
</p>
</li>
<li>
</dd>
<dt class="hdlist1">
<code>vimdiff</code>
</dt>
<dd>
<p>
vimdiff
Use Vim with a custom layout (see <code>git help mergetool</code>'s <code>BACKEND SPECIFIC HINTS</code> section)
</p>
</li>
<li>
</dd>
<dt class="hdlist1">
<code>vimdiff1</code>
</dt>
<dd>
<p>
vimdiff1
Use Vim with a 2 panes layout (LOCAL and REMOTE)
</p>
</li>
<li>
</dd>
<dt class="hdlist1">
<code>vimdiff2</code>
</dt>
<dd>
<p>
vimdiff2
Use Vim with a 3 panes layout (LOCAL, MERGED and REMOTE)
</p>
</li>
<li>
</dd>
<dt class="hdlist1">
<code>vimdiff3</code>
</dt>
<dd>
<p>
vimdiff3
Use Vim where only the MERGED file is shown
</p>
</li>
<li>
</dd>
<dt class="hdlist1">
<code>winmerge</code>
</dt>
<dd>
<p>
winmerge
Use WinMerge (requires a graphical session)
</p>
</li>
<li>
</dd>
<dt class="hdlist1">
<code>xxdiff</code>
</dt>
<dd>
<p>
xxdiff
Use xxdiff (requires a graphical session)
</p>
</li>
</ul></div>
</dd>
</dl></div>
</dd>
<dt class="hdlist1">
merge.verbosity
@ -2143,16 +2301,6 @@ merge.&lt;driver&gt;.recursive
See <a href="gitattributes.html">gitattributes(5)</a> for details.
</p>
</dd>
<dt class="hdlist1">
branch.&lt;name&gt;.mergeOptions
</dt>
<dd>
<p>
Sets default options for merging into branch &lt;name&gt;. The syntax and
supported options are the same as those of <em>git merge</em>, but option
values containing whitespace characters are currently not supported.
</p>
</dd>
</dl></div>
</div>
</div>
@ -2178,7 +2326,7 @@ branch.&lt;name&gt;.mergeOptions
<div id="footer">
<div id="footer-text">
Last updated
2021-11-15 13:27:01 PST
2022-10-08 14:40:28 PDT
</div>
</div>
</body>

@ -832,7 +832,7 @@ run_merge_tool
<div id="footer">
<div id="footer-text">
Last updated
2021-10-06 09:57:11 PDT
2022-06-28 20:23:28 PDT
</div>
</div>
</body>

@ -887,6 +887,9 @@ success of the resolution after the custom tool has exited.</p></div>
<div class="sect1">
<h2 id="_configuration">CONFIGURATION</h2>
<div class="sectionbody">
<div class="paragraph"><p>Everything below this line in this section is selectively included
from the <a href="git-config.html">git-config(1)</a> documentation. The content is the same
as what&#8217;s found there:</p></div>
<div class="dlist"><dl>
<dt class="hdlist1">
mergetool.&lt;tool&gt;.path
@ -966,6 +969,17 @@ mergetool.meld.useAutoMerge
</p>
</dd>
<dt class="hdlist1">
mergetool.vimdiff.layout
</dt>
<dd>
<p>
The vimdiff backend uses this variable to control how its split
windows look like. Applies even if you are using Neovim (<code>nvim</code>) or
gVim (<code>gvim</code>) as the merge tool. See BACKEND SPECIFIC HINTS section
for details.
</p>
</dd>
<dt class="hdlist1">
mergetool.hideResolved
</dt>
<dd>
@ -1037,6 +1051,274 @@ are successfully merged.</p></div>
</div>
</div>
<div class="sect1">
<h2 id="_backend_specific_hints">BACKEND SPECIFIC HINTS</h2>
<div class="sectionbody">
<div class="sect2">
<h3 id="_vimdiff">vimdiff</h3>
<div class="sect3">
<h4 id="_description_2">Description</h4>
<div class="paragraph"><p>When specifying <code>--tool=vimdiff</code> in <code>git mergetool</code> Git will open Vim with a 4
windows layout distributed in the following way:</p></div>
<div class="literalblock">
<div class="content">
<pre><code>------------------------------------------
| | | |
| LOCAL | BASE | REMOTE |
| | | |
------------------------------------------
| |
| MERGED |
| |
------------------------------------------</code></pre>
</div></div>
<div class="paragraph"><p><code>LOCAL</code>, <code>BASE</code> and <code>REMOTE</code> are read-only buffers showing the contents of the
conflicting file in specific commits ("commit you are merging into", "common
ancestor commit" and "commit you are merging from" respectively)</p></div>
<div class="paragraph"><p><code>MERGED</code> is a writable buffer where you have to resolve the conflicts (using the
other read-only buffers as a reference). Once you are done, save and exit Vim as
usual (<code>:wq</code>) or, if you want to abort, exit using <code>:cq</code>.</p></div>
</div>
<div class="sect3">
<h4 id="_layout_configuration">Layout configuration</h4>
<div class="paragraph"><p>You can change the windows layout used by Vim by setting configuration variable
<code>mergetool.vimdiff.layout</code> which accepts a string where the following separators
have special meaning:</p></div>
<div class="ulist"><ul>
<li>
<p>
<code>+</code> is used to "open a new tab"
</p>
</li>
<li>
<p>
<code>,</code> is used to "open a new vertical split"
</p>
</li>
<li>
<p>
<code>/</code> is used to "open a new horizontal split"
</p>
</li>
<li>
<p>
<code>@</code> is used to indicate which is the file containing the final version after
solving the conflicts. If not present, <code>MERGED</code> will be used by default.
</p>
</li>
</ul></div>
<div class="paragraph"><p>The precedence of the operators is this one (you can use parentheses to change
it):</p></div>
<div class="literalblock">
<div class="content">
<pre><code>`@` &gt; `+` &gt; `/` &gt; `,`</code></pre>
</div></div>
<div class="paragraph"><p>Let&#8217;s see some examples to understand how it works:</p></div>
<div class="ulist"><ul>
<li>
<p>
<code>layout = "(LOCAL,BASE,REMOTE)/MERGED"</code>
</p>
<div class="openblock">
<div class="content">
<div class="paragraph"><p>This is exactly the same as the default layout we have already seen.</p></div>
<div class="paragraph"><p>Note that <code>/</code> has precedence over <code>,</code> and thus the parenthesis are not
needed in this case. The next layout definition is equivalent:</p></div>
<div class="literalblock">
<div class="content">
<pre><code>layout = "LOCAL,BASE,REMOTE / MERGED"</code></pre>
</div></div>
</div></div>
</li>
<li>
<p>
<code>layout = "LOCAL,MERGED,REMOTE"</code>
</p>
<div class="openblock">
<div class="content">
<div class="paragraph"><p>If, for some reason, we are not interested in the <code>BASE</code> buffer.</p></div>
<div class="literalblock">
<div class="content">
<pre><code>------------------------------------------
| | | |
| | | |
| LOCAL | MERGED | REMOTE |
| | | |
| | | |
------------------------------------------</code></pre>
</div></div>
</div></div>
</li>
<li>
<p>
<code>layout = "MERGED"</code>
</p>
<div class="openblock">
<div class="content">
<div class="paragraph"><p>Only the <code>MERGED</code> buffer will be shown. Note, however, that all the other
ones are still loaded in vim, and you can access them with the "buffers"
command.</p></div>
<div class="literalblock">
<div class="content">
<pre><code>------------------------------------------
| |
| |
| MERGED |
| |
| |
------------------------------------------</code></pre>
</div></div>
</div></div>
</li>
<li>
<p>
<code>layout = "@LOCAL,REMOTE"</code>
</p>
<div class="openblock">
<div class="content">
<div class="paragraph"><p>When <code>MERGED</code> is not present in the layout, you must "mark" one of the
buffers with an asterisk. That will become the buffer you need to edit and
save after resolving the conflicts.</p></div>
<div class="literalblock">
<div class="content">
<pre><code>------------------------------------------
| | |
| | |
| | |
| LOCAL | REMOTE |
| | |
| | |
| | |
------------------------------------------</code></pre>
</div></div>
</div></div>
</li>
<li>
<p>
<code>layout = "LOCAL,BASE,REMOTE / MERGED + BASE,LOCAL + BASE,REMOTE"</code>
</p>
<div class="openblock">
<div class="content">
<div class="paragraph"><p>Three tabs will open: the first one is a copy of the default layout, while
the other two only show the differences between (<code>BASE</code> and <code>LOCAL</code>) and
(<code>BASE</code> and <code>REMOTE</code>) respectively.</p></div>
<div class="literalblock">
<div class="content">
<pre><code>------------------------------------------
| &lt;TAB #1&gt; | TAB #2 | TAB #3 | |
------------------------------------------
| | | |
| LOCAL | BASE | REMOTE |
| | | |
------------------------------------------
| |
| MERGED |
| |
------------------------------------------</code></pre>
</div></div>
<div class="literalblock">
<div class="content">
<pre><code>------------------------------------------
| TAB #1 | &lt;TAB #2&gt; | TAB #3 | |
------------------------------------------
| | |
| | |
| | |
| BASE | LOCAL |
| | |
| | |
| | |
------------------------------------------</code></pre>
</div></div>
<div class="literalblock">
<div class="content">
<pre><code>------------------------------------------
| TAB #1 | TAB #2 | &lt;TAB #3&gt; | |
------------------------------------------
| | |
| | |
| | |
| BASE | REMOTE |
| | |
| | |
| | |
------------------------------------------</code></pre>
</div></div>
</div></div>
</li>
<li>
<p>
<code>layout = "LOCAL,BASE,REMOTE / MERGED + BASE,LOCAL + BASE,REMOTE + (LOCAL/BASE/REMOTE),MERGED"</code>
</p>
<div class="openblock">
<div class="content">
<div class="paragraph"><p>Same as the previous example, but adds a fourth tab with the same
information as the first tab, with a different layout.</p></div>
<div class="literalblock">
<div class="content">
<pre><code>---------------------------------------------
| TAB #1 | TAB #2 | TAB #3 | &lt;TAB #4&gt; |
---------------------------------------------
| LOCAL | |
|---------------------| |
| BASE | MERGED |
|---------------------| |
| REMOTE | |
---------------------------------------------</code></pre>
</div></div>
<div class="paragraph"><p>Note how in the third tab definition we need to use parenthesis to make <code>,</code>
have precedence over <code>/</code>.</p></div>
</div></div>
</li>
</ul></div>
</div>
<div class="sect3">
<h4 id="_variants">Variants</h4>
<div class="paragraph"><p>Instead of <code>--tool=vimdiff</code>, you can also use one of these other variants:</p></div>
<div class="ulist"><ul>
<li>
<p>
<code>--tool=gvimdiff</code>, to open gVim instead of Vim.
</p>
</li>
<li>
<p>
<code>--tool=nvimdiff</code>, to open Neovim instead of Vim.
</p>
</li>
</ul></div>
<div class="paragraph"><p>When using these variants, in order to specify a custom layout you will have to
set configuration variables <code>mergetool.gvimdiff.layout</code> and
<code>mergetool.nvimdiff.layout</code> instead of <code>mergetool.vimdiff.layout</code></p></div>
<div class="paragraph"><p>In addition, for backwards compatibility with previous Git versions, you can
also append <code>1</code>, <code>2</code> or <code>3</code> to either <code>vimdiff</code> or any of the variants (ex:
<code>vimdiff3</code>, <code>nvimdiff1</code>, etc&#8230;) to use a predefined layout.
In other words, using <code>--tool=[g,n,]vimdiffx</code> is the same as using
<code>--tool=[g,n,]vimdiff</code> and setting configuration variable
<code>mergetool.[g,n,]vimdiff.layout</code> to&#8230;</p></div>
<div class="ulist"><ul>
<li>
<p>
<code>x=1</code>: <code>"@LOCAL, REMOTE"</code>
</p>
</li>
<li>
<p>
<code>x=2</code>: <code>"LOCAL, MERGED, REMOTE"</code>
</p>
</li>
<li>
<p>
<code>x=3</code>: <code>"MERGED"</code>
</p>
</li>
</ul></div>
<div class="paragraph"><p>Example: using <code>--tool=gvimdiff2</code> will open <code>gvim</code> with three columns (LOCAL,
MERGED and REMOTE).</p></div>
</div>
</div>
</div>
</div>
<div class="sect1">
<h2 id="_git">GIT</h2>
<div class="sectionbody">
<div class="paragraph"><p>Part of the <a href="git.html">git(1)</a> suite</p></div>
@ -1047,7 +1329,7 @@ are successfully merged.</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2021-10-06 09:57:11 PDT
2022-10-08 14:40:28 PDT
</div>
</div>
</body>

@ -828,7 +828,7 @@ care about, but that can be verified with gpg.</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2021-10-06 09:57:11 PDT
2022-06-28 20:23:28 PDT
</div>
</div>
</body>

@ -792,7 +792,7 @@ built is written to the standard output.</p></div>
<dd>
<p>
Allow building of more than one tree object before exiting. Each
tree is separated by as single blank line. The final new-line is
tree is separated by a single blank line. The final new-line is
optional. Note - if the <code>-z</code> option is used, lines are terminated
with NUL.
</p>
@ -811,7 +811,7 @@ built is written to the standard output.</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2021-09-30 23:04:56 PDT
2022-08-31 14:31:31 PDT
</div>
</div>
</body>

@ -942,8 +942,8 @@ Verify the MIDX file for the packfiles in the current <code>.git</code> director
<h2 id="_see_also">SEE ALSO</h2>
<div class="sectionbody">
<div class="paragraph"><p>See <a href="technical/multi-pack-index.html">The Multi-Pack-Index Design
Document</a> and <a href="technical/pack-format.html">The Multi-Pack-Index
Format</a> for more information on the multi-pack-index feature.</p></div>
Document</a> and <a href="gitformat-pack.html">gitformat-pack(5)</a> for more information on the
multi-pack-index feature and its file format.</p></div>
</div>
</div>
<div class="sect1">
@ -957,7 +957,7 @@ Format</a> for more information on the multi-pack-index feature.</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2021-11-15 13:27:01 PST
2022-09-16 17:50:33 PDT
</div>
</div>
</body>

@ -857,7 +857,7 @@ been implemented.</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2018-06-15 19:46:24 PDT
2022-01-27 18:10:56 PST
</div>
</div>
</body>

@ -808,14 +808,44 @@ format parsable by <em>git rev-parse</em>.</p></div>
</p>
</dd>
<dt class="hdlist1">
--stdin
--annotate-stdin
</dt>
<dd>
<p>
Transform stdin by substituting all the 40-character SHA-1
hexes (say $hex) with "$hex ($rev_name)". When used with
--name-only, substitute with "$rev_name", omitting $hex
altogether. Intended for the scripter&#8217;s use.
altogether.
</p>
<div class="paragraph"><p>For example:</p></div>
<div class="listingblock">
<div class="content">
<pre><code>$ cat sample.txt
An abbreviated revision 2ae0a9cb82 will not be substituted.
The full name after substitution is 2ae0a9cb8298185a94e5998086f380a355dd8907,
while its tree object is 70d105cc79e63b81cfdcb08a15297c23e60b07ad
$ git name-rev --annotate-stdin &lt;sample.txt
An abbreviated revision 2ae0a9cb82 will not be substituted.
The full name after substitution is 2ae0a9cb8298185a94e5998086f380a355dd8907 (master),
while its tree object is 70d105cc79e63b81cfdcb08a15297c23e60b07ad
$ git name-rev --name-only --annotate-stdin &lt;sample.txt
An abbreviated revision 2ae0a9cb82 will not be substituted.
The full name after substitution is master,
while its tree object is 70d105cc79e63b81cfdcb08a15297c23e60b07ad</code></pre>
</div></div>
</dd>
<dt class="hdlist1">
--stdin
</dt>
<dd>
<p>
This option is deprecated in favor of <em>git name-rev --annotate-stdin</em>.
They are functionally equivalent.
</p>
</dd>
<dt class="hdlist1">
@ -881,7 +911,7 @@ not the context.</p></div>
<div id="footer">
<div id="footer-text">
Last updated
2021-09-30 23:04:56 PDT
2022-08-31 14:31:31 PDT
</div>
</div>
</body>

Some files were not shown because too many files have changed in this diff Show More

Loading…
Cancel
Save