-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Git object hashing in libstore #8918
Conversation
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/obsidian-systems-is-excited-to-bring-ipfs-support-to-nix/7375/64 |
3b44d2d
to
06a23cd
Compare
I think it's RFC133 👍 very cool to see the progress in this space! |
3c52443
to
5fdf6e2
Compare
Discussed in Nix team meeting 2023-09-15: The first four commits are independent cleanups, can be split out. |
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/2023-09-15-nix-team-meeting-minutes-86/33171/1 |
79fc9f6
to
ef57479
Compare
ef57479
to
aa9d55b
Compare
fb0c11b
to
a37bd98
Compare
79c9cc9
to
6578193
Compare
36e5ff3
to
aab19fa
Compare
aab19fa
to
7629584
Compare
🎉 All dependencies have been resolved ! |
7629584
to
bf8b9ab
Compare
echo Run Hello World! > $TEST_ROOT/dummy3/dir/executable | ||
path3=$(nix store add --mode git --hash-algo sha1 $TEST_ROOT/dummy3) | ||
hash3=$(nix-store -q --hash $path3) | ||
test "$hash3" = "sha256:08y3nm3mvn9qvskqnf13lfgax5lh73krxz4fcjd5cp202ggpw9nv" |
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.
This needs some tests for what happens with store paths that have an executable file or symlink at top-level.
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/2024-02-03-nix-team-meeting-127/40309/1 |
42373e5
to
6becfa8
Compare
@@ -147,7 +148,7 @@ public: | |||
|
|||
void narFromPath(const StorePath & path, Sink & sink) override; | |||
|
|||
ref<SourceAccessor> getFSAccessor(bool requireValidPath) override; | |||
ref<SourceAccessor> getFSAccessor(bool requireValidPath = true) override; |
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.
Specifying defaults on overrides should be superfluous, so I think it's best to omit them.
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.
Actually see https://en.cppreference.com/w/cpp/language/default_arguments
The overriders of virtual functions do not acquire the default arguments from the base class declarations, and when the virtual function call is made, the default arguments are decided based on the static type of the object.
* An enumeration of the ways we can ingest file system | ||
* objects, producing a hash or digest. | ||
*/ | ||
enum struct FileIngestionMethod : uint8_t { |
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.
Maybe we can get rid of FileSerialisationMethod
by having isFlat()
and isRecursive()
methods on FileIngestionMethod
.
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.
I wish, but that only helps when we are returning FileSerializationMethod
, dumpPath
and other things that take FileSerialisationMethod
as an argument really want to statically, provably, exclude the "git" case.
6becfa8
to
3673dd7
Compare
They were getting skipped for the test-against checks.
Part of RFC 133 Extracted from our old IPFS branches. Co-Authored-By: Matthew Bauer <[email protected]> Co-Authored-By: Carlo Nucera <[email protected]> Co-authored-by: Robert Hensing <[email protected]> Co-authored-by: Florian Klink <[email protected]>
Instead, serialize as NAR and send that over, then rehash sever side. This is alorithmically simpler, but comes at the cost of a newer parameter to `Store::addToStoreFromDump`. Co-authored-by: Eelco Dolstra <[email protected]>
d32f528
to
d4ad1fc
Compare
This seems to now cause a failure in the daemon compatibility test in #9546. |
Thanks, both of you! |
Motivation
Part of RFC 133, tracking issue #8919
Method
The libnixutil interfaces for working with NARs have been resused for a new implementation that works with Git tree+blob Merkle DAGs.
libnixstore's
ContentAddress
and friends have been augmented to also express git hashes. There are new store paths accordingly.libfetcher's git fetcher has been agumented to also support this. Any fetcher could create git-hashed objects in principle, but the git fetcher is the best candidate since the source-side objects are also hashed this way; this allows us to fetch by tree hash and thus only need a single hash while still being pure.
The most notable detail is that when transferring git-hashed files over the wire, we create a store object for every subdir and file. This is the easiest way to make building the Merkle Dag safe and easy.
Context
Extracted from our old IPFS branches.
depends on #9294depends on #9325depends on #9815Checklist for maintainers
Maintainers: tick if completed or explain if not relevant
tests/**.sh
src/*/tests
tests/nixos/*
Priorities
Add 👍 to pull requests you find important.