Replying to Avatar DanConwayDev

here you go nostr:npub1elta7cneng3w8p9y4dw633qzdjr4kyvaparuyuttyrx6e8xp7xnq32cume. I didn't build any dummy binaries to test it with, so don't expect it to work yet or anything.

Sure, no expectations here!

As an initial note, I think I'll need the blossom server to be passed down in args to the scripts.

Reply to this note

Please Login to reply.

Discussion

It can just simply be a positional argument.

Passing commit ID's are fine for pushes. But for fetch, I need the blossom sha256 hashes instead of the commit IDs in order to find the blobs on blossom.

Shouldn't that be caculated from within the fetch script?

The way it works in the current version of git-remote-blossom is that it saves both the sha1 and the sha256 hash in the state event. So a ref tag looks like this:

`["refs/heads/master", "3437fd950d4ba37ba51e3bc788025698cfb20ca1", "3b58e484825e5b96428ab0b0c19cb760d5ebbd39acb4795446a89c99482e2d62"],`

It needs the sha256 to be able to start the graph traversal at the HEAD. All the rest can be calculated.

This is somewhat diverges from the current NIP-34. It needs to be updated with the sha256 - which is right now in the place of the optional parent commit ids.

I'm not crazy about breaking changes to the spec but I don't think anyone is using the optional parent commit ids.

For a minimum viable solution I thought we could just hard code it. I suppose in could initially add it as an CLI argument for `ngit init` for now and store it in blossom tag in 30317.

Yes, we can hardcode it, but then I guess we don't even need to handle it in ngit init nor add it to the blossom tag. Or I might misunderstand something.

Right now it assumes the blossom state is always reflected in the latest 30618 event. This means it will only upload state for branches / tags that have had changes since blossom was added to the `clone` list.

If there is no blossom sha256 for a tag, it cannot be cloned from blossom. I think it is not the expected behaviour from the user. If he makes the move from github to blossom, then removes github.com clone url from the repo announcement even, then he will be disappointed if he cannot clone old versions.

I think blossom keys should be added to each ref upon the first push to blossom to keep the functionality.