From 4b4567c45aae4498a3609d0f4d343f930e9964fc Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Mon, 2 Jan 2023 22:39:48 +0900 Subject: Autogenerated HTML docs for v2.39.0-158-g2b4f5 --- RelNotes/2.40.0.txt | 12 ++ git-config.html | 20 +++ gitprotocol-v2.html | 224 +++++++++++++++++++++++++++- gitprotocol-v2.txt | 201 +++++++++++++++++++++++++ howto/coordinate-embargoed-releases.html | 2 +- howto/keep-canonical-history-correct.html | 2 +- howto/maintain-git.html | 2 +- howto/new-command.html | 2 +- howto/rebase-from-internal-branch.html | 2 +- howto/rebuild-from-update-hook.html | 2 +- howto/recover-corrupted-blob-object.html | 2 +- howto/recover-corrupted-object-harder.html | 2 +- howto/revert-a-faulty-merge.html | 2 +- howto/revert-branch-rebase.html | 2 +- howto/separating-topic-branches.html | 2 +- howto/setup-git-server-over-http.html | 2 +- howto/update-hook-example.html | 2 +- howto/use-git-daemon.html | 2 +- howto/using-merge-subtree.html | 2 +- howto/using-signed-tag-in-pull-request.html | 2 +- 20 files changed, 472 insertions(+), 17 deletions(-) diff --git a/RelNotes/2.40.0.txt b/RelNotes/2.40.0.txt index 634f0ae33..80b3b5040 100644 --- a/RelNotes/2.40.0.txt +++ b/RelNotes/2.40.0.txt @@ -23,6 +23,9 @@ UI, Workflows & Features choose which editor gets used behind it, "git var" now give support to GIT_SEQUENCE_EDITOR. + * "git format-patch" learned to honor format.mboxrd even when sending + patches to the standard output stream, + Performance, Internal Implementation, Development Support etc. @@ -82,6 +85,15 @@ Fixes since v2.39 request and barfed, which has been corrected. (merge 6f65f84766 ss/pull-v-recurse-fix later to maint). + * When given a pattern that matches an empty string at the end of a + line, the code to parse the "git diff" line-ranges fell into an + infinite loop, which has been corrected. + (merge 4e57c88e02 lk/line-range-parsing-fix later to maint). + + * Fix the sequence to fsync $GIT_DIR/packed-refs file that forgot to + flush its output to the disk.. + (merge ce54672f9b ps/fsync-refs-fix later to maint). + * Other code cleanup, docfix, build fix, etc. (merge 77e04b2ed4 rs/t4205-do-not-exit-in-test-script later to maint). (merge faebba436e rs/plug-pattern-list-leak-in-lof later to maint). diff --git a/git-config.html b/git-config.html index 3725fb649..31b2bfb9a 100644 --- a/git-config.html +++ b/git-config.html @@ -5831,6 +5831,15 @@ previous configurations and not show notes.

will only show notes from refs/notes/bar.

+format.mboxrd +
+
+

+ A boolean value which enables the robust "mboxrd" format when + --stdout is in use to escape "^>+From " lines. +

+
+
filter.<driver>.clean
@@ -11184,6 +11193,17 @@ transfer.advertiseSID

+transfer.bundleURI +
+
+

+ When true, local git clone commands will request bundle + information from the remote server (if advertised) and download + bundles before continuing the clone through the Git protocol. + Defaults to false. +

+
+
uploadarchive.allowUnreachable
diff --git a/gitprotocol-v2.html b/gitprotocol-v2.html index a4ff6ee1f..a49b2fbaf 100644 --- a/gitprotocol-v2.html +++ b/gitprotocol-v2.html @@ -1484,6 +1484,228 @@ and associated requested information, each separated by a single space.

obj-info = obj-id SP obj-size +
+

bundle-uri

+

If the bundle-uri capability is advertised, the server supports the +‘bundle-uri’ command.

+

The capability is currently advertised with no value (i.e. not +"bundle-uri=somevalue"), a value may be added in the future for +supporting command-wide extensions. Clients MUST ignore any unknown +capability values and proceed with the 'bundle-uri` dialog they +support.

+

The bundle-uri command is intended to be issued before fetch to +get URIs to bundle files (see git-bundle(1)) to "seed" and +inform the subsequent fetch command.

+

The client CAN issue bundle-uri before or after any other valid +command. To be useful to clients it’s expected that it’ll be issued +after an ls-refs and before fetch, but CAN be issued at any time +in the dialog.

+
+

DISCUSSION of bundle-uri

+

The intent of the feature is optimize for server resource consumption +in the common case by changing the common case of fetching a very +large PACK during git-clone(1) into a smaller incremental +fetch.

+

It also allows servers to achieve better caching in combination with +an uploadpack.packObjectsHook (see git-config(1)).

+

By having new clones or fetches be a more predictable and common +negotiation against the tips of recently produces *.bundle file(s). +Servers might even pre-generate the results of such negotiations for +the uploadpack.packObjectsHook as new pushes come in.

+

One way that servers could take advantage of these bundles is that the +server would anticipate that fresh clones will download a known bundle, +followed by catching up to the current state of the repository using ref +tips found in that bundle (or bundles).

+
+
+

PROTOCOL for bundle-uri

+

A bundle-uri request takes no arguments, and as noted above does not +currently advertise a capability value. Both may be added in the +future.

+

When the client issues a command=bundle-uri request, the response is a +list of key-value pairs provided as packet lines with value +<key>=<value>. Each <key> should be interpreted as a config key from +the bundle.* namespace to construct a list of bundles. These keys are +grouped by a bundle.<id>. subsection, where each key corresponding to a +given <id> contributes attributes to the bundle defined by that <id>. +See git-config(1) for the specific details of these keys and how +the Git client will interpret their values.

+

Clients MUST parse the line according to the above format, lines that do +not conform to the format SHOULD be discarded. The user MAY be warned in +such a case.

+
+
+

bundle-uri CLIENT AND SERVER EXPECTATIONS

+
+
+URI CONTENTS +
+
+

+The content at the advertised URIs MUST be one of two types. +

+

The advertised URI may contain a bundle file that git bundle verify +would accept. I.e. they MUST contain one or more reference tips for +use by the client, MUST indicate prerequisites (in any) with standard +"-" prefixes, and MUST indicate their "object-format", if +applicable.

+

The advertised URI may alternatively contain a plaintext file that git +config --list would accept (with the --file option). The key-value +pairs in this list are in the bundle.* namespace (see +git-config(1)).

+
+
+bundle-uri CLIENT ERROR RECOVERY +
+
+

+A client MUST above all gracefully degrade on errors, whether that +error is because of bad missing/data in the bundle URI(s), because +that client is too dumb to e.g. understand and fully parse out bundle +headers and their prerequisite relationships, or something else. +

+

Server operators should feel confident in turning on "bundle-uri" and +not worry if e.g. their CDN goes down that clones or fetches will run +into hard failures. Even if the server bundle bundle(s) are +incomplete, or bad in some way the client should still end up with a +functioning repository, just as if it had chosen not to use this +protocol extension.

+

All subsequent discussion on client and server interaction MUST keep +this in mind.

+
+
+bundle-uri SERVER TO CLIENT +
+
+

+The ordering of the returned bundle uris is not significant. Clients +MUST parse their headers to discover their contained OIDS and +prerequisites. A client MUST consider the content of the bundle(s) +themselves and their header as the ultimate source of truth. +

+

A server MAY even return bundle(s) that don’t have any direct +relationship to the repository being cloned (either through accident, +or intentional "clever" configuration), and expect a client to sort +out what data they’d like from the bundle(s), if any.

+
+
+bundle-uri CLIENT TO SERVER +
+
+

+The client SHOULD provide reference tips found in the bundle header(s) +as have lines in any subsequent fetch request. A client MAY also +ignore the bundle(s) entirely if doing so is deemed worse for some +reason, e.g. if the bundles can’t be downloaded, it doesn’t like the +tips it finds etc. +

+
+
+WHEN ADVERTISED BUNDLE(S) REQUIRE NO FURTHER NEGOTIATION +
+
+

+If after issuing bundle-uri and ls-refs, and getting the header(s) +of the bundle(s) the client finds that the ref tips it wants can be +retrieved entirely from advertised bundle(s), the client MAY disconnect +from the Git server. The results of such a clone or fetch should be +indistinguishable from the state attained without using bundle-uri. +

+
+
+EARLY CLIENT DISCONNECTIONS AND ERROR RECOVERY +
+
+

+A client MAY perform an early disconnect while still downloading the +bundle(s) (having streamed and parsed their headers). In such a case +the client MUST gracefully recover from any errors related to +finishing the download and validation of the bundle(s). +

+

I.e. a client might need to re-connect and issue a fetch command, +and possibly fall back to not making use of bundle-uri at all.

+

This "MAY" behavior is specified as such (and not a "SHOULD") on the +assumption that a server advertising bundle uris is more likely than +not to be serving up a relatively large repository, and to be pointing +to URIs that have a good chance of being in working order. A client +MAY e.g. look at the payload size of the bundles as a heuristic to see +if an early disconnect is worth it, should falling back on a full +"fetch" dialog be necessary.

+
+
+WHEN ADVERTISED BUNDLE(S) REQUIRE FURTHER NEGOTIATION +
+
+

+A client SHOULD commence a negotiation of a PACK from the server via +the "fetch" command using the OID tips found in advertised bundles, +even if’s still in the process of downloading those bundle(s). +

+

This allows for aggressive early disconnects from any interactive +server dialog. The client blindly trusts that the advertised OID tips +are relevant, and issues them as have lines, it then requests any +tips it would like (usually from the "ls-refs" advertisement) via +want lines. The server will then compute a (hopefully small) PACK +with the expected difference between the tips from the bundle(s) and +the data requested.

+

The only connection the client then needs to keep active is to the +concurrently downloading static bundle(s), when those and the +incremental PACK are retrieved they should be inflated and +validated. Any errors at this point should be gracefully recovered +from, see above.

+
+
+
+
+

bundle-uri PROTOCOL FEATURES

+

The client constructs a bundle list from the <key>=<value> pairs +provided by the server. These pairs are part of the bundle.* namespace +as documented in git-config(1). In this section, we discuss some +of these keys and describe the actions the client will do in response to +this information.

+

In particular, the bundle.version key specifies an integer value. The +only accepted value at the moment is 1, but if the client sees an +unexpected value here then the client MUST ignore the bundle list.

+

As long as bundle.version is understood, all other unknown keys MAY be +ignored by the client. The server will guarantee compatibility with older +clients, though newer clients may be better able to use the extra keys to +minimize downloads.

+

Any backwards-incompatible addition of pre-URI key-value will be +guarded by a new bundle.version value or values in bundle-uri +capability advertisement itself, and/or by new future bundle-uri +request arguments.

+

Some example key-value pairs that are not currently implemented but could +be implemented in the future include:

+
    +
  • +

    +Add a "hash=<val>" or "size=<bytes>" advertise the expected hash or + size of the bundle file. +

    +
    • +
  • +

    +Advertise that one or more bundle files are the same (to e.g. have + clients round-robin or otherwise choose one of N possible files). +

    +
    • +
  • +

    +A "oid=<OID>" shortcut and "prerequisite=<OID>" shortcut. For + expressing the common case of a bundle with one tip and no + prerequisites, or one tip and one prerequisite. +

    +

    This would allow for optimizing the common case of servers who’d like +to provide one "big bundle" containing only their "main" branch, +and/or incremental updates thereof.

    +

    A client receiving such a a response MAY assume that they can skip +retrieving the header from a bundle at the indicated URI, and thus +save themselves and the server(s) the request(s) needed to inspect the +headers of that bundle or bundles.

    +
    • +
+
+
@@ -1497,7 +1719,7 @@ and associated requested information, each separated by a single space.

Last updated - 2022-09-22 07:44:34 JST + 2023-01-02 22:37:31 JST
diff --git a/gitprotocol-v2.txt b/gitprotocol-v2.txt index 59bf41cef..10bd2d40c 100644 --- a/gitprotocol-v2.txt +++ b/gitprotocol-v2.txt @@ -578,6 +578,207 @@ and associated requested information, each separated by a single space. obj-info = obj-id SP obj-size +bundle-uri +~~~~~~~~~~ + +If the 'bundle-uri' capability is advertised, the server supports the +`bundle-uri' command. + +The capability is currently advertised with no value (i.e. not +"bundle-uri=somevalue"), a value may be added in the future for +supporting command-wide extensions. Clients MUST ignore any unknown +capability values and proceed with the 'bundle-uri` dialog they +support. + +The 'bundle-uri' command is intended to be issued before `fetch` to +get URIs to bundle files (see linkgit:git-bundle[1]) to "seed" and +inform the subsequent `fetch` command. + +The client CAN issue `bundle-uri` before or after any other valid +command. To be useful to clients it's expected that it'll be issued +after an `ls-refs` and before `fetch`, but CAN be issued at any time +in the dialog. + +DISCUSSION of bundle-uri +^^^^^^^^^^^^^^^^^^^^^^^^ + +The intent of the feature is optimize for server resource consumption +in the common case by changing the common case of fetching a very +large PACK during linkgit:git-clone[1] into a smaller incremental +fetch. + +It also allows servers to achieve better caching in combination with +an `uploadpack.packObjectsHook` (see linkgit:git-config[1]). + +By having new clones or fetches be a more predictable and common +negotiation against the tips of recently produces *.bundle file(s). +Servers might even pre-generate the results of such negotiations for +the `uploadpack.packObjectsHook` as new pushes come in. + +One way that servers could take advantage of these bundles is that the +server would anticipate that fresh clones will download a known bundle, +followed by catching up to the current state of the repository using ref +tips found in that bundle (or bundles). + +PROTOCOL for bundle-uri +^^^^^^^^^^^^^^^^^^^^^^^ + +A `bundle-uri` request takes no arguments, and as noted above does not +currently advertise a capability value. Both may be added in the +future. + +When the client issues a `command=bundle-uri` request, the response is a +list of key-value pairs provided as packet lines with value +`=`. Each `` should be interpreted as a config key from +the `bundle.*` namespace to construct a list of bundles. These keys are +grouped by a `bundle..` subsection, where each key corresponding to a +given `` contributes attributes to the bundle defined by that ``. +See linkgit:git-config[1] for the specific details of these keys and how +the Git client will interpret their values. + +Clients MUST parse the line according to the above format, lines that do +not conform to the format SHOULD be discarded. The user MAY be warned in +such a case. + +bundle-uri CLIENT AND SERVER EXPECTATIONS +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +URI CONTENTS:: +The content at the advertised URIs MUST be one of two types. ++ +The advertised URI may contain a bundle file that `git bundle verify` +would accept. I.e. they MUST contain one or more reference tips for +use by the client, MUST indicate prerequisites (in any) with standard +"-" prefixes, and MUST indicate their "object-format", if +applicable. ++ +The advertised URI may alternatively contain a plaintext file that `git +config --list` would accept (with the `--file` option). The key-value +pairs in this list are in the `bundle.*` namespace (see +linkgit:git-config[1]). + +bundle-uri CLIENT ERROR RECOVERY:: +A client MUST above all gracefully degrade on errors, whether that +error is because of bad missing/data in the bundle URI(s), because +that client is too dumb to e.g. understand and fully parse out bundle +headers and their prerequisite relationships, or something else. ++ +Server operators should feel confident in turning on "bundle-uri" and +not worry if e.g. their CDN goes down that clones or fetches will run +into hard failures. Even if the server bundle bundle(s) are +incomplete, or bad in some way the client should still end up with a +functioning repository, just as if it had chosen not to use this +protocol extension. ++ +All subsequent discussion on client and server interaction MUST keep +this in mind. + +bundle-uri SERVER TO CLIENT:: +The ordering of the returned bundle uris is not significant. Clients +MUST parse their headers to discover their contained OIDS and +prerequisites. A client MUST consider the content of the bundle(s) +themselves and their header as the ultimate source of truth. ++ +A server MAY even return bundle(s) that don't have any direct +relationship to the repository being cloned (either through accident, +or intentional "clever" configuration), and expect a client to sort +out what data they'd like from the bundle(s), if any. + +bundle-uri CLIENT TO SERVER:: +The client SHOULD provide reference tips found in the bundle header(s) +as 'have' lines in any subsequent `fetch` request. A client MAY also +ignore the bundle(s) entirely if doing so is deemed worse for some +reason, e.g. if the bundles can't be downloaded, it doesn't like the +tips it finds etc. + +WHEN ADVERTISED BUNDLE(S) REQUIRE NO FURTHER NEGOTIATION:: +If after issuing `bundle-uri` and `ls-refs`, and getting the header(s) +of the bundle(s) the client finds that the ref tips it wants can be +retrieved entirely from advertised bundle(s), the client MAY disconnect +from the Git server. The results of such a 'clone' or 'fetch' should be +indistinguishable from the state attained without using bundle-uri. + +EARLY CLIENT DISCONNECTIONS AND ERROR RECOVERY:: +A client MAY perform an early disconnect while still downloading the +bundle(s) (having streamed and parsed their headers). In such a case +the client MUST gracefully recover from any errors related to +finishing the download and validation of the bundle(s). ++ +I.e. a client might need to re-connect and issue a 'fetch' command, +and possibly fall back to not making use of 'bundle-uri' at all. ++ +This "MAY" behavior is specified as such (and not a "SHOULD") on the +assumption that a server advertising bundle uris is more likely than +not to be serving up a relatively large repository, and to be pointing +to URIs that have a good chance of being in working order. A client +MAY e.g. look at the payload size of the bundles as a heuristic to see +if an early disconnect is worth it, should falling back on a full +"fetch" dialog be necessary. + +WHEN ADVERTISED BUNDLE(S) REQUIRE FURTHER NEGOTIATION:: +A client SHOULD commence a negotiation of a PACK from the server via +the "fetch" command using the OID tips found in advertised bundles, +even if's still in the process of downloading those bundle(s). ++ +This allows for aggressive early disconnects from any interactive +server dialog. The client blindly trusts that the advertised OID tips +are relevant, and issues them as 'have' lines, it then requests any +tips it would like (usually from the "ls-refs" advertisement) via +'want' lines. The server will then compute a (hopefully small) PACK +with the expected difference between the tips from the bundle(s) and +the data requested. ++ +The only connection the client then needs to keep active is to the +concurrently downloading static bundle(s), when those and the +incremental PACK are retrieved they should be inflated and +validated. Any errors at this point should be gracefully recovered +from, see above. + +bundle-uri PROTOCOL FEATURES +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The client constructs a bundle list from the `=` pairs +provided by the server. These pairs are part of the `bundle.*` namespace +as documented in linkgit:git-config[1]. In this section, we discuss some +of these keys and describe the actions the client will do in response to +this information. + +In particular, the `bundle.version` key specifies an integer value. The +only accepted value at the moment is `1`, but if the client sees an +unexpected value here then the client MUST ignore the bundle list. + +As long as `bundle.version` is understood, all other unknown keys MAY be +ignored by the client. The server will guarantee compatibility with older +clients, though newer clients may be better able to use the extra keys to +minimize downloads. + +Any backwards-incompatible addition of pre-URI key-value will be +guarded by a new `bundle.version` value or values in 'bundle-uri' +capability advertisement itself, and/or by new future `bundle-uri` +request arguments. + +Some example key-value pairs that are not currently implemented but could +be implemented in the future include: + + * Add a "hash=" or "size=" advertise the expected hash or + size of the bundle file. + + * Advertise that one or more bundle files are the same (to e.g. have + clients round-robin or otherwise choose one of N possible files). + + * A "oid=" shortcut and "prerequisite=" shortcut. For + expressing the common case of a bundle with one tip and no + prerequisites, or one tip and one prerequisite. ++ +This would allow for optimizing the common case of servers who'd like +to provide one "big bundle" containing only their "main" branch, +and/or incremental updates thereof. ++ +A client receiving such a a response MAY assume that they can skip +retrieving the header from a bundle at the indicated URI, and thus +save themselves and the server(s) the request(s) needed to inspect the +headers of that bundle or bundles. + GIT --- Part of the linkgit:git[1] suite diff --git a/howto/coordinate-embargoed-releases.html b/howto/coordinate-embargoed-releases.html index 9aa132074..59d760219 100644 --- a/howto/coordinate-embargoed-releases.html +++ b/howto/coordinate-embargoed-releases.html @@ -1038,7 +1038,7 @@ Thanks, diff --git a/howto/keep-canonical-history-correct.html b/howto/keep-canonical-history-correct.html index 1b1d5f1ba..4714f742c 100644 --- a/howto/keep-canonical-history-correct.html +++ b/howto/keep-canonical-history-correct.html @@ -938,7 +938,7 @@ tip of your master again and redo the two merges:

diff --git a/howto/maintain-git.html b/howto/maintain-git.html index c1e159859..18a64f33d 100644 --- a/howto/maintain-git.html +++ b/howto/maintain-git.html @@ -1478,7 +1478,7 @@ $ git update-ref -d $mf/ai/topic diff --git a/howto/new-command.html b/howto/new-command.html index 1823b3415..782c76d92 100644 --- a/howto/new-command.html +++ b/howto/new-command.html @@ -863,7 +863,7 @@ letter [PATCH 0/n]. diff --git a/howto/rebase-from-internal-branch.html b/howto/rebase-from-internal-branch.html index be4f15217..327b6bdb2 100644 --- a/howto/rebase-from-internal-branch.html +++ b/howto/rebase-from-internal-branch.html @@ -895,7 +895,7 @@ the #1' commit.

diff --git a/howto/rebuild-from-update-hook.html b/howto/rebuild-from-update-hook.html index f0b255d94..c6ade29bf 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 diff --git a/howto/recover-corrupted-blob-object.html b/howto/recover-corrupted-blob-object.html index dc179ce18..768df1251 100644 --- a/howto/recover-corrupted-blob-object.html +++ b/howto/recover-corrupted-blob-object.html @@ -880,7 +880,7 @@ thing.

diff --git a/howto/recover-corrupted-object-harder.html b/howto/recover-corrupted-object-harder.html index 697ddc679..f5721b92a 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) diff --git a/howto/revert-a-faulty-merge.html b/howto/revert-a-faulty-merge.html index 0fbaffe82..0eb529d27 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 diff --git a/howto/revert-branch-rebase.html b/howto/revert-branch-rebase.html index 7f6f1565b..7039f81a8 100644 --- a/howto/revert-branch-rebase.html +++ b/howto/revert-branch-rebase.html @@ -907,7 +907,7 @@ Committed merge 7fb9b7262a1d1e0a47bbfdcbbcf50ce0635d3f8f diff --git a/howto/separating-topic-branches.html b/howto/separating-topic-branches.html index 20c707b59..0852b3268 100644 --- a/howto/separating-topic-branches.html +++ b/howto/separating-topic-branches.html @@ -841,7 +841,7 @@ o---o"master" diff --git a/howto/setup-git-server-over-http.html b/howto/setup-git-server-over-http.html index b3ff10e1b..91f2a750d 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.

diff --git a/howto/update-hook-example.html b/howto/update-hook-example.html index c4c76c6a0..0c93aa6f1 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.

diff --git a/howto/use-git-daemon.html b/howto/use-git-daemon.html index 51e110a31..ea9e1ddf7 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.

diff --git a/howto/using-merge-subtree.html b/howto/using-merge-subtree.html index 0caa1e145..8cf4acf65 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 diff --git a/howto/using-signed-tag-in-pull-request.html b/howto/using-signed-tag-in-pull-request.html index 354c06b4c..ac20d4c52 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.

-- cgit 1.2.3-korg