Sığ git alt modülleri nasıl yapılır?

Sığ alt modüllere sahip olmak mümkün mü? Her biri uzun bir geçmişe sahip birkaç alt modüle sahip bir süper projem var, bu yüzden tüm bu geçmişi gereksiz yere sürükleyerek büyük oluyor.

Bulduğum tek şey bu cevapsız iplik .

Sadece uygulamak için git-submodule kesmek mi?

Gelecek git1.8.4'te (Temmuz 2013) yenilikler :

" git submodule update" isteğe bağlı olarak alt modül havuzlarını sığ biçimde klonlayabilir.

(Ve git 2.10 3. Çeyrek 2016 bunu ile kaydetmeyi sağlar git config -f .gitmodules submodule.<name>.shallow true.
Bu cevabın sonuna bakınız)

Bkz. Taahhüt 275cd184d52b5b81cb89e4ec33e540fb2ae61c1f :

Ekle --depthardından klon komuta geçirilir "git altmodülün" nin eklenti ve güncelleme komutları seçeneği. Bu, alt modül (ler) çok büyük olduğunda ve en son taahhütten başka bir şeyle gerçekten ilgilenmediğinizde yararlıdır.

Testler eklenir ve "alt modül güncellemesi pwd'deki sembolik bağlantıları işleyebilir" üzerindeki test dosyasının geri kalanına uyacak şekilde bazı girinti ayarlamaları yapılmıştır.

İmzalayan: Fredrik Gustafsson <iveqy@iveqy.com>
Kabul eden: Jens Lehmann<Jens.Lehmann@web.de>

Bu şu anlama gelir:

git submodule add --depth 1 -- repository path
git submodule update --depth -- [<path>...]

İle:

--depth::

Bu seçenek addve updatekomutları için geçerlidir .
Geçmişi belirtilen sayıda düzeltmeye kesilmiş bir 'sığ' klon oluşturun.

atwyman yorumlarda ekliyor :

Anlayabildiğim kadarıyla bu seçenek masterçok yakından takip etmeyen alt modüller için kullanılamaz . Derinlik 1'i ayarlarsanız submodule update, ancak istediğiniz alt modül taahhüdü en son mastersa başarılı olabilir. Aksi takdirde " fatal: reference is not a tree" alırsınız .

Bu doğru.
Yani git 2.8'e kadar (Mart 2016). 2.8 ile, submodule update --depthSHA1'e uzaktan repo HEAD'lerinden birinden doğrudan ulaşılabilse bile, başarılı olmak için bir şans daha var.

Bakınız Stefan Beller ( ) tarafından fb43e31 (24 Şub 2016 ) . Yardım eden: Junio ​​C Hamano ( ) . ^{(Göre Birleştirilmiş - Junio Cı Hamano - içinde 9671a76 tamamlama 2016, 26 Şubat)}stefanbeller
gitster
gitster

submodule: doğrudan sha1 getirerek gerekli sha1'i getirmek için daha çok deneyin

Gerrit'te bir alt modülü de güncelleyen bir değişikliği incelerken, yaygın bir inceleme uygulaması, yamayı test etmek için yerel olarak indirip kiraz seçmektir.
Bununla birlikte, yerel olarak test edilirken, ' git submodule update' doğru alt modül sha1 getirilemediğinden, alt modüldeki ilgili taahhüt henüz proje geçmişinin bir parçası değil, aynı zamanda sadece önerilen bir değişikliktir.

Eğer $sha1varsayılan bir parçası değildi biz almaya çalışın getirme $sha1doğrudan . Ancak bazı sunucular sha1 tarafından doğrudan getirmeyi desteklemez, bu da git-fetchhızlı bir şekilde başarısızlığa neden olur.
Hala eksik olan sha1 zaten ödeme aşamasında daha sonra başarısızlığa yol açacağı için kendimizi başarabiliriz, bu yüzden burada başarısız olmak alabileceğimiz kadar iyidir.

MVG işaret yorumlarda için taahhüt fb43e31 (git 2.9 2016 Şubat)

Bana öyle geliyor ki, fb43e31 , SHA1 kimliğinin eksik taahhüdünü talep ediyor gibi görünüyor , bu nedenle sunucudaki uploadpack.allowReachableSHA1InWantve uploadpack.allowTipSHA1InWantayarları muhtemelen bunun çalışıp çalışmadığını etkileyecektir. Bugün git listesine
bir yazı yazdım , bazı senaryolarda, yani taahhüdün de bir etiket olması durumunda, sığ alt modüllerin kullanımının nasıl yapılabileceğine işaret ettim .
Bekleyelim ve görelim.

Bu fb43e31 belirli bir SHA1 için getirme varsayılan dal getirme sonra bir geri dönüş yaptı neden olduğunu tahmin ediyorum.
Bununla birlikte, “--depth 1” durumunda, erken iptal etmenin mantıklı olacağını düşünüyorum: Listelenen referanslardan hiçbiri talep edilenle eşleşmiyorsa ve SHA1 tarafından sormak sunucu tarafından desteklenmiyorsa, bir şey getirmektir, çünkü alt modül gereksinimini her iki şekilde de karşılayamayız.

Ağustos 2016 Güncellemesi (3 yıl sonra)

Git 2.10 (3. Çeyrek 2016) ile şunları yapabilirsiniz:

 git config -f .gitmodules submodule.<name>.shallow true

Daha fazla bilgi için bkz. " Ek ağırlık olmadan Git alt modülü ".

Git 2.13 ( 2.Çeyrek 2017) Sebastian Schuberth ( sschuberth) tarafından 8d3047c (19 Nis 2017) taahhüdünde bulunuldu .
^{(Göre Birleştirilmiş Sebastian Schuberth - sschuberth- içinde 8d3047c tamamlama , 20 Nisan 2017)}

bu alt modülün bir klonu, sığ bir klon olarak gerçekleştirilecektir (geçmiş derinliği 1 olan)

Ancak, Ciro Santilli yorumları ekliyor (ve cevabındaki detaylar )

shallow = trueüzerinde .gitmodulesde etkiler kullanırken referans uzaktan BAŞ tarafından izlenen --recurse-submoduleshedef bir şube tarafından gösterilen taahhüt bile, ve sen koymak bile branch = mybranchüzerinde .gitmodulesde.

Git 2.20 (Q4 2018) HEAD:.gitmodules, .gitmodulesdosya çalışma ağacında eksik olduğunda blobdan okunacak şekilde güncellenen alt modül desteğinde gelişir .

Bkz 2b1257e işlemek , 76e9bdc taahhüt (25 Ekim 2018) ve b5c259f işlemek , 23dd8f5 işlemek , b2faad4 işlemek , 2502ffc işlemek , 996df4d taahhüt , d1b13df işlemek , 45f5ef3 taahhüt , bcbc780 taahhüt tarafından (05 Eki 2018) Antonio Ospite ( ao2) .
^{(Tarafından Birleştirilmiş - Junio C Hamano gitster- içinde abb4824 taahhüt 2018 13 Kasım,)}

submodule: .gitmodulesçalışma ağacında değilken okumayı destekleyin

Ne zaman .gitmodulesdosya çalışma ağacında mevcut değildir, dizinden ve mevcut şubesinden içeriği kullanmayı deneyin.
Bu, dosyanın deponun bir parçası olduğu, ancak bir nedenden dolayı, örneğin seyrek bir ödeme nedeniyle teslim alınmadığı durumu kapsar.

Bu sayede en azından kullanmayı kolaylaştırır ' git submodule' komutları okumakgitmodules dolu çalışma ağaç doldurma olmadan yapılandırma dosyası.

İçin yazmak .gitmodulesyine de dosyanın teslim alınmasını gerektirir, bu yüzden aramadan önce dosyayı kontrol edin config_set_in_gitmodules_file_gently.

Güvenli bir şekilde yazılamadığında git-submodule.sh::cmd_add()" git submodule add" komutunun nihai hatasını tahmin etmek için de benzer bir onay ekleyin .gitmodules; bu, komutun havuzu sahte bir durumda bırakmasını önler (örn. alt modül deposu klonlanmıştır, ancak başarısız .gitmodulesolduğu için güncellenmemiştir config_set_in_gitmodules_file_gently).

Ayrıca, config_from_gitmodules()şimdi global nesne deposuna eriştiği için, işlevi çağıran tüm kod yollarını, global nesne deposuna eşzamanlı erişime karşı korumak gerekir.
Şu anda bu sadece olur builtin/grep.c::grep_submodules(), bu yüzden grep_read_lock()ilgili kodu çağırmadan önce arayın config_from_gitmodules().

NOT: Bu yeni özelliğin henüz düzgün çalışmadığı nadir bir durum vardır: .gitmodulesçalışma ağacında olmayan iç içe alt modüller .

Not: Git 2.24 (Q4 2019), bir alt modül sığ klonlanırken olası bir segfaultu düzeltir.

Ali Utku Selen ( ) tarafından taahhüt edilen ddb3c85 (30 Eyl 2019) bölümüne bakınız . ^{(Tarafından Birleştirilmiş - Junio C Hamano - içinde 678a9ca taahhüt 2019, 09 Eki)}auselen
gitster

Git 2.25 (Q1 2020), git submodule updatebelgeleri açıklar .

Philippe Blain ( ) tarafından taahhüt edilen f0e58b3 (24 Kas 2019) bölümüne bakınız . ^{(Göre Birleştirilmiş - Junio Cı Hamano - içinde ef61045 tamamlama 2019 05 Ara)}phil-blain
gitster

doc: 'git submodule update'in eksik taahhütleri aldığını belirtin

^{Yardım eden: Junio ​​C Hamano
Yardım eden: Johannes Schindelin
İmzalayan: Philippe Blain}

Süper projeye kaydedilen SHA-1 bulunmazsa, ' git submodulegüncelleme' alt modül uzaktan kumandasından yeni taahhütler getirecektir . Bu belgelerde belirtilmemiştir.

Uyarı: Git 2.25 (Q1 2020) ile " git clone --recurse-submodules" ve alternatif nesne deposu arasındaki etkileşim kötü tasarlanmıştı.

Dokümantasyon ve kod, kullanıcılar hata gördüğünde daha net önerilerde bulunmayı öğretmiştir.

Bkz. Taahhüt 4f3e57e , taahhüt: 10c64a0 (02 Aralık 2019), Jonathan Tan ( jhowtan) .
^{(Göre Birleştirilmiş - Junio Cı Hamano gitster- içinde 5dd1d59 tamamlama 2019 10 Ara)}

submodule--helper: önemli alternatif hata hakkında tavsiye

^{İmzalayan: Jonathan Tan
Kabul eden: Jeff King}

Bir süper .gitmodulesprojeyi tanımlanmış bazı sığ modüllerle özyineli olarak klonlarken, sonra " --reference=<path>" ile yeniden klonlarken bir hata oluşur. Örneğin:

git clone --recurse-submodules --branch=master -j8 \
  https://android.googlesource.com/platform/superproject \
  master
git clone --recurse-submodules --branch=master -j8 \
  https://android.googlesource.com/platform/superproject \
  --reference master master2

ile başarısız:

fatal: submodule '<snip>' cannot add alternate: reference repository
'<snip>' is shallow

Süper projenin alternatifinden hesaplanan bir alternatif eklenemiyorsa, bu durumda veya başka bir durumda, " submodule.alternateErrorStrategy" yapılandırma seçeneğini yapılandırma ve klonlama sırasında " --reference-if-able" yerine " " kullanma hakkında bilgi verin --reference.

Ayrıntılı olarak:

Git 2.25 (Q1 2020) ile, "git clone --recurse-submodules" ile alternatif nesne deposu arasındaki etkileşim kötü tasarlanmıştı.

Doc: açıklamak submodule.alternateErrorStrateji

^{İmzalayan: Jonathan Tan
Kabul eden: Jeff King}

Taahhüt 31224cbdc7 (" clone: özyinelemeli ve başvuru seçeneği alt modül alternatiflerini tetikler", 2016-08-17, Git v2.11.0-rc0 - toplu iş # 1'de listelenen birleştirme ) Git'e bir süper projede yapılandırma seçeneklerini desteklemesi için " " ve " " .submodule.alternateLocationsubmodule.alternateErrorStrategy

Bir üst projede " submodule.alternateLocation", " " olarak yapılandırılırsa superproject, bu üst projenin bir alt modülü klonlandığında, bunun yerine üst projenin o alt modülünün benzer alternatif yolunu hesaplar ve ona $GIT_DIR/objects/info/alternatesbaşvurur.

" submodule.alternateErrorStrategy" Seçeneği, bu alternatife başvurulamazsa ne olacağını belirler.
Bununla birlikte, klonun, bu seçenek "kalıp" olarak ayarlanmadığında ( 31224cbdc7'deki testlerde görülebileceği gibi) alternatif belirtilmemiş gibi devam ettiği açık değildir .
Bu nedenle, uygun şekilde belgeleyin.

Yapılandırma alt modül belgeler şimdi içerir:

submodule.alternateErrorStrategy::

Alt modülün üzerinden hesaplandığı gibi alternatiflerle hataların nasıl ele alınacağını belirtir submodule.alternateLocation.
Olası değerler ignore, info, die.
Varsayılan değer die.
İçin ayarlanmış eğer Not ignoreveya infove bilgisayarlı alternatif bir hata varsa, klon ilerler hiçbir alternatif belirtilen sanki .

Git 2.9.0 doğrudan sığ klon alt modüllerini destekler, böylece şimdi arayabilirsiniz:

git clone url://to/source/repository --recursive --shallow-submodules

Ryan'ın cevabını takiben , tüm alt modüllerden tekrarlayan ve sığ klonlayan bu basit senaryoyu bulabildim:

#!/bin/bash
git submodule init
for i in $(git submodule | sed -e 's/.* //'); do
    spath=$(git config -f .gitmodules --get submodule.$i.path)
    surl=$(git config -f .gitmodules --get submodule.$i.url)
    git clone --depth 1 $surl $spath
done
git submodule update

Git-submodule "source" 'dan okurken git submodule add, depoları zaten mevcut olan alt modülleri işleyebilir gibi görünüyor . Bu durumda...

$ git clone $remote1 $repo
$ cd $repo
$ git clone --depth 5 $remotesub1 $sub1
$ git submodule add $remotesub1 $sub1
#repeat as necessary...

Gerekli taahhüdün alt modül deposunda olduğundan emin olmak istersiniz, bu nedenle uygun bir derinlik ayarladığınızdan emin olun.

Düzenleme: Birden fazla manuel alt modül klonu ve ardından tek bir güncelleme ile kurtulabilirsiniz:

$ git clone $remote1 $repo
$ cd $repo
$ git clone --depth 5 $remotesub1 $sub1
#repeat as necessary...
$ git submodule update

Git 2.14.1 itibariyle buggy / beklenmedik / can sıkıcı davranışların özeti

1. shallow = trueiçinde .gitmodulessadece etkiler git clone --recurse-submoduleseğer HEADgerekli uzaktan alt modülü noktalarının taahhüt hedef bir şube tarafından gösterilen taahhüt bile, ve sen koymak bile branch = mybranchüzerinde .gitmodulesde.

   Yerel test komut dosyası . HEADVarsayılan şube repo ayarıyla denetlenen GitHub 2017-11'de aynı davranış :

   git clone --recurse-submodules https://github.com/cirosantilli/test-shallow-submodule-top-branch-shallow
   cd test-shallow-submodule-top-branch-shallow/mod
   git log
   # Multiple commits, not shallow.
   

2. git clone --recurse-submodules --shallow-submodulesne bir mesaj ile bir şube veya etiketi tarafından başvuruda bulunulan işlerlerse başarısız: error: Server does not allow request for unadvertised object.

   Yerel test komut dosyası . GitHub'da aynı davranış:

   git clone --recurse-submodules --shallow-submodules https://github.com/cirosantilli/test-shallow-submodule-top-sha
   # error
   

   Posta listesinde de sordum: https://marc.info/?l=git&m=151863590026582&w=2 ve cevap:

   Teoride bu kolay olmalı. :)

   Uygulamada maalesef çok fazla değil. Bunun nedeni klonlamanın sadece bir dalın en son ucunu (genellikle master) elde etmesidir. Klonda istenen kesin sha1'i belirten bir mekanizma yoktur.

   Tel protokolü, kesin sha1'lerin sorulmasını destekler, bu yüzden kapsamalıdır. (Uyarı: yalnızca sunucu operatörü uploadpack.allowReachableSHA1In hangi github'ın AFAICT'ye sahip olmadığını etkinleştirirse çalışır)

   git-fetch rasgele sha1 alınmasına izin verir, bu nedenle bir geçici çözüm olarak, ilk klondan sonra getirmeleri kullanacağı için "git submodule update" kullanarak yinelemeli klondan sonra bir getirme çalıştırabilirsiniz.

TODO testi: allowReachableSHA1InWant.

Alt modüllerinizin kanonik konumları uzak mı? Eğer öyleyse, onları bir kez klonlama konusunda uygun musunuz? Başka bir deyişle, sadece sık sık kullanılan alt modül (re) klonlarının boşa harcanan bant genişliğine sahip olduğunuz için sığ klonları mı istiyorsunuz?

Sığ klonların yerel disk alanını kurtarmak istiyorsanız, Ryan Graham'ın cevabı gitmek için iyi bir yol gibi görünüyor. Depoları sığ olacak şekilde el ile klonlayın. Bunun yararlı olacağını düşünüyorsanız, git submoduledesteklemeye adapte olun. Listeye bu konuyu soran bir e-posta gönderin (uygulamaya ilişkin öneriler, arayüzle ilgili öneriler vb.). Bence millet, Git'i yapıcı yollarla ciddiyetle geliştirmek isteyen potansiyel katkıda bulunanları oldukça destekliyor.

Her alt modülün bir tam klonunu yapmayı tamamlıyorsanız (ve bunları güncel tutmak için daha sonra alır), yerel nesne depolarına (ör. Git 1.6.4 ve sonraki sürümlerde) --referenceseçeneğini kullanmayı deneyebilirsiniz git submodule update(ör. yapmak --mirrorkanonik alt modülü depolarının klonları, daha sonra kullanmak --reference) bu yerel klonlar için noktasına submodules içinde. Kullanmadan önce git clone --reference/ hakkında okuduğunuzdan emin olun . Referans aynaları ile ilgili tek olası sorun, hızlı ileriye dönük güncellemeleri getirmeme ihtimalidir (yine de, sorunlara neden olabilecek terk edilmiş taahhütleri tutmaya yardımcı olmak için reflog'ları etkinleştirebilir ve son kullanma pencerelerini genişletebilirsiniz). Sürece herhangi bir sorun yaşamamalısıngit clone --shared--reference

• herhangi bir yerel alt modül taahhütte bulunmazsanız veya
• kanonik depoların yayınlayabileceği hızlı ileriye doğru sarkan herhangi bir taahhüt, yerel alt modül taahhütlerinizin atası değildir veya
• kanonik alt modül depolarında yayınlanamayan ileriye dönük olanların üstüne yerel alt modül taahhütlerinizi yeniden tutma konusunda gayretlisiniz.

Böyle bir şeyle giderseniz ve çalışma ağaçlarınızda yerel alt modül taahhütlerini taşıyabilme şansınız varsa, muhtemelen teslim alınan alt modüllerin referans aldığı kritik nesnelerin olmadığından emin olan otomatik bir sistem oluşturmak iyi bir fikir olacaktır. ayna depolarında sarkan bıraktı (ve varsa, onları ihtiyaç duyan depolara kopyalar).

Ve, git clonemanpage'in dediği gibi, --referencebu sonuçları anlamadıysanız kullanmayın .

# Full clone (mirror), done once.
git clone --mirror $sub1_url $path_to_mirrors/$sub1_name.git
git clone --mirror $sub2_url $path_to_mirrors/$sub2_name.git

# Reference the full clones any time you initialize a submodule
git clone $super_url super
cd super
git submodule update --init --reference $path_to_mirrors/$sub1_name.git $sub1_path_in_super
git submodule update --init --reference $path_to_mirrors/$sub2_name.git $sub2_path_in_super

# To avoid extra packs in each of the superprojects' submodules,
#   update the mirror clones before any pull/merge in super-projects.
for p in $path_to_mirrors/*.git; do GIT_DIR="$p" git fetch; done

cd super
git pull             # merges in new versions of submodules
git submodule update # update sub refs, checkout new versions,
                     #   but no download since they reference the updated mirrors

Alternatif olarak, --referenceayna klonlarını git clonealt modüllerinizin kaynağı olarak yerel aynaları kullanarak varsayılan sabit bağlantı işleviyle birlikte kullanabilirsiniz . Yeni süper proje klonlarında, yerel aynalara işaret etmek için git submodule initalt modül URL'lerini düzenleyin .git/config, ardındangit submodule update. Sabit bağlantıları elde etmek için mevcut tüm kullanıma alınmış alt modülleri yeniden eklemeniz gerekir. Aynalara yalnızca bir kez indirip ardından bunlardan yerel olarak teslim alınmış alt modüllerinize getirerek bant genişliğinden tasarruf edersiniz. Sabit bağlantı, disk alanından tasarruf etmesine rağmen (getirmeler, teslim alınan alt modüllerin nesne depolarının birden fazla örneği arasında birikme ve çoğaltılma eğiliminde olsa da, sağlanan disk alanı tasarrufunu yeniden kazanmak için düzenli olarak teslim alınan alt modülleri aynalardan geri alabilirsiniz. ) sabit bağlar.

Tüm projelerin yapamadığı, kanayan kenarda çalışmadığı için biraz farklı bir sürüm oluşturdum. Standart alt modül eklemeleri işe yaramadı ve yukarıdaki komut dosyası da işe yaramadı. Bu yüzden ref etiketi için bir karma arama ekledim ve eğer yoksa, tam klonuna geri döner.

#!/bin/bash
git submodule init
git submodule | while read hash name junk; do
    spath=$(git config -f .gitmodules --get submodule.$name.path)
    surl=$(git config -f .gitmodules --get submodule.$name.url)
    sbr=$(git ls-remote --tags $surl | sed -r "/${hash:1}/ s|^.*tags/([^^]+).*\$|\1|p;d")
    if [ -z $sbr ]; then
        git clone $surl $spath
    else
        git clone -b $sbr --depth 1 --single-branch $surl $spath
    fi
done
git submodule update 

Git deposunu belirli bir revizyon / changeet ile klonlama referansı ?

Submodule referansınız master'dan uzakta olduğunda sorun olmayan basit bir komut dosyası yazdım

git submodule foreach --recursive 'git rev-parse HEAD | xargs -I {} git fetch origin {} && git reset --hard FETCH_HEAD'

Bu ifade, başvurulan alt modülün sürümünü getirecektir.

Hızlıdır, ancak alt modüldeki düzenlemenizi yapamazsınız ( https://stackoverflow.com/a/17937889/3156509 tarihinden önce bu görüntüyü almanız gerekir )

dolu:

#!/bin/bash
git submodule init
git submodule foreach --recursive 'git rev-parse HEAD | xargs -I {} git fetch origin {} && git reset --hard FETCH_HEAD'
git submodule update --recursive

Bir alt modülün sığ klonu mükemmeldir, çünkü belirli bir revizyon / değişiklik setinde anlık görüntü alırlar. Bir script için denedim bu yüzden web sitesinden bir zip indirmek kolaydır.

#!/bin/bash
git submodule deinit --all -f
for value in $(git submodule | perl -pe 's/.*(\w{40})\s([^\s]+).*/\1:\2/'); do
  mysha=${value%:*}
  mysub=${value#*:}
  myurl=$(grep -A2 -Pi "path = $mysub" .gitmodules | grep -Pio '(?<=url =).*/[^.]+')
  mydir=$(dirname $mysub)
  wget $myurl/archive/$mysha.zip
  unzip $mysha.zip -d $mydir
  test -d $mysub && rm -rf $mysub
  mv $mydir/*-$mysha $mysub
  rm $mysha.zip
done
git submodule init

git submodule deinit --all -f komut dosyasının yeniden kullanılabilmesini sağlayan alt modül ağacını temizler.

git submodule40 karakterlik sha1 ve ardından aynı değere karşılık gelen bir yol alır .gitmodules. İki nokta üst üste işareti ile ayrılmış bu bilgileri birleştirmek için perl kullanıyorum, sonra değerleri myshave değerlerine ayırmak için değişken dönüşüm kullanıyorum mysub.

Bunlar kritik anahtarlardır çünkü indirmek için urlsha1'e ve .gitmodules ile ilişkilendirilecek yola ihtiyacımız var.

Tipik bir alt modül girişi verildiğinde:

[submodule "label"]
    path = localpath
    url = https://github.com/repository.git

myurltuşları path =değeri elde etmek sonra sonra 2 çizgiler görünüyor. Bu yöntem tutarlı bir şekilde çalışmayabilir ve iyileştirme gerektirebilir. Url grep, kalanla .gittür referansları sonuncuyla /ve a'ya kadar herhangi bir şeyle eşleyerek keser ..

mydirolduğunu mysubeksi nihai /namealt modül adı giden dizin tarafından olur ki.

Sonraki, wgetindirilebilir zip arşiv URL'si biçiminde bir. Bu gelecekte değişebilir.

Alt mydirmodül yolunda belirtilen alt dizin olacak dosyayı sıkıştırın. Sonuçta elde edilen klasör url- öğesinin son öğesi olacaktır sha1.

Alt modül yolunda belirtilen alt dizinin mevcut olup olmadığını kontrol edin ve ayıklanan klasörün yeniden adlandırılmasına izin vermek için bu dizini kaldırın.

mv sha1 kodumuzu içeren ayıklanan klasörü doğru alt modül yoluna yeniden adlandırın.

İndirilen zip dosyasını silin.

Alt modül başlangıcı

Bu, bir çözümden ziyade bir WIP kavram kanıtıdır. Çalıştığında, sonuç, belirtilen bir değişiklik kümesinde bir alt modülün sığ bir klonudur.

Depo farklı bir işleme alt modülü yeniden barındırırsa, güncelleştirmek için komut dosyasını yeniden çalıştırın.

Böyle bir komut dosyasının yararlı olacağı tek zaman, bir kaynak projenin işbirlikçi olmayan yerel inşası içindir.