गिट रिपॉज़िटरी के नियम

यहां दिए गए फ़ंक्शन यहां से लोड किए जा सकते हैं @bazel_tools//tools/build_defs/repo:git.bzl.

बाहरी git डेटा स्टोर करने की जगहों की क्लोनिंग करने के नियम.

git_repository

git_repository(name, branch, build_file, build_file_content, commit, init_submodules, patch_args,
               patch_cmds, patch_cmds_win, patch_tool, patches, recursive_init_submodules, remote,
               repo_mapping, shallow_since, strip_prefix, tag, verbose, workspace_file,
               workspace_file_content)

बाहरी git रिपॉज़िटरी का क्लोन बनाएं.

Git रिपॉज़िटरी को क्लोन करता है, बताए गए टैग को चेक आउट करता है या कमिट करता है, और अपने टारगेट को बाइंडिंग के लिए उपलब्ध कराता है. आईडी का आईडी भी तय करें चेक आउट और इसकी तारीख को कमिट करके, पैरामीटर के साथ लिखवाने की सुविधा का इस्तेमाल करता है जो इस नियम का पुनः बनाने योग्य वर्शन प्रदान करते हैं (जो आवश्यक रूप से टैग नहीं है है).

Baज़ल, सबसे पहले सिर्फ़ तय की गई कमिटी का शैलो फ़ेच करने की कोशिश करेगा. अगर यह काम नहीं करता है (आम तौर पर, सर्वर की सुविधा न होने की वजह से), तो यह वापस डेटा स्टोर करने की जगह को पूरी तरह फ़ेच कर सकता है.

git_repository से http_archive को प्राथमिकता दें. इसकी वजहें ये हैं:

• Git रिपॉज़िटरी के नियम सिस्टम git(1) पर निर्भर करते हैं, जबकि एचटीटीपी डाउनलोडर बनाया गया है और इसकी कोई सिस्टम डिपेंडेंसी नहीं है.
• http_archive urls की सूची को मिरर के रूप में इस्तेमाल करता है, और git_repository सिर्फ़ काम करता है एक remote.
• http_archive, डेटा स्टोर करने की कैश मेमोरी के साथ काम करता है, लेकिन यह काम नहीं करता git_repository. यहां जाएं: #5116 पर जाएं.

विशेषताएं

name	नाम; आवश्यक डेटा स्टोर करने की इस जगह के लिए यूनीक नाम.
branch	String; ज़रूरी नहीं ब्रांच में जाकर उससे चेक आउट किया जा सकता है. ब्रांच, टैग या कमिट में से किसी एक को सटीक रूप से बताया जाना चाहिए.
build_file	लेबल; ज़रूरी नहीं डेटा स्टोर करने की इस फ़ाइल के लिए, बिल्ड फ़ाइल के तौर पर इस्तेमाल की जाने वाली फ़ाइल. यह एट्रिब्यूट एक ऐब्सलूट लेबल है. मुख्य रेपो के लिए, '@//' का इस्तेमाल करें. फ़ाइल का नाम BUILD रखने की ज़रूरत नहीं है. हालांकि, यह हो सकता है (BUILD.new-repo-name जैसा कुछ इस तरह से काम करता है कि इसे रिपॉज़िटरी की असल BUILD फ़ाइलों से अलग किया जा सके.
build_file_content	String; ज़रूरी नहीं इस डेटा स्टोर करने की जगह के लिए BUILD फ़ाइल का कॉन्टेंट.
commit	String; ज़रूरी नहीं करने का वादा किया. ब्रांच, टैग या कमिट में से किसी एक को सटीक रूप से बताया जाना चाहिए.
init_submodules	बूलियन; ज़रूरी नहीं रिपॉज़िटरी में सबमॉड्यूल का क्लोन बनाना है या नहीं.
patch_args	स्ट्रिंग की सूची; ज़रूरी नहीं पैच टूल को दिए गए आर्ग्युमेंट. डिफ़ॉल्ट तौर पर -p0 होता है. हालांकि, git से जनरेट किए गए पैच के लिए, आम तौर पर -p1 की ज़रूरत होती है. अगर एक से ज़्यादा -p आर्ग्युमेंट तय किए गए हैं, तो आखिरी वाला आर्ग्युमेंट लागू होगा.अगर -p के अलावा किसी अन्य आर्ग्युमेंट के बारे में बताया जाता है, तो Basel-नेटिव पैच को लागू करने के बजाय, पैच कमांड लाइन टूल का इस्तेमाल करेगा. पैच कमांड लाइन टूल और पैच_टूल एट्रिब्यूट पर वापस जाने पर, `पैच` का इस्तेमाल किया जाएगा.
patch_cmds	स्ट्रिंग की सूची; ज़रूरी नहीं पैच लागू होने के बाद, Linux/Macos पर Bash कमांड का क्रम.
patch_cmds_win	स्ट्रिंग की सूची; ज़रूरी नहीं पैच लागू होने के बाद, Windows पर पावरशेल कमांड का क्रम. अगर यह एट्रिब्यूट सेट नहीं है, तो Windows पर Patch_cmds का इस्तेमाल किया जाएगा. इसके लिए, Bash बाइनरी का मौजूद होना ज़रूरी है.
patch_tool	String; ज़रूरी नहीं इस्तेमाल की जाने वाली पैच(1) सुविधा. अगर इसका इस्तेमाल किया जा रहा है, तो Basel-नेटिव पैच को लागू करने के बजाय, Basel के बताए गए पैच टूल का इस्तेमाल किया जाएगा.
patches	लेबल की सूची; ज़रूरी नहीं उन फ़ाइलों की सूची जिन्हें संग्रह से निकालने के बाद, पैच के तौर पर लागू किया जाना है. डिफ़ॉल्ट रूप से, यह BaZ-नेटिव पैच लागू करने की सुविधा का इस्तेमाल करता है, जो फ़ज़ मैच और बाइनरी पैच के साथ काम नहीं करता. हालांकि, अगर `patch_tool` एट्रिब्यूट के बारे में बताया गया है या `patch_orgs` एट्रिब्यूट में `-p` के अलावा कोई अन्य आर्ग्युमेंट हैं, तो Baज़र, पैच कमांड लाइन टूल का इस्तेमाल करने लगेगा.
recursive_init_submodules	बूलियन; ज़रूरी नहीं क्या रिपॉज़िटरी में सबमॉड्यूल को बार-बार क्लोन करना है.
remote	String; आवश्यक रिमोट Git रिपॉज़िटरी का यूआरआई
repo_mapping	शब्दकोश: स्ट्रिंग -> String; आवश्यक लोकल रिपॉज़िटरी के नाम से लेकर ग्लोबल रिपॉज़िटरी के नाम तक का डिक्शनरी. इससे, इस रिपॉज़िटरी की डिपेंडेंसी के लिए फ़ाइल फ़ोल्डर डिपेंडेंसी रिज़ॉल्यूशन को कंट्रोल किया जा सकता है. उदाहरण के लिए, एंट्री `"@foo": "@bar"` से पता चलता है कि किसी भी समय यह रिपॉज़िटरी, `@foo` पर निर्भर करती है. जैसे, `@foo//some:target` पर डिपेंडेंसी. इसे असल में ग्लोबल एलान `@bar` (`@bar//some:target`) में डिपेंडेंसी को हल करना चाहिए.
shallow_since	String; ज़रूरी नहीं वैकल्पिक तारीख, तय की गई प्रतिबद्धता के बाद नहीं; तर्क की अनुमति नहीं है अगर कोई टैग या शाखा दर्ज की गई है (जिसकी हमेशा --depth=1 से क्लोन की जा सकती है). तय की गई कमिट के करीब ऐसी तारीख सेट करने से, रिपॉज़िटरी के शैलो क्लोन की अनुमति मिल सकती है. भले ही, सर्वर आर्बिट्रेरी कमिट के शैलो फ़ेच की सुविधा न देता हो. git के --shallow-since को लागू करने में हुई गड़बड़ियों की वजह से, इस एट्रिब्यूट का इस्तेमाल करने का सुझाव नहीं दिया जाता. इसकी वजह से, फ़ेच करने में गड़बड़ी हो सकती है.
strip_prefix	String; ज़रूरी नहीं निकाली गई फ़ाइलों से स्ट्रिप करने के लिए एक डायरेक्ट्री प्रीफ़िक्स.
tag	String; ज़रूरी नहीं टैग को चेक आउट करने के लिए रिमोट रिपॉज़िटरी में ब्रांच, टैग या कमिट में से किसी एक को सटीक रूप से बताया जाना चाहिए.
verbose	बूलियन; ज़रूरी नहीं
workspace_file	लेबल; ज़रूरी नहीं इस डेटा स्टोर करने की जगह के लिए `वर्कस्पेस` फ़ाइल के तौर पर इस्तेमाल की जाने वाली फ़ाइल. `workspace_file` या `workspace_file_content`, दोनों में से किसी को बताया जा सकता है या दोनों में से कोई भी नहीं बताया जा सकता है.
workspace_file_content	String; ज़रूरी नहीं इस डेटा स्टोर करने की जगह के लिए वर्कस्पेस फ़ाइल का कॉन्टेंट. `workspace_file` या `workspace_file_content`, दोनों में से किसी को बताया जा सकता है या दोनों में से कोई भी नहीं बताया जा सकता है.

new_git_repository

new_git_repository(name, branch, build_file, build_file_content, commit, init_submodules,
                   patch_args, patch_cmds, patch_cmds_win, patch_tool, patches,
                   recursive_init_submodules, remote, repo_mapping, shallow_since, strip_prefix, tag,
                   verbose, workspace_file, workspace_file_content)

बाहरी git रिपॉज़िटरी का क्लोन बनाएं.

Git रिपॉज़िटरी को क्लोन करता है, बताए गए टैग को चेक आउट करता है या कमिट करता है, और अपने टारगेट को बाइंडिंग के लिए उपलब्ध कराता है. आईडी का आईडी भी तय करें चेक आउट और इसकी तारीख को कमिट करके, पैरामीटर के साथ लिखवाने की सुविधा का इस्तेमाल करता है जो इस नियम का पुनः बनाने योग्य वर्शन प्रदान करते हैं (जो आवश्यक रूप से टैग नहीं है है).

Baज़ल, सबसे पहले सिर्फ़ तय की गई कमिटी का शैलो फ़ेच करने की कोशिश करेगा. अगर यह काम नहीं करता है (आम तौर पर, सर्वर की सुविधा न होने की वजह से), तो यह वापस डेटा स्टोर करने की जगह को पूरी तरह फ़ेच कर सकता है.

git_repository से http_archive को प्राथमिकता दें. इसकी वजहें ये हैं:

• Git रिपॉज़िटरी के नियम सिस्टम git(1) पर निर्भर करते हैं, जबकि एचटीटीपी डाउनलोडर बनाया गया है और इसकी कोई सिस्टम डिपेंडेंसी नहीं है.
• http_archive urls की सूची को मिरर के रूप में इस्तेमाल करता है, और git_repository सिर्फ़ काम करता है एक remote.
• http_archive, डेटा स्टोर करने की कैश मेमोरी के साथ काम करता है, लेकिन यह काम नहीं करता git_repository. यहां जाएं: #5116 पर जाएं.

विशेषताएं

name	नाम; आवश्यक डेटा स्टोर करने की इस जगह के लिए यूनीक नाम.
branch	String; ज़रूरी नहीं ब्रांच में जाकर उससे चेक आउट किया जा सकता है. ब्रांच, टैग या कमिट में से किसी एक को सटीक रूप से बताया जाना चाहिए.
build_file	लेबल; ज़रूरी नहीं डेटा स्टोर करने की इस फ़ाइल के लिए, बिल्ड फ़ाइल के तौर पर इस्तेमाल की जाने वाली फ़ाइल. यह एट्रिब्यूट एक ऐब्सलूट लेबल है. मुख्य रेपो के लिए, '@//' का इस्तेमाल करें. फ़ाइल का नाम BUILD रखने की ज़रूरत नहीं है. हालांकि, यह हो सकता है (BUILD.new-repo-name जैसा कुछ इस तरह से काम करता है कि इसे रिपॉज़िटरी की असल BUILD फ़ाइलों से अलग किया जा सके.
build_file_content	String; ज़रूरी नहीं इस डेटा स्टोर करने की जगह के लिए BUILD फ़ाइल का कॉन्टेंट.
commit	String; ज़रूरी नहीं करने का वादा किया. ब्रांच, टैग या कमिट में से किसी एक को सटीक रूप से बताया जाना चाहिए.
init_submodules	बूलियन; ज़रूरी नहीं रिपॉज़िटरी में सबमॉड्यूल का क्लोन बनाना है या नहीं.
patch_args	स्ट्रिंग की सूची; ज़रूरी नहीं पैच टूल को दिए गए आर्ग्युमेंट. डिफ़ॉल्ट तौर पर -p0 होता है. हालांकि, git से जनरेट किए गए पैच के लिए, आम तौर पर -p1 की ज़रूरत होती है. अगर एक से ज़्यादा -p आर्ग्युमेंट तय किए गए हैं, तो आखिरी वाला आर्ग्युमेंट लागू होगा.अगर -p के अलावा किसी अन्य आर्ग्युमेंट के बारे में बताया जाता है, तो Basel-नेटिव पैच को लागू करने के बजाय, पैच कमांड लाइन टूल का इस्तेमाल करेगा. पैच कमांड लाइन टूल और पैच_टूल एट्रिब्यूट पर वापस जाने पर, `पैच` का इस्तेमाल किया जाएगा.
patch_cmds	स्ट्रिंग की सूची; ज़रूरी नहीं पैच लागू होने के बाद, Linux/Macos पर Bash कमांड का क्रम.
patch_cmds_win	स्ट्रिंग की सूची; ज़रूरी नहीं पैच लागू होने के बाद, Windows पर पावरशेल कमांड का क्रम. अगर यह एट्रिब्यूट सेट नहीं है, तो Windows पर Patch_cmds का इस्तेमाल किया जाएगा. इसके लिए, Bash बाइनरी का मौजूद होना ज़रूरी है.
patch_tool	String; ज़रूरी नहीं इस्तेमाल की जाने वाली पैच(1) सुविधा. अगर इसका इस्तेमाल किया जा रहा है, तो Basel-नेटिव पैच को लागू करने के बजाय, Basel के बताए गए पैच टूल का इस्तेमाल किया जाएगा.
patches	लेबल की सूची; ज़रूरी नहीं उन फ़ाइलों की सूची जिन्हें संग्रह से निकालने के बाद, पैच के तौर पर लागू किया जाना है. डिफ़ॉल्ट रूप से, यह BaZ-नेटिव पैच लागू करने की सुविधा का इस्तेमाल करता है, जो फ़ज़ मैच और बाइनरी पैच के साथ काम नहीं करता. हालांकि, अगर `patch_tool` एट्रिब्यूट के बारे में बताया गया है या `patch_orgs` एट्रिब्यूट में `-p` के अलावा कोई अन्य आर्ग्युमेंट हैं, तो Baज़र, पैच कमांड लाइन टूल का इस्तेमाल करने लगेगा.
recursive_init_submodules	बूलियन; ज़रूरी नहीं क्या रिपॉज़िटरी में सबमॉड्यूल को बार-बार क्लोन करना है.
remote	String; आवश्यक रिमोट Git रिपॉज़िटरी का यूआरआई
repo_mapping	शब्दकोश: स्ट्रिंग -> String; आवश्यक लोकल रिपॉज़िटरी के नाम से लेकर ग्लोबल रिपॉज़िटरी के नाम तक का डिक्शनरी. इससे, इस रिपॉज़िटरी की डिपेंडेंसी के लिए फ़ाइल फ़ोल्डर डिपेंडेंसी रिज़ॉल्यूशन को कंट्रोल किया जा सकता है. उदाहरण के लिए, एंट्री `"@foo": "@bar"` से पता चलता है कि किसी भी समय यह रिपॉज़िटरी, `@foo` पर निर्भर करती है. जैसे, `@foo//some:target` पर डिपेंडेंसी. इसे असल में ग्लोबल एलान `@bar` (`@bar//some:target`) में डिपेंडेंसी को हल करना चाहिए.
shallow_since	String; ज़रूरी नहीं वैकल्पिक तारीख, तय की गई प्रतिबद्धता के बाद नहीं; तर्क की अनुमति नहीं है अगर कोई टैग या शाखा दर्ज की गई है (जिसकी हमेशा --depth=1 से क्लोन की जा सकती है). तय की गई कमिट के करीब ऐसी तारीख सेट करने से, रिपॉज़िटरी के शैलो क्लोन की अनुमति मिल सकती है. भले ही, सर्वर आर्बिट्रेरी कमिट के शैलो फ़ेच की सुविधा न देता हो. git के --shallow-since को लागू करने में हुई गड़बड़ियों की वजह से, इस एट्रिब्यूट का इस्तेमाल करने का सुझाव नहीं दिया जाता. इसकी वजह से, फ़ेच करने में गड़बड़ी हो सकती है.
strip_prefix	String; ज़रूरी नहीं निकाली गई फ़ाइलों से स्ट्रिप करने के लिए एक डायरेक्ट्री प्रीफ़िक्स.
tag	String; ज़रूरी नहीं टैग को चेक आउट करने के लिए रिमोट रिपॉज़िटरी में ब्रांच, टैग या कमिट में से किसी एक को सटीक रूप से बताया जाना चाहिए.
verbose	बूलियन; ज़रूरी नहीं
workspace_file	लेबल; ज़रूरी नहीं इस डेटा स्टोर करने की जगह के लिए `वर्कस्पेस` फ़ाइल के तौर पर इस्तेमाल की जाने वाली फ़ाइल. `workspace_file` या `workspace_file_content`, दोनों में से किसी को बताया जा सकता है या दोनों में से कोई भी नहीं बताया जा सकता है.
workspace_file_content	String; ज़रूरी नहीं इस डेटा स्टोर करने की जगह के लिए वर्कस्पेस फ़ाइल का कॉन्टेंट. `workspace_file` या `workspace_file_content`, दोनों में से किसी को बताया जा सकता है या दोनों में से कोई भी नहीं बताया जा सकता है.