Ideas

[prologic]

@icyphox Hey 👋 I'm not sure what your plans are for this project, but just in case our goals align, here's what I'd like to achieve (assuming I continue hacking on this):

Basically what you've got so far now +

• Remove use of CGO Add a non-CGO Git HTTP Service #13
• Support for rendering Markdown README(s) Add support for rendering Markdown README(s) #11
• Push and Auth over both HTTP and SSH (after Add a non-CGO Git HTTP Service #13)
• Triggering external web-hooks for CI/CD
• Issue Tracker using git-bug
• Builtin SMTP server for git send-email ¹

Footnotes

1. However this may not be well thought out yet, as I'm not sure how "code reviews" would work (without reinventing giant wheels and adding a lot of bloat) ↩

[icyphox]

Hi there, Thank you for hacking on legit. Some great stuff so far! As far as my goals for this project are concerned, the below two ideas are in alignment:

Basically what you've got so far now +  * Remove use of CGO #13  * Support for rendering Markdown README(s) #11

The following, unfortunately, are a tad beyond what I'd consider the scope of legit.

 * Push and Auth over both HTTP and SSH (after #13)

http pulls/clones are enough, in my opinion. http push, as you mentioned, needs auth and seems superfluous when the user can simply push using ssh, aided by the remote server's sshd. legit was intended to be read-only.

 * Triggering external web-hooks for CI/CD

Probably doable using post-receive hooks. Doesn't need to be in legit.

 * Issue Tracker using git-bug

Very cool project. The author of git-bug reached out to me regarding integrating legit and git-bug, but I had to turn them down because I personally wouldn't use it -- and don't want to spend cycles on it as a result.

 * Builtin SMTP server for git send-email

Again, doesn't really need to be in legit.

[prologic]

@icyphox Thanks for the quick updat!

Very cool project. The author of git-bug reached out to me regarding
integrating legit and git-bug, but I had to turn them down because I
personally wouldn't use it -- and don't want to spend cycles on it as a
result.

Was this done privately or over some public medium I missed? I'd be curious to work with @MichaelMure on something like this myself, however it would then likely mean I would hard-fork my version of legit and we would diverge. Which is okay 👌

I do also want to support Push with Auth (probably over SSH I think) and some kind 'f Review" process (but as I said, I'm not sure how yet...)...

Again, thanks for the great work you've done so far! I'm interested mostly because it might b e nice to have something in between something like cgit/sagit and Goga/Gitea (but now as feature rich/heavy).

[prologic]

Just as an aside, I just discovered git-apprise which along with git-bug (which both operate in a similar manner) might be a nice way to do fully "distributed" and "decentralised" Git hosting + Issue tracking + Code reviews 👌 -- I'd be all over this 😎

[icyphox]

Was this done privately or over some public medium I missed? I'd be curious to work with @MichaelMure on something like this myself, however it would then likely mean I would hard-fork my version of legit and we would diverge. Which is okay 👌

Indeed, this was over email. I fully support a hard-fork of legit! Watching this turn into a truly distributed + self-hosted git forge would be awesome. Heck, maybe even throw in ActivityPub into the mix like what Gitea is doing.

[prologic]

Heck, maybe even throw in ActivityPub into the mix
like what Gitea is doing.

That was a joke right?! 🤣

[MichaelMure]

Chiming in as I've been pinged. My 2cts:
I certainly don't want to steal anyone's thunder, and legit has a point on its own as a purposely-simple read-only git viewer.

At the same time, a git viewer (logs, commits, code ...) would be super useful in git-bug, and is almost a requirement to sanely support pull-requests (git-bug/git-bug#373).
git-bug is also a superset of legit's feature, and as the webUI support a read-only mode, it could also fill-in exactly legit's usecase, possibly with an option to hide the extra bug/PRs ... stuff, and a larger binary.

So my thinking really is just that: we seemed to be like minded individuals, what if we teamed together to make that truly distributed + self-hosted git forge idea a reality?

I just discovered git-appraise which along with git-bug (which both operate in a similar manner)

Same purpose, but actually quite different under the hood (git notes vs graph CRDT like structure). git-appraise showed that this kind of things were possible, but I like to believe that git-bug is now in a more capable, viable and robust place to build such a forge.

maybe even throw in ActivityPub into the mix like what Gitea is doing.

Sounds like a good idea to me, so that different forges (or even multiple instances of the same forge) can cooperate. I'm curious to have your take on this as it seems like you have worked in that area.

[MichaelMure]

On the technical side of things, git-bug and legit share two important things (golang and go-git), but diverge on one: legit render things server-side with go templates, git-bug has a HTTP+GraphQL API and a React SPA. Exercise is left to the reader to judge what's best :-)

[prologic]

Hi @MichaelMure 👋 I agree, I'm sure if we find the time, energy and effort we could build something awesome 👌 -- However I'm personally a bit of a strickly (grumpy old man) when it comes to "distributed" vs. "decentralised". I'd love to see something that utilises the best parts of Git itself, rather then forming a "distributed networking protocol" (such as is ActivityPub) -- That is why I'm quite intruiged by leggit, git-but and even git-apraise (to a lesser extend, though I agree with you I'm not happy about its design and storage, I'd rather see it use the same data structures as git-but).

[prologic]

On the technical side of things, git-bug and legit share two important things (golang and go-git), but diverge on one: legit render things server-side with go templates, git-bug has a HTTP+GraphQL API and a React SPA. Exercise is left to the reader to judge what's best :-)

I think this depends whether you want something truely client-side only or a bit of both. There is a good use-case for both, but without centralising issue tracking, pull request reviews and credentials onto a single instance (distributed the issues, reviews via git-bug's storage, etc)

[MichaelMure]

I'd love to see something that utilises the best parts of Git itself, rather then forming a "distributed networking protocol" (such as is ActivityPub)

Ha, I see your point and agree. Using git as storage and transport is the way (it can even be made truly p2p/global by merging every repo in the same key space). However, there is still a point for interop with other forge with things like ActivityPub.

[prologic]

there is still a point for interop with other forge with things like ActivityPub

I've yet to see what that point is yet, but happy to be prove wrong 😅