- Jujutsu और अन्य version control systems के उपयोगकर्ताओं के लिए, ऐसे शुद्ध Git workflow चर्चा का विषय हैं जिन्हें प्रमुख Forge पर्याप्त रूप से कवर नहीं करते
- मुख्य रुचि SPA/JS या server-rendered HTML जैसी implementation methods में नहीं, बल्कि इस बात में है कि repository version control features को कैसे प्रस्तुत और संचालित करती है
- Tangled, GitHub के stacked PRs, forgefed जैसे विचार मौजूद हैं, लेकिन design पर user opinions इकट्ठा होने की जगह खोजना मुश्किल है
- इसमें stacked PR/MR और वैकल्पिक collaboration models भी शामिल हैं, और मौजूदा Forge से आगे जाने वाला version control experience एक प्रमुख मुद्दा है
- tags, commits, trees, blob जैसे repository objects का प्रदर्शन अधिकांश Forge में broadly समान है, और मामूली format differences के अलावा इस पर लगभग कोई चर्चा नहीं होती
1 टिप्पणियां
Lobste.rs की राय
अगर code review comments खुद repository का हिस्सा नहीं हैं, तो मैं उन्हें कभी इस्तेमाल नहीं करूँगा
कीमती ऐतिहासिक संदर्भ को mailing list, database silo, या ऐसी अलग layer में रखना जो HEAD commit hash से बंधी न हो, मूल रूप से GitHub जैसे ही जोखिम पैदा करता है
Fossil इस दिशा में कुछ हद तक जाता है, लेकिन वह अभी सिर्फ issues संभालता है और code review अब भी email patch तरीके से होता है: https://fossil-scm.org/home/doc/tip/www/contribute.wiki
एक बार यह जानकारी version control system के अंदर आ जाए, तो उसके ऊपर शानदार web UI, RSS feed, mailing list जैसी चीज़ें बनाई जा सकती हैं
दूसरी सुविधा है merge queue के लिए built-in support। किसी भी गैर-तुच्छ project में अलग-अलग contributors को main branch पर सीधे push नहीं करना चाहिए; अगर किसी commit को “integration के लिए तैयार” चिह्नित किया जाए, तो bot को suggested changes को serialize करना चाहिए, CI को optimal तरीके से schedule करना चाहिए, और main को verified hash तक आगे बढ़ाना चाहिए
तीसरी सुविधा है Windows, macOS जैसी heterogeneous environments में isolated work executor के रूप में CI: https://gregoryszorc.com/blog/2021/…
किसी को भी account बनाकर issue खोलने की अनुमति होनी चाहिए, लेकिन spam नहीं होना चाहिए
अभी GitHub यह काफ़ी अच्छी तरह करता है। कभी-कभी spam दिखता है, लेकिन abuse report के बाद बहुत जल्दी हटा दिया जाता है। लगता है इसके पीछे automated systems और असली लोगों की classification team दोनों हैं
मैं hobby project के लिए “forge” के रूप में Fossil देख रहा हूँ, और शायद बाहरी contributors बहुत ज़्यादा नहीं होंगे, इसलिए code review होना अच्छा है, पर अनिवार्य नहीं
इसकी जगह मैं एक SQLite DB चाहता हूँ जिसे sync किया जा सके, भेजा जा सके, और मनचाहे तरीके से query किया जा सके
git-pr में अगला बड़ा refactoring, जिस पर मैं काम करना चाहता हूँ, वह SQLite DB को SSH command के ज़रिए expose करना है:
ssh pr.pico.sh sqlSQLite हर जगह उपलब्ध है और general-purpose भी है, लेकिन forge के हिस्से के रूप में इसके लिए usability गायब है
लेकिन अगर history rewrite हो, जैसे force-push या squash merge, तो बाद में comments किस चीज़ पर “pin” होंगे ताकि users उन्हें ढूँढ सकें, यह जानने की उत्सुकता है
GitHub में इसका आधार Pull Request होता है, इसलिए शामिल commits बदल जाएँ तब भी discussion दिखती रहती है
क्या इस system में भी repository के अंदर stored अलग PR concept होगा, या इससे भी ज़्यादा tightly integrated कुछ सोचा जा रहा है, यह जानना चाहूँगा
फिर भी, मैं
jjअच्छी तरह इस्तेमाल कर रहा हूँ, इसलिए शायद व्यवहार में यह कोई बड़ी समस्या न होGerrit और email दोनों इस्तेमाल करने के बाद अफ़सोस होता है कि pull request model सबसे ज़्यादा हावी है
ख़ासकर तब, जब maintainer किसी style जैसी मामूली बात पर comment छोड़ने के बजाय खुद ही उसे ठीक कर सकता है, और contributor को भी शायद ऐसी style की उतनी परवाह न हो
लेकिन इससे भी ज़्यादा अफ़सोस की बात यह है कि आजकल मैं Darcs और Pijul का इस्तेमाल बढ़ा रहा हूँ, और इनके लिए email के अलावा कोई workflow है ही नहीं
email की जगह XMPP-based कुछ होना अच्छा रहेगा। इससे चल रहे patches पर real-time distributed collaboration हो सकती है, और हर patchset के लिए एक MUC भी रखा जा सकता है
MUC voice chat की तरह खुल सकता है, और roles, attachments, reactions, search, MAM, moderation, completion के बाद tombstoning जैसी सुविधाएँ तो XEP में पहले से defined हैं
subscription के लिए PubSub इस्तेमाल किया जा सकता है, और CI transport के रूप में भी
इसे practical बनाने के लिए dedicated client चाहिए होगा, लेकिन कई features किसी भी client में वैसे ही काम कर सकते हैं
वास्तविकता में शायद यह हाल के दिनों में पुरानी federated technologies के अनपेक्षित रूप से फैलने की तरफ़ मेरे आकर्षण का हिस्सा भर हो
code review और approval ही bottleneck हैं
code submitter के साथ communication में latency बहुत ज़्यादा होती है; कभी-कभी हफ़्तों या महीनों लग जाते हैं, और reliability भी कम होती है। कुछ लोग PR डालकर गायब ही हो जाते हैं
GitHub model, जो back-and-forth interaction पर निर्भर करता है, यहाँ पूरी तरह टूट जाता है
अच्छा होगा अगर review के दौरान code को सीधे edit किया जा सके और
git-absorbकी तरह commits amend किए जा सकें। typo जैसी छोटी बातों के लिए submitter के साथ आगे-पीछे करना समय की बर्बादी है, और GitHub का Edit Suggestion hack झंझट भरा है और history को भी गंदा करता हैमैं वही code दोबारा review नहीं करना चाहता। अगर किसी एक function या एक commit में ही दिक्कत है, तो बाकी सबको पहले से approve कर देना चाहिए, ताकि submitter force-push से fix कर दे तो बाकी चीज़ें फिर से न देखनी पड़ें
अच्छा होगा अगर PR का सिर्फ़ हिस्सा merge किया जा सके, या PR बंद किए बिना commits हटाए जा सकें। कभी-कभी feature नहीं चाहिए होता, लेकिन उसके लिए किया गया groundwork रखने लायक होता है; और कभी बेकार की “cleanup” या formatting भी बीच में घुस जाती है
जब original submitter जवाब न दे, तब दूसरे लोग PR पर मिलकर काम कर सकें, उसे polish कर सकें, और issues सुलझा सकें। GitHub model में सिद्धांत रूप से यह संभव है, लेकिन व्यवहार में यह किसी और PR पर PR बनाने जैसी छिपी हुई तकनीक लगती है, और वह code तथा notifications target project में दिखते भी नहीं
अगर लोग fork करके fix PR भेजते हैं, तो बस confusion और merge conflicts बढ़ते हैं
अक्सर submitted code काफ़ी ठीक-ठाक होता है, लेकिन थोड़ा improvement चाहिए होता है। submitter को लगता है कि PR तब तक बंधक बना हुआ है जब तक वह आख़िरी polishing भी पूरी न कर दे; maintainer के लिए दिक्कत यह है कि अगर अभी merge कर दिया और submitter गायब हो गया, तो follow-up improvements शायद कभी न हों। अच्छा होगा अगर temporary merge का कोई तरीका हो, जहाँ बाद में cleanup करने की obligation बनी रहे। उदाहरण के लिए, staging branch में merge कर दिया जाए लेकिन FIXME हल होने तक stable branch में cherry-pick न किया जाए
popular open source projects में अक्सर ऐसा होता है कि project को आगे बढ़ाने वाली code review और approval करने वाला सिर्फ़ 1 व्यक्ति होता है, जबकि contribute करना और एक-दूसरे की मदद करना चाहने वाले 500 लोग होते हैं। GitHub model इस surplus contributor capacity का ज़रा भी उपयोग नहीं कर पाता। सहयोग में मदद करने के बजाय इसे crisis, confusion, और angry mob pressure में बदल देता है। ऐसा बेहतर fork management और forks के बीच code copying support होना चाहिए, जिससे दूसरे लोग किसी एक maintainer पर अटके बिना experiment कर सकें और project को आगे बढ़ा सकें, और maintainer कई forks में से popular और proven changes आसानी से चुन सके
organizations में शायद यह default था; खैर, ऐसे मामलों में आप force-push से सीधे साफ़-सुथरे तरीके से fix कर सकते हैं
जिन छोटे fixes के लिए back-and-forth की कोई ज़रूरत नहीं होती, मैं हमेशा वही करता हूँ
आम तौर पर यह महीनों या वर्षों में मापा जाता है
कभी-कभी मैं खुद maintainer होता हूँ, और मानता हूँ कि मैं भी हमेशा इससे तेज़ नहीं होता
मैं go-to-definition, signature या doc comments दिखाने वाले hover popup जैसी चीज़ें चाहता हूँ
branch checkout करके अपनी पसंद के editor में review करें तो यह संभव है, लेकिन जैसा कहा, review ही bottleneck है
कई PR review करते समय बार-बार branches बदलना बहुत ज़्यादा overhead है
single-user, या कम से कम single-user mode ज़रूरी है
मुझे https://code.chrismorgan.example/chrismorgan/repository-name जैसे URL क्यों झेलने चाहिए? https://code.chrismorgan.example/repository-name काफ़ी है
मैं यह पूरी गंभीरता से कह रहा हूँ, और https://github.com/go-gitea/gitea/issues/11028 देखकर साफ़ है कि बहुत से लोग ऐसा चाहते हैं
मेरे Fediverse account न रखने के तीन बड़े कारणों में से एक यह भी है कि उसके addresses भयानक लगते हैं
अगर primary email address की तरह @me@chrismorgan.info इस्तेमाल करूँ, तो कुछ लोगों को शायद वह बस “@me” दिखे; और @chrismorgan@chrismorgan.info तो देखने में ही बुरा लगता है
इस मामले में ATProto ने बहुत अच्छा काम किया है। domain names handles के रूप में शानदार हैं, और अगर कई users चाहिए हों तो subdomains काफ़ी हैं
shared forge पर भी subdomains इस्तेमाल करके चीज़ों को तार्किक रूप से single-user जैसा बनाया जा सकता है। github.com/chris-morgan की जगह chris-morgan.github.com की कल्पना करना दिलचस्प हो सकता है
aesthetics मायने रखती है
single-user की तरफ़ जाना बड़े परिणाम भी लाता है। Mastodon जैसी चीज़ को single-user के लिए छोटा करें तब भी वह भारी रहती है, लेकिन शुरू से single-user के लिए डिज़ाइन किए गए Fediverse projects उस काम में ज़्यादा फिट बैठते हैं
मैं अपना server खुद चलाना चाहता हूँ, लेकिन local user सिर्फ़ मैं रहूँ; दूसरे users की संभावना के कारण समझौता नहीं करना चाहता
इसका मतलब यह भी है कि forges में आम
gitजैसे username की जगह मैं सामान्य SSH की तरहchrisusername से push करना चाहता हूँअगर उसे सामान्य अर्थ वाला forge माना जाए, तो federation तो स्वाभाविक रूप से चाहिए। लेकिन हर किसी के “home server” पर local user एक ही होना अच्छा रहेगा
अगर आप अपना domain इस्तेमाल करते हैं, तो वहाँ भी ऐसा ही मसला नहीं आता?
इस विषय पर Nesbitt’s article मुझे पसंद आया
ख़ासकर downstream के साथ बेहतर communication वाली बात
अपनी पसंद के editor में local code review कर पाना चाहिए
मैं किसी सुस्त web interface में फँसना नहीं चाहता, जहाँ न font बदला जा सकता हो और न ही syntax highlighting ढंग की हो
अभी मैं Neovim के लिए custom tools वाले workflow का इस्तेमाल करता हूँ, जिससे side-by-side diff ठीक से दिख सके, और
git prcommand से pull request checkout कर लेता हूँलेकिन जैसे ही review comment छोड़ने जैसी थोड़ी और ज़रूरत होती है, मुझे किसी ऐसे CLI या tool पर निर्भर होना पड़ता है जो GitHub API से बात करता है और जिसके 5 साल बाद भी maintain रहने की संभावना कम है
और ज़्यादा सटीक रूप से कहूँ तो सिर्फ़ local में “चल सकने” वाले tools नहीं, बल्कि editor आदि के साथ local पर integrated local-first tools ज़्यादा चाहिए
इसे first-class feature बनाना मुश्किल इसलिए है क्योंकि इसमें काफ़ी मेहनत लगती है। एक web interface users को मजबूर करके हर platform और editing environment में “काम” कर जाता है, लेकिन tighter integration के लिए editors और environments अगर N हैं तो integrations भी N चाहिए
CI के साथ भी यही बात है। मैं branch पर commit push करके 15 मिनट तक queue में फँसना नहीं चाहता; मैं Linux, FreeBSD, macOS पर tests आसानी से चला सकूँ, यह चाहिए
run-remotely some-command --on freebsd,linux,macजैसा कुछ काफ़ी होगामूल रूप से यह local-first और decentralized CI system होना चाहिए, लेकिन साथ ही ऐसा central system भी support करना चाहिए जो single source of truth की तरह यह सुनिश्चित करे कि merge से पहले सारा code एक ही “approved” system से गुज़रे
यह सिर्फ़
ssh user@host command ...से आगे की चीज़ है, क्योंकि हर बार वही भरोसेमंद state पाने के लिए source code copying, caching, और ज़रूरी dependencies install करने जैसी चीज़ें भी शामिल होंगीलेकिन मुझे नहीं लगता कि यह forge feature है। इसे किसी specific forge के बिना इस्तेमाल किया जा सके, और किसी भी forge से call किया जा सके, ऐसे task executor tool के रूप में देना चाहिए
मुझे लगता है यह थोड़ा “driver-based” होना चाहिए। उसी task को पूरी तरह local चलाया जा सके, या remote system पर भेजकर वहाँ run कराया जा सके। वह task virtual machine भी हो सकता है, container भी, या direct execution भी
Git के अलावा दूसरे version control systems का support भी होना चाहिए
issues, wiki वगैरह को सुविधाजनक format में import/export किया जा सके, ताकि किसी एक system में बंद न हो जाएँ
self-hosting भी आसान होनी चाहिए
व्यवहार में शायद कुछ महत्वपूर्ण systems की सीमित range ही मायने रखेगी
sibling comment में Heptapod, Mercurial के लिए है, और sourcehut, also भी है
Fossil की अपनी forge है, और SourceForge के Apache version allura में Subversion मिलता है
अच्छा होगा अगर कोई forge CI layer में Bazel-जैसी कोई चीज़ दे
मतलब “CI में Bazel चला सकते हैं” नहीं, बल्कि ऐसा रूप जहाँ लोग dependencies के साथ अच्छे tests और builds का सेट लिखने के लिए स्वाभाविक रूप से प्रेरित हों, ताकि बिना वजह CI time बर्बाद न हो
इसी से जुड़ी बात यह है कि “एक project = एक repository” model ने बहुत सी समस्याएँ पैदा की हैं
आप इसे बेहतर monorepo support भी कह सकते हैं, लेकिन मूल रूप से CI और issues जैसी चीज़ों का scope “इस directory के top-level” से बड़ा होना चाहिए
कई projects forge या CI की वजह से repositories को बाँट देते हैं, और उस हालत में काम करना मज़ेदार नहीं होता
reviewer के रूप में मैं inline patch splitting भी चाहता हूँ
मतलब, जिन हिस्सों को मैं अच्छा समझता हूँ उन्हें चुन सकूँ, सिर्फ़ उन्हीं को approve कर सकूँ, और संतोषजनक हिस्सों को integrate किया जा सके
stacked PR अभी भी मेरे हिसाब से बहुत भारी concept है
अगर कोई कहे, “मैं 4 files बदलना चाहता हूँ और इसे एक PR मानता हूँ,” तो reviewer को कह पाने में सक्षम होना चाहिए, “ठीक है, ये 2 files सही हैं,” और उन changes के bundle को PR के अलग हिस्से में बदल दे, या यहाँ तक कि सिर्फ़ उसी टुकड़े को अलग commit के रूप में merge कर दे
मौजूदा stacked PR systems भी PR को atomic unit की तरह ही लेते हैं। ज़्यादातर systems में PR बहुत भारी लगता है
वजह यह दी जाती थी कि “वह file का subset है, इसलिए यह पता नहीं कि वह compile होगा या नहीं”
मैं उस सोच से बिल्कुल सहमत नहीं हूँ, लेकिन web view में ऐसा काम करना काफ़ी सावधानी माँगता है, इसलिए यह comment पढ़कर वही याद आया
बेशक, ऊपर वाले comment की तरह अगर आप repository owner हैं तो branch पर अपनी पसंद का version force-push कर सकते हैं—उस बात को अभी अलग रखकर
बिना मेहनत वाली CI/CD setup चाहिए
सिर्फ़
make build,make test,make uploadहों, इतना काफ़ी हैबाकी सब makefile में रहने दें, और वहीं से लोग बेहतर build system की तरफ़ बढ़ सकते हैं
मैं idea से published execution artifact तक 2 मिनट के भीतर पहुँचना चाहता हूँ
ज़्यादातर CI/CD systems की तरह किसी well-known location में config file रखने के बजाय, किसी well-known directory में well-known names वाली तीन shell scripts रख दीजिए
bonus के तौर पर, अगर Windows build चाहिए तो उन्हें
.batfiles भी बनाया जा सकता हैयह operating system के हिसाब से बदल सकता है, और हो सकता है लोग इसे makefile के अंदर न रखना चाहें
फ़ायदा यह है कि हर task zmx के नीचे अपने pty में चलता है
किसी failed task से attach होकर ऊपर वाला arrow और Enter दबाकर उसे फिर से चलाया जा सकता है
मैं security advisories चाहता हूँ जिनमें guardrails हों, ताकि high-quality data publish हो
ऐसा commit-centric ecosystem चाहिए जिससे हर project अर्थपूर्ण data publish कर सके, और जो projects चाहें उनके लिए खुद CVE जारी करने का integration भी होना चाहिए