Gitea: फ़ेडरेटेड पुल अनुरोधों का समर्थन करें

_From 25 मई, वर्ष 2016 12 पर @roblabla: 9_

कुछ हद तक संबंधित: https://github.com/gogits/gogs/issues/2210

व्यक्तिगत होस्टेड गिट सेवा के लिए यह नंबर एक विशेषता है!
#185 के साथ और भी बड़ा होगा!

इसे गिट-मूल्यांकन एकीकरण के साथ भी एकीकृत किया जा सकता है?

@ekozan औपचारिक प्रस्तावों का स्वागत है, लेकिन मुझे लगता है कि git-appraise एकीकरण फ़ेडरेटेड पुल अनुरोधों के लिए एक अच्छा साथी हो सकता है (मूल रूप से बाकी कोड के साथ फ़ेडरेटेड नोड्स में समीक्षा यात्रा है, है ना?)

GitLab इस मुद्दे को यहां ट्रैक कर रहा योजना बना रहे हैं।

@bkcsoft शायद आप GitLab स्पेक्स को इतना खुला रखने में मदद कर सकते हैं कि GitLab और Gita के बीच भी PR को फ़ेडरेट करने की अनुमति दे सके?

@strk @bkcsoft GitLab से संबद्ध है?

@strk मैं इसे सर्वर के बीच पैच-फाइल भेजने की दिशा में चला सकता हूं (शायद वेबहुक का उपयोग कर रहा हूं?) मेरा सुझाव है कि गीता को भी यही करना चाहिए। सर्वर के बीच धक्का/खींचना आसान नहीं है :)
@stevenroose हाँ

ठीक है, ऐसा लगता है कि वे पहले से ही सोच रहे हैं या git request-pull -p (जो साथ में पैच भेजता है) का उपयोग कर रहे हैं, इसलिए यह क्रॉस-प्लेटफ़ॉर्म संगत होना चाहिए: थोड़ा_स्माइलिंग_फेस:

वे अपने शिखर सम्मेलन के दौरान इस सुविधा का उल्लेख करने की योजना बना रहे हैं।

https://gitlab.com/gitlab-org/gitlab-ce/issues/4013 को moonshot रूप में टैग किया गया है, असाइन नहीं किया गया है, कोई मील का पत्थर नहीं है और दृष्टि में कोई एमआर नहीं है। तो हो सकता है कि अभी तक आपकी उम्मीदें पूरी न हों: थोड़ा_मुस्कुराते हुए_फेस:

@bkcsoft हम यहां नेतृत्व कर सकते हैं :)

@bkcsoft हम यहां नेतृत्व कर सकते हैं :)

मुझे विश्वास नहीं हो रहा है कि गिटहब लॉकिन समस्या को हल करना चाहता है: पी

नहीं, लेकिन अगर अन्य प्लेटफॉर्म आगे बढ़ते हैं, तो लोग मांग कर सकते हैं कि वे अनुसरण करें। और लोग पलायन कर सकते हैं :)

गेरिट जैसा सॉफ्टवेयर उसके लिए अनुमति देता है

@stevenroose क्या आपके पास गेरिट समर्थन के बारे में संदर्भ है?

यदि हम गेरिट को लागू करते हैं, तो क्या हम गोलंग टीम को गीता का उपयोग करने के लिए आमंत्रित कर सकते हैं? मैं

@strk गेरिट के साथ, आप git-review का उपयोग करके अपने कामों को पैकेज करते हैं और उन्हें एक निश्चित रेफरी पर धक्का देते हैं और यह कोड समीक्षा के रूप में गेरिट में दिखाई देगा। गेरिट कांटा बनाने की आवश्यकता नहीं है। हालांकि यह git request-pull उपयोग नहीं करता है।

आपको उन्हें आगे बढ़ाने के लिए अभी भी रेपो को लिखने की अनुमति की आवश्यकता होगी
रेफरी के लिए समीक्षा, है ना?

उस स्थिति में लापता बिट अभी भी अंततः ट्रैकिंग करेगा
समीक्षा रेफरी रखने वाला एक अलग रेपो?

हाँ यह अलग है। यह व्यक्तिगत बिट्स को लिखने की अनुमति के साथ धक्का देता है।

फ़ेडरेटेड पीआर के साथ, गीता को समय-समय पर (या अनुरोध पर) नए परिवर्तनों के लिए शाखा संदर्भ की जांच करनी चाहिए।

AFAIK, git अनुरोध-पुल git कमिट का उपयोग बिल्कुल नहीं करता है। यह केवल स्थानीय और दूरस्थ के बीच काम करने की एक सूची उत्पन्न करता है, और इसे stdout पर प्रिंट करता है। हमें उन परिवर्तनों को रिमोट में भेजने/उन्हें रिमोट से खींचने के लिए एक तरीका निर्दिष्ट करने की आवश्यकता होगी

गिट अनुरोध-पुल मानक गिट इंस्टॉल का हिस्सा है, हालांकि गिट मूल्यांकन या गिट समीक्षा के विपरीत।

@roblabla हाँ प्रवाह git request-pull को एक फ़ाइल में सहेजना और उसे अपलोड करना होगा (जैसे अतीत में पैच सबमिट करना कैसे काम करता था)। या या तो रिमोट रेपो की शाखा में एक यूआरएल दर्ज करें ताकि गीता पीआर को अपडेट कर सके।

जब तक मुझे कुछ याद नहीं आ रहा है git request-pull एक विशिष्ट प्रतिबद्धता का संदर्भ देता है,
जबकि जिथब/गीता पुल अनुरोध एक (संभवतः चलती) शाखा का संदर्भ देता है।

क्या हम विशिष्ट प्रतिबद्धताओं के बजाय शाखाओं को ट्रैक करने के लिए फ़ेडरेटेड अनुरोध चाहते हैं?
मुझे लगता है कि हम एक शाखा को ट्रैक करने के लिए एक पीआर (टिप्पणियों/चर्चा का धागा) चाहते हैं।

यह विशिष्ट _commits_ हाँ का संदर्भ देता है। इसलिए हमें लगातार डेटा को फिर से लाना होगा

मंगलवार, 20 दिसंबर, 2016 को 12:20:34 पूर्वाह्न -0800 बजे, bkcsoft ने लिखा:

यह विशिष्ट _commits_ हाँ का संदर्भ देता है। इसलिए हमें लगातार डेटा को फिर से लाना होगा

हम केवल नए कमिट प्राप्त कर सकते हैं यदि हमारे पास किसी शाखा के नाम का संदर्भ है,
जो git request-pull आउटपुट में नहीं है। तो अगर हम रखना चाहते हैं
track-a-branch दृष्टिकोण, हम git request-pull पर भरोसा नहीं कर सकते।

एक पीआर निर्माता एक दूरस्थ यूआरएल और एक शाखा का नाम मांग सकता है, देखें
दूरस्थ शाखा स्थानीय रूप से, कुछ जाँच करें (यानी: पीआर बनाने से इनकार करें
बड़ी संख्या में परिवर्तन), और पीआर बनाएं।

फिर अधिक प्राप्त करने के लिए एक बटन और एक वेबहुक उपलब्ध कराया जा सकता है
दूरस्थ शाखा से, यदि कोई हो, करता है। केवल पीआर लेखक होना चाहिए
अद्यतनों का अनुरोध करने की क्षमता दी गई है। अपने कांटे पर एक गिट हुक रखकर
गंतव्य वेबहुक को हिट करने के लिए अद्यतन अनुभव को आसान बना देगा।

--स्ट्रक;

मैं सुझाव दूंगा कि अतिथि खाते के रूप में पीआर बनाते समय, आपके पास "बाहरी" या "संघीय" या जो भी दो विकल्प हों, वाला एक टैब होगा:

1. एक शाखा यूआरएल के लिए एक टेक्स्ट इनपुट फ़ील्ड, "लाने" या "परीक्षण" बटन के साथ पहुंच योग्यता और ट्रैकिंग की उपलब्धता की जांच करने के लिए हो सकता है

2. .diff , .patch फ़ाइल या git-request-pull के आउटपुट को अपलोड करने के लिए फ़ाइल अपलोड फ़ील्ड; यह एक textarea भी हो सकता है

बाद के मामले में, एक बार पीआर बन जाने के बाद, उपयोगकर्ताओं को पीआर में कमिट्स को बदलने के लिए अपनी पिछली फाइल को ओवरराइट करने में सक्षम होना चाहिए।

साथ ही, स्वचालित शाखा अद्यतनों की अनुपलब्धता के मामले में, आपको उपयोगकर्ता को मैन्युअल रूप से रीफ़ेच को ट्रिगर करने की आवश्यकता हो सकती है। लगभग सभी मामलों में, उपयोगकर्ता विशेष रूप से प्रतिबद्धता के आलोक में एक PR'ed शाखा के लिए प्रतिबद्ध होते हैं, इसलिए जब भी शाखा को अपडेट करना होता है, तो वे केवल रीफ़ेच कर सकते हैं। (ध्यान रखें कि अक्सर, पीआर में फीडबैक के कारण प्रतिबद्धता के अपडेट होते हैं, इसलिए उनके पास पेज वैसे भी खुला रहता है।)

जैसा कि मेरी थीसिस प्रमोटर ने कहा: "एक बदलाव का असली विरोध उन लोगों से नहीं होता है जो इसके खिलाफ हैं बल्कि उन लोगों से आते हैं जो कहते हैं कि यह पर्याप्त नहीं है।"

मुझे नहीं लगता कि यह सुविधा उपयोगी है, आप इस मामले के लिए दो रिमोट जोड़ सकते हैं। उदाहरण के लिए जीएच के लिए शाखा जीथब, गोग्स के लिए मास्टर, मैं अपने काम में एक भंडार के साथ दोनों का उपयोग करता हूं। और गिट समीक्षा एक और चीज है। छोटी समस्या को हल करने के लिए बड़ी सुविधा न बनाएं।
वैसे भी, गॉग्स छोटे व्यवसाय या स्वयं होस्टिंग पर ध्यान केंद्रित करते हैं। सार्वजनिक क्लाउड सेवा के लिए नहीं।

@renothing मुझे नहीं लगता कि आप प्रस्ताव को पूरी तरह से समझते हैं। इसका विभिन्न दूरस्थ स्रोतों से कोड की तुलना या चेकआउट करने में सक्षम होने से कोई लेना-देना नहीं है। इसके बजाय, यह लोगों को आपके सिस्टम में पंजीकृत किए बिना पुल अनुरोध या पैच सबमिट करने की अनुमति देने के बारे में है। अगर मैं अपने गीता इंस्टेंस पर सॉफ़्टवेयर का एक टुकड़ा प्रकाशित करता हूं, तो मैं चाहता हूं कि अन्य लोग पंजीकरण, फोर्किंग, मेरे उदाहरण में अपने परिवर्तनों को आगे बढ़ाने और फिर पीआर बनाने की परेशानी से गुजरने की आवश्यकता के बिना पीआर बनाने में सक्षम हों।

@stevenroose
जैसा कि मैंने कहा, यह काफी मांग वाला दृश्य है। इसके बारे में सोचें, कितने लोगों को पीआर को सार से मर्ज करने की आवश्यकता है? मुझे नहीं लगता कि इस फीचर को गीता कोर में जोड़ना जरूरी है। शायद यह एक प्लगइन के लिए ठीक है जब gita प्लगइन आर्किटेक्चर तैयार है।

@renothing अगर मैं समझता हूं कि इस मुद्दे को यहां सही तरीके से निपटाया जा रहा है, तो यह सिर्फ एक साधारण सार विलय से कहीं आगे निकल जाता है। यह कई गिटिया विभिन्न उदाहरणों के बीच विलय से निपटता है, और यहां तक ​​​​कि गिटहब भंडार और एक गिटिया उदाहरण के बीच भी। यह इंटरनेट पर किसी भी समर्थित git सर्वर पर किसी भी दूरस्थ शाखा से परिवर्तनों को मर्ज करने की अनुमति देता है।

@stevenroose अगर मैं गलत हूं तो मुझे सुधारो: स्माइली:

@sbrl
आप सही हैं, लेकिन अगर कोई आपके रेपो के लिए योगदान करना चाहता है, तो उसे पहले आपका कोड लाने की आवश्यकता होगी, उसे दो रिमोट रखना होगा (एक अपने लिए, एक आपके लिए)। इसने काम को बिल्कुल भी कम नहीं किया। यह सुविधा सिर्फ लॉगिन/रजिस्टर चरण को कम करती है। यह बहुत ज्यादा मदद नहीं करता है, शायद ईमेल पथ भेजना लिनक्स कर्नेल की तरह बेहतर विकल्प है।

मैं तुम्हारे साथ ठीक नहीं हूँ @ renothing

1. जब आप गिट के साथ काम करते हैं तो आपके पास हमेशा कई रिमोट होते हैं
2. यह जरूरी है
3. लॉगिन कदम उबाऊ हैं
4. gitlab यह भी करेगा: https://gitlab.com/gitlab-org/gitlab-ce/issues/4013
5. यह एक मुख्य विशेषता है इसलिए यह एक प्लगइन नहीं है

मैं वैसे भी फ़ेडरेटेड पुल अनुरोधों के समर्थन के लिए तैयार हूँ
मुझे नहीं लगता कि वे लॉग इन की जगह ले सकते हैं, जैसा कि आप अभी भी चाहते हैं
किसी तरह पीआर फाइल करने और टिप्पणी करने की अनुमति देना/निरस्त करना
संबंधित धागा।

लॉगिन भाग का OpenID लॉगिन द्वारा ध्यान रखा जाना चाहिए (वहाँ है
उस हिस्से के बारे में एक और टिकट)।

@renothing जहां तक ​​​​मैं कह सकता हूं, वास्तव में यह सर्वर होगा जो स्वचालित रूप से रिमोट से कोड को स्वचालित रूप से प्राप्त करेगा, जिसका अर्थ है कि पुल अनुरोध करने वाले दोस्त को बस अपने सर्वर पर एक शाखा को धक्का देना है, और करता है 2 रिमोट नहीं होने चाहिए (फिर से, अगर मैं गलत हूं तो मुझे सुधारें)।

इसके अलावा, अगर आपको यह पसंद नहीं है, तो मुझे यकीन है कि इसे अक्षम करने का एक विकल्प होगा - कोई भी आपको यह नहीं बता रहा है कि आपको इसका उपयोग करना है: स्माइली:

वास्तव में। आप गिटहब का इस्तेमाल कर सकते हैं, मैं अपनी खुद की गीता का इस्तेमाल करता हूं। यदि आप मेरे प्रोजेक्ट में योगदान देना चाहते हैं, तो मैं नहीं चाहता कि आप मेरे गीता उदाहरण पर एक खाता रखें, क्योंकि आप गिटहब का उपयोग करते हैं। मैं चाहता हूं कि आप गिटहब पर अपने रेपो पर एक शाखा में एक सुविधा को धक्का दें, फिर मेरे उदाहरण, प्रोजेक्ट होमपेज पर वापस आएं और अपनी गिटहब शाखा से पीआर को मास्टर में दर्ज करें। आपको एक खाता बनाने की आवश्यकता के बिना, आपको बस अपने GitHub खाते से लॉगिन करना है, (शायद एक कैप्चा करें) और URL को अपनी GitHub शाखा में पेस्ट करें।

जैसा कि मैंने शायद किसी अन्य पीआर (ओपनआईडी एक) में देखा हो, भले ही कोई लॉग करता हो
एक दूरस्थ प्रमाणीकरण तंत्र के साथ (मेरे मामले में OpenID, GitHub/OAuth2
आपके द्वारा बनाए गए उदाहरण में) उसे अभी भी स्थानीय उदाहरण पर एक रिकॉर्ड की आवश्यकता है,
यदि नहीं तो अपने प्रस्तावित के बारे में चर्चा में भाग लेने में सक्षम होने के लिए
परिवर्तन, और शायद उत्तर के मेल द्वारा अधिसूचित किया जा सकता है।

इसलिए दूरस्थ git सर्वर पर शाखाओं को संदर्भित करने की अनुमति देना ज्यादातर है
योगदानकर्ता को अनुमति दिए जाने की आवश्यकता को दूर करने के साथ क्या करें
और वास्तव में वह पहले से होस्ट किए गए कोड के लिए एक नया गिट भंडार बनाएं
कहीं और। मूल रूप से मनमाने ढंग से कांटे की मेजबानी करने की स्वतंत्रता देना
होस्टर्स

हो सकता है कि एक दिन हमें सक्षम होने के लिए पर्याप्त अनुमतियां मिलें
ऐसे उपयोगकर्ता रखने के लिए जो पीआर भेज सकते हैं लेकिन स्थानीय भंडार/कांटे नहीं बना सकते हैं।

गीता कोर को सरल रखने के लिए, मुझे यह सुविधा बिल्कुल पसंद नहीं है। यह मुख्य सुविधाओं को और अधिक जटिल बना देगा, न केवल पुल अनुरोध प्रणाली के साथ, अनुमति प्रणाली के साथ और तीसरे सीआई सिस्टम के साथ एकीकरण के लिए कठिन। वैसे भी, मुख्य लेखकों को चुनने का अधिकार है।

@renothing ठीक है, मुख्य लेखक वे नहीं हैं जिन्हें चुनना चाहिए, यह उपयोगकर्ता हैं जिन्हें करना चाहिए।

सीआई पर, मुझे नहीं लगता कि यह कोई मुद्दा है। सीआई जो करता है वह सिर्फ एक शाखा खींचता है और कुछ स्क्रिप्ट चलाता है। चूंकि सीआई सिस्टम वैसे भी गोग्स इंस्टेंस से अलग है, इसलिए गोग्स रेपो या किसी अन्य रिमोट रेपो से शाखा खींचने में वास्तव में कोई फर्क नहीं पड़ता है।

इसके अलावा, एक अनुमति प्रणाली वैसे भी होनी चाहिए। लेकिन यह केवल "अतिथि खातों" के लिए एक अतिरिक्त चेकबॉक्स होने से अधिक जटिल नहीं होना चाहिए। आपके पास _प्रतिबद्धता, मुद्दे बनाने, पीआर बनाने और टिप्पणी करने जैसी अनुमतियां हैं और फिर आपके पास तीन प्रकार के उपयोगकर्ता होंगे _रेपो के सदस्य, गोग्स में पंजीकृत खाते, और अतिथि_। ईज़ी z

"अतिथि खाते" के लिए एकल ध्वज का विचार दिलचस्प लगता है।
लेकिन तब कोई भी अतिथि परिवर्तन "देख" नहीं सकता था, है ना?

आप एक फ़ेडरेटेड पीआर दाखिल कर रहे होंगे और उस पर टिप्पणियाँ प्राप्त नहीं करेंगे, जब तक कि
आपका ईमेल (और प्रीफ़) सिस्टम द्वारा जाना जाता है।

क्या आप सहमत हैं कि उपयोगकर्ता के लिए वैसे भी एक स्थानीय रिकॉर्ड बनाया जाना चाहिए?

@strk। आप करेंगे। मेहमान OpenID से लॉगिन करते हैं, ताकि उनका ई-मेल पता पता चल सके। उपयोगकर्ता डीबी को केवल "असली" उपयोगकर्ताओं और अतिथि लोगों के बीच अंतर करना चाहिए।

"इस उदाहरण के सदस्य नहीं" के साथ, मेरा मतलब यह नहीं था कि डीबी में उनका कोई रिकॉर्ड नहीं था।

आपको अभी भी यह जानना होगा कि टिकट पर टिप्पणियां प्राप्त करने पर कौन सा ईमेल (और इस प्रकार उपयोगकर्ता) सूचित करना है, इसलिए टिकट (पीआर) और "उपयोगकर्ता" (अतिथि या नहीं) के बीच एक संबंध होना चाहिए - इसका मतलब अभी भी है उस एसोसिएशन के लिए डेटाबेस में एक रिकॉर्ड।

BTW, OpenID प्रदान किया गया ईमेल आवश्यक रूप से विश्वसनीय/पुष्टि नहीं है, इसलिए यदि आप ईमेल के बारे में सुनिश्चित होना चाहते हैं तो आपको अभी भी इसका ध्यान रखना होगा

फ़ेडरेटेड गिट होस्टिंग सेवा के बारे में विचारों वाले NotABug लोगों द्वारा दिलचस्प डिज़ाइन दस्तावेज़: https://notabug.org/NotABug.org/notabug/src/master/README.md

जीएच/बीबी/जीएल के लिए ओएथ का उपयोग एक बार खाते को लिंक करने के लिए किया जा सकता है, फिर यदि आप इसे अनुमति देते हैं तो गीता आपके रिमोट रेपो और शाखाओं को सूचीबद्ध करता है और आप किसी भी रेपो के लिए पीआर बना सकते हैं जिसमें एक आम पूर्वज है (यह पता लगाना कि ऐसा दर्द होगा। ..) केवल एक समस्या जो मैं देख रहा हूं वह यह है कि _all_ अन्य सिस्टम (GitHub, BitBucket, GitLab) में इस डेटा को लाने के लिए अलग-अलग API हैं, हमें सभी या किसी का समर्थन करने की आवश्यकता नहीं होगी। मैं प्लगइन्स कहता हूं: ट्रोलफेस:

@strk वह डिज़ाइन दस्तावेज़ सिद्धांत में अच्छा दिखता है, लेकिन
कोई इसका मुकाबला कर सकता है "लेकिन हम पहले हो सकते हैं!", अगर हम पहले हैं और फिर हर कोई दूसरे "मानक" पर बस जाता है तो हम फंसे रह जाते हैं और हमारे मौजूदा प्रवाह को अन्य मानक के साथ बदलने के लिए _व्यक्तिगत शौक समय_ लेना पड़ता है , संभवतः वर्तमान प्रवाह को तोड़ना। यदि हम इसके बजाय कुछ मौजूदा तकनीक का उपयोग करते हैं जो कि व्यवहार्य है, और अन्य किसी ऐसी चीज पर समझौता करते हैं जिसे हम इसके बजाय लागू कर सकते हैं। लेकिन उस समय तक मैं "फेडरेशन" शुरू करने से बचना चाहूंगा, जब यह बिल्कुल फ़ेडरेटेड नहीं है। एक बार करो, और सही करो

यह वास्तव में चिकन और अंडे की समस्या है। जब तक कोई फेडरेशन को लागू नहीं करेगा, तब तक कोई भी फेडरेशन को लागू नहीं करेगा।

संपादित करें: मैं यह भी तर्क दूंगा कि यदि हम गॉग्स के उदाहरणों में संघटित हो सकते हैं, तो हमने पहले ही महासंघ की ओर पहला कदम बढ़ा दिया है।

@roblabla ठीक है, मैं उदाहरणों में पुल अनुरोधों के खिलाफ नहीं हूं, हालांकि मैं जो कह रहा हूं वह _use मौजूदा कार्यक्षमता_ है, जैसे कि विभिन्न प्रदाता एपीआई :)

मैं एक सामान्य समाधान पसंद करूंगा जो ज्ञात एपीआई के लिए बाध्य है, खासकर स्वामित्व सेवाओं से।

मैं @strk से सहमत हूं। गिट अपने आप में काफी शक्तिशाली है, मैं जितना संभव हो सके कोर गिट कार्यक्षमता का सहारा लेने की कोशिश करूंगा।

यदि महासंघ को Git URI के आधार पर लागू किया जाता है, तो होस्टिंग प्रदाताओं के लिए UI चीनी जोड़ना इतना कठिन नहीं है। गीता के लिए, हम पीआर से जानकारी निकालने के लिए अपने स्वयं के एपीआई का उपयोग करते हैं। जीएच/जीएल/... के लिए हम या तो उनका समर्थन नहीं कर सकते हैं, इसलिए बस कॉपी-पेस्ट गिट यूआरआई का समर्थन करें, या इन यूआरआई को एपीआई से पुनर्प्राप्त करने के लिए यूआई विजेट लागू करें। या इससे भी आसान, पीआर यूआरएल को गिट यूआरआई के साथ मैप करें।

एक मुद्दा यह है कि जहां तक ​​​​मुझे पता है, रिमोट रेपो में शाखा का प्रतिनिधित्व करने का कोई मानक तरीका नहीं है। मुझे लगता है कि मैंने पहले git://provider/repo.git#refs/mybranchref था, लेकिन मुझे यकीन नहीं है कि यह कितना मानक है।

बुध, 22 मार्च, 2017 को 09:47:06 पूर्वाह्न -0700 बजे, स्टीवन रूज ने लिखा:

एक मुद्दा यह है कि जहां तक ​​​​मुझे पता है, रिमोट रेपो में शाखा का प्रतिनिधित्व करने का कोई मानक तरीका नहीं है। मुझे लगता है कि मैंने पहले git://provider/repo.git#refs/mybranchref था, लेकिन मुझे यकीन नहीं है कि यह कितना मानक है।

मैं नहीं देखता कि यह कैसा मुद्दा है।
बस यह कहें कि "संघीय पुल अनुरोध" सबमिट करने के लिए आपके पास होगा
सभी सूचनाएं प्रदान करने के लिए जो "गिट अनुरोध-पुल" आपसे पूछता है
प्रदान करना ...

यह अनिवार्य रूप से एक ही URL नहीं है, एक संपूर्ण रूप भी हो सकता है...

प्रस्तावित मानक पर जीएच/जीएल से उनकी प्रतिक्रिया के लिए पूछने के बारे में क्या? इस विषय पर व्यापक चर्चा की शुरुआत हो सकती है

ज़रूर, लेकिन हमें पहले उस प्रस्तावित मानक की आवश्यकता है ...

Pagure (https://pagure.io/pagure) सिस्टम रिमोट पुल अनुरोध का समर्थन करता है, जो मुझे फेडोरा पैकेज रिपॉजिटरी पर काम करते समय उपयोगी लगा। रिमोट पुल अनुरोध करने के लिए आपको पंजीकृत होने की आवश्यकता है।

देखें: https://docs.pagure.org/pagure/usage/pull_requests.html#remote -git-to-pagure-pull-request

संबंधित: https://github.com/gogits/gogs/issues/4437

इस पर कोई भी समाचार? वर्तमान में माइक्रोसॉफ्ट द्वारा गिथब के अधिग्रहण के बारे में बहुत सारी खबरें हैं, इसलिए एक गिट वेब-सेवा के संदर्भ में महासंघ बहुत अच्छा होगा :)

आपकी टिप्पणी से अधिसूचना देखने से एक मिनट पहले मैं सचमुच इस मुद्दे की खोज में आया था। यह (और फ़ेडरेटेड पुल अनुरोध) वास्तव में अगले गिट प्लेटफॉर्म के लिए हत्यारा सुविधा है। मुझे एक OpenID लॉगिन टैब दिखाई देता है, लेकिन Google जैसे बड़े OpenID प्रदाताओं तक आसान पहुंच के संबंध में यह बहुत उपयोगकर्ता के अनुकूल नहीं है। मैंने केवल गिटहब के लिए अपवाद देखा।

हेलो सब लोग। माइक्रोसॉफ्ट द्वारा गिटहब की खरीद के बाद, फ़ेडरेटेड गिट इंफ्रास्ट्रक्चर के विषय पर क्या किया जा रहा था, यह देखते हुए मुझे यह समस्या मिली।

जब उपयोगकर्ता पहचान, टिप्पणियों, गतिविधि को फ़ेडरेट करने की बात आती है ... और मुझे लगता है कि अनुरोधों को भी खींचें/मर्ज करें, मुझे लगता है कि एक्टिविटीपब मानक का उपयोग करके इसे केवल गिट इंफ्रास्ट्रक्चर को एक साथ जोड़ने से भी ज्यादा कुछ होगा: यह अन्य गतिविधिपब के साथ गिट इंफ्रास्ट्रक्चर को फेडरेट करेगा कार्यान्वयन। उदाहरण के लिए, तो यह आपको एक पर पुल अनुरोध टिप्पणी करने के लिए अनुमति दे सकते हैं Gitea एक से उदाहरण मेस्टोडोन उदाहरण, अनुवर्ती करने के लिए एक पर एक वीडियो के भीतर एक बग रिपोर्ट पर PeerTube एक पर उदाहरण या एक स्लाइड डेक MediaGoblin एक पर उदाहरण के लिए एक टिकट के साथ GitLab उदाहरण …

मेरे 2 सीटी;)

@Arkanosis क्या लिखा करने के दौरान सुर: कि क्या की तरह लगता है GitPub उद्देश्य पर। हो सकता है कि कुछ गीता देव वहां झंकार दें? यही वर्तमान में मांगा गया है:

इस तरह के एक विनिर्देश पर कम से कम कुछ Git वेब सेवा कार्यान्वयन द्वारा सहमति होनी चाहिए। यदि आप ऐसे सॉफ़्टवेयर के डेवलपर हैं, तो कृपया हमारी चर्चा में शामिल हों और बोलें। हम आपको केवल कार्य समूह में जोड़ देंगे।

मुझे यकीन नहीं है कि @Arkanosis टिप्पणी डायस्पोरा पर भी लागू होगी लेकिन अगर ऐसा होता तो यह निश्चित रूप से मेरे लिए उपयोगी होगा! इस सुविधा के लिए तत्पर हैं! :)

मुझे यकीन नहीं है कि @Arkanosis टिप्पणी प्रवासी पर भी लागू होगी

@ किंगडकजेड : काश! पिछली बार जब मैंने जाँच की थी, हालाँकि डायस्पोरा एक्टिविटीपब को लागू नहीं कर रहा था। मैं वास्तव में इसे अन्य नेटवर्क (विशेष रूप से मास्टोडन के साथ) के साथ संघ बनाने के लिए ऐसा करना चाहता हूं। यह, एक अतिरिक्त लाभ के रूप में, प्रवासी भारतीयों और इस प्रस्ताव से जो कुछ भी निकलता है (GitPub या कुछ और) को संघटित करना बहुत आसान बना देगा।

निश्चित रूप से, डायस्पोरा फ़ेडरेशन प्रोटोकॉल (वेबफ़िंगर + माइक्रोफ़ॉर्मेट + अन्य) का उपयोग करके डायस्पोरा के साथ सीधे फ़ेडरेट करना संभव होगा, लेकिन इस प्रोटोकॉल को एक्टिविटीस्ट्रीम / एक्टिविटीपब के रूप में उतना कर्षण नहीं मिलता है।

कृपया विषय पर बने रहें। यह समस्या केवल दूरस्थ रेपो से पुल अनुरोध खोलने में सक्षम होने से संबंधित है। इसे प्राप्त करने के लिए केवल "रेपो और शाखा" का एक सामान्य सूत्रीकरण आवश्यक है।

एक उदाहरण https://github.com/go-gitea/gitea.git#federated-prs ।

अन्य डेटा जैसे मुद्दों और टिप्पणियों का संघ इसके दायरे से बाहर है। मुझे लगता है कि पहले कदम के रूप में, आपको गिट रेपो पर खाता बनाये बिना पीआर बनाने में सक्षम होना चाहिए।

@stevenroose अगर आप मुझे संदर्भित करते हैं: क्षमा करें, मुझे इसे बेहतर तरीके से # 1612 में रखना चाहिए था। इस बीच किसी और ने वहां इसका जिक्र किया।

एक्टिविटीपब आधारित गिट फेडरेशन प्रोटोकॉल को डिजाइन करने के लिए अब एक कार्य समूह/परियोजना मौजूद है। https://github.com/git-federation/gitpub

यदि आप रुचि रखते हैं तो उनकी मेलिंग सूची में शामिल हों।

GitLab इसे लागू कर रहा है!
https://gitlab.com/gitlab-org/gitlab-ce/issues/40830
https://gitlab.com/groups/gitlab-org/-/epics/260

निआइस!

फेडरेटेड गिट कमाल का होगा। गिट रेपो के लिए अनगिनत खातों को पंजीकृत करना पसंद नहीं है ...
संघीय जनसंपर्क और मुद्दे! मैं

@pwFoo मुझे लगता है कि इसे निर्दिष्ट करने और लागू करने में कुछ समय लगेगा।

गिट रेपो के लिए अनगिनत खातों को पंजीकृत करना पसंद नहीं है ...

क्या यह आपके लिए "गिटहब के साथ लॉगिन" करने का विकल्प होगा, जब तक कि यह तब तक सिर्फ एक क्लिक न हो?

वर्कअराउंड हो सकता है, लेकिन लक्ष्य को भविष्य में फ़ेडरेटेड इश्यू/पीआर, फ़ेडरेटेड सोशल नेटवर्क्स (मास्टोडन, प्लेरोमा, मिसकी, ...) होना चाहिए।

वर्कअराउंड हो सकता है, लेकिन लक्ष्य को भविष्य में फ़ेडरेटेड इश्यू/पीआर, फ़ेडरेटेड सोशल नेटवर्क्स (मास्टोडन, प्लेरोमा, मिसकी, ...) होना चाहिए।

इसका उपयोग मामला क्या है? एक्टिविटीपब प्लेटफॉर्म और गिटफेड या यहां जो भी समाधान बनाया गया है, उसके बीच जबरदस्ती जानकारी साझा करने के लिए गीता को निचोड़ने से ओवरइंजीनियरिंग हो जाएगी।

@jalcine उपयोग का मामला यह है कि यदि आप कई अलग-अलग सॉफ़्टवेयर प्रोजेक्ट्स पर काम करते हैं, तो आपको उन सभी प्लेटफ़ॉर्म पर खाता बनाने और बनाए रखने की आवश्यकता नहीं है, जिन पर ये प्रोजेक्ट होस्ट किए गए हैं (GitHub, GitLab या उनके स्वयं के द्वारा होस्ट किए गए Gitea/GitLab/ जो भी हो)। आदर्श रूप से आपके पास अपना स्वयं का रेपो (GitHub, GitLab, या आपका अपना कस्टम Gitea) है और आप अपने स्वयं के रेपो से उन सभी परियोजनाओं के लिए PR बना सकते हैं जिन पर आप काम करते हैं।

ठीक है, लेकिन मैं जिस व्यक्ति को उत्तर दे रहा था, वह कह रहा था कि आप मास्टोडन का उपयोग करके गीता में साइन इन करेंगे?

मेरे मामले में, मेरे पास होम सर्वर पर एक गीता उदाहरण है। मेरे रास्पबेरी पाई और मेरे इंटरनेट कनेक्शन में सीमित संसाधन हैं। और मैं यह रोकना चाहता हूं कि बॉट्स खाते बना सकें ताकि मेरे खाली समय में मेरे पास कम प्रशासन हो।

उसके कारण, मैंने पंजीकरण पृष्ठ को अक्षम कर दिया। इस प्रकार, कोई भी मेरे सार्वजनिक भंडार में मुद्दों को जोड़ने में सक्षम नहीं है।

वर्तमान में, लोगों से समस्याएँ प्राप्त करने का एकमात्र तरीका Github पर मिरर रिपॉजिटरी का उपयोग करना है। लेकिन फिर, मैं अपना गीता उदाहरण बंद कर सकता हूं।

गितूब की तुलना में गीता बेहतर होने का एकमात्र तरीका यह है कि यह फ़ेडरेटेड मुद्दों और पुल अनुरोधों (विकेंद्रीकरण का सिद्धांत) का समर्थन करता है।

मास्टोडन जैसे सामाजिक नेटवर्क एक और विषय है और अच्छा है।

लेकिन फ़ेडरेटेड मुद्दे और पुल अनुरोध अनिवार्य हैं ताकि लोगों को नेक्स्टक्लाउड/ओनक्लाउड जैसे प्रत्येक उदाहरण पर खाता निर्माण के बारे में चिंता करने की आवश्यकता न हो।

@jalcine
"फेडरेटेड गिट कमाल का होगा। गिट रेपो के लिए बेशुमार खातों को पंजीकृत करना पसंद नहीं है ...
संघीय जनसंपर्क और मुद्दे! "

लक्ष्य GitHub या Mastodon खाते से लॉगिन करना नहीं है... मैंने अपना उत्तर उद्धृत किया है।
लक्ष्य एक खाते का उपयोग करना है (आदर्श रूप से मेरा अपना) मुद्दों को खोलने, पीआर का जवाब देने या खोलने के लिए।

मैंने इस मुद्दे को लॉक कर दिया है क्योंकि वर्तमान में जाली मेलिंग सूची में इस पर चर्चा की जा रही है, कृपया वहां सभी वार्तालापों को पुनर्निर्देशित करें।

अधिक जानकारी: https://github.com/forgefed/forgefed