-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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
initial implementation of save #1187
Conversation
Note: this does work with a live mounted fuse fs 😄 |
So “Insert <QmSomeObject> as link <name> of <QmParentObject> and
bubble changes up to <QmAncestorObject> …” seems like the general
problem. I'd make re-publishing to IPNS a separate step. Something
like:
$ ipfs link set [--ancestor <ipfs-path>] <parent-ipfs-path> <name> <linkes-ipfs-path>
spitting out the adjested parent ID if --ancestor wasn't set, or the
adjusted ancestor ID if it was.
|
More thoughts on this today on IRC from 1 through at least 2. a You might edit both (b) and (c) and just want to update (a) after both Also, finding the path from a parent to a deeply-nested route is going $ ipfs link set [--ancestor ] <link's-ipfs-path> would allow the user to supply the path when they new it. |
alright, i want to get back to working on this command. I beleive the need for a staging area is apparent, so maybe we could do something git-like for this. # start an edit under <root hash>
ipfs $CMD edit <root hash>
# add <hash> at <path> under the <root hash> for this edit session
ipfs $CMD add <path> <hash>
# delete <path> under <root hash>
ipfs $CMD rm <path>
# finalize this edit session and print out the modified root hash
ipfs $CMD commit |
On Sat, May 23, 2015 at 10:54:17AM -0700, Jeromy Johnson wrote:
Hmm, this is going to be racy if you have multiple edits running at $ SESSION=$(ipfs $CMD edit $ROOT_HASH) to override a default like “the most-recently opened session”. |
@wking passing a root hash is used to specify your 'working dir' essentially, this command doesnt even make sense without it. in regards to this being racy, using ids might be what we want to do. Doing things git style on the fielsystem doesnt make sense because clients will need to interface with this over the http API. |
Notes:
What we need here is a plumbing command. # return the hash of a <blank-root> object (0 links, 0 data)
> ipfs object blank # or 'ipfs object new'
<blank-root>
# adds a link `name -> hash`
> ipfs object patch <root-hash> add-link <name> <hash>
<new-hash>
# removes all links with `name` or `hash` or `<int-offset>`
> ipfs object patch <root-hash> rm-link [ <name> | <hash> | <int-offset> ]
<new-hash>
# where <int-offset> is the number in the link table.
# (<int-offset> is only way to address uniquely. names and hashes may repeat)
# set the data of the object. reads from stdin
> echo hello | ipfs object patch <root-hash> data
<new-hash> These commands take the object, modify it, write it, and output the hash of the new object. writing an object is very cheap and will be gc-ed out (i.e. do not pin it automatically). pin can be a separate step. a "session" turns into:
it's a bit annoying having to put the output of the previous command in the right place for the next, but we could:
# empty IPFS_PATCH_ROOT. is equivalent to <blank-root> (0 links, 0 data)
> ipfs patch $root add-link hello $hello # exports IPFS_PATCH_ROOT=<new-root-1>
<new-root-1>
> ipfs patch $root add-link world $world # exports IPFS_PATCH_ROOT=<new-root-2>
<new-root-2>
> ipfs patch clear # exports IPFS_PATCH_ROOT=<blank-root> |
(i'm hesitant to burn the top-level porcelain name |
sorry, thats not possible :/ best we can do is print out the new root |
ah right :) |
On Thu, May 28, 2015 at 08:00:48AM -0700, Juan Batiz-Benet wrote:
This non-bubbly form sounds reasonable to me, but I'd like an HTTP
Maybe ‘empty’ instead of ‘blank’ or ‘new’?
How is this going to extend to extensible links? See ipfs/ipfs#36 and
How do you distinguish the int-offset ‘0’ from the name ‘0’? |
alright, so after implementing patch, doing what my save command here does is still very convoluted and difficult. Thoughts on actually merging this in one form or another? |
On Thu, May 28, 2015 at 07:52:22PM -0700, Jeromy Johnson wrote:
First round of porcelain: immediate bubbling. Pardon the shell, and #!/bin/sh usage: replace.sh IPFS_PATH ACTION REPLACMENTFor example:replace.sh QmZKetgwm4o3LhNaoLSHv32wBhTwj9FBwAdSchDMKyFQEx/foo/bar/baz add-link QmTz3oc4gdpRMKP2sdGUPZTAGRngqjsi99BPoztyP53JMMwill add a 'baz' entry toQmZKetgwm4o3LhNaoLSHv32wBhTwj9FBwAdSchDMKyFQEx/foo/bar pointing atQmTz3oc4gdpRMKP2sdGUPZTAGRngqjsi99BPoztyP53JMM, and then updateQmZKetgwm4o3LhNaoLSHv32wBhTwj9FBwAdSchDMKyFQEx/foo to point to that,and then print out the new root hash.set -e dereference an IPFS pathdereference() { replace_link() { replace() { replace "$@" Making ‘dereference’ a builtin command (‘ipfs object stat’) is #1082. |
the patch porcelain on top of @wking that's really good. 👍 on shell. we're on the git road ;) @chriscool would be proud. (i hope to be able to make prototyping command implementations in shell or other langs nicer before adding to api / core, etc). @whyrusleeping said
i like the
idea (instead of |
On Mon, Jun 01, 2015 at 08:10:49PM -0700, Juan Batiz-Benet wrote:
This is #1320 (and maybe also #1082), but I think we should think |
maybe we could rename this to something like |
On Thu, Jun 04, 2015 at 09:42:22AM -0700, Jeromy Johnson wrote:
Using the patch command shouldn't have any effect on the IPNS-linked |
closing for now, will reopen later when i get to it |
I'm not sold on the name, or placement of this command, or even that this needs to be a command, or even that this is the right way to accomplish this (all of the above are up for discussion). But what I am set on is the fact that I need to be able to do what this command does.