diff options
| author | Junio C Hamano <gitster@pobox.com> | 2022-03-27 10:31:23 -0700 |
|---|---|---|
| committer | Junio C Hamano <gitster@pobox.com> | 2022-03-27 10:31:23 -0700 |
| commit | 67fef49427c9457e52b6bed728023f84fd8967d4 (patch) | |
| tree | 7e3db4a268775a3ab9b9dd670a3397388d646b55 | |
| parent | 14390e2aecb283765a5377385680c6baef1ed254 (diff) | |
| download | git-htmldocs-67fef49427c9457e52b6bed728023f84fd8967d4.tar.gz | |
Autogenerated HTML docs for v2.35.1-677-gabf47
33 files changed, 386 insertions, 180 deletions
diff --git a/MyFirstObjectWalk.html b/MyFirstObjectWalk.html index 220998c3b..e0e57c830 100644 --- a/MyFirstObjectWalk.html +++ b/MyFirstObjectWalk.html @@ -1315,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’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>
@@ -1347,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 paramter:</p></div>
+<div class="ulist"><ul>
<li>
<p>
<code>struct oidset *omitted</code>: A linked-list of object IDs which the provided
@@ -1354,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’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’s add the callbacks first.</p></div>
<div class="paragraph"><p>For the sake of this tutorial, we’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>
@@ -1532,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’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 = { 0 };
-
- ...</code></pre>
-</div></div>
<div class="paragraph"><p>For now, we are not going to track the omitted objects, so we’ll replace those
parameters with <code>NULL</code>. For the sake of simplicity, we’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’ve just performed:</p></div>
<div class="listingblock">
@@ -1552,18 +1539,16 @@ walk we’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(&filter_options, "tree:1");
-
- traverse_commit_list_filtered(&filter_options, rev,
- walken_show_commit, walken_show_object, NULL, NULL);
- }</code></pre>
+ CALLOC_ARRAY(rev->filter, 1);
+ parse_list_objects_filter(rev->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->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’t taking user input right now, we can still build one with
a hardcoded string using <code>parse_list_objects_filter()</code>.</p></div>
@@ -1599,7 +1584,7 @@ object:</p></div> <div class="content">
<pre><code> ...
- traverse_commit_list_filtered(&filter_options, rev,
+ traverse_commit_list_filtered(rev,
walken_show_commit, walken_show_object, NULL, &omitted);
...</code></pre>
@@ -1737,7 +1722,7 @@ Changed the display order of the filtered object walk <div id="footer">
<div id="footer-text">
Last updated
- 2021-12-10 14:52:02 PST
+ 2022-03-27 10:29:17 PDT
</div>
</div>
</body>
diff --git a/MyFirstObjectWalk.txt b/MyFirstObjectWalk.txt index ca267941f..8d9e85566 100644 --- a/MyFirstObjectWalk.txt +++ b/MyFirstObjectWalk.txt @@ -522,24 +522,25 @@ function shows that the all-object walk is being performed by `traverse_commit_list()` or `traverse_commit_list_filtered()`. Those two functions reside in `list-objects.c`; examining the source shows that, despite the name, these functions traverse all kinds of objects. Let's have a look at -the arguments to `traverse_commit_list_filtered()`, which are a superset of the -arguments to the unfiltered version. +the arguments to `traverse_commit_list()`. -- `struct list_objects_filter_options *filter_options`: This is a struct which - stores a filter-spec as outlined in `Documentation/rev-list-options.txt`. -- `struct rev_info *revs`: This is the `rev_info` used for the walk. +- `struct rev_info *revs`: This is the `rev_info` used for the walk. If + its `filter` member is not `NULL`, then `filter` contains information for + how to filter the object list. - `show_commit_fn show_commit`: A callback which will be used to handle each individual commit object. - `show_object_fn show_object`: A callback which will be used to handle each non-commit object (so each blob, tree, or tag). - `void *show_data`: A context buffer which is passed in turn to `show_commit` and `show_object`. + +In addition, `traverse_commit_list_filtered()` has an additional paramter: + - `struct oidset *omitted`: A linked-list of object IDs which the provided filter caused to be omitted. -It looks like this `traverse_commit_list_filtered()` uses callbacks we provide -instead of needing us to call it repeatedly ourselves. Cool! Let's add the -callbacks first. +It looks like these methods use callbacks we provide instead of needing us +to call it repeatedly ourselves. Cool! Let's add the callbacks first. For the sake of this tutorial, we'll simply keep track of how many of each kind of object we find. At file scope in `builtin/walken.c` add the following @@ -712,20 +713,9 @@ help understand. In our case, that means we omit trees and blobs not directly referenced by `HEAD` or `HEAD`'s history, because we begin the walk with only `HEAD` in the `pending` list.) -First, we'll need to `#include "list-objects-filter-options.h"` and set up the -`struct list_objects_filter_options` at the top of the function. - ----- -static void walken_object_walk(struct rev_info *rev) -{ - struct list_objects_filter_options filter_options = { 0 }; - - ... ----- - For now, we are not going to track the omitted objects, so we'll replace those parameters with `NULL`. For the sake of simplicity, we'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 `traverse_commit_list()` with the following, which will remind us which kind of walk we've just performed: @@ -733,19 +723,17 @@ walk we've just performed: 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(&filter_options, "tree:1"); - - traverse_commit_list_filtered(&filter_options, rev, - walken_show_commit, walken_show_object, NULL, NULL); + CALLOC_ARRAY(rev->filter, 1); + parse_list_objects_filter(rev->filter, "tree:1"); } + traverse_commit_list(rev, walken_show_commit, + walken_show_object, NULL); ---- -`struct list_objects_filter_options` is usually built directly from a command +The `rev->filter` 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't taking user input right now, we can still build one with a hardcoded string using `parse_list_objects_filter()`. @@ -784,7 +772,7 @@ object: ---- ... - traverse_commit_list_filtered(&filter_options, rev, + traverse_commit_list_filtered(rev, walken_show_commit, walken_show_object, NULL, &omitted); ... diff --git a/RelNotes/2.36.0.txt b/RelNotes/2.36.0.txt index d67727baa..721b5d203 100644 --- a/RelNotes/2.36.0.txt +++ b/RelNotes/2.36.0.txt @@ -74,6 +74,16 @@ UI, Workflows & Features refs involved, takes long time renaming them. The command has been taught to show progress bar while making the user wait. + * Bundle file format gets extended to allow a partial bundle, + filtered by similar criteria you would give when making a + partial/lazy clone. + + * A new built-in userdiff driver for kotlin has been added. + + * "git repack" learned a new configuration to disable triggering of + age-old "update-server-info" command, which is rarely useful these + days. + Performance, Internal Implementation, Development Support etc. @@ -132,6 +142,22 @@ Performance, Internal Implementation, Development Support etc. * Count string_list items in size_t, not "unsigned int". + * The single-key interactive operation used by "git add -p" has been + made more robust. + + * Remove unneeded <meta http-equiv=content-type...> from gitweb + output. + + * "git name-rev" learned to use the generation numbers when setting + the lower bound of searching commits used to explain the revision, + when available, instead of committer time. + + * Replace core.fsyncObjectFiles with two new configuration variables, + core.fsync and core.fsyncMethod. + + * Updates to refs traditionally weren't fsync'ed, but we can + configure using core.fsync variable to do so. + Fixes since v2.35 ----------------- @@ -320,6 +346,16 @@ Fixes since v2.35 (not) handled has been corrected. (merge 6dbf4b8172 ds/commit-graph-gen-v2-fixes later to maint). + * The method to trigger malloc check used in our tests no longer work + with newer versions of glibc. + (merge baedc59543 ep/test-malloc-check-with-glibc-2.34 later to maint). + + * When "git fetch --recurse-submodules" grabbed submodule commits + that would be needed to recursively check out newly fetched commits + in the superproject, it only paid attention to submodules that are + in the current checkout of the superproject. We now do so for all + submodules that have been run "git submodule init" on. + * Other code cleanup, docfix, build fix, etc. (merge cfc5cf428b jc/find-header later to maint). (merge 40e7cfdd46 jh/p4-fix-use-of-process-error-exception later to maint). @@ -345,3 +381,7 @@ Fixes since v2.35 (merge 04bf052eef ab/grep-patterntype later to maint). (merge 6ee36364eb ab/diff-free-more later to maint). (merge 63a36017fe nj/read-tree-doc-reffix later to maint). + (merge eed36fce38 sm/no-git-in-upstream-of-pipe-in-tests later to maint). + (merge c614beb933 ep/t6423-modernize later to maint). + (merge 57be9c6dee ab/reflog-prep-fix later to maint). + (merge 5327d8982a js/in-place-reverse-in-sequencer later to maint). diff --git a/fetch-options.txt b/fetch-options.txt index f90368318..6cdd9d43c 100644 --- a/fetch-options.txt +++ b/fetch-options.txt @@ -186,15 +186,23 @@ endif::git-pull[] ifndef::git-pull[] --recurse-submodules[=yes|on-demand|no]:: 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 'no' or to - unconditionally recurse into all populated submodules when set to - 'yes', which is the default when this option is used without any - value. Use 'on-demand' to only recurse into a populated submodule - when the superproject retrieves a commit that updates the submodule's - reference to a commit that isn't already in the local submodule - clone. By default, 'on-demand' is used, unless - `fetch.recurseSubmodules` is set (see linkgit:git-config[1]). + submodules should be fetched too. When recursing through submodules, + `git fetch` 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 `$GIT_DIR/modules/` (see linkgit:gitsubmodules[7]); if the upstream + adds a new submodule, that submodule cannot be fetched until it is + cloned e.g. by `git submodule update`. ++ +When set to 'on-demand', only changed submodules are fetched. When set +to 'yes', all populated submodules are fetched and submodules that are +both unpopulated and changed are fetched. When set to 'no', submodules +are never fetched. ++ +When unspecified, this uses the value of `fetch.recurseSubmodules` if it +is set (see linkgit:git-config[1]), defaulting to 'on-demand' if unset. +When this option is used without any value, it defaults to 'yes'. endif::git-pull[] -j:: diff --git a/git-bundle.html b/git-bundle.html index 7dde574d9..c1f515eb9 100644 --- a/git-bundle.html +++ b/git-bundle.html @@ -823,8 +823,11 @@ verify <file> 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.
+ Information about additional capabilities, such as "object filter",
+ is printed. See "Capabilities" in link:technical/bundle-format.html
+ for more information. Finally, <em>git bundle</em> prints a list of
+ missing commits, if any. The exit code is zero for success, but
+ will be nonzero if the bundle file is invalid.
</p>
</dd>
<dt class="hdlist1">
@@ -1121,7 +1124,7 @@ references when fetching:</p></div> <div id="footer">
<div id="footer-text">
Last updated
- 2021-10-29 16:18:45 PDT
+ 2022-03-27 10:29:17 PDT
</div>
</div>
</body>
diff --git a/git-bundle.txt b/git-bundle.txt index 72ab81390..ac4c4352a 100644 --- a/git-bundle.txt +++ b/git-bundle.txt @@ -75,8 +75,11 @@ verify <file>:: 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. - 'git bundle' prints a list of missing commits, if any, and exits - with a non-zero status. + Information about additional capabilities, such as "object filter", + is printed. See "Capabilities" in link:technical/bundle-format.html + for more information. Finally, 'git bundle' prints a list of + missing commits, if any. The exit code is zero for success, but + will be nonzero if the bundle file is invalid. list-heads <file>:: Lists the references defined in the bundle. If followed by a diff --git a/git-config.html b/git-config.html index 88e58677d..59cef4d6b 100644 --- a/git-config.html +++ b/git-config.html @@ -3027,16 +3027,133 @@ core.whitespace </ul></div>
</dd>
<dt class="hdlist1">
+core.fsync
+</dt>
+<dd>
+<p>
+ A comma-separated list of components of the repository that
+ should be hardened via the core.fsyncMethod when created or
+ modified. You can disable hardening of any component by
+ prefixing it with a <em>-</em>. Items that are not hardened may be
+ lost in the event of an unclean system shutdown. Unless you
+ have special requirements, it is recommended that you leave
+ this option empty or pick one of <code>committed</code>, <code>added</code>,
+ or <code>all</code>.
+</p>
+<div class="paragraph"><p>When this configuration is encountered, the set of components starts with
+the platform default value, disabled components are removed, and additional
+components are added. <code>none</code> resets the state so that the platform default
+is ignored.</p></div>
+<div class="paragraph"><p>The empty string resets the fsync configuration to the platform
+default. The default on most platforms is equivalent to
+<code>core.fsync=committed,-loose-object</code>, which has good performance,
+but risks losing recent work in the event of an unclean system shutdown.</p></div>
+<div class="ulist"><ul>
+<li>
+<p>
+<code>none</code> clears the set of fsynced components.
+</p>
+</li>
+<li>
+<p>
+<code>loose-object</code> hardens objects added to the repo in loose-object form.
+</p>
+</li>
+<li>
+<p>
+<code>pack</code> hardens objects added to the repo in packfile form.
+</p>
+</li>
+<li>
+<p>
+<code>pack-metadata</code> hardens packfile bitmaps and indexes.
+</p>
+</li>
+<li>
+<p>
+<code>commit-graph</code> hardens the commit graph file.
+</p>
+</li>
+<li>
+<p>
+<code>index</code> hardens the index when it is modified.
+</p>
+</li>
+<li>
+<p>
+<code>objects</code> is an aggregate option that is equivalent to
+ <code>loose-object,pack</code>.
+</p>
+</li>
+<li>
+<p>
+<code>reference</code> hardens references modified in the repo.
+</p>
+</li>
+<li>
+<p>
+<code>derived-metadata</code> is an aggregate option that is equivalent to
+ <code>pack-metadata,commit-graph</code>.
+</p>
+</li>
+<li>
+<p>
+<code>committed</code> is an aggregate option that is currently equivalent to
+ <code>objects</code>. This mode sacrifices some performance to ensure that work
+ that is committed to the repository with <code>git commit</code> or similar commands
+ is hardened.
+</p>
+</li>
+<li>
+<p>
+<code>added</code> is an aggregate option that is currently equivalent to
+ <code>committed,index</code>. This mode sacrifices additional performance to
+ ensure that the results of commands like <code>git add</code> and similar operations
+ are hardened.
+</p>
+</li>
+<li>
+<p>
+<code>all</code> is an aggregate option that syncs all individual components above.
+</p>
+</li>
+</ul></div>
+</dd>
+<dt class="hdlist1">
+core.fsyncMethod
+</dt>
+<dd>
+<p>
+ A value indicating the strategy Git will use to harden repository data
+ using fsync and related primitives.
+</p>
+<div class="ulist"><ul>
+<li>
+<p>
+<code>fsync</code> uses the fsync() system call or platform equivalents.
+</p>
+</li>
+<li>
+<p>
+<code>writeout-only</code> issues pagecache writeback requests, but depending on the
+ filesystem and storage hardware, data added to the repository may not be
+ durable in the event of a system crash. This is the default mode on macOS.
+</p>
+</li>
+</ul></div>
+</dd>
+<dt class="hdlist1">
core.fsyncObjectFiles
</dt>
<dd>
<p>
This boolean will enable <em>fsync()</em> when writing object files.
+ This setting is deprecated. Use core.fsync instead.
</p>
-<div class="paragraph"><p>This is a total waste of time and effort on a filesystem that orders
-data writes properly, but can be useful for filesystems that do not use
-journalling (traditional UNIX filesystems) or that only journal metadata
-and not file contents (OS X’s HFS+, or Linux ext3 with "data=writeback").</p></div>
+<div class="paragraph"><p>This setting affects data added to the Git repository in loose-object
+form. When set to true, Git will issue an fsync or similar system call
+to flush caches so that loose-objects remain consistent in the face
+of a unclean system shutdown.</p></div>
</dd>
<dt class="hdlist1">
core.preloadIndex
@@ -9350,6 +9467,16 @@ repack.writeBitmaps </p>
</dd>
<dt class="hdlist1">
+repack.updateServerInfo
+</dt>
+<dd>
+<p>
+ If set to false, <a href="git-repack.html">git-repack(1)</a> will not run
+ <a href="git-update-server-info.html">git-update-server-info(1)</a>. Defaults to true. Can be overridden
+ when true by the <code>-n</code> option of <a href="git-repack.html">git-repack(1)</a>.
+</p>
+</dd>
+<dt class="hdlist1">
rerere.autoUpdate
</dt>
<dd>
diff --git a/git-fetch.html b/git-fetch.html index 3a580e963..40a2532ea 100644 --- a/git-fetch.html +++ b/git-fetch.html @@ -1091,16 +1091,22 @@ Internally this is used to implement the <code>push.negotiate</code> option, see <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’s
- reference to a commit that isn’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
@@ -1976,12 +1982,10 @@ As in #1, the attacker chooses an object ID X to steal. The victim sends <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">
@@ -2001,7 +2005,7 @@ version.</p></div> <div id="footer">
<div id="footer-text">
Last updated
- 2021-08-06 16:16:38 PDT
+ 2022-03-27 10:29:17 PDT
</div>
</div>
</body>
diff --git a/git-fetch.txt b/git-fetch.txt index 550c16ca6..e9d364669 100644 --- a/git-fetch.txt +++ b/git-fetch.txt @@ -287,12 +287,10 @@ include::transfer-data-leaks.txt[] BUGS ---- -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. +Using --recurse-submodules can only fetch new commits in submodules that are +present locally e.g. in `$GIT_DIR/modules/`. If the upstream adds a new +submodule, that submodule cannot be fetched until it is cloned e.g. by `git +submodule update`. This is expected to be fixed in a future Git version. SEE ALSO -------- diff --git a/git-index-pack.html b/git-index-pack.html index b15936c22..db0206873 100644 --- a/git-index-pack.html +++ b/git-index-pack.html @@ -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[=<message>]
+</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><message></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-09-20 15:44:03 PDT
+ 2022-03-27 10:29:17 PDT
</div>
</div>
</body>
diff --git a/git-index-pack.txt b/git-index-pack.txt index 1f1e35922..4e71c256e 100644 --- a/git-index-pack.txt +++ b/git-index-pack.txt @@ -122,6 +122,14 @@ This option cannot be used with --stdin. + include::object-format-disclaimer.txt[] +--promisor[=<message>]:: + 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 `<message>` is provided, then that content will be + written to the .promisor file for future reference. See + link:technical/partial-clone.html[partial clone] for more information. + NOTES ----- diff --git a/git-maintenance.html b/git-maintenance.html index 3f0efa2e4..89b1c5519 100644 --- a/git-maintenance.html +++ b/git-maintenance.html @@ -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 [<options>]</pre>
+<pre class="content"><em>git maintenance</em> run [<options>]
+<em>git maintenance</em> start [--scheduler=<scheduler>]
+<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.<task>.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.<task>.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>
@@ -1239,7 +1241,7 @@ custom tasks.</p></div> <div id="footer">
<div id="footer-text">
Last updated
- 2021-09-20 15:44:03 PDT
+ 2022-03-27 10:29:17 PDT
</div>
</div>
</body>
diff --git a/git-maintenance.txt b/git-maintenance.txt index e2cfb68ab..e56bad28c 100644 --- a/git-maintenance.txt +++ b/git-maintenance.txt @@ -10,6 +10,8 @@ SYNOPSIS -------- [verse] 'git maintenance' run [<options>] +'git maintenance' start [--scheduler=<scheduler>] +'git maintenance' (stop|register|unregister) DESCRIPTION @@ -29,6 +31,24 @@ Git repository. SUBCOMMANDS ----------- +run:: + Run one or more maintenance tasks. If one or more `--task` options + are specified, then those tasks are run in that order. Otherwise, + the tasks are determined by which `maintenance.<task>.enabled` + config options are true. By default, only `maintenance.gc.enabled` + is true. + +start:: + Start running maintenance on the current repository. This performs + the same config updates as the `register` subcommand, then updates + the background scheduler to run `git maintenance run --scheduled` + on an hourly basis. + +stop:: + 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. + register:: Initialize Git config values so any scheduled maintenance will start running on this repository. This adds the repository to the @@ -55,24 +75,6 @@ task: setting `maintenance.auto = false` in the current repository. This config setting will remain after a `git maintenance unregister` command. -run:: - Run one or more maintenance tasks. If one or more `--task` options - are specified, then those tasks are run in that order. Otherwise, - the tasks are determined by which `maintenance.<task>.enabled` - config options are true. By default, only `maintenance.gc.enabled` - is true. - -start:: - Start running maintenance on the current repository. This performs - the same config updates as the `register` subcommand, then updates - the background scheduler to run `git maintenance run --scheduled` - on an hourly basis. - -stop:: - 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. - unregister:: Remove the current repository from background maintenance. This only removes the repository from the configured list. It does not diff --git a/gitattributes.html b/gitattributes.html index 89a462b1b..9b6713224 100644 --- a/gitattributes.html +++ b/gitattributes.html @@ -1634,6 +1634,11 @@ patterns are available:</p></div> </li>
<li>
<p>
+<code>kotlin</code> suitable for source code in the Kotlin language.
+</p>
+</li>
+<li>
+<p>
<code>markdown</code> suitable for Markdown documents.
</p>
</li>
@@ -2197,7 +2202,7 @@ frotz unspecified</code></pre> <div id="footer">
<div id="footer-text">
Last updated
- 2022-02-23 17:16:40 PST
+ 2022-03-27 10:29:17 PDT
</div>
</div>
</body>
diff --git a/gitattributes.txt b/gitattributes.txt index a71dad267..4b36d51be 100644 --- a/gitattributes.txt +++ b/gitattributes.txt @@ -829,6 +829,8 @@ patterns are available: - `java` suitable for source code in the Java language. +- `kotlin` suitable for source code in the Kotlin language. + - `markdown` suitable for Markdown documents. - `matlab` suitable for source code in the MATLAB and Octave languages. diff --git a/howto/coordinate-embargoed-releases.html b/howto/coordinate-embargoed-releases.html index 696877c1c..20acf5d63 100644 --- a/howto/coordinate-embargoed-releases.html +++ b/howto/coordinate-embargoed-releases.html @@ -873,7 +873,7 @@ Thanks, <div id="footer">
<div id="footer-text">
Last updated
- 2022-03-16 18:09:14 PDT
+ 2022-03-27 10:29:50 PDT
</div>
</div>
</body>
diff --git a/howto/keep-canonical-history-correct.html b/howto/keep-canonical-history-correct.html index 7f9e183fc..70407147b 100644 --- a/howto/keep-canonical-history-correct.html +++ b/howto/keep-canonical-history-correct.html @@ -938,7 +938,7 @@ tip of your <em>master</em> again and redo the two merges:</p></div> <div id="footer">
<div id="footer-text">
Last updated
- 2022-03-16 18:09:13 PDT
+ 2022-03-27 10:29:50 PDT
</div>
</div>
</body>
diff --git a/howto/maintain-git.html b/howto/maintain-git.html index 5f85139f4..9437691de 100644 --- a/howto/maintain-git.html +++ b/howto/maintain-git.html @@ -1469,7 +1469,7 @@ $ git update-ref -d $mf/ai/topic</code></pre> <div id="footer">
<div id="footer-text">
Last updated
- 2022-03-16 18:09:14 PDT
+ 2022-03-27 10:29:50 PDT
</div>
</div>
</body>
diff --git a/howto/new-command.html b/howto/new-command.html index 3c0f6e689..a9a8a0444 100644 --- a/howto/new-command.html +++ b/howto/new-command.html @@ -863,7 +863,7 @@ letter [PATCH 0/n]. <div id="footer">
<div id="footer-text">
Last updated
- 2022-03-16 18:09:10 PDT
+ 2022-03-27 10:29:47 PDT
</div>
</div>
</body>
diff --git a/howto/rebase-from-internal-branch.html b/howto/rebase-from-internal-branch.html index 43d4acf61..56adb969e 100644 --- a/howto/rebase-from-internal-branch.html +++ b/howto/rebase-from-internal-branch.html @@ -895,7 +895,7 @@ the #1' commit.</p></div> <div id="footer">
<div id="footer-text">
Last updated
- 2022-03-16 18:09:13 PDT
+ 2022-03-27 10:29:50 PDT
</div>
</div>
</body>
diff --git a/howto/rebuild-from-update-hook.html b/howto/rebuild-from-update-hook.html index eafbb27f5..dd8321ef1 100644 --- a/howto/rebuild-from-update-hook.html +++ b/howto/rebuild-from-update-hook.html @@ -847,7 +847,7 @@ This is still crude and does not protect against simultaneous <div id="footer">
<div id="footer-text">
Last updated
- 2022-03-16 18:09:13 PDT
+ 2022-03-27 10:29:49 PDT
</div>
</div>
</body>
diff --git a/howto/recover-corrupted-blob-object.html b/howto/recover-corrupted-blob-object.html index f0b59cab7..8a4f120b8 100644 --- a/howto/recover-corrupted-blob-object.html +++ b/howto/recover-corrupted-blob-object.html @@ -880,7 +880,7 @@ thing.</p></div> <div id="footer">
<div id="footer-text">
Last updated
- 2022-03-16 18:09:13 PDT
+ 2022-03-27 10:29:49 PDT
</div>
</div>
</body>
diff --git a/howto/recover-corrupted-object-harder.html b/howto/recover-corrupted-object-harder.html index 58c39a5a3..7b8758779 100644 --- a/howto/recover-corrupted-object-harder.html +++ b/howto/recover-corrupted-object-harder.html @@ -1189,7 +1189,7 @@ int main(int argc, char **argv) <div id="footer">
<div id="footer-text">
Last updated
- 2022-03-16 18:09:13 PDT
+ 2022-03-27 10:29:49 PDT
</div>
</div>
</body>
diff --git a/howto/revert-a-faulty-merge.html b/howto/revert-a-faulty-merge.html index 9f5cec4b5..10388d581 100644 --- a/howto/revert-a-faulty-merge.html +++ b/howto/revert-a-faulty-merge.html @@ -1025,7 +1025,7 @@ P---o---o---M---x---x---W---x---M2 <div id="footer">
<div id="footer-text">
Last updated
- 2022-03-16 18:09:12 PDT
+ 2022-03-27 10:29:49 PDT
</div>
</div>
</body>
diff --git a/howto/revert-branch-rebase.html b/howto/revert-branch-rebase.html index 96823bd14..91ef8f565 100644 --- a/howto/revert-branch-rebase.html +++ b/howto/revert-branch-rebase.html @@ -907,7 +907,7 @@ Committed merge 7fb9b7262a1d1e0a47bbfdcbbcf50ce0635d3f8f <div id="footer">
<div id="footer-text">
Last updated
- 2022-03-16 18:09:10 PDT
+ 2022-03-27 10:29:48 PDT
</div>
</div>
</body>
diff --git a/howto/separating-topic-branches.html b/howto/separating-topic-branches.html index 58c8568cb..469756dbf 100644 --- a/howto/separating-topic-branches.html +++ b/howto/separating-topic-branches.html @@ -841,7 +841,7 @@ o---o"master"</code></pre> <div id="footer">
<div id="footer-text">
Last updated
- 2022-03-16 18:09:12 PDT
+ 2022-03-27 10:29:49 PDT
</div>
</div>
</body>
diff --git a/howto/setup-git-server-over-http.html b/howto/setup-git-server-over-http.html index 02fb92c91..c226e68dd 100644 --- a/howto/setup-git-server-over-http.html +++ b/howto/setup-git-server-over-http.html @@ -1071,7 +1071,7 @@ help diagnosing the problem, but removes security checks.</p></div> <div id="footer">
<div id="footer-text">
Last updated
- 2022-03-16 18:09:12 PDT
+ 2022-03-27 10:29:48 PDT
</div>
</div>
</body>
diff --git a/howto/update-hook-example.html b/howto/update-hook-example.html index f067ab548..6dda827ec 100644 --- a/howto/update-hook-example.html +++ b/howto/update-hook-example.html @@ -930,7 +930,7 @@ that JC can make non-fast-forward pushes on it.</p></div> <div id="footer">
<div id="footer-text">
Last updated
- 2022-03-16 18:09:11 PDT
+ 2022-03-27 10:29:48 PDT
</div>
</div>
</body>
diff --git a/howto/use-git-daemon.html b/howto/use-git-daemon.html index 4df67c5ee..a7daad6bc 100644 --- a/howto/use-git-daemon.html +++ b/howto/use-git-daemon.html @@ -791,7 +791,7 @@ a good practice to put the paths after a "--" separator.</p></div> <div id="footer">
<div id="footer-text">
Last updated
- 2022-03-16 18:09:11 PDT
+ 2022-03-27 10:29:48 PDT
</div>
</div>
</body>
diff --git a/howto/using-merge-subtree.html b/howto/using-merge-subtree.html index 44934f0f4..9c74de214 100644 --- a/howto/using-merge-subtree.html +++ b/howto/using-merge-subtree.html @@ -848,7 +848,7 @@ Please note that if the other project merges from you, then it will <div id="footer">
<div id="footer-text">
Last updated
- 2022-03-16 18:09:10 PDT
+ 2022-03-27 10:29:48 PDT
</div>
</div>
</body>
diff --git a/howto/using-signed-tag-in-pull-request.html b/howto/using-signed-tag-in-pull-request.html index b817c151a..b99c1a2ef 100644 --- a/howto/using-signed-tag-in-pull-request.html +++ b/howto/using-signed-tag-in-pull-request.html @@ -952,7 +952,7 @@ as part of the merge commit.</p></div> <div id="footer">
<div id="footer-text">
Last updated
- 2022-03-16 18:09:11 PDT
+ 2022-03-27 10:29:48 PDT
</div>
</div>
</body>
diff --git a/technical/bundle-format.html b/technical/bundle-format.html index a6c588f24..5440bec8e 100644 --- a/technical/bundle-format.html +++ b/technical/bundle-format.html @@ -827,9 +827,22 @@ and the Git bundle v2 format cannot represent a shallow clone repository.</p></d <h2 id="_capabilities">Capabilities</h2>
<div class="sectionbody">
<div class="paragraph"><p>Because there is no opportunity for negotiation, unknown capabilities cause <em>git
-bundle</em> to abort. The only known capability is <code>object-format</code>, which specifies
-the hash algorithm in use, and can take the same values as the
-<code>extensions.objectFormat</code> configuration value.</p></div>
+bundle</em> to abort.</p></div>
+<div class="ulist"><ul>
+<li>
+<p>
+<code>object-format</code> specifies the hash algorithm in use, and can take the same
+ values as the <code>extensions.objectFormat</code> configuration value.
+</p>
+</li>
+<li>
+<p>
+<code>filter</code> specifies an object filter as in the <code>--filter</code> option in
+ <a href="../git-rev-list.html">git-rev-list(1)</a>. The resulting pack-file must be marked as a
+ <code>.promisor</code> pack-file after it is unbundled.
+</p>
+</li>
+</ul></div>
</div>
</div>
</div>
@@ -837,7 +850,7 @@ the hash algorithm in use, and can take the same values as the <div id="footer">
<div id="footer-text">
Last updated
- 2020-08-11 20:37:50 PDT
+ 2022-03-27 10:29:17 PDT
</div>
</div>
</body>
diff --git a/technical/bundle-format.txt b/technical/bundle-format.txt index bac558d04..b9be8644c 100644 --- a/technical/bundle-format.txt +++ b/technical/bundle-format.txt @@ -71,6 +71,11 @@ and the Git bundle v2 format cannot represent a shallow clone repository. == Capabilities Because there is no opportunity for negotiation, unknown capabilities cause 'git -bundle' to abort. The only known capability is `object-format`, which specifies -the hash algorithm in use, and can take the same values as the -`extensions.objectFormat` configuration value. +bundle' to abort. + +* `object-format` specifies the hash algorithm in use, and can take the same + values as the `extensions.objectFormat` configuration value. + +* `filter` specifies an object filter as in the `--filter` option in + linkgit:git-rev-list[1]. The resulting pack-file must be marked as a + `.promisor` pack-file after it is unbundled. |