-
Notifications
You must be signed in to change notification settings - Fork 137
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pack-objects: Create an alternative name hash algorithm (recreated) #1823
base: master
Are you sure you want to change the base?
Changes from all commits
68b4127
d035e3e
e219124
86ff0d0
163aaab
e9ce79f
18a41f2
3d63954
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -15,7 +15,8 @@ SYNOPSIS | |
[--revs [--unpacked | --all]] [--keep-pack=<pack-name>] | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. On the Git mailing list, karthik nayak wrote (reply to this): "Derrick Stolee via GitGitGadget" <[email protected]> writes:
[snip]
> diff --git a/builtin/repack.c b/builtin/repack.c
> index d6bb37e84ae..05e13adb87f 100644
> --- a/builtin/repack.c
> +++ b/builtin/repack.c
> @@ -58,6 +58,7 @@ struct pack_objects_args {
> int no_reuse_object;
> int quiet;
> int local;
> + int full_name_hash;
> struct list_objects_filter_options filter_options;
> };
>
This variable doesn't seem to be used anywhere in this commit, and the
following commit replaces it. I'm guessing it is from the previous
version.
[snip] |
||
[--cruft] [--cruft-expiration=<time>] | ||
[--stdout [--filter=<filter-spec>] | <base-name>] | ||
[--shallow] [--keep-true-parents] [--[no-]sparse] < <object-list> | ||
[--shallow] [--keep-true-parents] [--[no-]sparse] | ||
[--name-hash-version=<n>] < <object-list> | ||
|
||
|
||
DESCRIPTION | ||
|
@@ -345,6 +346,44 @@ raise an error. | |
Restrict delta matches based on "islands". See DELTA ISLANDS | ||
below. | ||
|
||
--name-hash-version=<n>:: | ||
While performing delta compression, Git groups objects that may be | ||
similar based on heuristics using the path to that object. While | ||
grouping objects by an exact path match is good for paths with | ||
many versions, there are benefits for finding delta pairs across | ||
different full paths. Git collects objects by type and then by a | ||
"name hash" of the path and then by size, hoping to group objects | ||
that will compress well together. | ||
+ | ||
The default name hash version is `1`, which prioritizes hash locality by | ||
considering the final bytes of the path as providing the maximum magnitude | ||
to the hash function. This version excels at distinguishing short paths | ||
and finding renames across directories. However, the hash function depends | ||
primarily on the final 16 bytes of the path. If there are many paths in | ||
the repo that have the same final 16 bytes and differ only by parent | ||
directory, then this name-hash may lead to too many collisions and cause | ||
poor results. At the moment, this version is required when writing | ||
reachability bitmap files with `--write-bitmap-index`. | ||
+ | ||
The name hash version `2` has similar locality features as version `1`, | ||
except it considers each path component separately and overlays the hashes | ||
with a shift. This still prioritizes the final bytes of the path, but also | ||
"salts" the lower bits of the hash using the parent directory names. This | ||
method allows for some of the locality benefits of version `1` while | ||
breaking most of the collisions from a similarly-named file appearing in | ||
many different directories. At the moment, this version is not allowed | ||
when writing reachability bitmap files with `--write-bitmap-index` and it | ||
will be automatically changed to version `1`. | ||
+ | ||
The name hash version `3` abandons the locality features of versions `1` | ||
and `2` in favor of minimizing collisions. The goal here is to separate | ||
objects by their full path and abandon hope for cross-path delta | ||
compression. For this reason, this option is preferred for repacking large | ||
repositories with many versions and many name hash collisions when using | ||
the first two versions. At the moment, this version is not allowed when | ||
writing reachability bitmap files with `--write-bitmap-index` and it will | ||
be automatically changed to version `1`. | ||
|
||
|
||
DELTA ISLANDS | ||
------------- | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -9,7 +9,9 @@ git-repack - Pack unpacked objects in a repository | |
SYNOPSIS | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. On the Git mailing list, Taylor Blau wrote (reply to this): On Tue, Nov 05, 2024 at 03:05:04AM +0000, Derrick Stolee via GitGitGadget wrote:
> From: Derrick Stolee <[email protected]>
>
> This also adds the '--full-name-hash' option introduced in the previous
> change and adds newlines to the synopsis.
I think "the previous change" is not quite accurate here, even if
you move the implementation to pass through '--full-name-hash' via
repack into the second patch.
It would be nice to have the option added in 'repack' in the same commit
as adjusts the documentation instead of splitting them apart.
Thanks,
Taylor There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. On the Git mailing list, Derrick Stolee wrote (reply to this): On 11/21/24 3:17 PM, Taylor Blau wrote:
> On Tue, Nov 05, 2024 at 03:05:04AM +0000, Derrick Stolee via GitGitGadget wrote:
>> From: Derrick Stolee <[email protected]>
>>
>> This also adds the '--full-name-hash' option introduced in the previous
>> change and adds newlines to the synopsis.
> > I think "the previous change" is not quite accurate here, even if
> you move the implementation to pass through '--full-name-hash' via
> repack into the second patch.
Ah, I should definitely rearrange the commits.
> It would be nice to have the option added in 'repack' in the same commit
> as adjusts the documentation instead of splitting them apart.
Part of the point of the split was that the synopsis in builtin/repack.c
needs more than just the addition of the --full-name-hash option in order
to make it match the Documentation synopsis.
But you're right, the code change is small enough that these things can
be combined.
Thanks,
-Stolee
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. On the Git mailing list, karthik nayak wrote (reply to this): "Derrick Stolee via GitGitGadget" <[email protected]> writes:
[snip]
> DESCRIPTION
> -----------
> @@ -249,6 +251,36 @@ linkgit:git-multi-pack-index[1]).
> Write a multi-pack index (see linkgit:git-multi-pack-index[1])
> containing the non-redundant packs.
>
> +--name-hash-version=<n>::
> + While performing delta compression, Git groups objects that may be
> + similar based on heuristics using the path to that object. While
> + grouping objects by an exact path match is good for paths with
> + many versions, there are benefits for finding delta pairs across
> + different full paths. Git collects objects by type and then by a
> + "name hash" of the path and then by size, hoping to group objects
> + that will compress well together.
> ++
> +The default name hash version is `1`, which prioritizes hash locality by
> +considering the final bytes of the path as providing the maximum magnitude
> +to the hash function. This version excels at distinguishing short paths
> +and finding renames across directories. However, the hash function depends
> +primarily on the final 16 bytes of the path. If there are many paths in
> +the repo that have the same final 16 bytes and differ only by parent
> +directory, then this name-hash may lead to too many collisions and cause
> +poor results. At the moment, this version is required when writing
> +reachability bitmap files with `--write-bitmap-index`.
> ++
> +The name hash version `2` has similar locality features as version `1`,
> +except it considers each path component separately and overlays the hashes
> +with a shift. This still prioritizes the final bytes of the path, but also
> +"salts" the lower bits of the hash using the parent directory names. This
> +method allows for some of the locality benefits of version `1` while
> +breaking most of the collisions from a similarly-named file appearing in
> +many different directories. At the moment, this version is not allowed
> +when writing reachability bitmap files with `--write-bitmap-index` and it
> +will be automatically changed to version `1`.
> +
> +
Nit: I wonder if it'd be nicer to simply point to the documentation in
'Documentation/git-pack-objects.txt'. This would ensure we have
consistent documentation and a single source of truth.
>
> CONFIGURATION
> -------------
>
> diff --git a/builtin/repack.c b/builtin/repack.c
> index 05e13adb87f..5e7ff919c1a 100644
> --- a/builtin/repack.c
> +++ b/builtin/repack.c
> @@ -39,7 +39,9 @@ static int run_update_server_info = 1;
> static char *packdir, *packtmp_name, *packtmp;
>
> static const char *const git_repack_usage[] = {
> - N_("git repack [<options>]"),
> + N_("git repack [-a] [-A] [-d] [-f] [-F] [-l] [-n] [-q] [-b] [-m]\n"
> + "[--window=<n>] [--depth=<n>] [--threads=<n>] [--keep-pack=<pack-name>]\n"
> + "[--write-midx] [--name-hash-version=<n>]"),
> NULL
> };
So this fixes the mismatch in t0450 which is seen below.
Nit: might be worthwhile adding this in the commit message.
[snip] |
||
-------- | ||
[verse] | ||
'git repack' [-a] [-A] [-d] [-f] [-F] [-l] [-n] [-q] [-b] [-m] [--window=<n>] [--depth=<n>] [--threads=<n>] [--keep-pack=<pack-name>] [--write-midx] | ||
'git repack' [-a] [-A] [-d] [-f] [-F] [-l] [-n] [-q] [-b] [-m] | ||
[--window=<n>] [--depth=<n>] [--threads=<n>] [--keep-pack=<pack-name>] | ||
[--write-midx] [--name-hash-version=<n>] | ||
|
||
DESCRIPTION | ||
----------- | ||
|
@@ -249,6 +251,11 @@ linkgit:git-multi-pack-index[1]). | |
Write a multi-pack index (see linkgit:git-multi-pack-index[1]) | ||
containing the non-redundant packs. | ||
|
||
--name-hash-version=<n>:: | ||
Provide this argument to the underlying `git pack-objects` process. | ||
See linkgit:git-pack-objects[1] for full details. | ||
|
||
|
||
CONFIGURATION | ||
------------- | ||
|
||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -816,6 +816,7 @@ TEST_BUILTINS_OBJS += test-lazy-init-name-hash.o | |
TEST_BUILTINS_OBJS += test-match-trees.o | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. On the Git mailing list, Taylor Blau wrote (reply to this): On Tue, Nov 05, 2024 at 03:05:07AM +0000, Derrick Stolee via GitGitGadget wrote:
> Test this tree
> -----------------------------------------------------------------
> 5314.1: paths at head 4.5K
> 5314.2: number of distinct name-hashes 4.1K
> 5314.3: number of distinct full-name-hashes 4.5K
> 5314.4: maximum multiplicity of name-hashes 13
> 5314.5: maximum multiplicity of fullname-hashes 1
>
> Here, the maximum collision multiplicity is 13, but around 10% of paths
> have a collision with another path.
Neat.
> diff --git a/t/helper/test-name-hash.c b/t/helper/test-name-hash.c
> new file mode 100644
> index 00000000000..e4ecd159b76
> --- /dev/null
> +++ b/t/helper/test-name-hash.c
> @@ -0,0 +1,24 @@
> +/*
> + * test-name-hash.c: Read a list of paths over stdin and report on their
> + * name-hash and full name-hash.
> + */
> +
> +#include "test-tool.h"
> +#include "git-compat-util.h"
> +#include "pack-objects.h"
> +#include "strbuf.h"
> +
> +int cmd__name_hash(int argc UNUSED, const char **argv UNUSED)
> +{
> + struct strbuf line = STRBUF_INIT;
> +
> + while (!strbuf_getline(&line, stdin)) {
> + uint32_t name_hash = pack_name_hash(line.buf);
> + uint32_t full_hash = pack_full_name_hash(line.buf);
> +
> + printf("%10"PRIu32"\t%10"PRIu32"\t%s\n", name_hash, full_hash, line.buf);
I'm definitely nitpicking, but having a tab to separate these two 32-bit
values feels odd when we know already that they will be at most
10-characters wide.
I probably would have written:
printf("%10"PRIu32" %10"PRIu32"\t%s\n", name_hash, full_hash, line.buf);
instead, but this is obviously not a big deal either way ;-).
> diff --git a/t/perf/p5314-name-hash.sh b/t/perf/p5314-name-hash.sh
> new file mode 100755
> index 00000000000..9fe26612fac
> --- /dev/null
> +++ b/t/perf/p5314-name-hash.sh
> @@ -0,0 +1,41 @@
> +#!/bin/sh
> +
> +test_description='Tests pack performance using bitmaps'
> +. ./perf-lib.sh
> +
> +GIT_TEST_PASSING_SANITIZE_LEAK=0
> +export GIT_TEST_PASSING_SANITIZE_LEAK
Does this conflict with Patrick's series to remove these leak checking
annotations? I think it might, which is not unexpected given this series
was written before that one (and it's my fault for not reviewing it
earlier).
> +test_perf_large_repo
> +
> +test_size 'paths at head' '
> + git ls-tree -r --name-only HEAD >path-list &&
> + wc -l <path-list
> +'
> +
> +test_size 'number of distinct name-hashes' '
> + cat path-list | test-tool name-hash >name-hashes &&
> + cat name-hashes | awk "{ print \$1; }" | sort -n | uniq -c >name-hash-count &&
In these two (and a handful of others lower down in this same script)
the "cat ... |" is unnecessary. I think this one should be written as:
test-tool name-hash <path-list >name-hashes &&
awk "{ print \$1; }" <name-hashes | sort | uniq -c >name-hash-count &&
(sort -n is unnecessary, since we just care about getting the list in
sorted order so that "uniq -c" can count the number of unique values).
> + wc -l <name-hash-count
> +'
> +
> +test_size 'number of distinct full-name-hashes' '
> + cat name-hashes | awk "{ print \$2; }" | sort -n | uniq -c >full-name-hash-count &&
> + wc -l <full-name-hash-count
> +'
> +
> +test_size 'maximum multiplicity of name-hashes' '
> + cat name-hash-count | \
> + sort -nr | \
> + head -n 1 | \
> + awk "{ print \$1; }"
> +'
> +
> +test_size 'maximum multiplicity of fullname-hashes' '
> + cat full-name-hash-count | \
> + sort -nr | \
> + head -n 1 | \
> + awk "{ print \$1; }"
Nitpicking again, but you could extract the "sort | head | awk" pipeline
into a function.
Thanks,
Taylor There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. On the Git mailing list, Jonathan Tan wrote (reply to this): "Derrick Stolee via GitGitGadget" <[email protected]> writes:
> From: Derrick Stolee <[email protected]>
>
> Add a new test-tool helper, name-hash, to output the value of the
> name-hash algorithms for the input list of strings, one per line.
I've looked at all 7 patches.
I didn't really understand the concern with shallow in patch 6 (in
particular, the documentation of "git pack-objects --shallow" seems
to imply that it's for use by a server to a shallow client, but at
the point that the server would need such a feature, it probably would
already have bitmaps packed with the new hash algorithm). I didn't look
at it further, though, since I had an algorithm that seemed to also do
OK in the shallow test. So we might be able to drop patch 6.
Other than that, and other than all my comments and Taylor's comments,
this series looks good.
|
||
TEST_BUILTINS_OBJS += test-mergesort.o | ||
TEST_BUILTINS_OBJS += test-mktemp.o | ||
TEST_BUILTINS_OBJS += test-name-hash.o | ||
TEST_BUILTINS_OBJS += test-online-cpus.o | ||
TEST_BUILTINS_OBJS += test-pack-mtimes.o | ||
TEST_BUILTINS_OBJS += test-parse-options.o | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -266,6 +266,39 @@ struct configured_exclusion { | |
static struct oidmap configured_exclusions; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. On the Git mailing list, Taylor Blau wrote (reply to this): On Tue, Nov 05, 2024 at 03:05:03AM +0000, Derrick Stolee via GitGitGadget wrote:
> diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh
> index 2e28d02b20f..75b40f07bbd 100755
> --- a/ci/run-build-and-tests.sh
> +++ b/ci/run-build-and-tests.sh
> @@ -30,6 +30,7 @@ linux-TEST-vars)
> export GIT_TEST_NO_WRITE_REV_INDEX=1
> export GIT_TEST_CHECKOUT_WORKERS=2
> export GIT_TEST_PACK_USE_BITMAP_BOUNDARY_TRAVERSAL=1
> + export GIT_TEST_FULL_NAME_HASH=1
> ;;
> linux-clang)
> export GIT_TEST_DEFAULT_HASH=sha1
Hmm. I appreciate what this new GIT_TEST_ variable is trying to do, but
I am somewhat saddened to see this list in linux-TEST-vars growing
rather than shrinking.
I'm most definitely part of the problem here, but I think too often we
add new entries to this list and let them languish without ever removing
them after they have served their intended purpose.
So I think the question is: what do we hope to get out of running the
test suite in a mode where we use the full-name hash all of the time? I
can't imagine any interesting breakage (other than individual tests'
sensitivity to specific delta/base pairs) that would be caught by merely
changing the hash function here.
I dunno. Maybe there is some exotic behavior that this shook out for you
during development which I'm not aware of. If that were the case, I
think that keeping this variable around makes sense, since the appearance
of that exotic behavior proves that the variable is useful at shaking
out bugs.
But assuming not, I think that I would just as soon avoid this test
variable entirely, which I think in this case amounts to dropping this
patch from the series.
Thanks,
Taylor There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. On the Git mailing list, Derrick Stolee wrote (reply to this): On 11/21/24 3:15 PM, Taylor Blau wrote:
> On Tue, Nov 05, 2024 at 03:05:03AM +0000, Derrick Stolee via GitGitGadget wrote:
>> diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh
>> index 2e28d02b20f..75b40f07bbd 100755
>> --- a/ci/run-build-and-tests.sh
>> +++ b/ci/run-build-and-tests.sh
>> @@ -30,6 +30,7 @@ linux-TEST-vars)
>> export GIT_TEST_NO_WRITE_REV_INDEX=1
>> export GIT_TEST_CHECKOUT_WORKERS=2
>> export GIT_TEST_PACK_USE_BITMAP_BOUNDARY_TRAVERSAL=1
>> + export GIT_TEST_FULL_NAME_HASH=1
>> ;;
>> linux-clang)
>> export GIT_TEST_DEFAULT_HASH=sha1
> > Hmm. I appreciate what this new GIT_TEST_ variable is trying to do, but
> I am somewhat saddened to see this list in linux-TEST-vars growing
> rather than shrinking.
You make good points that this does not need to be here.
It's enough that someone could manually check the test suite
with this test variable to make sure that enough of the other
options are tested with this feature.
Thanks,
-Stolee
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. On the Git mailing list, Jonathan Tan wrote (reply to this): "Derrick Stolee via GitGitGadget" <[email protected]> writes:
> Second, there are two tests in t5616-partial-clone.sh that I believe are
> actually broken scenarios.
I took a look...this is a tricky one.
> While the client is set up to clone the
> 'promisor-server' repo via a treeless partial clone filter (tree:0),
> that filter does not translate to the 'server' repo. Thus, fetching from
> these repos causes the server to think that the client has all reachable
> trees and blobs from the commits advertised as 'haves'. This leads the
> server to providing a thin pack assuming those objects as delta bases.
It is expected that the server sometimes sends deltas based on objects
that the client doesn't have. In fact, this test tests the ability of
Git to lazy-fetch delta bases.
> Changing the name-hash algorithm presents new delta bases and thus
> breaks the expectations of these tests.
To be precise, the change resulted in no deltas being sent (before this
change, one delta was sent). Here's what is meant to happen. The server has:
commitB - treeB - file1 ("make the tree big\nanother line\n"), file2...file100
|
commitA - treeA - file1...file100 ("make the tree big\n")
The client only has commitA. (The client does not have treeA or any
blob, since it was cloned with --filter=tree:0.)
When GIT_TEST_FULL_NAME_HASH=0 (matching the current behavior), the
server sends a non-delta commitB, a delta treeB (with base treeA), and
a non-delta blob "make the tree big\nanother line\n". This triggers a
lazy fetch of treeA, and thus treeB is inflated successfully. During
the subsequent connectivity check (with --exclude-promisor-objects,
see connected.c), it is noticed that the "make the tree big\n" blob is
missing, but since it is a promisor object (referenced by treeA, which
was fetched from the promisor remote), the connectivity check since
passes.
When GIT_TEST_FULL_NAME_HASH=1, the server sends a non-delta commitB,
a non-delta treeB, and a non-delta blob "make the tree big\nanother
line\n". No lazy fetch is triggered. During the subsequent connectivity
check, the "make the tree big\n" blob (referenced by treeB) is missing.
There is nothing that can vouch for it (the client does not have treeA,
remember) so the client does not consider it a promisor object, and thus
the connectivity check fails.
Investigating this was made a bit harder due to a missing "git -C
promisor-remote config --local uploadpack.allowfilter 1" in the test.
The above behavior is after this is included in the test.
I think the solution is to have an algorithm that preserves the property
that treeB is sent as a delta object - if not, we need to find another
way to test the lazy-fetch of delta bases. My proposal in [1] does do
that.
[1] https://lore.kernel.org/git/[email protected]/
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. On the Git mailing list, Junio C Hamano wrote (reply to this): Jonathan Tan <[email protected]> writes:
> ... During the subsequent connectivity
> check, the "make the tree big\n" blob (referenced by treeB) is missing.
> There is nothing that can vouch for it (the client does not have treeA,
> remember) so the client does not consider it a promisor object, and thus
> the connectivity check fails.
It is sad that it is a (probably unfixable) flaw in the "promisor
object" concept that the "promisor object"-ness of blobA depends on
the lazy-fetch status of treeA. This is not merely a test failure,
but it would cause blobA pruned if such a lazy fetch happens in the
wild and then "git gc" triggers, no? It may not manifest as a
repository corruption, since we would lazily fetch it again if the
user requests to fully fetch what commitA and treeA need, but it
does feel somewhat suboptimal.
Thanks for a detailed explanation on what is going on. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. On the Git mailing list, Jonathan Tan wrote (reply to this): Junio C Hamano <[email protected]> writes:
> It is sad that it is a (probably unfixable) flaw in the "promisor
> object" concept that the "promisor object"-ness of blobA depends on
> the lazy-fetch status of treeA. This is not merely a test failure,
> but it would cause blobA pruned if such a lazy fetch happens in the
> wild and then "git gc" triggers, no?
Right now, it won't be pruned since we never prune promisor objects
(we just concatenate all of them into one file). But in the future, we
might only keep reachable promisor objects, in which case, yes, blobA
will be pruned. In this case, though, I think blobA is like any other
unreachable object in git. If a user memorizes a commit hash but does
not point a ref to it (or point a ref to one of its descendants), that
commit is still subject to being lost by GC. I think it's the same case
here. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. On the Git mailing list, Junio C Hamano wrote (reply to this): Jonathan Tan <[email protected]> writes:
> Junio C Hamano <[email protected]> writes:
>> It is sad that it is a (probably unfixable) flaw in the "promisor
>> object" concept that the "promisor object"-ness of blobA depends on
>> the lazy-fetch status of treeA. This is not merely a test failure,
>> but it would cause blobA pruned if such a lazy fetch happens in the
>> wild and then "git gc" triggers, no?
>
> Right now, it won't be pruned since we never prune promisor objects
> (we just concatenate all of them into one file).
Sorry, but I am lost. In the scenario discussed, you have two
commits A and B with their trees and blobs. You initially only have
commit A because the partial clone is done with "tree:0". Then you
fetch commit B (A's child), tree B in non-delta form, and blob B
contained within tree B. Due to the tweak in the name hash
function, we do not know of tree A (we used to learn about it
because tree B was sent as a delta against it with the old name
hash). If blob B was sent as a delta against blob A, lazy fetch
would later materialize blob A even if you do not still have tree A,
no?
I thought the story was that we would not know who refers to blobA
when treeA hasn't been lazily fetched, hence we cannot tell if blobA
is a "promisor object" to begin with, no?
The blob in such a scenario may be reclaimed by GC and we may still
be able to refetch from the promisor, so it may not be the end of
the world, but feels suboptimal.
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. On the Git mailing list, Jonathan Tan wrote (reply to this): Junio C Hamano <[email protected]> writes:
> Jonathan Tan <[email protected]> writes:
>
> > Junio C Hamano <[email protected]> writes:
> >> It is sad that it is a (probably unfixable) flaw in the "promisor
> >> object" concept that the "promisor object"-ness of blobA depends on
> >> the lazy-fetch status of treeA. This is not merely a test failure,
> >> but it would cause blobA pruned if such a lazy fetch happens in the
> >> wild and then "git gc" triggers, no?
> >
> > Right now, it won't be pruned since we never prune promisor objects
> > (we just concatenate all of them into one file).
>
> Sorry, but I am lost. In the scenario discussed, you have two
> commits A and B with their trees and blobs. You initially only have
> commit A because the partial clone is done with "tree:0". Then you
> fetch commit B (A's child), tree B in non-delta form, and blob B
> contained within tree B. Due to the tweak in the name hash
> function, we do not know of tree A (we used to learn about it
> because tree B was sent as a delta against it with the old name
> hash).
Yes, that's correct.
> If blob B was sent as a delta against blob A, lazy fetch
> would later materialize blob A even if you do not still have tree A,
> no?
Just to be clear, this is not happening right now (blob B is sent whole,
not as a delta). But let's suppose that blob B was sent as a delta, then
yes, the lazy fetch would materialize blob A...
> I thought the story was that we would not know who refers to blobA
> when treeA hasn't been lazily fetched, hence we cannot tell if blobA
> is a "promisor object" to begin with, no?
...ah, in this case, blob A vouches for itself. Whenever we lazy fetch,
all objects that are fetched go into promisor packs (packfiles with an
associated .promisor file), so we know that they are promisor objects. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. On the Git mailing list, Junio C Hamano wrote (reply to this): Jonathan Tan <[email protected]> writes:
> ...ah, in this case, blob A vouches for itself. Whenever we lazy fetch,
> all objects that are fetched go into promisor packs (packfiles with an
> associated .promisor file), so we know that they are promisor objects.
Thanks. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. On the Git mailing list, karthik nayak wrote (reply to this): "Derrick Stolee via GitGitGadget" <[email protected]> writes:
> From: Derrick Stolee <[email protected]>
>
> Add a new environment variable to opt-in to differen values of the
s/differen/different
> --name-hash-version=<n> option in 'git pack-objects'. This allows for
> extra testing of the feature without repeating all of the test
> scenarios. Unlike many GIT_TEST_* variables, we are choosing to not add
> this to the linux-TEST-vars CI build as that test run is already
> overloaded. The behavior exposed by this test variable is of low risk
> and should be sufficient to allow manual testing when an issue arises.
>
> But this option isn't free. There are a few tests that change behavior
> with the variable enabled.
>
> First, there are a few tests that are very sensitive to certain delta
> bases being picked. These are both involving the generation of thin
> bundles and then counting their objects via 'git index-pack --fix-thin'
> which pulls the delta base into the new packfile. For these tests,
> disable the option as a decent long-term option.
>
> Second, there are two tests in t5616-partial-clone.sh that I believe are
> actually broken scenarios. While the client is set up to clone the
> 'promisor-server' repo via a treeless partial clone filter (tree:0),
> that filter does not translate to the 'server' repo. Thus, fetching from
> these repos causes the server to think that the client has all reachable
> trees and blobs from the commits advertised as 'haves'. This leads the
> server to providing a thin pack assuming those objects as delta bases.
> Changing the name-hash algorithm presents new delta bases and thus
> breaks the expectations of these tests. An alternative could be to set
> up 'server' as a promisor server with the correct filter enabled. This
> may also point out more issues with partial clone being set up as a
> remote-based filtering mechanism and not a repository-wide setting. For
> now, do the minimal change to make the test work by disabling the test
> variable.
>
> Third, there are some tests that compare the exact output of a 'git
> pack-objects' process when using bitmaps. The warning that ignores the
> --name-hash-version=2 and forces version 1 causes these tests to fail.
> Disable the environment variable to get around this issue.
>
The patch itself looked good to me.
[snip] There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. On the Git mailing list, Jonathan Tan wrote (reply to this): "Derrick Stolee via GitGitGadget" <[email protected]> writes:
> t/t5616-partial-clone.sh | 26 ++++++++++++++++++++++++--
I believe the changes to this file are no longer needed. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. On the Git mailing list, Derrick Stolee wrote (reply to this): On 12/9/24 6:12 PM, Jonathan Tan wrote:
> "Derrick Stolee via GitGitGadget" <[email protected]> writes:
>> t/t5616-partial-clone.sh | 26 ++++++++++++++++++++++++--
> > I believe the changes to this file are no longer needed.
You're right. They are only needed in the last patch when the v3
name-hash is possible.
(Unless maybe you fixed this issue in 'master' and I didn't see it)
Thanks,
-Stolee
|
||
|
||
static struct oidset excluded_by_config; | ||
static int name_hash_version = -1; | ||
|
||
static void validate_name_hash_version(void) | ||
{ | ||
if (name_hash_version < 1 || name_hash_version > 3) | ||
die(_("invalid --name-hash-version option: %d"), name_hash_version); | ||
} | ||
|
||
static inline uint32_t pack_name_hash_fn(const char *name) | ||
{ | ||
static int seen_version = -1; | ||
|
||
if (seen_version < 0) | ||
seen_version = name_hash_version; | ||
else if (seen_version != name_hash_version) | ||
BUG("name hash version changed from %d to %d mid-process", | ||
seen_version, name_hash_version); | ||
|
||
switch (name_hash_version) | ||
{ | ||
case 1: | ||
return pack_name_hash(name); | ||
|
||
case 2: | ||
return pack_name_hash_v2((const unsigned char *)name); | ||
|
||
case 3: | ||
return pack_name_hash_v3(name); | ||
|
||
default: | ||
BUG("invalid name-hash version: %d", name_hash_version); | ||
} | ||
} | ||
|
||
/* | ||
* stats | ||
|
@@ -1698,7 +1731,7 @@ static int add_object_entry(const struct object_id *oid, enum object_type type, | |
return 0; | ||
} | ||
|
||
create_object_entry(oid, type, pack_name_hash(name), | ||
create_object_entry(oid, type, pack_name_hash_fn(name), | ||
exclude, name && no_try_delta(name), | ||
found_pack, found_offset); | ||
return 1; | ||
|
@@ -1912,7 +1945,7 @@ static void add_preferred_base_object(const char *name) | |
{ | ||
struct pbase_tree *it; | ||
size_t cmplen; | ||
unsigned hash = pack_name_hash(name); | ||
unsigned hash = pack_name_hash_fn(name); | ||
|
||
if (!num_preferred_base || check_pbase_path(hash)) | ||
return; | ||
|
@@ -3422,7 +3455,7 @@ static void show_object_pack_hint(struct object *object, const char *name, | |
* here using a now in order to perhaps improve the delta selection | ||
* process. | ||
*/ | ||
oe->hash = pack_name_hash(name); | ||
oe->hash = pack_name_hash_fn(name); | ||
oe->no_try_delta = name && no_try_delta(name); | ||
|
||
stdin_packs_hints_nr++; | ||
|
@@ -3572,7 +3605,7 @@ static void add_cruft_object_entry(const struct object_id *oid, enum object_type | |
entry = packlist_find(&to_pack, oid); | ||
if (entry) { | ||
if (name) { | ||
entry->hash = pack_name_hash(name); | ||
entry->hash = pack_name_hash_fn(name); | ||
entry->no_try_delta = no_try_delta(name); | ||
} | ||
} else { | ||
|
@@ -3595,7 +3628,7 @@ static void add_cruft_object_entry(const struct object_id *oid, enum object_type | |
return; | ||
} | ||
|
||
entry = create_object_entry(oid, type, pack_name_hash(name), | ||
entry = create_object_entry(oid, type, pack_name_hash_fn(name), | ||
0, name && no_try_delta(name), | ||
pack, offset); | ||
} | ||
|
@@ -4069,6 +4102,15 @@ static int get_object_list_from_bitmap(struct rev_info *revs) | |
if (!(bitmap_git = prepare_bitmap_walk(revs, 0))) | ||
return -1; | ||
|
||
/* | ||
* For now, force the name-hash version to be 1 since that | ||
* is the version implied by the bitmap format. Later, the | ||
* format can include this version explicitly in its format, | ||
* allowing readers to know the version that was used during | ||
* the bitmap write. | ||
*/ | ||
name_hash_version = 1; | ||
|
||
if (pack_options_allow_reuse()) | ||
reuse_partial_packfile_from_bitmap(bitmap_git, | ||
&reuse_packfiles, | ||
|
@@ -4429,6 +4471,8 @@ int cmd_pack_objects(int argc, | |
OPT_STRING_LIST(0, "uri-protocol", &uri_protocols, | ||
N_("protocol"), | ||
N_("exclude any configured uploadpack.blobpackfileuri with this protocol")), | ||
OPT_INTEGER(0, "name-hash-version", &name_hash_version, | ||
N_("use the specified name-hash function to group similar objects")), | ||
OPT_END(), | ||
}; | ||
|
||
|
@@ -4576,6 +4620,15 @@ int cmd_pack_objects(int argc, | |
if (pack_to_stdout || !rev_list_all) | ||
write_bitmap_index = 0; | ||
|
||
if (name_hash_version < 0) | ||
name_hash_version = (int)git_env_ulong("GIT_TEST_NAME_HASH_VERSION", 1); | ||
|
||
validate_name_hash_version(); | ||
if (write_bitmap_index && name_hash_version != 1) { | ||
warning(_("currently, --write-bitmap-index requires --name-hash-version=1")); | ||
name_hash_version = 1; | ||
} | ||
|
||
if (use_delta_islands) | ||
strvec_push(&rp, "--topo-order"); | ||
|
||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -207,6 +207,60 @@ static inline uint32_t pack_name_hash(const char *name) | |
return hash; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. On the Git mailing list, karthik nayak wrote (reply to this): "Jonathan Tan via GitGitGadget" <[email protected]> writes:
[snip]
> diff --git a/pack-objects.h b/pack-objects.h
> index b9898a4e64b..15be8368d21 100644
> --- a/pack-objects.h
> +++ b/pack-objects.h
> @@ -207,6 +207,34 @@ static inline uint32_t pack_name_hash(const char *name)
> return hash;
> }
>
> +static inline uint32_t pack_name_hash_v2(const char *name)
> +{
> + uint32_t hash = 0, base = 0, c;
> +
> + if (!name)
> + return 0;
> +
> + while ((c = *name++)) {
> + if (isspace(c))
> + continue;
> + if (c == '/') {
> + base = (base >> 6) ^ hash;
Just two questions about the implementation for my own knowledge.
1. Why use '6' here? I couldn't understand the reasoning for the
specific value.
2. Generally in hashing algorithms the XOR is used to ensure that the
output distribution is uniform which reduces collisions. Here, as you
noted, we're more finding values for sorting rather than hashing in the
traditional sense. So why use an XOR?
> + hash = 0;
> + } else {
> + /*
> + * 'c' is only a single byte. Reverse it and move
> + * it to the top of the hash, moving the rest to
> + * less-significant bits.
> + */
> + c = (c & 0xF0) >> 4 | (c & 0x0F) << 4;
> + c = (c & 0xCC) >> 2 | (c & 0x33) << 2;
> + c = (c & 0xAA) >> 1 | (c & 0x55) << 1;
> + hash = (hash >> 2) + (c << 24);
> + }
> + }
> + return (base >> 6) ^ hash;
> +}
> +
> static inline enum object_type oe_type(const struct object_entry *e)
> {
> return e->type_valid ? e->type_ : OBJ_BAD;
> --
> gitgitgadget There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. On the Git mailing list, Junio C Hamano wrote (reply to this): karthik nayak <[email protected]> writes:
> 2. Generally in hashing algorithms the XOR is used to ensure that the
> output distribution is uniform which reduces collisions. Here, as you
> noted, we're more finding values for sorting rather than hashing in the
> traditional sense. So why use an XOR?
I am not Jonathan, but since the mixing-of-bits is done with XOR in
the original that Linus and I wrote, I think the question applies to
our version as well. We prefer not to lose entropy from input
bytes, so we do not want to use OR or AND, which tend to paint
everything with 1 or 0 as you mix in bits from more bytes.
Anyway the question sounds like "generally when you take tests you
write with a pencil, but right now you are merely taking notes and
not taking any tests. why are you writing with a pencil?" There are
multiple occasions that a pencil is a great fit as writing equipment. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. On the Git mailing list, karthik nayak wrote (reply to this): Junio C Hamano <[email protected]> writes:
> karthik nayak <[email protected]> writes:
>
>> 2. Generally in hashing algorithms the XOR is used to ensure that the
>> output distribution is uniform which reduces collisions. Here, as you
>> noted, we're more finding values for sorting rather than hashing in the
>> traditional sense. So why use an XOR?
>
> I am not Jonathan, but since the mixing-of-bits is done with XOR in
> the original that Linus and I wrote, I think the question applies to
> our version as well. We prefer not to lose entropy from input
> bytes, so we do not want to use OR or AND, which tend to paint
> everything with 1 or 0 as you mix in bits from more bytes.
>
Thanks for the answering. My reasoning at the start was more of my
thoughts on why XOR could be used here and your explanation makes it
clearer.
> Anyway the question sounds like "generally when you take tests you
> write with a pencil, but right now you are merely taking notes and
> not taking any tests. why are you writing with a pencil?" There are
> multiple occasions that a pencil is a great fit as writing equipment.
I'd say my questions was more of "I know a pencil is used when taking
tests because of XYZ reasons. On similar lines, why is a pencil used
here?" :) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. On the Git mailing list, Jonathan Tan wrote (reply to this): "Jonathan Tan via GitGitGadget" <[email protected]> writes:
> diff --git a/pack-objects.h b/pack-objects.h
> index b9898a4e64b..15be8368d21 100644
> --- a/pack-objects.h
> +++ b/pack-objects.h
> @@ -207,6 +207,34 @@ static inline uint32_t pack_name_hash(const char *name)
> return hash;
> }
>
> +static inline uint32_t pack_name_hash_v2(const char *name)
> +{
> + uint32_t hash = 0, base = 0, c;
> +
> + if (!name)
> + return 0;
> +
> + while ((c = *name++)) {
> + if (isspace(c))
> + continue;
> + if (c == '/') {
> + base = (base >> 6) ^ hash;
> + hash = 0;
> + } else {
> + /*
> + * 'c' is only a single byte. Reverse it and move
> + * it to the top of the hash, moving the rest to
> + * less-significant bits.
> + */
> + c = (c & 0xF0) >> 4 | (c & 0x0F) << 4;
> + c = (c & 0xCC) >> 2 | (c & 0x33) << 2;
> + c = (c & 0xAA) >> 1 | (c & 0x55) << 1;
> + hash = (hash >> 2) + (c << 24);
> + }
> + }
> + return (base >> 6) ^ hash;
> +}
This works because `c` is masked before any arithmetic is performed on
it, but the cast from potentially signed char to uint32_t still makes
me nervous - if char is signed, it behaves as if it was first cast to
int32_t and only then to uint32_t, as you can see from running the code
below:
#include <stdio.h>
int main() {
signed char c = 128;
unsigned int u = c;
printf("hello %u\n", u);
return 0;
}
I would declare `c` as uint8_t or unsigned char. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. On the Git mailing list, Junio C Hamano wrote (reply to this): Jonathan Tan <[email protected]> writes:
> "Jonathan Tan via GitGitGadget" <[email protected]> writes:
>> diff --git a/pack-objects.h b/pack-objects.h
>> index b9898a4e64b..15be8368d21 100644
>> --- a/pack-objects.h
>> +++ b/pack-objects.h
>> @@ -207,6 +207,34 @@ static inline uint32_t pack_name_hash(const char *name)
>> return hash;
>> }
>>
>> +static inline uint32_t pack_name_hash_v2(const char *name)
>> +{
>> + uint32_t hash = 0, base = 0, c;
>> + ...
>> + while ((c = *name++)) {
>> + ...
>> + /*
>> + * 'c' is only a single byte. Reverse it and move
>> + * it to the top of the hash, moving the rest to
>> + * less-significant bits.
>> + */
>> + c = (c & 0xF0) >> 4 | (c & 0x0F) << 4;
>> + ...
> This works because `c` is masked before any arithmetic is performed on
> it, but the cast from potentially signed char to uint32_t still makes
> me nervous - if char is signed, it behaves as if it was first cast to
> int32_t and only then to uint32_t, ...
> I would declare `c` as uint8_t or unsigned char.
I think you meant the type of "name", and your worry is that *name
may pick up a negative integer from there when the platform char is
signed? Here we are dealing with a pathname that has often UTF-8
encoded non-ASCII letters with 8th bit set, and I agree with you
that being explicitly unsigned would certainly help reduce the
cognitive load.
Thanks.
|
||
} | ||
|
||
static inline uint32_t pack_name_hash_v2(const unsigned char *name) | ||
{ | ||
uint32_t hash = 0, base = 0, c; | ||
|
||
if (!name) | ||
return 0; | ||
|
||
while ((c = *name++)) { | ||
if (isspace(c)) | ||
continue; | ||
if (c == '/') { | ||
base = (base >> 6) ^ hash; | ||
hash = 0; | ||
} else { | ||
/* | ||
* 'c' is only a single byte. Reverse it and move | ||
* it to the top of the hash, moving the rest to | ||
* less-significant bits. | ||
*/ | ||
c = (c & 0xF0) >> 4 | (c & 0x0F) << 4; | ||
c = (c & 0xCC) >> 2 | (c & 0x33) << 2; | ||
c = (c & 0xAA) >> 1 | (c & 0x55) << 1; | ||
hash = (hash >> 2) + (c << 24); | ||
} | ||
} | ||
return (base >> 6) ^ hash; | ||
} | ||
|
||
static inline uint32_t pack_name_hash_v3(const char *name) | ||
{ | ||
/* | ||
* This 'bigp' value is a large prime, at least 25% of the max | ||
* value of an uint32_t. Multiplying by this value (modulo 2^32) | ||
* causes the 32 bits to change pseudo-randomly. | ||
*/ | ||
const uint32_t bigp = 1234572167U; | ||
uint32_t c, hash = bigp; | ||
|
||
if (!name) | ||
return 0; | ||
|
||
/* | ||
* Do the simplest thing that will resemble pseudo-randomness: add | ||
* random multiples of a large prime number with a binary shift. | ||
* The goal is not to be cryptographic, but to be generally | ||
* uniformly distributed. | ||
*/ | ||
while ((c = *name++) != 0) { | ||
hash += c * bigp; | ||
hash = (hash >> 5) | (hash << 27); | ||
} | ||
return hash; | ||
} | ||
|
||
static inline enum object_type oe_type(const struct object_entry *e) | ||
{ | ||
return e->type_valid ? e->type_ : OBJ_BAD; | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,24 @@ | ||
/* | ||
* test-name-hash.c: Read a list of paths over stdin and report on their | ||
* name-hash and full name-hash. | ||
*/ | ||
|
||
#include "test-tool.h" | ||
#include "git-compat-util.h" | ||
#include "pack-objects.h" | ||
#include "strbuf.h" | ||
|
||
int cmd__name_hash(int argc UNUSED, const char **argv UNUSED) | ||
{ | ||
struct strbuf line = STRBUF_INIT; | ||
|
||
while (!strbuf_getline(&line, stdin)) { | ||
printf("%10u ", pack_name_hash(line.buf)); | ||
printf("%10u ", pack_name_hash_v2((unsigned const char *)line.buf)); | ||
printf("%10u ", pack_name_hash_v3(line.buf)); | ||
printf("%s\n", line.buf); | ||
} | ||
|
||
strbuf_release(&line); | ||
return 0; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On the Git mailing list, Taylor Blau wrote (reply to this):
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On the Git mailing list, Taylor Blau wrote (reply to this):
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On the Git mailing list, Junio C Hamano wrote (reply to this):
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On the Git mailing list, Derrick Stolee wrote (reply to this):
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On the Git mailing list, Derrick Stolee wrote (reply to this):