गिट-दोष - क्लाउड में ऑनलाइन

कार्यक्रम:

नाम

गिट-दोष - दिखाएँ कि किस संशोधन और लेखक ने फ़ाइल की प्रत्येक पंक्ति को अंतिम बार संशोधित किया है

SYNOPSIS

Git दोष [-सी] [-बी] [-एल] [--रूट] [-टी] [-एफ] [-एन] [-एस] [-ई] [-पी] [-डब्ल्यू] [--इंक्रीमेंटल]
[-एल ] [-एस ] [-एम] [-सी] [-सी] [-सी] [--से= ]
[--abbrev= ] [ | --सामग्री | --उलटना ] [--]

वर्णन

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

जब एक या अधिक बार निर्दिष्ट किया जाता है, तो -L एनोटेशन को अनुरोधित पंक्तियों तक सीमित कर देता है।

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

रिपोर्ट आपको उन पंक्तियों के बारे में कुछ नहीं बताती है जिन्हें हटा दिया गया है या बदल दिया गया है; आप
जैसे उपकरण का उपयोग करने की आवश्यकता है Git diff या "पिकैक्स" इंटरफ़ेस का संक्षेप में उल्लेख किया गया है
निम्नलिखित पैराग्राफ।

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

$ git log --pretty=oneline -S'blame_usage'
5040f17eba15504bad66b14a645bddd9b015ebb7 blame -S <ancestry-file>
ea4c7f9bf69e781dd0cd88d2bccb2bf5cc15c9a7 git-blame: Make the output

विकल्प

-b
बाउंड्री कमिट के लिए खाली SHA-1 दिखाएं। इसे के माध्यम से भी नियंत्रित किया जा सकता है
दोष.रिक्त सीमा विन्यास विकल्प।

--जड़
रूट कमिट्स को सीमाओं के रूप में न मानें। इसे के माध्यम से भी नियंत्रित किया जा सकता है
दोष.शोरूट विन्यास विकल्प।

--शो-आँकड़े
दोष आउटपुट के अंत में अतिरिक्त आँकड़े शामिल करें।

-एल , , -एल :
केवल दी गई लाइन रेंज को एनोटेट करें। कई बार निर्दिष्ट किया जा सकता है। ओवरलैपिंग
श्रेणियों की अनुमति है।

तथा वैकल्पिक हैं। "-L "या" -L , "से फैला है प्रति
फाइल समाप्त। "-एल, "फ़ाइल की शुरुआत से लेकर . तक फैला हुआ है .

तथा इनमें से कोई एक रूप ले सकते हैं:

· संख्या

अगर या एक संख्या है, यह एक निरपेक्ष रेखा संख्या निर्दिष्ट करती है (लाइनें गिनती
1 से)।

· /रेगेक्स/

यह फ़ॉर्म दिए गए POSIX रेगेक्स से मेल खाने वाली पहली पंक्ति का उपयोग करेगा। अगर एक है
रेगेक्स, यह पिछली -L श्रेणी के अंत से खोज करेगा, यदि कोई हो, अन्यथा
फ़ाइल की शुरुआत से। अगर "^/regex/" है, यह की शुरुआत से खोज करेगा
फ़ाइल। अगर एक रेगेक्स है, यह द्वारा दी गई लाइन से शुरू होकर खोज करेगा .

+ ऑफ़सेट या -ऑफ़सेट

यह केवल के लिए मान्य है और पहले या बाद में कई पंक्तियों को निर्दिष्ट करेगा
द्वारा दी गई रेखा .

अगर ": के स्थान पर दिया गया है तथा , यह एक नियमित अभिव्यक्ति है
जो मेल खाने वाली पहली funcname लाइन की सीमा को दर्शाता है , तक
अगली funcname पंक्ति। ": "पिछली -L श्रेणी के अंत से खोज करता है, if
कोई भी, अन्यथा फ़ाइल की शुरुआत से। "^: "फ़ाइल की शुरुआत से खोज करता है।

-l
लंबा रेव दिखाएं (डिफ़ॉल्ट: बंद).

-t
कच्चा टाइमस्टैम्प दिखाएं (डिफ़ॉल्ट: बंद)।

-एस
कॉल करने के बजाय revs-file से संशोधन का उपयोग करें गिट-रेव-सूची(1).

--उलटना
इतिहास को पीछे की बजाय आगे बढ़ाएं। संशोधन दिखाने के बजाय जिसमें a
लाइन दिखाई दी, यह आखिरी संशोधन को दर्शाता है जिसमें एक लाइन मौजूद है। इस आवश्यकता है
START..END जैसे संशोधन की एक श्रृंखला जहां दोष का मार्ग START में मौजूद है।

-पी, - चीनी मिट्टी के बरतन
मशीन की खपत के लिए डिज़ाइन किए गए प्रारूप में दिखाएं।

--लाइन-चीनी मिट्टी के बरतन
चीनी मिट्टी के बरतन प्रारूप दिखाएं, लेकिन आउटपुट प्रत्येक पंक्ति के लिए जानकारी प्रतिबद्ध करता है, न कि केवल
पहली बार एक प्रतिबद्धता का संदर्भ दिया जाता है। तात्पर्य - चीनी मिट्टी के बरतन।

--वृद्धिशील
मशीन की खपत के लिए डिज़ाइन किए गए प्रारूप में परिणाम को क्रमिक रूप से दिखाएं।

--एन्कोडिंग=
लेखक के नामों को आउटपुट करने और सारांश प्रस्तुत करने के लिए उपयोग किए गए एन्कोडिंग को निर्दिष्ट करता है। इसे सेट करना
कोई भी दोष आउटपुट को अपरिवर्तित डेटा नहीं बनाता है। अधिक जानकारी के लिए चर्चा देखें
में एन्कोडिंग के बारे में गिट-लॉग(1) मैनुअल पेज।

--सामग्री
कब निर्दिष्ट नहीं है, कमांड पीछे से शुरू होने वाले परिवर्तनों की व्याख्या करता है
वर्किंग ट्री कॉपी। यह ध्वज कमांड को ऐसा दिखावा करता है जैसे कि वर्किंग ट्री कॉपी
नामित फ़ाइल की सामग्री है (निर्दिष्ट करें - कमांड को पढ़ने के लिए)
मानक इनपुट)।

--दिनांक
तारीखों को आउटपुट करने के लिए प्रयुक्त प्रारूप को निर्दिष्ट करता है। यदि --date प्रदान नहीं किया गया है, तो का मान
दोष.डेट कॉन्फ़िगरेशन चर का उपयोग किया जाता है। यदि दोष.तिथि विन्यास चर भी सेट नहीं है,
आईएसओ प्रारूप का उपयोग किया जाता है। समर्थित मानों के लिए, --date विकल्प की चर्चा देखें
at गिट-लॉग(1).

-एम| |
फ़ाइल में स्थानांतरित या कॉपी की गई पंक्तियों का पता लगाएं। जब कोई प्रतिबद्ध के ब्लॉक को स्थानांतरित या कॉपी करता है
लाइनें (उदाहरण के लिए मूल फ़ाइल में ए और फिर बी है, और प्रतिबद्धता इसे बी में बदल देती है और
तब ए), पारंपरिक दोष एल्गोरिथम केवल आधे आंदोलन को नोटिस करता है और
आम तौर पर उन पंक्तियों को दोष देता है जो माता-पिता को ऊपर ले जाया गया था (यानी बी) और दोष असाइन करता है
उन पंक्तियों के लिए जिन्हें नीचे ले जाया गया था (यानी ए) बच्चे को प्रतिबद्ध करने के लिए। इस विकल्प के साथ, दोनों
निरीक्षण के अतिरिक्त पास चलाकर लाइनों के समूहों को माता-पिता पर दोष दिया जाता है।

वैकल्पिक है लेकिन यह अल्फ़ान्यूमेरिक वर्णों की संख्या पर निचली सीमा है
कि गिट को उन पंक्तियों को जोड़ने के लिए फ़ाइल के भीतर चलने/प्रतिलिपि के रूप में पता लगाना चाहिए
माता-पिता की प्रतिबद्धता के साथ। डिफ़ॉल्ट मान 20 है।

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

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

-h
सहायता संदेश दिखाएं।

-c
के समान आउटपुट मोड का उपयोग करें गिट-एनोटेट(1) (डिफ़ॉल्ट: बंद)।

--स्कोर-डीबग
फाइलों के बीच लाइनों की आवाजाही से संबंधित डिबगिंग जानकारी शामिल करें (देखें-सी)
और रेखाएँ एक फ़ाइल के भीतर चली गईं (देखें -M)। सूचीबद्ध पहला नंबर स्कोर है। यह है
अल्फ़ान्यूमेरिक वर्णों की संख्या के बीच या भीतर ले जाने के रूप में पता चला है
फ़ाइलें। यह के लिए एक निश्चित सीमा से ऊपर होना चाहिए Git दोष की उन पंक्तियों पर विचार करने के लिए
कोड ले जाया गया है।

-एफ, --शो-नाम
मूल प्रतिबद्धता में फ़ाइल नाम दिखाएं। डिफ़ॉल्ट रूप से फ़ाइल नाम दिखाया जाता है यदि वहाँ है
नाम बदलने के कारण किसी भिन्न नाम वाली फ़ाइल से आने वाली कोई भी पंक्ति।

-एन, --शो-नंबर
मूल कमिट में लाइन नंबर दिखाएं (डिफ़ॉल्ट: बंद)।

-s
आउटपुट से लेखक का नाम और टाइमस्टैम्प दबाएं।

-ई, --शो-ईमेल
लेखक के नाम के बजाय लेखक का ईमेल दिखाएं (डिफ़ॉल्ट: बंद)। ये भी हो सकता है
दोष.शोईमेल कॉन्फ़िगरेशन विकल्प के माध्यम से नियंत्रित किया जाता है।

-w
माता-पिता के संस्करण और बच्चे के संस्करण की तुलना करते समय व्हॉट्सएप पर ध्यान न दें ताकि पता लगाया जा सके कि कहाँ है
रेखा से आई है।

--अब्रेव=
संक्षिप्त ऑब्जेक्ट नाम के रूप में डिफ़ॉल्ट 7+1 हेक्साडेसिमल अंकों का उपयोग करने के बजाय,
उपयोग +1 अंक। ध्यान दें कि सीमा प्रतिबद्धता को चिह्नित करने के लिए कैरेट के लिए 1 कॉलम का उपयोग किया जाता है।

THE चीनी मिटटी FORMAT

इस प्रारूप में, प्रत्येक पंक्ति हेडर के बाद आउटपुट होती है; हेडर कम से कम है
पहली पंक्ति जिसमें है:

· 40-बाइट SHA-1 के लिए प्रतिबद्ध लाइन का श्रेय दिया जाता है;

मूल फ़ाइल में पंक्ति की पंक्ति संख्या;

अंतिम फ़ाइल में पंक्ति की पंक्ति संख्या;

एक लाइन पर जो पिछले वाले की तुलना में एक अलग कमिट से लाइनों का एक समूह शुरू करता है,
इस समूह में पंक्तियों की संख्या। बाद की पंक्तियों में यह क्षेत्र अनुपस्थित है।

इस हेडर लाइन के बाद प्रत्येक कमिट के लिए कम से कम एक बार निम्नलिखित जानकारी दी जाती है:

· लेखक का नाम ("लेखक"), ईमेल ("लेखक-मेल"), समय ("लेखक-समय"), और समय क्षेत्र
("लेखक-टीजेड"); इसी तरह कमिटर के लिए।

· प्रतिबद्धता में फ़ाइल नाम जिसके लिए लाइन को जिम्मेदार ठहराया गया है।

प्रतिबद्ध लॉग संदेश की पहली पंक्ति ("सारांश")।

वास्तविक लाइन की सामग्री उपरोक्त शीर्षलेख के बाद आउटपुट होती है, जो एक TAB द्वारा प्रीफ़िक्स की जाती है। इस
बाद में अधिक शीर्षलेख तत्वों को जोड़ने की अनुमति देना है।

चीनी मिट्टी के बरतन प्रारूप आम तौर पर पहले से देखी गई जानकारी को दबा देता है।
उदाहरण के लिए, दो पंक्तियाँ जिन्हें एक ही प्रतिबद्ध के लिए दोषी ठहराया गया है, दोनों को दिखाया जाएगा, लेकिन
उस प्रतिबद्धता का विवरण केवल एक बार दिखाया जाएगा। यह अधिक कुशल है, लेकिन इसकी आवश्यकता हो सकती है
अधिक राज्य पाठक द्वारा रखा जाना चाहिए। --लाइन-चीनी मिट्टी के विकल्प का उपयोग पूर्ण आउटपुट के लिए किया जा सकता है
सरल (लेकिन कम कुशल) उपयोग की अनुमति देते हुए, प्रत्येक पंक्ति के लिए जानकारी दें:

# प्रत्येक लेखक के लिए जिम्मेदार पंक्तियों की संख्या गिनें
गिट दोष --लाइन-चीनी मिट्टी के बरतन फ़ाइल |
sed -n 's/^author//p' |
सॉर्ट | यूनिक-सी | सॉर्ट-आरएन

निर्दिष्ट करना पर्वतमाला

विपरीत Git दोष और Git व्याख्या गिट के पुराने संस्करणों में, एनोटेशन की सीमा
लाइन रेंज और रिवीजन रेंज दोनों तक सीमित किया जा सकता है। -L विकल्प, जो सीमित करता है
कई पंक्तियों के लिए एनोटेशन, कई बार निर्दिष्ट किया जा सकता है।

जब आप फ़ाइल फू के लिए लाइन 40-60 के लिए मूल खोजने में रुचि रखते हैं, तो आप इसका उपयोग कर सकते हैं
इस तरह -L विकल्प (उनका मतलब एक ही है - दोनों लाइन से शुरू होने वाली 21 पंक्तियों के लिए कहते हैं
40):

गिट दोष -एल 40,60 फू
गिट दोष -एल 40,+21 फू

इसके अलावा आप लाइन रेंज निर्दिष्ट करने के लिए नियमित अभिव्यक्ति का उपयोग कर सकते हैं:

गिट दोष -एल '/^ उप हैलो {/,/^}$/' फू

जो हैलो सबरूटीन के मुख्य भाग में एनोटेशन को सीमित करता है।

जब आप संस्करण v2.6.18 से पुराने परिवर्तनों में रुचि नहीं रखते हैं, या 3 . से पुराने परिवर्तनों में रुचि नहीं रखते हैं
सप्ताह, आप के समान संशोधन श्रेणी विनिर्देशकों का उपयोग कर सकते हैं Git संशोधित सूची:

गिट दोष v2.6.18.. -- foo
गिट दोष - चूंकि = 3. सप्ताह - फू

जब एनोटेशन को सीमित करने के लिए रिवीजन रेंज स्पेसिफायर का उपयोग किया जाता है, तो जिन पंक्तियों में नहीं होता है
सीमा सीमा के बाद से बदल गया है (या तो प्रतिबद्ध v2.6.18 या सबसे हाल ही में प्रतिबद्ध है कि
उपरोक्त उदाहरण में 3 सप्ताह से अधिक पुराना है) को उस सीमा सीमा प्रतिबद्धता के लिए दोषी ठहराया जाता है।

एक विशेष रूप से उपयोगी तरीका यह देखना है कि क्या किसी अतिरिक्त फ़ाइल में कॉपी-एंड-पेस्ट द्वारा बनाई गई लाइनें हैं
मौजूदा फाइलों से। कभी-कभी यह इंगित करता है कि डेवलपर लापरवाह था और उसने किया
कोड को ठीक से रिफलेक्टर न करें। आप सबसे पहले उस कमिट को ढूंढ सकते हैं जिसने फाइल पेश की थी
संग:

git log --diff-filter=A --pretty=short --foo

और फिर प्रतिबद्ध ^! का उपयोग करके प्रतिबद्ध और उसके माता-पिता के बीच परिवर्तन को एनोटेट करें! संकेतन:

गिट दोष-सी-सी-एफ $ प्रतिबद्ध ^! -- फू

INCREMENTAL आउटपुट

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

आउटपुट स्वरूप चीनी मिट्टी के बरतन प्रारूप के समान है, लेकिन इसमें वास्तविक शामिल नहीं है
उस फ़ाइल से लाइनें जो एनोटेट की जा रही हैं।

1. प्रत्येक दोष प्रविष्टि हमेशा की एक पंक्ति से शुरू होती है:

<40-बाइट हेक्स sha1>

लाइन नंबर 1 से गिने जाते हैं।

2. पहली बार जब कोई प्रतिबद्ध स्ट्रीम में दिखाई देता है, तो उसमें कई अन्य जानकारी होती है
इसके बारे में वर्णन करने वाली प्रत्येक पंक्ति की शुरुआत में एक-शब्द टैग के साथ मुद्रित किया गया
अतिरिक्त प्रतिबद्ध जानकारी (लेखक, ईमेल, कमिटर, तिथियां, सारांश, आदि)।

3. चीनी मिट्टी के बरतन प्रारूप के विपरीत, फ़ाइल नाम की जानकारी हमेशा दी जाती है और समाप्त हो जाती है
प्रवेश:

"फ़ाइल का नाम"

और इस प्रकार कुछ लाइन- और शब्द-उन्मुख पार्सर के लिए पार्स करना वास्तव में काफी आसान है
(जो अधिकांश स्क्रिप्टिंग भाषाओं के लिए काफी स्वाभाविक होना चाहिए)।

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

मानचित्रण लेखक

यदि फ़ाइल .mailmap रिपॉजिटरी के शीर्ष स्तर पर या इंगित स्थान पर मौजूद है
करने के लिए mailmap.file या mailmap.blob कॉन्फ़िगरेशन विकल्पों द्वारा, इसका उपयोग लेखक को मैप करने के लिए किया जाता है और
विहित वास्तविक नामों और ईमेल पतों के लिए कमिटर के नाम और ईमेल पते।

सरल रूप में, फ़ाइल की प्रत्येक पंक्ति में an . का विहित वास्तविक नाम होता है
लेखक, व्हॉट्सएप, और कमिट में प्रयुक्त एक ईमेल पता (द्वारा संलग्न) < और >) नक्शा
नाम को। उदाहरण के लिए:

सही नाम[ईमेल संरक्षित]>

अधिक जटिल रूप हैं:

<[ईमेल संरक्षित]>[ईमेल संरक्षित]>

जो मेलमैप को एक कमिट के केवल ईमेल भाग को बदलने की अनुमति देता है, और:

सही नाम[ईमेल संरक्षित]>[ईमेल संरक्षित]>

जो मेलमैप को मेलमैप से मेल खाने वाले कमिट के नाम और ईमेल दोनों को बदलने की अनुमति देता है
निर्दिष्ट प्रतिबद्ध ईमेल पता, और:

सही नाम[ईमेल संरक्षित]> प्रतिबद्ध नाम[ईमेल संरक्षित]>

जो मेलमैप को दोनों से मेल खाने वाले कमिट के नाम और ईमेल दोनों को बदलने की अनुमति देता है
निर्दिष्ट प्रतिबद्ध नाम और ईमेल पता।

उदाहरण 1: आपके इतिहास में दो लेखकों, जेन और जो, के कमिट हैं, जिनके नाम दिखाई देते हैं
कई रूपों के तहत भंडार में:

जो डेवलपर[ईमेल संरक्षित]>
जो आर डेवलपर[ईमेल संरक्षित]>
जेन डोए[ईमेल संरक्षित]>
जेन डोए
जेन डी.

अब मान लीजिए कि जो चाहता है कि उसका मध्य नाम पहले इस्तेमाल किया जाए, और जेन उसके परिवार के नाम को पसंद करती है
पूरी तरह से लिखा हुआ। एक उचित .mailmap फ़ाइल इस तरह दिखेगी:

जेन डोए
जो आर डेवलपर[ईमेल संरक्षित]>

ध्यान दें कि कैसे के लिए किसी प्रविष्टि की आवश्यकता नहीं है , क्योंकि . का असली नाम
वह लेखक पहले से ही सही है।

उदाहरण 2: आपके भंडार में निम्नलिखित लेखकों के कमिट हैं:

निक1[ईमेल संरक्षित]>
निक2[ईमेल संरक्षित]>
निक2[ईमेल संरक्षित]>
सांता[ईमेल संरक्षित]>
क्लॉज[ईमेल संरक्षित]>
सीटीओ[ईमेल संरक्षित]>

तब आप एक .mailmap फ़ाइल चाहते हैं जो इस तरह दिखती है:

<[ईमेल संरक्षित]>[ईमेल संरक्षित]>
कुछ यार[ईमेल संरक्षित]> निक1[ईमेल संरक्षित]>
अन्य लेखक[ईमेल संरक्षित]> निक2[ईमेल संरक्षित]>
अन्य लेखक[ईमेल संरक्षित]>[ईमेल संरक्षित]>
सांता क्लॉज़[ईमेल संरक्षित]>[ईमेल संरक्षित]>

हैश का प्रयोग करें # उन टिप्पणियों के लिए जो या तो उनकी अपनी लाइन पर हैं, या ईमेल पते के बाद हैं।

onworks.net सेवाओं का उपयोग करके ऑनलाइन git-blame का उपयोग करें