GitRoot
60 points by Hasnep
60 points by Hasnep
Hi here! I'm the creator of GitRoot, if you have any questions, please feel free to ask ;)
I have 3 related questions:
<pre> tags are mysteriously only 720px wide (the answer seems to be the display:grid on the body; unchecking it widens things as expected)
I do appreciate this is your project for your needs, but wanted to bring them to your attention only as "for your consideration"
Thanks for your questions. Yes the project is "for my needs" but I want to move it to "our needs".
I'm largely against anything that makes the repository larger (which in turn adversely affects CI clone time), but the idea of packing more features into the repository really sounds enticing.
To that end, this opens up to a plethora of questions that ensure that as GitRoot evolves, the size of the repository doesn't get out of control. So, it would be great to do some experimentation and share results for how the file size of the repository grows - as a small example, how does the repository file size grow in proportion to the number of issues or pull requests that exist? And how would you handle aged out content, like issues that were created years and years ago? Would you really need to store every comment ever written in every pull request?
Maybe one of the things that these hosted version control systems (GitHub, BitBucket, etc) get right is they make the repository cheap and slim (mostly git and other tooling content), while having all the other bloat (issues, pull requests, etc) something explicitly separated out so as to keep all of the tooling around the repository cheap and slim.
Yes it's true, the repository size could become big. I think about that since the beginning of GitRoot and I've found some solutions, choose the one that best for you.
Firstly, vast majority of projects is small. With one contributir, between 0-10 issues and no contribution. I know it's not an answer but just a reminder of what is our world today.
Then, there’s no need to keep code and issues in the same repository. You can have a repo for code and another for issues/boards. You will not be able to link an issue in your commit. But well, it's like other forges except your issues are on your computer. Off course contributions must be in the same repo, but, if you don't want them it's easy to delete them before merge. After all, it is files in git. Delete the file where discussion take place, squash and merge. Better, clean the file (no need to keep files modification/diff... Just keep what is important for your project). Maybe use this file has a base for your changelog... Possibilities are infinite.
Finally, a plugin which stock issues, grafts outside of git is feasible. Render them in web, the only missing part is a way for plugin to receive http request, guess what is on my todo list ;) Not my philosophy, but system plugin is here for that: do what you want with GitRoot!
PS: about cloning in CI/CD, is a thing I want to change too. GitRoot works on change set. When you push, only what's changed is mounted. Today, it is not finished and so there is a classical container CI/CD. But tomorrow when plugins will be here, only what's is needed will be loaded from hard drive. The size of the repo will no matter anymore. The idea is: if you have changed something in repo/src and want to build, only files there will be used. I can talk about that all day, but I don't think it's the good place. Please contact me (contact page of gitroot.dev) if you want to know more.
ad PS: you can also use sparse+shallow clone in the CI/CD (although it's not the default anywhere I know) and larger repo shouldn't be an issue (and for large commit numbers git starts to get slow anyway)
I prefer copying tarballs into CICD for a clean no nonsense environment that is easy to cache and validate.
Pretty cool! I've been toying with writing my own git forge too, and this is giving me some ideas.
GitHub has long been not only the biggest player, but also the most influential forge. You can feel its influence in the design of other forges like Forgejo and Gitlab. With GitHub's fall, I'm very excited to see how people stray from GitHub's model and forge their own paths. I think there's a lot of room for innovation in this space!
Gitea used to be almost 1:1 clone of GitHub’s old frontend that Forgejo simply inherited when they forked Gitea.
@manland do you have an LLM policy or guidance on whether or not you allow/disallow contributions created with an LLM?
No there is no policy today. Because I haven't contributors (2 one time contributors), 99,999% of the code is done by me.
I personnaly don't use llm for code and I'm against them. But, to be honest, if someone make a graft reasonably small even if llm was used, I'm not sure I'll refuse it.
If you look carefully you will find trace of llm in my communication. English is not my mother tongue and it's hard for me to explain GitRoot without them. I have asked for help in the past https://gts.gitroot.dev/@forge/statuses/01KFNWDKSZBEHTC16N5G02HJZ6 or https://gts.gitroot.dev/@forge/statuses/01KTP30NTY9FK91Q9B5Z9B4M52 but nobody come.
It really breaks my heart to have to use them. But between that and doing nothing, I’ve chosen to use them as little as possible. In future, with a community, i hope to be able to banish them (even if I think economic will do the job before me 🤣). I have a lot of article in my todo list to explain the philosophie, security, future... And what stop me writing them is to know that an llm will resentence/fix typo or translate them.
// TODO this comment should be a blog article!
Thanks so much and I appreciate your approach. Sorry no one's responded about proofreading help. I've done technical proof reading in the past. Feel free to contact me for future posts. If I have time, I'd be happy to help.
I also encourage you to write down those ideas, or even codify them into a policy, before it would be difficult or controversial to add them. Either way, excited to see where your project goes 🙂
Love the use of Tinygo for compiling go plugins to WASM!
Yes tinygo is amazing, there is also SDK for AssemblyScript and rust. I'm developing the zig one https://gts.gitroot.dev/@forge/statuses/01KXRJ1GE0CNEQHVQ0R41D7V06
While reading your motives to make it, https://fossil-scm.org came instantly to mind.
Have you considered it?
Yes, I like fossil and I take a lot of inspiration from it. But fossil is not git, and fossil doesn't have a plugin system. If you don't want a forum, wiki, or chat in your fossil repository, you get them anyway.
On the other hand, it is much simpler for admin (with no configuration) if you do want them.
Really cool project, congratulations on releasing it! I've been passively working on writing a lightweight specification to make different code forges more interoperable called https://forge-feed.org. Essentially the idea is to expose VCS information in an easily consumable and discoverable format (JSON+WebFinger). Large forges like Forgejo are working on ActivityPub/Mastodon style federation (which is great) but I think there is space for a smaller, simpler protocol that is straight forward to implement in a forge like yours.
I like your vision of simple federation. And I agree with you, activity pub (or at-protocol (tangled)) is way too complexe for that. For GitRoot-to-GitRoot federation I want to try to use only git (don't know if realist but want to try).
Anyway if/when you want to implement your specification, i'll happy to help you to build a plugin. RSS feed is already here (thanks to pollen plugin). But making http request is a missing feature, i'll try to do for next version. After that all will be here to try your specification.