Skip to content
This repository has been archived by the owner on Apr 29, 2020. It is now read-only.

Ignoring shared subtrees #5

Open
wking opened this issue May 6, 2015 · 0 comments
Open

Ignoring shared subtrees #5

wking opened this issue May 6, 2015 · 0 comments

Comments

@wking
Copy link

wking commented May 6, 2015

As I pointed out in the root ipfs/kubo#1195 message, a useful extention for the UI would be a repeatable --ignore <ip*s-path> argument to the export command which would allow to to say “export all objects reachable by <names-listed-in-the-positional-arguments>except for <names-listed-in-ignore-options> and their descendents”. That's the same sort of thing you can do with:

$ git bundle create mybundle v1.0.0..master

for “bundle all objects reachable from my master branch reference except for those reachable from my v1.0.0 tag”, but I like the separate option to make it easier to truncate in multiple locations.

I'm pretty confident that that's a good UI, but I'm not sure how we want to represent these instances in the archive file. Constraints:

  1. We want this to be unambiguous (obviously).
  2. We want a fast way to get the list of ignored IP*S paths, so a node can quickly check whether or not it already has the ignored IPFS objects locally. Nodes may want to check that they can resolve any non-IPFS links (e.g. dnslinks, IPNS links, …).

That sounds like a separate header table listing the ignored <ip*s-paths>. Or maybe just a magic 0 offset in the main index (but that's going to be hard to distinguish if we don't store the full multihash in that lookup table)? I'll try to find specs for how Git's bundle handles this situation without looking through any GPLed code.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant