Tracking issue for RFC 133: Git hashing and Git-hashing-based remote stores

[Ericson2314]

Info

• RFC 133: Git hashing and Git-hashing-based remote stores
• PR thread
• Milestone

Steps

Preperatory

• Shuffle ParseSink code in preparation for git hashing support #9024
• Factor out MemorySourceAccessor, implement missing features #9283
• Content addressing and adding to store cleanup #9325

Feature itself

• Git object hashing in libutil #9294

• Git object hashing in libstore #8918

  • At the store layer (manually added files, derivation outputs)

• Git hashing for Git fetching #9025
  -builtins.fetchGit and friends.

• Use StorePathDescriptor to fetching from CA-only stores #3754

  • Nix-agnostic content-addressing "stores"
  • That PR might be changed a lot.

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/nixcon-governance-workshop/32705/9

[nixos-discourse]

This issue 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/65

[roberth]

Idea:

1. Store Object =~ Name + File System Object:
2. Git hashing can not hash an executable blob
3. Store Object =~ single-item Git directory (which includes the Name)

I know you don't like Name, but maybe this is helpful.

File under storeDir bad, name as directory?

Another idea is maybe paths should have been $storeDir/$hash/$name/$fhsLikeStuffOrWhatever. It'd prevent things like cp ${fooScript} $out/bin producing a command containing a hash, but it's not the only way to do it, and probably a little bit slower than the current store path format, and not worth the effort to make such a change. That specific problem is solved more easily by making Nixpkgs produce directories, and making writeScript return an outPath of "${drv.outPath}/bin/${name}".