I've been thinking about how to improve #GitViaNostr
* make it more git native experience
* reduce the role of the git server
* integrate releases
Here is a concept ngit quick start guide: https://gitworkshop.dev/concept
I'd love your feedback
I've already started to build out some of the new features
nostr:npub16r0tl8a39hhcrapa03559xahsjqj4s0y6t2n5gpdk64v06jtgekqdkz5pl nostr:npub1m4ny6hjqzepn4rxknuq94c2gpqzr29ufkkw7ttcxyak7v43n6vvsajc2jl nostr:npub1wqfzz2p880wq0tumuae9lfwyhs8uz35xd0kr34zrvrwyh3kvrzuskcqsyn nostr:npub1uplxcy63up7gx7cladkrvfqh834n7ylyp46l3e8t660l7peec8rsd2sfek nostr:npub1elta7cneng3w8p9y4dw633qzdjr4kyvaparuyuttyrx6e8xp7xnq32cume nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6
You're heading in our direction, sir. 🤔
nostr:npub1wqfzz2p880wq0tumuae9lfwyhs8uz35xd0kr34zrvrwyh3kvrzuskcqsyn y'all might need to just sit down and hash this out in a telephone conference. Y'all both went off to think and came back with something similar, but not identical.
Since we're using Ngit as CLI, it makes sense to collaborate on it.
I actually started off writing a Python CLI, but my interaction with you was so productive, that I was like,
Why do this twice? 😂
And, as you can see, we need to match at the CLI level, or the events will eventually lose interoperability.
There is so much design space in #GitViaNostr, so few of us working on it and hardly any usage, that it makes less sense to duplicate functionality right now.
It is somewhat inevitable and eventually healthy when things are more mature as projects die, new projects do things better or on different stacks, etc.
Yes, I think this realm isn't mature enough to handle competition on that level, yet. We're still working through the kinks in our own NIP-01, basically.
If we diverge too much, now, it's gonna be a shitshow and turn people off of the concept.
We should probably compete more on sw features, than on core event kinds.
Yes, at a protocol level (event kinds and format), it is almost never a good idea to diverge.
Product/ project manager experience taking
Yeah, sorry. Used to managing complex sw projects and it occasionally leaks out.
Ngit silos just sounds like a train wreck. 😂
I think we are probably long overdue a dev call!
Yeah, we are one step further on some of what you described and one step back on others. This is becoming inefficient.
Where is your proposal? Is it just a proposal or there's a poc?
We're not ngit maintainers, so we've been keeping our deliberations private, on Slack and in private repos.
We were considering forking ngit, but if Michael were a maintainer, we'd have less incentive to do that. Also, we just added a Rust developer, to the team, nostr:npub1w4jkwspqn9svwnlrw0nfg0u2yx4cj6yfmp53ya4xp7r24k7gly4qaq30zp
Perhaps we should deepen the collaboration to prevent drift. It's been mostly happening through my testing and should probably move to the ngit repo proper, otherwise it's just an effect of my person.
Im open to the idea of more maintainers. Also, you don't have to be a maintainer to shape the vision and add features you want.
Hmm. Yes. But it would take away motivation to duplicate the effort.
And make me feel less like I'm cheating on him. 😂
It would totally be worth while having a call to discuss our visions for #GitViaNostr.
I bet we would come up with new ideas and better approaches as our thoughts collide.
I think you and I have slightly differing visions, which is great, as we're less likely to clash.
I've been seeing ngit and GitWorkshop heading in the direction of the distributed/patch model of project organization. Setting up a multitude of git servers to act as relays for git objects that anyone can draw from is a good idea. That model is also excellent for open-source development, where contributions are driven primarily by fork submissions.
I'm personally leaning towards fleshing out the "cathedral" model. Tight-knit or closed-source teams might prefer that, with a shared git server and contributions coming from branches rather than forks. Even there, however, I aim for our solution to avoid centralization by using the basic model of repo discovery over Nostr.
In that sense, we definitely want to seek compatibility in the core model. Someone using GitRepublic should be able to submit patch proposals to an ngit/GitWorkshop user on the distributed model, and someone using ngit should be able to at least fork and create PRs against projects using GitRepublic and the cathedral model.
My hope is that we can maintain core interoperability but avoid unnecessary competition if we are aiming to serve different sectors of the market.
Yes thanks for sharing.
Currently, we have a gigantic external dependence in Ngit. Which is fine, so long as everything is fine.
But we have a strong incentive to duplicate or fork it, so that we can be maintainers. Otherwise, we get no credit for any improvements and if we need a bugfix and isn't available, we'll be forced to fork it and have our customers switch to our version in a rush. I've had that happen in a software project before and it's incredibly embarrassing to admit that you have no control over a core feature.
This is why everyone prefers to fork, rather than contribute. Contributing regularly to something you don't have your name on is cucky.
Why not with selfhosted nodes?
Don’t hold binaries and dependencies but just code and version control with comments
Don't forget to mention that you'll be happy to contribute later when your team is huge and it's just an intern taking a few minutes to submit your code to other projects via your own ngit platform
This is obvious to me but maybe not to people that have no idea who you are
Forking/collaborating is one option, but I'm also interested in parallel development on different tech stacks. If ngit is in Rust, then we can develop GitRepublic in C++, for instance. As long as we're working on lower-level tools, having multiple options in different languages out in the wild expands the space for others to build on that foundation.
well said
