Skip to content

GitLab

Switch branch/tag
  1. 21 Jul, 2015 1 commit
  3. 20 Jul, 2015 2 commits
  5. 18 Jul, 2015 1 commit
  7. 14 Jul, 2015 1 commit
  9. 10 Jul, 2015 2 commits
  11. 09 Jul, 2015 1 commit
  13. 06 Jul, 2015 1 commit
  15. 05 Jul, 2015 1 commit
  17. 04 Jul, 2015 3 commits
  19. 03 Jul, 2015 4 commits
  21. 02 Jul, 2015 1 commit
  23. 01 Jul, 2015 2 commits
  25. 30 Jun, 2015 1 commit
  27. 29 Jun, 2015 1 commit
  29. 27 Jun, 2015 2 commits
  31. 23 Jun, 2015 1 commit
  33. 22 Jun, 2015 1 commit
  35. 20 Jun, 2015 9 commits
  37. 19 Jun, 2015 3 commits
    • Dylan Powers's avatar
      "object" added to the descriptions of object patch and object data · 3f22954f
      Dylan Powers authored 
      License: MIT
Signed-off-by: default avatarDylan Powers <dylan.kyle.powers@gmail.com>
      3f22954f
    • W. Trevor King's avatar
      core/commands/publish: Allow explicit local node ID · e700c02c
      W. Trevor King authored 
      Instead of raising "keychains not yet implemented" whenever we have an
explicit node ID, only raise the error when the given node ID isn't
the local node.  This allows folks to use the more-general
explicit-node-ID form in scripts and such now, as long as they use the
local node name when calling those scripts.

Also add a test for this case, and update the comment for the
one-argument case to match the current syntax for extracting a
multihash name string.

License: MIT
Signed-off-by: default avatarW. Trevor King <wking@tremily.us>
      e700c02c
    • W. Trevor King's avatar
      core/commands: Make IpnsCmd and PublishCmd public · 40c6ffd4
      W. Trevor King authored 
      ipfs-shell [1] accesses the Command objects directly to construct
requests for an external IPFS daemon API.  This isn't a terribly
robust approach, because it doesn't handle version differences between
the version of go-ipfs used to build the daemon and the version used
to build the ipfs-shell-consuming application.  But for cases where
you can get those APIs to match it works well.  Making these two
commands public allows us to write ipfs-shell wrappers for them.
Until we figure out how to get ipfs-shell working without access to
core/commands, I think the best approach is to make future command
objects and their returned structures public, and to go back and
expose existing commands/structures on an as-needed basis.

In this case, I need the public PublishCmd for the Docker-registry
storage driver, and I made the IpnsCmd public at the same time to stay
consistent for both 'ipfs name ...' sub-commands.

[1]: https://github.com/whyrusleeping/ipfs-shell

License: MIT
Signed-off-by: default avatarW. Trevor King <wking@tremily.us>
      40c6ffd4
  39. 18 Jun, 2015 2 commits