GitRoot

 (gitroot.dev)
2 पॉइंट द्वारा GN⁺ 1 일 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • GitRoot एक छोटा Git forge है, जो एक single binary के रूप में repositories और access permissions मैनेज करता है, और standalone plugins के जरिए issues, boards, branch merge और web interface को जोड़ता है
  • यह सिर्फ code ही नहीं, बल्कि issues, merge requests और boards तक सारा data ordinary files के रूप में Git में store करता है, इसलिए अलग database या hidden blobs पर निर्भर नहीं रहता
  • .gitroot/users.yml और branch-specific write permissions के जरिए बदलाव नियंत्रित करता है; repository की मौजूदा स्थिति दिखाने वाली default branch पर केवल अनुमति प्राप्त users ही push कर सकते हैं
  • अभी यह alpha version है; repositories, users, plugins, SSH Git commands और HTTP browsing सपोर्ट करता है, लेकिन production use के लिए उपयुक्त नहीं है
  • 1.0 से पहले updates, file-level permissions, HTTP Git commands, groups/subgroups और plugin API stabilization पर काम होगा; फिलहाल contribution के लिए Git और grafter plugin flow की समझ जरूरी है

केवल जरूरी features जोड़कर बनने वाला छोटा Git forge

  • GitRoot एक single binary से चलने वाला छोटा Git forge है, और core functionality को repository creation और repository-wise access permission management तक सीमित रखता है
  • बाकी features ऐसे plugins संभालते हैं जिन्हें स्वतंत्र रूप से install किया जा सकता है
    • issues, roadmaps, sprints और milestones बनाना
    • items को board के रूप में दिखाना
    • GitRoot में graft कहे जाने वाले branch review और merge
    • repository data और अलग-अलग features को web interface के रूप में उपलब्ध कराना
  • Plugins पूरी तरह अलग हैं, इसलिए web interface के बिना सिर्फ board भी इस्तेमाल किया जा सकता है, और project के लिए जरूरी features खुद plugin के रूप में बनाए जा सकते हैं

Project के हिसाब से forge बदलने वाला design

  • यह मानकर design किया गया है कि हर project की काम करने की जरूरतें अलग होती हैं, इसलिए हर project को अपने forge को modify करने की स्वतंत्रता मिलनी चाहिए
  • Developer जिस environment को चाहते हैं, वह इस प्रकार है
    • code, issues, pull/merge requests और boards को एक ही repository में रखना
    • landing page, translations, ticket system, forum जैसे project promotion और operations के लिए जरूरी features देना
    • migration scripts या data/contributor display loss के बिना किसी दूसरे server forge पर जाना
  • इसके उलट, वे इस तरह की complexity से बचना चाहते हैं
    • pull/merge requests या issues manage करने के लिए browser खोलना पड़े
    • project पहली बार देखने वाले लोगों को सबसे पहले files और directories की list दिखाने वाला setup
    • forge ही sprints, milestones, epics और user stories के अर्थ व workflow तय करे
    • एक user permission set करने के लिए कई menus से गुजरना पड़े

Installation और operations की autonomy

  • Admins के लिए आसानी से install और maintain करने हेतु dependencies और database के बिना distribution का लक्ष्य है
  • Admin users के लिए allowed actions set कर सकें, और users email या chat के बिना project व features create/access करने का request सीधे कर सकें—ऐसा होना चाहिए
  • लक्ष्य upgrade का burden घटाना है, साथ ही project और user data को third parties को दिए बिना और operating policies अचानक बदल सकने वाले बड़े vendors पर निर्भर हुए बिना चलना है
  • यह project अभी पूरा नहीं हुआ है और external contributions स्वीकार कर रहा है

Ordinary files और branches से manage होने वाली permissions

  • Database या Git tree के अंदर hidden blobs के बजाय code के पास ordinary files में सारा data store करता है
  • हर repository की .gitroot/users.yml user-wise writable locations specify करती है, और access control मुख्य रूप से branch restrictions पर काम करता है
    • शुरुआत में केवल owner को default branch तक access होता है
    • बिना permission वाला user default branch पर push करे तो GitRoot बदलाव reject कर देता है
    • कोई भी नई branch बना सकता है; बनाने वाले user को उस branch की write permission मिलती है और दूसरे users उसे modify नहीं कर सकते
    • अगर .gitroot/users.yml modify किया जाए या कोई ऐसी branch merge हो जिसमें user ने खुद को add किया हो, तो वह user भी default branch पर push कर सकता है
  • कोई भी files पढ़ सकता है और local या नई branch में modify कर सकता है, लेकिन repository की current state दिखाने वाली default branch में changes शामिल करने के लिए owner का merge जरूरी है
  • Forge की अपनी settings भी root repository में manage होती हैं
    • root repository की default branch के .gitroot/repositories.yml में changes जोड़ने या उन changes को merge करने पर repository बनती है
    • detailed working documentation में देखी जा सकती है

Alpha version में supported features

  • अभी यह alpha version है, इसलिए इसे test किया जा सकता है लेकिन production में इस्तेमाल नहीं करना चाहिए
  • Support का scope इस प्रकार है
    • repository creation और deletion
    • SSH के जरिए Git commands handle करना
    • repository और branch level पर user-wise writable locations manage करना
    • plugins install करना और repository-wise activate करना
    • installation के समय working tree में plugins run करना
    • installation के बाद हर commit पर diff के against plugins run करना
    • HTTP के जरिए repository browsing

1.0 तक की development plan

  • Version 1.0 से पहले ये features implement करने की योजना है
    • GitRoot और plugins updates
    • file-level user permissions management
    • HTTP के जरिए Git commands handle करना
    • groups और subgroups से repository management
    • plugin API stabilization

Self-hosting और contribution process

  • GitRoot website एक GitRoot instance है जो GitRoot code को ही host करता है, और सिर्फ GitRoot project के लिए operate होता है
  • दूसरे projects में test करने के लिए installation and usage documentation follow करनी होगी
  • GitRoot खुद भी GitRoot repository है, इसलिए उसी तरीके से contribute किया जा सकता है; process contribution guide में देखा जा सकता है
  • मौजूदा instance code के कुछ हिस्सों को default branch में integrate करने के लिए grafter plugin का उपयोग करता है, इसलिए contribute करने से पहले उसके working model को समझना जरूरी है
  • code, issues और translations सहित सारा data Git में store होता है, इसलिए अभी contribute करने के लिए Git का इस्तेमाल जानना जरूरी है
  • भविष्य में लक्ष्य है कि browser से ही git commit और git push सीधे चलाकर कोई भी participate कर सके

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 1 일 전
Lobste.rs की रायें
  • GitHub सिर्फ़ सबसे बड़ा Git repo ही नहीं था, बल्कि सबसे प्रभावशाली repo भी था, और Forgejo व GitLab के डिज़ाइन में भी उसका असर महसूस होता है। GitHub के पतन को एक अवसर मानें तो पुराने मॉडल से अलग कई तरह के repo उभर सकते हैं, इसलिए इनोवेशन की गुंजाइश काफ़ी बड़ी लगती है
    • Gitea ने पहले GitHub frontend को लगभग 1:1 कॉपी किया था, और Forgejo ने Gitea से fork होने पर वही रूप विरासत में लिया
  • मैं GitRoot बनाने वाला हूँ, और अगर कोई सवाल हो तो बेझिझक पूछ सकते हैं
    • मुझे तीन बातें जाननी हैं। CSS को minified state में commit करने की वजह क्या थी: https://gitroot.dev/worktree/app/…
      <pre> टैग की चौड़ाई 720px तक सीमित होने की वजह body का display:grid लगती है; इसे हटाने पर चौड़ाई उम्मीद के मुताबिक बढ़ जाती है। साथ ही URL में किसी खास commit point की जानकारी नहीं है, इसलिए लिंक भेजने और पाने वाले के लिए एक ही स्क्रीन देखना मुश्किल होता है। समझ सकता हूँ कि यह आपकी निजी ज़रूरत के लिए बना प्रोजेक्ट है, बस इसे विचार करने लायक बिंदु के रूप में कहना चाहता था
  • @manland, क्या LLM से बने contributions को अनुमति देने या रोकने के लिए कोई policy या guideline है
    • अभी ऐसी कोई अलग policy नहीं है। दो one-off contributors को छोड़कर code का 99.999% मैंने खुद लिखा है
      व्यक्तिगत रूप से मैं coding में LLM का इस्तेमाल नहीं करता और इसके ख़िलाफ़ हूँ, लेकिन अगर LLM का इस्तेमाल हुआ भी हो, तो patch काफ़ी छोटा हो तो क्या मैं उसे reject करूँगा, यह पक्का नहीं कह सकता
      मेरी मातृभाषा English नहीं है, इसलिए GitRoot को समझाना मेरे लिए मुश्किल है; इसी वजह से बाहरी communication में LLM के निशान हैं। पहले भी https://gts.gitroot.dev/@forge/statuses/01KFNWDKSZBEHTC16N5G02HJZ6 और https://gts.gitroot.dev/@forge/statuses/01KTP30NTY9FK91Q9B5Z9B4M52 पर मदद माँगी थी, लेकिन कोई नहीं आया
      यह दुखद है कि LLM का सहारा लेना पड़ता है, लेकिन कुछ भी न करने के बजाय मैंने इसे न्यूनतम रूप में इस्तेमाल करने का फैसला किया। आगे चलकर अगर community बनती है तो मैं इसे पूरी तरह हटाना चाहूँगा, और उससे पहले भी आर्थिक कारणों से यह अपने आप गायब हो सकता है। philosophy, security और future पर लिखने के लिए मेरी to-do list में बहुत कुछ है, लेकिन यह सोचकर लिखने से हिचकता हूँ कि आख़िर में LLM ही वाक्य सुधार देगा, typo ठीक करेगा और अनुवाद करेगा
  • Go plugins को WASM में compile करने के लिए TinyGo का इस्तेमाल किया गया, यह मुझे पसंद आया