Skip to content
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

WIP: Git with refs types refactor #53

Open
wants to merge 21 commits into
base: ipfs-develop
Choose a base branch
from

Conversation

matthewbauer
Copy link
Collaborator

No description provided.

typedef std::variant<
TextInfo,
FixedOutputInfo,
IPFSHashWithOptValue<IPFSGitTreeNode>
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't this duplicate data because IPFSHashWithOptValue has a hash, but we can also compute the hash from IPFSGitTreeNode?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be better to make IPFSHashWithOptValue a variant of either a hash or a value.

src/nix/ipfs.cc Outdated Show resolved Hide resolved
+ fsh.hash.to_string(Base32, true);
[](IPFSHash<IPFSGitTreeNode> ih) {
// FIXME do Base-32 for consistency
return "ipfs-git:" + ih.to_string();
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we need to restrict ourselves to git. The cid could be any object, and we might decide later on that we want to use nar instead of git, given the 2MB git limit and that we have to convert to and from nar for the store api calls a lot.


struct ContentAddress {
template<typename Underlying>
struct ContentAddressT {
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think a little duplication here would be much better than doing this. What even is ContentAddressT? If you really want to use it, you should call it something like NameWrapper or something.

});
}
// FIXME: ipfs sort order is weird, it always puts type before
// references, so we rename it to qtype so it always comes
Copy link
Collaborator Author

@matthewbauer matthewbauer Jul 9, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's no qtype anymore. Shouldn't we have something telling ipfs what type we have?

auto ca_ = store->queryPathInfo(ref)->fullContentAddressOpt(*store);
assert(ca_);
ipfsRefs.insert(IPFSRef(computeIPFSCid(*ca_), ref.name()));
rewritingSink.flush();
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this got merged wrong - it should have been deleted i think

IPFSHash<Deref> fromString(std::string_view cid) {
auto prefix = cid.substr(0, 9);
HashType algo = prefix == "f01711220" ? htSHA256
: prefix == "f01781114" ? htSHA1
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

f0178 means it's the git codec, which should be an error for the "full" content address at least

// References for the paths
PathReferences<IPFSRef> references;
PathReferences<ContentAddressT<Ref<IPFSGitTreeNodeT<Ref>>>> references;
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why would you ever need more than one level of PathReferences? We can always query the daemon once we have the cid of a reference.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

More importantly, when would we ever fill in more than one layer of references? We handle each path on its own, so no room to share information like this between queryPathInfo calls.

std::shared_ptr<Deref> value = nullptr;

// Will calculate and store hash from value
static IPFSHashWithOptValue fromValue(Deref value);
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

once you have this, you don't need the value

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so this should just be:

IPFSHash fromValue(Deref value);

Just some link errors for knowingly-missing functions
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants