मूल पर नवीनतम कमिट के लिए Git सबमॉड्यूल अपडेट करें


853

मेरे पास गिट सबमॉड्यूल वाला एक प्रोजेक्ट है। यह एक ssh से है: // ... URL, और प्रतिबद्ध है। A. प्रतिबद्ध B को उस URL पर धकेल दिया गया है, और मैं चाहता हूं कि सबमॉडल कमिट को पुनः प्राप्त करे, और इसे बदल दे।

अब, मेरी समझ यह है कि git submodule updateऐसा करना चाहिए, लेकिन ऐसा नहीं है। यह कुछ भी नहीं करता है (कोई आउटपुट, सफलता निकास कोड)। यहाँ एक उदाहरण है:

$ mkdir foo
$ cd foo
$ git init .
Initialized empty Git repository in /.../foo/.git/
$ git submodule add ssh://user@host/git/mod mod
Cloning into mod...
user@host's password: hunter2
remote: Counting objects: 131, done.
remote: Compressing objects: 100% (115/115), done.
remote: Total 131 (delta 54), reused 0 (delta 0)
Receiving objects: 100% (131/131), 16.16 KiB, done.
Resolving deltas: 100% (54/54), done.
$ git commit -m "Hello world."
[master (root-commit) 565b235] Hello world.
 2 files changed, 4 insertions(+), 0 deletions(-)
 create mode 100644 .gitmodules
 create mode 160000 mod
# At this point, ssh://user@host/git/mod changes; submodule needs to change too.
$ git submodule init
Submodule 'mod' (ssh://user@host/git/mod) registered for path 'mod'
$ git submodule update
$ git submodule sync
Synchronizing submodule url for 'mod'
$ git submodule update
$ man git-submodule 
$ git submodule update --rebase
$ git submodule update
$ echo $?
0
$ git status
# On branch master
nothing to commit (working directory clean)
$ git submodule update mod
$ ...

मैं भी कोशिश की है git fetch mod, जो एक लाने ऐसा करने के लिए प्रकट होता है (लेकिन नहीं कर सकते हैं संभवतः, क्योंकि यह पासवर्ड के लिए उत्साह नहीं है!), लेकिन git logऔर git showनई प्रतिबद्ध के अस्तित्व से इनकार करते हैं। इस प्रकार अब तक मैं सिर्फ rmमॉड्यूल को चला रहा हूं और इसे फिर से जोड़ रहा हूं , लेकिन यह सिद्धांत रूप में गलत है और व्यवहार में थकाऊ है।


5
डेविड जेड का जवाब ऐसा करने के बेहतर तरीके की तरह लगता है - अब जब गिट में आपके द्वारा --remoteविकल्प के माध्यम से बनाई गई कार्यक्षमता है, तो शायद यह चिह्नित करना उपयोगी होगा कि जेसन के जवाब में "हाथ से" दृष्टिकोण के बजाय स्वीकार किए गए उत्तर के रूप में?
मार्क एमी

1
मैं @MarkAmery के साथ बहुत सहमत हूं। जबकि जेसन ने एक काम करने वाला समाधान दिया, यह इसे करने का अभीष्ट तरीका नहीं है, क्योंकि यह गलत कम पहचानकर्ता में सबमॉड्यूल के कमेंट पॉइंटर को छोड़ देता है। इस समय में नया --remoteनिश्चित रूप से एक बेहतर समाधान है, और चूंकि यह सवाल एक गीथब जिस्ट से सबमॉड्यूल के बारे में जुड़ा हुआ है, इसलिए मुझे लगता है कि आने वाले पाठकों के लिए नया उत्तर देखना बेहतर होगा।
मुतांतओक्टोपस

hunter2पासवर्ड के साथ अच्छा स्पर्श : o)
lfarroco

जवाबों:


1458

git submodule updateआदेश वास्तव में Git बताता है कि आप प्रत्येक चेक करने के लिए अपने submodules पहले से ही superproject के सूचकांक में निर्दिष्ट प्रतिबद्ध बाहर करना चाहते हैं। यदि आप अपने रिमोट से उपलब्ध नवीनतम सबमॉड्यूल्स को अपडेट करना चाहते हैं , तो आपको सीधे सबमॉडल्स में यह करने की आवश्यकता होगी।

तो संक्षेप में:

# Get the submodule initially
git submodule add ssh://bla submodule_dir
git submodule init

# Time passes, submodule upstream is updated
# and you now want to update

# Change to the submodule directory
cd submodule_dir

# Checkout desired branch
git checkout master

# Update
git pull

# Get back to your project root
cd ..

# Now the submodules are in the state you want, so
git commit -am "Pulled down update to submodule_dir"

या, यदि आप एक व्यस्त व्यक्ति हैं:

git submodule foreach git pull origin master

335
git submodule foreach git pull
मथियास बीनेंस

87
@ निकल्स उस मामले में, उपयोग करें git submodule foreach git pull origin master
माथियास ब्यनेंस 10

54
इस बिंदु पर, इन सभी सुधारों के साथ, मुझे किसी को एक व्याख्यात्मक ब्लॉग पोस्ट लिखने और मुझे वहां इंगित करने की आवश्यकता है। कृप्या।
Suz

25
'foreach' दृष्टिकोण में मामूली सुधार - अगर आप submodules के भीतर सबमॉड्यूल्स हैं, तो आप इसमें कुछ और जोड़ सकते हैं। इसलिए: git submodule foreach --recursive git pull origin master
ओरियन एल्जेनिल

4
@Abdull के लिए -aस्विच git commit"बताएं [s] स्वचालित रूप से फ़ाइलों को संशोधित करने और हटाए जाने के लिए आदेश, लेकिन जिन नई फ़ाइलों के बारे में आपने नहीं बताया है, वे प्रभावित नहीं होती हैं।"
Godfrzero

473

Git 1.8.2 में एक नया विकल्प है --remote, जो वास्तव में इस व्यवहार को सक्षम करेगा। चल रहा है

git submodule update --remote --merge

प्रत्येक सबमॉड्यूल में अपस्ट्रीम से नवीनतम बदलाव लाएंगे, उन्हें मर्ज करेंगे और सबमॉड्यूल के नवीनतम संशोधन की जांच करेंगे। जैसा कि प्रलेखन यह कहता है:

--remote

यह विकल्प केवल अपडेट कमांड के लिए मान्य है। सबमॉड्यूल को अपडेट करने के लिए सुपरप्रोजेक्ट के रिकॉर्ड किए गए SHA-1 का उपयोग करने के बजाय, सबमॉड्यूल की रिमोट-ट्रैकिंग शाखा की स्थिति का उपयोग करें।

यह git pullप्रत्येक सबमॉड्यूल में चलने के बराबर है , जो आमतौर पर वास्तव में आप क्या चाहते हैं।


4
" git pullप्रत्येक सबमॉड्यूल में चलने के बराबर " स्पष्ट करने के लिए, आपके उत्तर और (उपयोगकर्ता के दृष्टिकोण से) में कोई अंतर नहीं है git submodule foreach git pull?
डेनिस

3
@ यह अनिवार्य रूप से एक ही काम करता है, लेकिन मुझे यकीन नहीं है कि कार्यक्षमता बिल्कुल समान है। कुछ छोटे अंतर हो सकते हैं जिनके बारे में मुझे नहीं पता है, जैसे कि दो कमांड कुछ कॉन्फ़िगरेशन सेटिंग का जवाब देते हैं।
डेविड जेड

5
मेरी इच्छा है कि मैं इस 10,000X को बढ़ा सकूं। इसे git के दस्तावेज़ में कहीं भी क्यों नहीं दिखाया गया है? बहुत बड़ा निरीक्षण।
सेराओसे

4
मेरे लिए वे वास्तव में काफी अलग थे; foreach git pullकेवल उन्हें चेक आउट किया, लेकिन सबमॉडल की नई प्रतिबद्धता को इंगित करने के लिए मुख्य रेपो के पॉइंटर को अपडेट नहीं किया। केवल इसके साथ ही --remoteयह नवीनतम प्रतिबद्ध की ओर इशारा करता है।
इला El२ El५

5
क्यों - वैकल्पिक विकल्प? इससे क्या फर्क पड़ता है?
mFeinstein

126

अपनी परियोजना मूल निर्देशिका में, चलाएं:

git submodule update --init

या यदि आपके पास पुनरावर्ती सबमॉड्यूल हैं:

git submodule update --init --recursive

कभी-कभी यह अभी भी काम नहीं करता है, क्योंकि किसी तरह आपके पास स्थानीय सबमॉड्यूल निर्देशिका में स्थानीय परिवर्तन होते हैं जबकि सबमॉड्यूल को अपडेट किया जा रहा है।

अधिकांश समय स्थानीय परिवर्तन वह नहीं हो सकता है जिसे आप करना चाहते हैं। यह आपके सबमॉड्यूल आदि में फ़ाइल हटाने के कारण हो सकता है, यदि ऐसा है, तो अपनी स्थानीय सबमॉड्यूल निर्देशिका में रीसेट करें और अपनी परियोजना की मूल निर्देशिका में, फिर से चलाएँ:

git submodule update --init --recursive

5
यह सही जवाब है। क्या मैं इसे किसी तरह अपने दूरस्थ भंडार में धकेल सकता हूँ?
मॉन्स्टरमोरपीजी

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

1
यह मौजूदा सबमॉड्यूल्स के लिए परिवर्तनों को नहीं खींचता
सर्गेई जी।

73

आपका मुख्य प्रोजेक्ट एक विशेष प्रतिबद्धता की ओर इशारा करता है कि सबमॉडल पर होना चाहिए। git submodule updateयह जाँचने का प्रयास करता है कि आरंभिक रूप से प्रत्येक सबमॉड्यूल में जो कमिटेड है। सबमॉड्यूल वास्तव में एक स्वतंत्र रिपॉजिटरी है - बस सबमॉड्यूल में एक नई प्रतिबद्धता पैदा करना और उसे धक्का देना पर्याप्त नहीं है। आपको मुख्य प्रोजेक्ट में सबमॉड्यूल के नए संस्करण को स्पष्ट रूप से जोड़ना होगा।

तो, आपके मामले में, आपको सबमॉड्यूल में सही कमिटमेंट मिलनी चाहिए - मान लेते हैं कि यह टिप है master:

cd mod
git checkout master
git pull origin master

अब मुख्य परियोजना पर वापस जाएं, सबमॉडल को चरणबद्ध करें और यह प्रतिबद्ध करें:

cd ..
git add mod
git commit -m "Updating the submodule 'mod' to the latest version"

अब मुख्य परियोजना के अपने नए संस्करण को धक्का दें:

git push origin master

इस बिंदु से, यदि कोई अन्य व्यक्ति अपने मुख्य प्रोजेक्ट git submodule updateको अपडेट करता है , तो उसके लिए यह सबमॉड्यूल अपडेट करेगा, यह मानते हुए कि यह आरंभिक है।


24

ऐसा लगता है कि इस चर्चा में दो अलग-अलग परिदृश्यों को एक साथ मिलाया जा रहा है:

दृष्टांत 1

अपने माता-पिता रिपॉजिटरी के पॉइंटर्स से सबमॉड्यूल का उपयोग करते हुए, मैं प्रत्येक सबमॉड्यूल में कमिटमेंट की जांच करना चाहता हूं जो कि पेरेंट रिपॉजिटरी की ओर इशारा कर रहा है, संभवतः पहले सभी सबमॉड्यूल्स के माध्यम से पुनरावृत्ति करने और रिमोट से इन्हें अपडेट / खींचने के बाद।

यह बताया गया है, जैसा कि बताया गया है

git submodule foreach git pull origin BRANCH
git submodule update

परिदृश्य 2, जो मुझे लगता है कि ओपी का लक्ष्य क्या है

एक या अधिक सबमॉड्यूल में नया सामान हुआ है, और मैं इन बदलावों को 1) करना चाहता हूं और 2) माता-पिता के भंडार को इस / इन सबमॉडल्स के HEAD (नवीनतम) प्रतिबद्ध की ओर इंगित करता है।

इसके द्वारा किया जाएगा

git submodule foreach git pull origin BRANCH
git add module_1_name
git add module_2_name
......
git add module_n_name
git push origin BRANCH

बहुत व्यावहारिक नहीं है, क्योंकि आपको मूल स्क्रिप्ट रिपॉजिटरी के कमिटर्स को अपडेट करने के लिए एक स्क्रिप्ट जैसे उदाहरण में सभी एन सबमॉड्यूल के लिए n रास्तों को हार्डकोड करना होगा।

प्रत्येक सबमॉड्यूल के माध्यम से एक स्वचालित पुनरावृत्ति होना अच्छा होगा, माता-पिता के रिपॉजिटरी पॉइंटर को अपडेट करना (उपयोग करना git add) सबमॉड्यूल (ओं) के प्रमुख को इंगित करना।

इसके लिए, मैंने यह छोटा सा बैश स्क्रिप्ट बनाया:

git-update-submodules.sh

#!/bin/bash

APP_PATH=$1
shift

if [ -z $APP_PATH ]; then
  echo "Missing 1st argument: should be path to folder of a git repo";
  exit 1;
fi

BRANCH=$1
shift

if [ -z $BRANCH ]; then
  echo "Missing 2nd argument (branch name)";
  exit 1;
fi

echo "Working in: $APP_PATH"
cd $APP_PATH

git checkout $BRANCH && git pull --ff origin $BRANCH

git submodule sync
git submodule init
git submodule update
git submodule foreach "(git checkout $BRANCH && git pull --ff origin $BRANCH && git push origin $BRANCH) || true"

for i in $(git submodule foreach --quiet 'echo $path')
do
  echo "Adding $i to root repo"
  git add "$i"
done

git commit -m "Updated $BRANCH branch of deployment repo to point to latest head of submodules"
git push origin $BRANCH

इसे चलाने के लिए, निष्पादित करें

git-update-submodules.sh /path/to/base/repo BRANCH_NAME

विस्तार

सबसे पहले, मैं मानता हूं कि ब्रांच $ ब्रांच (दूसरा तर्क) नाम की शाखा सभी रिपॉजिटरी में मौजूद है। इसे और भी जटिल बनाने के लिए स्वतंत्र महसूस करें।

कुछ खंडों की पहली जाँच है कि तर्क हैं। फिर जब भी मैं सिर्फ पुल कर रहा होता हूं, तब मैं अभिभावक भंडार के नवीनतम सामान को खींचता हूं (मैं उपयोग करना चाहता हूं --ff (तेजी से अग्रेषित करना)। मेरे पास रिबेट बंद है, BTW)।

git checkout $BRANCH && git pull --ff origin $BRANCH

तब कुछ सबमॉड्यूल को इनिशियलाइज़ करना आवश्यक हो सकता है, अगर नए सबमॉड्यूल्स को जोड़ा गया है या अभी तक इनिशियलाइज़ नहीं किया गया है:

git submodule sync
git submodule init
git submodule update

तब मैं सभी सबमॉडल्स को अपडेट / पुल करता हूं:

git submodule foreach "(git checkout $BRANCH && git pull --ff origin $BRANCH && git push origin $BRANCH) || true"

कुछ बातों पर ध्यान दें: सबसे पहले, मैं कुछ Git कमांड का उपयोग कर रहा हूं &&- जिसका अर्थ है कि पिछली कमांड को बिना किसी त्रुटि के निष्पादित करना चाहिए।

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

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

मेरा पसंदीदा हिस्सा:

for i in $(git submodule foreach --quiet 'echo $path')
do
  echo "Adding $i to root repo"
  git add "$i"
done

सभी --quietसबमॉड्यूल्स को Iterate करें - जिसके साथ , 'Entering MODULE_PATH' आउटपुट निकालता है। 'echo $path'(एकल-उद्धरण में होना चाहिए) का उपयोग करके , सबमॉड्यूल का रास्ता आउटपुट को लिखा जाता है।

रिश्तेदार सबमॉड्यूल रास्तों की यह सूची एक सरणी ( $(...)) में कैप्चर की गई है - अंत में इसे पुनरावृत्त करें और git add $iमाता-पिता के भंडार को अपडेट करने के लिए करें।

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

मेरे पास जेनकींस की नौकरी में एक स्क्रिप्ट है जो बाद में एक निर्धारित स्वचालित परिनियोजन के लिए चेन करती है, और यह एक आकर्षण की तरह काम करती है।

मुझे उम्मीद है कि यह किसी की मदद होगी।


2
! @ # $% SO हम आपके लिए स्क्रिप्ट का उपयोग कर रहे हैं; एक नोट: `` git सबमॉडल foreach --quiet '$ $ रास्ता' `` `के बजाय हम` `git सबमॉड्यूल foreach --recursive --quiet pwd` `का उपयोग लूप के लिए करते हैं। pwdआदेश प्रत्येक submodule वर्तमान के लिए उचित 'निरपेक्ष पथ' मुद्रण करता है; --recursiveयह सुनिश्चित करता है कि हम सभी सबमॉड्यूल्स पर जाएँ , जिसमें सबमॉड्यूल्स-इन-सबमॉड्यूल्स -... शामिल हैं, जो एक बड़े प्रोजेक्ट में मौजूद हो सकते हैं। दोनों तरीकों से निर्देशिकाओं में परेशानी होती है, जिसमें रिक्त स्थान शामिल होते हैं, उदाहरण के लिए, /c/Users/Ger/Project\ Files/...इसलिए नीति हमारी परियोजनाओं में कहीं भी व्हाट्सएप का उपयोग नहीं करना है।
गेर हॉबेल्ट

2
यह अच्छा है, और आप सही कह रहे हैं कि कुछ उत्तरों में गलतफहमी है कि प्रश्न यहां तक ​​कि क्या है, लेकिन जैसा कि डेविड जेड के उत्कृष्ट उत्तर द्वारा बताया गया है, आपकी स्क्रिप्ट अनावश्यक है क्योंकि कार्यक्षमता 2013 के मध्य से जब Git में बनाई गई थी। उन्होंने --remoteविकल्प जोड़ा । git submodule update --remoteलगभग वैसा ही व्यवहार करता है जैसा आपकी स्क्रिप्ट करती है।
मार्क एमी

@GerHobbelt धन्यवाद। आप सही हैं, हमारे पास केवल 1 स्तर के सबमॉड्यूल हैं, इसलिए मैंने इसे पुनरावर्ती बनाने के लिए कभी नहीं सोचा था। मैं स्क्रिप्ट को अपडेट नहीं करूंगा, इससे पहले कि मुझे उम्मीद के मुताबिक काम करने का मौका मिले, लेकिन निश्चित रूप से मेरी स्क्रिप्ट उप-उप-मॉड्यूल को प्रभावित करेगी। फ़ोल्डरों में रिक्त स्थान के रूप में, यह निश्चित रूप से बचने के लिए कुछ लगता है! : एस
फ्रेडरिक स्ट्रक-शोइंग

@MarkAmery आपकी प्रतिक्रिया के लिए धन्यवाद। हालाँकि, मुझे 1 अंक दिखाई देता है: उप-तर्क के लिए शाखा निर्दिष्ट करने में सक्षम नहीं होने के कारण। गिट मैनुअल से: The remote branch used defaults to master, but the branch name may be overridden by setting the submodule.<name>.branch option in either .gitmodules or .git/config (with .git/config taking precedence).मैं हर बार संपादित नहीं करना चाहता हूँ। लेकिन शायद मैं कुछ याद किया है? इसके अलावा, विधि पुनरावर्ती विलय को लागू करने के लिए लगता है (इस प्रकार एक तेजी से आगे की संभावना गायब है)।
फ्रेडरिक स्ट्रक-शोइंग

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

19

सादे और सरल, सबमोडुल्स लाने के लिए:

git submodule update --init --recursive

और अब उन्हें नवीनतम मास्टर शाखा में अद्यतन करें (उदाहरण के लिए):

git submodule foreach git pull origin master

12

ध्यान दें, जबकि सबमॉडल के अद्यतन के आधुनिक रूप निम्न होंगे:

git submodule update --recursive --remote --merge --force

पुराना रूप था:

git submodule foreach --quiet git pull --quiet origin

सिवाय ... यह दूसरा रूप वास्तव में "शांत" नहीं है।

Nguy Thn Thái Ngọc Duy ( pclouds) द्वारा a282f5a (12 अप्रैल 2019) देखें ।
( जूनियो सी gitsterहमानो द्वारा विलय - - प्रतिबद्ध एफ 1 सी 9 एफ 6 सी , 25 अप्रैल 2019)

submodule foreach: " <command> --quiet" ठीक करें सम्मान नहीं किया जा रहा है

रॉबिन ने बताया कि

git submodule foreach --quiet git pull --quiet origin

वास्तव में अब शांत नहीं है।
यह fc1b924 से पहले शांत होना चाहिए submodule: ( शेल से C, 2018-05-10, Git v2.19.0-rc0) पोर्ट पोर्ट submodule' foreach' क्योंकि parseoptगलती से विकल्प नहीं खा सकते हैं।

" git pull" ऐसा व्यवहार किया जाता है जैसे --quietकि नहीं दिया गया हो।

यह इसलिए होता है क्योंकि parseoptमें submodule--helperदोनों को पार्स करने की कोशिश करेंगे --quietविकल्प के रूप में यदि वे foreach के विकल्प नहीं हैं, git-pullके।
पार्स किए गए विकल्प कमांड लाइन से हटा दिए जाते हैं। इसलिए जब हम बाद में पुल बनाते हैं, तो हम इसे निष्पादित करते हैं

git pull origin

सबमॉड्यूल हेल्पर को कॉल करते समय, " --" के सामने " " जोड़ने से पार्सिंग के विकल्प git pullबंद हो जाएंगे parseoptजो वास्तव में संबंधित नहीं हैं submodule--helper foreach

PARSE_OPT_KEEP_UNKNOWNएक सुरक्षा उपाय के रूप में हटा दिया जाता है। parseoptकभी भी अज्ञात विकल्प नहीं देखना चाहिए या कुछ गलत हो गया है। जब मैं उन्हें देख रहा हूँ तो कुछ उपयोग स्ट्रिंग अद्यतन भी हैं।

इसके साथ ही, मैं " --" अन्य उपनगरों को भी जोड़ता हूं जो पास होते हैं$@ " करते हैं submodule--helper। " $@" इन ​​मामलों में पथ और कम होने की संभावना है --something-like-this
लेकिन बिंदु अभी भी खड़ा है, git-submoduleपार्स किया है और वर्गीकृत किया है कि विकल्प क्या हैं, पथ क्या हैं। यदि वे एक जैसे दिखते हैं, तो विकल्प
submodule--helperद्वारा पारित किए git-submoduleगए रास्तों पर कभी विचार नहीं करना चाहिए ।


और Git 2.23 (Q3 2019) एक अन्य समस्या को हल करता है: " git submodule foreach" कमांड लाइन विकल्प की रक्षा नहीं करता था ताकि कमांड को प्रत्येक सबमॉड्यूल में सही ढंग से चलाया जा सके, जब " --recursive" विकल्प प्रयोग में था।

मोरियन सॉनेट ( ) द्वारा देखें 30db18b (24 जून 2019) प्रतिबद्धmomoson
(द्वारा विलय Junio सी Hamano - gitster- में प्रतिबद्ध 968eecb , 09 जुला 2019)

submodule foreach: विकल्पों की पुनरावृत्ति को ठीक करें

कॉलिंग:

git submodule foreach --recursive <subcommand> --<option>

यह बताते हुए एक त्रुटि हुई कि विकल्प --<option>अज्ञात है submodule--helper
यह केवल तभी है, जब इसके <option>लिए कोई वैध विकल्प नहीं है git submodule foreach

इसका कारण यह है, कि उपर्युक्त कॉल को आंतरिक रूप से सबमॉड्यूल में कॉल किया जाता है - सहायक:

git submodule--helper foreach --recursive \
    -- <subcommand> --<option>

यह कॉल पहले स्तर के सबमॉड्यूल के अंदर अपने विकल्प के साथ उपकमांड को निष्पादित करने से शुरू होता है और कॉल के अगले पुनरावृत्ति को submodule foreachकॉल करके जारी रहता है

git --super-prefix <submodulepath> submodule--helper \
   foreach --recursive <subcommand> --<option>

पहले स्तर के सबमॉड्यूल के अंदर। ध्यान दें कि उपकमांड के सामने डबल डैश गायब है।

यह समस्या हाल ही में उत्पन्न होती है, क्योंकि PARSE_OPT_KEEP_UNKNOWNतर्क के पार्सिंग के लिए ध्वज git submodule foreachको हटा दिया गया था a282f5a
इसलिए, अज्ञात विकल्प के बारे में अब शिकायत की जाती है, क्योंकि डबल डैश द्वारा तर्क पार्सिंग को ठीक से समाप्त नहीं किया गया है।

यह पुनरावृत्ति के दौरान subcommand के सामने डबल डैश जोड़कर समस्या को हल करता है।


7
git pull --recurse-submodules

यह सभी नवीनतम आवागमन खींच लेगा।


4

मेरे मामले में, मैं चाहता था git नवीनतम को अद्यतन और उसी समय किसी भी लापता फाइल को फिर से आबाद ।

निम्नलिखित ने लापता फ़ाइलों को पुनर्स्थापित किया (धन्यवाद, --forceजिसके बारे में यहां उल्लेख नहीं किया गया है), लेकिन इसने कोई नया कमिट नहीं निकाला:

git submodule update --init --recursive --force

यह किया:

git submodule update --recursive --remote --merge --force


3

@ जेसन एक तरह से सही है लेकिन पूरी तरह से नहीं।

अपडेट करें

पंजीकृत सबमॉड्यूल को अपडेट करें, यानी लापता सबमॉड्यूल्स को क्लोन करें और युक्त भंडार के सूचकांक में निर्दिष्ट प्रतिबद्धताओं की जांच करें। यह सबमॉड्यूल्स HEAD को तब तक अलग कर देगा जब तक कि --rebase या --merge निर्दिष्ट या प्रमुखmmodule नहीं हो। $ name.update को रीबेस या मर्ज करने के लिए सेट किया गया है।

तो, git submodule updateचेकआउट करता है, लेकिन यह युक्त भंडार के सूचकांक में प्रतिबद्ध है। यह अभी तक नए प्रतिबद्ध के बारे में नहीं जानता है। इसलिए अपने सबमॉड्यूल पर जाएं, अपनी इच्छित कमिटमेंट प्राप्त करें और मुख्य रिपॉजिटरी में अपडेट किए गए सबमॉड्यूल स्टेट को कमिट करें और फिर करें git submodule update


1
ऐसा लगता है कि अगर मैं सबमॉड्यूल को एक अलग कमेटी में स्थानांतरित करता हूं, और फिर रन करता है git submodule update, तो अपडेट सुपरमॉडल के वर्तमान हेड में निर्दिष्ट किए गए कमिट में सबमॉड्यूल को स्थानांतरित करेगा। (जो भी सुपरप्रोजेक्ट में सबसे हालिया वचन कहता है, सबप्रोजेक्ट होना चाहिए - यह व्यवहार, जेसन के पोस्ट में स्पष्टीकरण के बाद, मेरे लिए तर्कसंगत लगता है) यह भी प्रतीत होता है, लेकिन केवल इस मामले में कि उपप्रोजेक्ट गलत प्रतिबद्ध है , जो मेरे भ्रम को जोड़ रहा था।
थानाटोस


2

यदि आप होस्ट शाखा को नहीं जानते हैं, तो इसे बनाएं:

git submodule foreach git pull origin $(git rev-parse --abbrev-ref HEAD)

यह मुख्य Git रिपॉजिटरी की एक शाखा प्राप्त करेगा और फिर प्रत्येक सबमॉड्यूल के लिए एक ही शाखा का एक पुल बना देगा।


0

यदि आप masterप्रत्येक सबमॉड्यूल के लिए चेकआउट शाखा की तलाश कर रहे हैं - आप उस उद्देश्य के लिए निम्नलिखित कमांड का उपयोग कर सकते हैं:

git submodule foreach git checkout master
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.