That is mixing git workflows and git service functionalities with core git commands, is that right? if I understand correctly, I don't know how I feel about that. my instinctive response is that pulling/pushing code should be all that the transport protocol should care about.
And I think there are more things we can do with nostr to improve UX working with git remotes hosted over nostr on that front, before thinking about adding overhead with what I consider is more a UI concern.
I'm not entirely sure how I feel about it either. I think there is a strong case for it.
Users can view open proposals using just the git tools they are used to using.
It is a nostr remote so expectations can be set as to what to expect.
Its quite easy to understand that branches starting origin/prs/* don't come from the maintainers and that pushing a branch will automatically create a proposal.
Its smoother than the github forking model and having to create PRs in the browser.
I'd be interested in hearing more opinions and trying it out in practice.
I might be on the conservative side regarding this. PRs are not first class citizens in git. so an integration of nostr+git doesn't need to have PRs.
I want to be able to work with git and nostr side by side. I see clear benefits in decentralization just by reducing friction for handling git server/service migration. And don't want to see nostr native repos become incompatible with regular git ones.
most of all, I like the idea that there are layers in the solutions we are exploring, and I'm hesitant to have protocol definitions across many layers. I don't think every good idea about how to do things in nostr need to be a protocol spec. it incentivizes gatekeeping and hinders flexibility. taking us closer to how centralized solutions work.
I am working on some ideas to improve the remote-helper I've made. Should have an update soon.
