Git के लिए साइन ऑफ़ सुविधा क्या है?


जवाबों:


535

लिनक्स कर्नेल और कुछ अन्य परियोजनाओं में पैच प्राप्त करने के लिए साइन-ऑफ एक आवश्यकता है, लेकिन अधिकांश परियोजनाएं वास्तव में इसका उपयोग नहीं करती हैं।

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


91
यह ध्यान दिया जाना चाहिए कि वर्णित अर्थ Signed-off-by:लिनक्स कर्नेल परियोजना (और गिट परियोजना खुद) द्वारा प्रतिबद्ध संदेश लाइनों को सौंपा गया है । अन्य परियोजनाओं के लिए, हालांकि, ऐसी पंक्तियाँ तब तक निरर्थक हैं जब तक कि परियोजना उनके लिए अर्थ प्रदान नहीं करती है (जैसे कि परियोजना के प्रलेखन में उनका वर्णन करके; जैसे लिनक्स के SubmitPPatches या Git's SubmittingPatches )।
क्रिस जॉन्सन

39
तो यह प्रतिबद्ध संदेश में करने की आवश्यकता क्यों थी? मुझे लगा कि कमिट्स के पास एक लेखक था, और वे SHA1 हैश का हिस्सा थे?
लीफ एंडरसन

34
@ लाइफ़ मेरे लेखक की जानकारी पर्याप्त नहीं है। मैंने एक पैच लिखा हो सकता है, लेकिन अगर मैं इसे यूनिक्स के कुछ कोड पर आधारित करता हूं, तो मुझे इसे GPL (कम से कम बिना किसी साइन अप के उच्चतर) से जारी करने की अनुमति नहीं होगी। या, कर्नेल के पेड़ में हवा लगाने से पहले एक पैच इसे कई अलग-अलग रखवालों के बीच बना सकता है; साइनऑफ़ हिरासत की श्रृंखला को इंगित करता है। मूल प्रमाण पत्र पढ़ें जिसे मैंने लिंक किया था; जब आप साइनऑफ़ लाइन जोड़ते हैं तो इसका अर्थ है। "लेखक" शीर्ष लेख गलत हो सकता है, और जरूरी नहीं कि मूल के प्रमाण पत्र में सब कुछ के साथ समझौता करें।
ब्रायन कैंपबेल

68
PGP कुंजी के बिना, यह कैसे स्थापित किया जा सकता है कि साइन-ऑफ वास्तविक है?
HRJ

7
@ एचआरजे एक हस्ताक्षरित बंद की असलियत वास्तव में आप पर है (कमिटेटर)। न लेखक पर, न खुद पर हस्ताक्षर किए जाने पर। यदि बाद में किसी ने (मुख्य रूप से हस्ताक्षरित बंद) विवाद को मान्य नहीं किया है, तो आपके पास एक ईमेल या ऐसा कुछ है जो साबित करता है कि वह इसके लिए सहमत है। कमेटी कह सकती है कि उसने इस तरह की बूँद नहीं मारी। अगर बूँद GPG पर हस्ताक्षरित नहीं है (IMHO एक कमजोर रक्षा, लेकिन ...)। इस स्थिति में, कम्यूटर सर्कल को बंद करने के लिए -S का उपयोग कर सकता है। अब -S और -s के साथ आपके पास कमिटर शब्द के आधार पर हिरासत की एक श्रृंखला है, कि कुछ लेखक द्वारा लिखे गए कोड को कुछ हस्ताक्षरित उच्चतर द्वारा उपयोग करने के लिए अधिकृत है।
डॉ। बीको

70

साइन-ऑफ कमिट मैसेज के अंत में एक लाइन है जो प्रमाणित करती है कि कमेटी का लेखक कौन है। इसका मुख्य उद्देश्य यह है कि किसने, विशेष रूप से पैच के साथ किसने ट्रैकिंग की है।

उदाहरण प्रतिबद्ध:

Add tests for the payment processor.

Signed-off-by: Humpty Dumpty <humpty.dumpty@example.com>

यदि ओपन-सोर्स प्रोजेक्ट के लिए उपयोग किया जाता है तो इसमें उपयोगकर्ता वास्तविक नाम होना चाहिए।

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

Add tests for the payment processor.

Signed-off-by: Humpty Dumpty <humpty.dumpty@example.com>

[Project Maintainer: Renamed test methods according to naming convention.]
Signed-off-by: Project Maintainer <project.maintainer@example.com>

स्रोत: http://gerrit.googlecode.com/svn/documentation/2.0/user-signedoffby.html


38
क्या यह authorएक कमिट के क्षेत्र से बेमानी नहीं है ? मैंने हमेशा सोचा था कि एक अलग authorऔर committerक्षेत्र क्यों था । पैच लेखक और कमेंट करने वाला वह व्यक्ति है जिसने पैच लगाया और धक्का दिया।
लीफ ग्रुएनवोल्ड्ट

10
क्या यह वास्तव में प्रमाणित करता है कि एक प्रतिबद्ध लेखक कौन है? मेरा मतलब है, जितना -S (--gpg-sign) करता है, क्योंकि मुझे ऐसा नहीं लगता। मुझे लगता है कि कोई भी किसी भी नाम और ई-मेल के साथ "साइन-ऑफ-बाय" लाइन जोड़ सकता है, जबकि एक जीपीजी हस्ताक्षर अधिक विश्वसनीय है, लेकिन शायद मैं गलत हूं।
एचडीएल

1
“साइन-ऑफ कमिट मैसेज के अंत में एक लाइन है जो प्रमाणित करता है कि कमिट का लेखक कौन है। इसका मुख्य उद्देश्य विशेष रूप से पैच के साथ किसने क्या किया, इसकी ट्रैकिंग में सुधार करना है। ” - यह लगभग निश्चित रूप से गलत है (विशेष रूप से पहला वाक्य)। एक काउंटर-उदाहरण के रूप में, उदाहरण के लिए देखें b2c150d3aa (VONC के उत्तर से जुड़ा हुआ) , जिसमें दो हस्ताक्षरित-बंद हेडर हैं; लेखक द्वारा एक , और अनुचर द्वारा एक। Git और Linux प्रोजेक्ट्स में यह आम बात है।
गिल्डनस्टर्न

(पिछली टिप्पणी से जारी है।) साइन-ऑफ करने का मतलब है कि आपने कुछ शर्तों के तहत प्रतिबद्ध किया है, या यह कि आप किसी ऐसी चीज से गुजर रहे हैं , जिसे किसी ने लिखा है (जिसके लिए) ने उक्त शर्त को पूरा किया है। तो यह चेन-ऑफ-सर्टिफिकेशन जैसा कुछ बनाता है।
गिल्डनस्टर्न

उपरोक्त पर अपडेट करें: यह पता चला है कि मैंने अपने अंतिम उत्तर में कुछ याद किया, और इसलिए मैंने इस उत्तर को कम करके आंका। लेखक "कोड को समायोजित करने" के बारे में आंशिक रूप से सही है, लेकिन "साइन-ऑफ" ट्रेलर पर गलत जोर देता है। प्रलेखन कहता है कि आपको एक ब्रैकेटेड ट्रेलर जोड़ना चाहिए (उदाहरण में उदाहरण के रूप में) जो उस बारे में सूचित करता है। तो उस के साथ संयोजन में साइन-ऑफ का उपयोग इंटीग्रेटर / अनुचर जैसे लोगों द्वारा छोटे परिवर्तन जोड़ने के लिए किया जा सकता है। लेकिन साइन-ऑफ अभी भी मुख्य रूप से वही करता है जो मैंने वर्णित किया है।
गिल्डनस्टर्न

30

git 2.7.1 (फरवरी 2016) स्पष्ट करता है कि डेविड ए व्हीलर ( ) द्वारा प्रतिबद्ध b2c150d (05 जनवरी 2016 ) में( जूनियो सी हमानो द्वारा विलय - - में 7aae9ba , 05 फरवरी 2016)david-a-wheeler
gitster

git commitमैन पेज में अब शामिल हैं:

-s::
--signoff::

Signed-off-byकमिट द्वारा लॉग इन संदेश के अंत में लाइन जोड़ें ।
एक साइनऑफ़ का अर्थ परियोजना पर निर्भर करता है, लेकिन यह आमतौर पर प्रमाणित करता है कि कमिटर के पास एक ही लाइसेंस के तहत इस काम को प्रस्तुत करने का अधिकार है और डेवलपर प्रमाणपत्र ऑफ ओरिजिनल ( अधिक जानकारी के लिए https://developercertificate.org देखें) से सहमत है


वर्णन करते हुए प्रलेखन का विस्तार करें --signoff

विभिन्न दस्तावेजों (मैन पेज) फ़ाइलों को संशोधित करें और अधिक विस्तार से बताएं कि --signoffइसका क्या मतलब है।

यह " lwn लेख 'बॉटमली: डीसीओ पर एक मामूली प्रस्ताव " (डेवलपर सर्टिफिकेट ऑफ़ ओरिजिनल) से प्रेरित था, जहाँ पाउज ने नोट किया:

मुद्दा मैं DCO साथ है वहाँ वह यह है कि एक "जोड़ने -s" तर्क Git प्रतिबद्ध करने के लिए वास्तव में मतलब यह नहीं है कि आप भी DCO बारे में सुना है ( आदमी पेज DCO कहीं का कोई जिक्र नहीं है ), कोई बात नहीं वास्तव में इसे देखा।git commit

तो signed-off-byकिसी भी तरह से " " की उपस्थिति कैसे प्रेषित कर सकती है और DCO को सहमति दे रही है? तथ्य के साथ संयुक्त मैंने SOB के बिना पैच के सूचियों पर उत्तरों को देखा है जो कहते हैं कि "इसे फिर से शुरू signed-off-byकरें मैं इसे प्रतिबद्ध कर सकता हूं " के अलावा और कुछ नहीं ।

गिट के प्रलेखन का विस्तार करने से यह तर्क देना आसान हो जाएगा कि डेवलपर्स समझ गए थे --signoffकि वे इसका उपयोग कब करते हैं।


ध्यान दें कि यह साइनऑफ़ अब (Git 2.15.x / 2.16, Q1 2018 के लिए) भी उपलब्ध है git pull

डब्ल्यू। ट्रेवर किंग ( ) द्वारा प्रतिबद्ध 3a4d2c7 (12 अक्टूबर 2017) देखें । (द्वारा विलय Junio सी Hamano - - में प्रतिबद्ध fb4cd88 , 06 नवंबर 2017)wking
gitster

pull: --signoff/--no-signoff" पास git merge"

मर्ज हो सकता है --signoff, लेकिन --signoffनीचे से गुजरने के बिना , इसका उपयोग करना असुविधाजनक है; pullविकल्प लेने के लिए और इसके माध्यम से पारित करने के लिए ' ' की अनुमति दें ।


2
यहाँ तक कि git कमिटमेंट डॉक्यूमेंट के साथ (पिछले) दस्तावेज़ को संदर्भित करने के लिए -s झंडा ज्ञान और समझौते / सहमति को इंगित करने के लिए है? ??? , मेरा मानना ​​है कि एसओबी कानूनी रूप से बहुत कमजोर है। एसओबी था, मुझे लगता है कि कम से कम, लिनुस द्वारा एक सामाजिक समस्या को हल करने के लिए आविष्कार किया गया था जो अन्य लोग उच्च-उपरि नौकरशाही के लिए वकालत कर रहे थे। लिनुस कुछ भी नहीं चाहता था, लेकिन उन्हें बंद करने के लिए आया था। जहां तक ​​मैं बता सकता हूं, वकील आपको ज्यादा निवेश करने की सलाह नहीं देंगे, यदि कोई हो, तो उस पर विश्वास करें। (मैं LWN पर 'पॉलज' हूं)।
पल्ज

3
VonC, आप एक वास्तविक Git क्यूरेटर हैं। आपके पास इस तरह के प्रश्नों पर हमेशा अच्छी तरह से संरचित, सूचनात्मक और अच्छी तरह से क्रॉस-रेफ़र किए गए उत्तर होते हैं - जो Git डेवलपमेंट के इतिहास को अंतिम रूप से यूज़र-फेसिंग टूल और डॉक्यूमेंटेशन में ट्रेस करता है। तो इसके लिए आपका शुक्रिया।
गिल्डनस्टर्न 10

3
@Guildenstern इस अच्छी टिप्पणी के लिए धन्यवाद।
VonC

17

इस सवाल पर कुछ अच्छे जवाब हैं। मैं एक और अधिक व्यापक उत्तर जोड़ने की कोशिश करूँगा, इस प्रकार की पंक्तियों / हेडर / ट्रेलरों के बारे में वर्तमान अभ्यास में क्या है। विशेष रूप से साइन-ऑफ हेडर के बारे में इतना नहीं है (यह केवल एक ही नहीं है)।

"साइन-ऑफ" (is 2) की तरह हेडर या ट्रेलर () 1), Git और Linux जैसी परियोजनाओं में वर्तमान अभ्यास के लिए, प्रभावी रूप से प्रतिबद्ध के लिए मेटाडेटा संरचित है। संदेश के मुख्य भाग के "मुक्त रूप" (असंरचित) भाग के बाद, ये सभी प्रतिबद्ध संदेश के अंत में जोड़ दिए जाते हैं। ये टोकन-मूल्य (या की-वैल्यू ) जोड़े हैं जो आमतौर पर एक बृहदान्त्र और एक स्थान द्वारा सीमांकित होते हैं ( :␣)।

जैसा कि मैंने उल्लेख किया है, "साइन-ऑफ" वर्तमान अभ्यास में एकमात्र ट्रेलर नहीं है। उदाहरण के लिए देखें यह प्रतिबद्ध , जिसे "डर्टी काउ" के साथ करना है:

 mm: remove gup_flags FOLL_WRITE games from __get_user_pages()
 This is an ancient bug that was actually attempted to be fixed once
 (badly) by me eleven years ago in commit 4ceb5db9757a ("Fix
 get_user_pages() race for write access") but that was then undone due to
 problems on s390 by commit f33ea7f404e5 ("fix get_user_pages bug").

 In the meantime, the s390 situation has long been fixed, and we can now
 fix it by checking the pte_dirty() bit properly (and do it better).  The
 s390 dirty bit was implemented in abf09bed3cce ("s390/mm: implement
 software dirty bits") which made it into v3.9.  Earlier kernels will
 have to look at the page state itself.

 Also, the VM has become more scalable, and what used a purely
 theoretical race back then has become easier to trigger.

 To fix it, we introduce a new internal FOLL_COW flag to mark the "yes,
 we already did a COW" rather than play racy games with FOLL_WRITE that
 is very fundamental, and then use the pte dirty flag to validate that
 the FOLL_COW flag is still valid.

 Reported-and-tested-by: Phil "not Paul" Oester <kernel@linuxace.com>
 Acked-by: Hugh Dickins <hughd@google.com>
 Reviewed-by: Michal Hocko <mhocko@suse.com>
 Cc: Andy Lutomirski <luto@kernel.org>
 Cc: Kees Cook <keescook@chromium.org>
 Cc: Oleg Nesterov <oleg@redhat.com>
 Cc: Willy Tarreau <w@1wt.eu>
 Cc: Nick Piggin <npiggin@gmail.com>
 Cc: Greg Thelen <gthelen@google.com>
 Cc: stable@vger.kernel.org
 Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

उपरोक्त में "साइन-ऑफ" ट्रेलर के अलावा, है:

  • "सीसी" (पैच के बारे में सूचित किया गया था)
  • "Acked-by" (कोड के स्वामी द्वारा स्वीकार किया गया, "मुझे अच्छा लग रहा है")
  • "समीक्षित द्वारा" (समीक्षा)
  • "रिपोर्ट किया गया और परीक्षण किया गया" (रिपोर्ट और परीक्षण किया गया है (मुझे लगता है))

उदाहरण के लिए, गेरिट जैसी अन्य परियोजनाओं के अपने हेडर और उनके लिए संबद्ध अर्थ हैं।

देखें: https://git.wiki.kernel.org/index.php/CommitMessageConventions

कहानी का नैतिक

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

[ man git-interpret-trailers
These 1]: [] 2]: इन्हें कभी-कभी "सोब" (प्रारंभिक) भी कहा जाता है, ऐसा लगता है।


2
दिलचस्प उपयोग मामला। +1
वॉन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.