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

अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है किसी समस्या की शिकायत करें सोर्स देखें रात · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

यहां दिए गए फ़ंक्शन यहां से लोड किए जा सकते हैं @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 पर Pat_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's --हैलो-से-इन लागू करने में गड़बड़ी की वजह से, इस एट्रिब्यूट का इस्तेमाल करने का सुझाव नहीं दिया जाता है, क्योंकि इससे फ़ेच करने में गड़बड़ी हो सकती है.
`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_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 पर Pat_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's --हैलो-से-इन लागू करने में गड़बड़ी की वजह से, इस एट्रिब्यूट का इस्तेमाल करने का सुझाव नहीं दिया जाता है, क्योंकि इससे फ़ेच करने में गड़बड़ी हो सकती है.
`strip_prefix`	String; ज़रूरी नहीं निकाली गई फ़ाइलों से निकालने के लिए एक डायरेक्ट्री प्रीफ़िक्स.
`tag`	String; ज़रूरी नहीं टैग को चेक आउट करने के लिए रिमोट रिपॉज़िटरी में ब्रांच, टैग या कमिट में से किसी एक को सटीक रूप से बताया जाना चाहिए.
`verbose`	बूलियन; ज़रूरी नहीं
`workspace_file`	लेबल; ज़रूरी नहीं इस डेटा स्टोर करने की जगह के लिए `वर्कस्पेस` फ़ाइल के तौर पर इस्तेमाल की जाने वाली फ़ाइल. `workspace_file` या `workspace_file_content`, दोनों में से किसी को बताया जा सकता है या दोनों में से कोई भी नहीं बताया जा सकता है.
`workspace_file_content`	String; ज़रूरी नहीं इस डेटा स्टोर करने की जगह के लिए वर्कस्पेस फ़ाइल का कॉन्टेंट. `workspace_file` या `workspace_file_content`, दोनों में से किसी को बताया जा सकता है या दोनों में से कोई भी नहीं बताया जा सकता है.