SHA-256 migration work continues.
* bc/sha-256-part-2: (44 commits)
remote-testgit: adapt for object-format
bundle: detect hash algorithm when reading refs
t5300: pass --object-format to git index-pack
t5704: send object-format capability with SHA-256
t5703: use object-format serve option
t5702: offer an object-format capability in the test
t/helper: initialize the repository for test-sha1-array
remote-curl: avoid truncating refs with ls-remote
t1050: pass algorithm to index-pack when outside repo
builtin/index-pack: add option to specify hash algorithm
remote-curl: detect algorithm for dumb HTTP by size
builtin/ls-remote: initialize repository based on fetch
t5500: make hash independent
serve: advertise object-format capability for protocol v2
connect: parse v2 refs with correct hash algorithm
connect: pass full packet reader when parsing v2 refs
Documentation/technical: document object-format for protocol v2
t1302: expect repo format version 1 for SHA-256
builtin/show-index: provide options to determine hash algo
t5302: modernize test formatting
...
@ -36,6 +36,15 @@ Note that you can get more information on a packfile by calling
@@ -36,6 +36,15 @@ Note that you can get more information on a packfile by calling
linkgit:git-verify-pack[1]. However, as this command considers only the
index file itself, it's both faster and more flexible.
OPTIONS
-------
--object-format=<hash-algorithm>::
Specify the given object format (hash algorithm) for the index file. The
valid values are 'sha1' and (if enabled) 'sha256'. The default is the
algorithm for the current repository (set by `extensions.objectFormat`), or
'sha1' if no value is set or outside a repository..
@ -238,6 +238,9 @@ the remote repository.
@@ -238,6 +238,9 @@ the remote repository.
`--signed-tags=verbatim` to linkgit:git-fast-export[1]. In the
absence of this capability, Git will use `--signed-tags=warn-strip`.
'object-format'::
This indicates that the helper is able to interact with the remote
side using an explicit hash algorithm extension.
COMMANDS
@ -257,12 +260,14 @@ Support for this command is mandatory.
@@ -257,12 +260,14 @@ Support for this command is mandatory.
'list'::
Lists the refs, one per line, in the format "<value> <name>
[<attr> ...]". The value may be a hex sha1 hash, "@<dest>" for
a symref, or "?" to indicate that the helper could not get the
value of the ref. A space-separated list of attributes follows
the name; unrecognized attributes are ignored. The list ends
with a blank line.
a symref, ":<keyword> <value>" for a key-value pair, or
"?" to indicate that the helper could not get the value of the
ref. A space-separated list of attributes follows the name;
unrecognized attributes are ignored. The list ends with a
blank line.
+
See REF LIST ATTRIBUTES for a list of currently defined attributes.
See REF LIST KEYWORDS for a list of currently defined keywords.
+
Supported if the helper has the "fetch" or "import" capability.
@ -432,6 +437,18 @@ attributes are defined.
@@ -432,6 +437,18 @@ attributes are defined.
This ref is unchanged since the last import or fetch, although
the helper cannot necessarily determine what value that produced.
REF LIST KEYWORDS
-----------------
The 'list' command may produce a list of key-value pairs.
The following keys are defined.
'object-format'::
The refs are using the given hash algorithm. This keyword is only
used if the server and client both support the object-format
extension.
OPTIONS
-------
@ -516,6 +533,14 @@ set by Git if the remote helper has the 'option' capability.
@@ -516,6 +533,14 @@ set by Git if the remote helper has the 'option' capability.
transaction. If successful, all refs will be updated, or none will. If the
remote side does not support this capability, the push will fail.
'option object-format' {'true'|algorithm}::
If 'true', indicate that the caller wants hash algorithm information
to be passed back from the remote. This mode is used when fetching
refs.
+
If set to an algorithm, indicate that the caller wants to interact with
@ -176,6 +176,21 @@ agent strings are purely informative for statistics and debugging
@@ -176,6 +176,21 @@ agent strings are purely informative for statistics and debugging
purposes, and MUST NOT be used to programmatically assume the presence
or absence of particular features.
object-format
-------------
This capability, which takes a hash algorithm as an argument, indicates
that the server supports the given hash algorithms. It may be sent
multiple times; if so, the first one given is the one used in the ref
advertisement.
When provided by the client, this indicates that it intends to use the
given hash algorithm to communicate. The algorithm provided must be one
that the server supports.
If this capability is not provided, it is assumed that the only
@ -483,3 +483,12 @@ included in a request. This is done by sending each option as a
@@ -483,3 +483,12 @@ included in a request. This is done by sending each option as a
a request.
The provided options must not contain a NUL or LF character.
object-format
~~~~~~~~~~~~~~~
The server can advertise the `object-format` capability with a value `X` (in the
form `object-format=X`) to notify the client that the server is able to deal
with objects using hash algorithm X. If not specified, the server is assumed to
only handle SHA-1. If the client would like to use a hash algorithm other than
SHA-1, it should specify its object-format string.
@ -7,65 +7,65 @@ test_description='pack index with 64-bit offsets and object CRC'
@@ -7,65 +7,65 @@ test_description='pack index with 64-bit offsets and object CRC'
'index-pack results should match pack-objects ones' \
'cmp "test-1-${pack1}.idx" "1.idx" &&
cmp "test-2-${pack2}.idx" "2.idx"'
test_expect_success 'index-pack results should match pack-objects ones' '
cmp "test-1-${pack1}.idx" "1.idx" &&
cmp "test-2-${pack2}.idx" "2.idx"
'
test_expect_success 'index-pack --verify on index version 1' '
git index-pack --verify "test-1-${pack1}.pack"
@ -75,13 +75,13 @@ test_expect_success 'index-pack --verify on index version 2' '
@@ -75,13 +75,13 @@ test_expect_success 'index-pack --verify on index version 2' '
git index-pack --verify "test-2-${pack2}.pack"
'
test_expect_success \
'pack-objects --index-version=2, is not accepted' \
@ -871,9 +871,10 @@ test_expect_success 'shallow since with commit graph and already-seen commit' '
@@ -871,9 +871,10 @@ test_expect_success 'shallow since with commit graph and already-seen commit' '
@ -200,6 +224,7 @@ test_expect_success 'unexpected lines are not allowed in fetch request' '
@@ -200,6 +224,7 @@ test_expect_success 'unexpected lines are not allowed in fetch request' '
test_expect_success 'create repo to be served by git-daemon' '
test_oid_init &&
git init "$daemon_parent" &&
test_commit -C "$daemon_parent" one
'
@ -393,6 +394,7 @@ test_expect_success 'even with handcrafted request, filter does not work if not
@@ -393,6 +394,7 @@ test_expect_success 'even with handcrafted request, filter does not work if not
# Custom request that tries to filter even though it is not advertised.
@ -132,7 +141,7 @@ test_expect_success 'mix want and want-ref' '
@@ -132,7 +141,7 @@ test_expect_success 'mix want and want-ref' '
git rev-parse e f >expected_commits &&
test-tool pkt-line pack >in <<-EOF &&
command=fetch
$(write_command fetch)
0001
no-progress
want-ref refs/heads/master
@ -155,7 +164,7 @@ test_expect_success 'want-ref with ref we already have commit for' '
@@ -155,7 +164,7 @@ test_expect_success 'want-ref with ref we already have commit for' '
@ -9,6 +9,7 @@ making sure that we do not segfault or otherwise behave badly.'
@@ -9,6 +9,7 @@ making sure that we do not segfault or otherwise behave badly.'
test_expect_success 'extra delim packet in v2 ls-refs args' '
@ -157,11 +160,14 @@ static int fetch_refs_from_bundle(struct transport *transport,
@@ -157,11 +160,14 @@ static int fetch_refs_from_bundle(struct transport *transport,