मैंने एक छोटी शेल स्क्रिप्ट बनाई है जो कुछ रिपोर्ट जेनरेट करने के लिए git blame के आउटपुट का उपयोग करती है। यह मेरी स्थानीय मशीन पर बहुत अच्छा काम करता है। लेकिन तब मैं अपने gitlab ci/cd पाइपलाइन में शेल स्क्रिप्ट को एकीकृत करना चाहता था और किसी कारण से जब मैं gitlab पर git blame चलाता हूं, तो सभी लाइनों को मेरे और नवीनतम प्रतिबद्धता के लिए जिम्मेदार ठहराया जाता है।

इस मुद्दे को डीबग करने के लिए मैंने अपनी पाइपलाइन फ़ाइल में यही रखा है:

run-git-blame:
  stage: mystage
  image: alpine
  before_script:
    - apk add bash git gawk
    - git status
    - git log
  script:
    - git blame HEAD -- somefile.txt

जब मैं स्थानीय रूप से git blame HEAD -- somefile.txt चलाता हूं तो मुझे मिलता है:

4588eb70a0b (DXXXXXXX                     2019-05-07 15:35:22 +0200    1) abc=123
4588eb70a0b (DXXXXXXX                     2019-05-07 15:35:22 +0200    2) def=456
4588eb70a0b (DXXXXXXX                     2019-05-07 15:35:22 +0200    3) ghi=789
4588eb70a0b (DXXXXXXX                     2019-05-07 15:35:22 +0200    4) jkl=abc
4588eb70a0b (DXXXXXXX                     2019-05-07 15:35:22 +0200    5) mno=def
[...]

हालांकि गिटलैब सीआई आउटपुट इस तरह दिखता है:

^5e95b8e5 (Sebastian Gellweiler 2020-09-24 09:32:54 +0200    1) abc=123
^5e95b8e5 (Sebastian Gellweiler 2020-09-24 09:32:54 +0200    2) def=456
^5e95b8e5 (Sebastian Gellweiler 2020-09-24 09:32:54 +0200    3) ghi=789
^5e95b8e5 (Sebastian Gellweiler 2020-09-24 09:32:54 +0200    4) jkl=abc
^5e95b8e5 (Sebastian Gellweiler 2020-09-24 09:32:54 +0200    5) mno=def
[...]

बू मैंने निश्चित रूप से निरीक्षण की जा रही फाइल को नहीं छुआ है।

git status कमांड सर्वर पर निम्न को आउटपुट करता है:

HEAD detached at 5e95b8e5
nothing to commit, working tree clean

और यह ठीक दिखता है, क्योंकि 5e95b8e5 नवीनतम प्रतिबद्धता का हैश है।

गिटलैब पर git log का आउटपुट भी मुझे परेशान करता है क्योंकि यह केवल एक प्रतिबद्धता दिखाता है और कोई इतिहास नहीं:

commit 5e95b8e5efcfd155d4248f4849b848e9f1580a20
Author: Sebastian Gellweiler <sebastian.gellweiler@dm.de>
Date:   Thu Sep 24 09:32:54 2020 +0200

    ...

मेरी स्थानीय मशीन पर इतिहास इस तरह दिखता है:

commit 5e95b8e5efcfd155d4248f4849b848e9f1580a20 (HEAD -> feature/XXX)
Author: Sebastian Gellweiler <sebastian.gellweiler@example.org>
Date:   Thu Sep 24 09:32:54 2020 +0200

    ...

commit bc689804f87d906e1b2435249fc1aaaf32e49b20
Author: Sebastian Gellweiler <sebastian.gellweiler@dm.de>
Date:   Wed Sep 23 18:40:18 2020 +0200

    XXX

commit 9d6fa2336aee0938aef0bd78563b6f12dee5934f (master)
Merge: 90ef282515 3eabec88c2
Author: XXXX <XXX@example.org>
Date:   Thu Sep 17 08:31:20 2020 +0000

    XYZ
    
[...]

जैसा कि आप देख सकते हैं कि शीर्ष प्रतिबद्ध हैश मेरी स्थानीय मशीन और रिमोट पर समान है।

मैं यहाँ फंस गया हूँ। किसी के पास इस विसंगति के लिए स्पष्टीकरण है?

1
Gellweiler 24 सितंबर 2020, 10:47

2 जवाब

सबसे बढ़िया उत्तर

मुझे लगता है कि आपने GitLab को एक उथला क्लोन बनाने के लिए कॉन्फ़िगर किया है जिसकी गहराई 1 है। चूंकि इसमें केवल एक ही कमिट है, रिपॉजिटरी की प्रत्येक फाइल उसी तरह से है जैसे कि (एकल, एक) कमिटमेंट के कारण होती है। भंडार में है, इसलिए वह हैश आईडी पैदा करता है।

विशेष रूप से, यह संकेतन:

^5e95b8e5

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

4
torek 24 सितंबर 2020, 11:11

गिट केवल अपने माता-पिता से जुड़ता है, गिट केवल इतिहास के पीछे जा सकता है। यदि आपके पास 5e95b8e5 से अधिक पुराना चेक आउट है, तो आप इसे git blame और न ही git log में नहीं देखेंगे।

वैकल्पिक रूप से, आपका स्थानीय रेपो पुराना हो चुका है और आपको git pull करने की आवश्यकता है।

1
Schwern 24 सितंबर 2020, 10:59