Where is your proposal? Is it just a proposal or there's a poc?
Discussion
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