Git alt modülü için yeni kaydetmeleri yoksay


83

Arka fon

Git 1.8.1.1'i Linux'ta kullanma. Depo aşağıdaki gibi görünür:

master
  book

Alt modül aşağıdaki gibi oluşturuldu:

$ cd /path/to/master
$ git submodule add https://user@bitbucket.org/user/repo.git book

Alt bookmodül temiz:

$ cd /path/to/master/book/
$ git status
# On branch master
nothing to commit, working directory clean

Sorun

Diğer yandan, master, kitap alt modülü için "yeni işlemlerin" olduğunu gösterir:

$ cd /path/to/master/
$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   book (new commits)
#
no changes added to commit (use "git add" and/or "git commit -a")

Git, ana modülün de temiz olması için alt modül dizinini tamamen yok saymalıdır:

$ cd /path/to/master/
$ git status
# On branch master
nothing to commit, working directory clean

Başarısız Deneme # 1 - kirli

Dosyanın içinde, master/.gitmodulesbu cevaba göre aşağıdaki gibidir :

[submodule "book"]
        path = book
        url = https://user@bitbucket.org/user/repo.git
        ignore = dirty

Başarısız Deneme 2 - izlenmeyen

master/.gitmodulesBu yanıta göre aşağıdakine değiştirildi :

[submodule "book"]
        path = book
        url = https://user@bitbucket.org/user/repo.git
        ignore = untracked

Başarısız Deneme 3 - showUntrackedFiles

master/.git/configBu yanıta göre aşağıdaki şekilde düzenlendi :

[status]
   showUntrackedFiles = no

Başarısız Deneme # 4 - yok say

Kitap dizini ana yoksayma dosyasına eklendi:

$ cd /path/to/master/
$ echo book > .gitignore

Başarısız Deneme # 5 - klon

Kitap dizinini ana klasöre aşağıdaki gibi eklendi:

$ cd /path/to/master/
$ rm -rf book
$ git clone https://user@bitbucket.org/user/repo.git book

Soru

bookAlt modül , havuzun altındaki kendi depo dizininde nasıl olabilir ve masteryine de git bookalt modülü yoksayabilir ? Yani, aşağıdakiler görüntülenmemelidir:

#
#       modified:   book (new commits)
#

git statusAna depoda çalıştırılırken bu mesaj nasıl bastırılır ?

Git submodule tuzaklarıyla ilgili bir makale , bunun uygunsuz bir alt modül kullanımı olduğunu gösteriyor?


3
Depoyu başka bir deponun belirli bir sürümüne bağlamak ve bunun kaydını tutmak istiyorsanız normalde alt modülleri kullanırsınız. Ama bu istediğin gibi görünmüyor. Bir depoyu başka birinin içinde izlemeden kullanmak istiyorsunuz. O zaman onu bir alt modül olarak eklemeyin.
Felix Kling

@FelixKling, bu tür depoları bu şekilde eklerseniz ve GitHub'a gönderirseniz, bu klasörlerin içeriğini kopyalamadan sadece bağlantı oluşturur mu?
Roman Bekkiev

@Roland: Alt modüller, başka bir deponun sürümüne referans olan dosyalardır. Deponun yerel bir kopyasında başlatıldıklarında, deponun gerçek içeriği ile değiştirilirler.
Felix Kling

2
"
İgnore

1
Git 2.13 (Q2 2017) ile düşünebileceksiniz git config submodule.<name>.active false. Aşağıdaki cevabımı
VonC

Yanıtlar:


60

Süper deposunda izlenmesi gerekmeyen başka bir depoyu dahil etmek için şunu deneyin:

$ cd /path/to/master/
$ rm -rf book
$ git clone https://user@bitbucket.org/user/repo.git book
$ git add book
$ echo "book" >> .gitignore

Sonra taahhüt edin.

Bağlantılı git alt modülü tuzakları makalesinde belirtildiği gibi :

... üst ve alt modül arasındaki tek bağlantı, alt modülün teslim alınmış SHA'sının üst öğenin taahhütlerinde depolanan kayıtlı değeridir.

Bu, bir alt modülün teslim alınan dalı veya etiketi tarafından değil, her zaman belirli bir kaydetme tarafından kaydedildiği anlamına gelir; bu commit (SHA) normal bir metin dosyası gibi süper depoya (alt modülü içeren) kaydedilir (elbette böyle bir referans olarak işaretlenir).

Alt modülde farklı bir kaydı kontrol ettiğinizde veya içinde yeni bir kayıt yaptığınızda, süper depo, teslim alınan SHA'nın değiştiğini görecektir. İşte o zaman modified (new commits)hattı alıyorsun git status.

Bunu ortadan kaldırmak için şunlardan birini yapabilirsiniz:

  • git submodule update, alt modülü şu anda süper depoda kayıtlı olan işleme sıfırlayacak (ayrıntılar için git submodulekılavuz sayfasına bakın ; veya
  • git add book && git commit Yeni SHA'yı süper depoya kaydetmek için.

Yorumlarda belirtildiği gibi, bookalt modülü terk etmeyi düşünün : süper reponun bir parçası olarak durumunun izlenmesi gerekli değilse, onu süper repo içinde klonlayın.


3
Vay canına, şimdi anlıyorum, süpermodülün neden alt modülün sürümünü bilmesi gerektiğini anladım . Tabii ki yapmak mantıklı git add book && git commit. Git'in aslında iki deponun senkronize olmasını sağlayabileceğinin farkında değildim.
Sergey Orshanskiy

103

Sadece koş:

$ git submodule update

Bu, ana depoyu alt modülün en son sürümüyle güncellemeden, alt modülü eski yürütmeye (ana depoda belirtilen) döndürür.


6
Hayır değil, durumu değiştirmeyecek.
Ed Bishop

Neden tam OP isteyeyim değil son var bookdepo? Cevabınızın bu bağlamda mantıklı olduğunu sanmıyorum.
Alexis Wilke

@AlexisWilke ve kitap arayüzü önemli ölçüde değişirse ve OP'nin ana depoda değişiklik yapmak için zamanı yoksa?
Logman

Bu aradığım cevap!
LLSv2.0

21

Bastırabileceğiniz iki tür değişiklik bildirimi vardır (1.7.2'ye gidin).

İlki, alt modülünüzde değişiklik yaptığınızda ancak bunları henüz işlemediğinizde gerçekleşen izlenmeyen içeriktir. Ana depo bunları fark eder ve git durumu buna göre raporlar:

modified: book (untracked content)

Bunları şu şekilde bastırabilirsiniz:

[submodule "book"]
    path = modules/media
    url = https://user@bitbucket.org/user/repo.git
    ignore = dirty

Ancak, bu değişiklikleri gerçekleştirdiğinizde, ana bilgi havuzu bir kez daha fark edecek ve bunları uygun şekilde raporlayacaktır:

modified:   book (new commits)

Bunları da bastırmak istiyorsanız, tüm değişiklikleri görmezden gelmelisiniz.

[submodule "book"]
    path = book
    url = https://user@bitbucket.org/user/repo.git
    ignore = all

ignore = allTüm alt modüllere seçenek eklediğimi hayal edin . Sonunda bazı modüllerin itilen yeni taahhütleri vardır. Eğer birisi o zaman süper repo klonlarsa, bu alt modüllerin eski durumunda mı olur yoksa en sonuncularını kontrol eder mi?
FelikZ

Komutla git clone --recursive git@...sen Altmodüllerin eski halini alacak. Bunları güncellemek için git submodule foreach "git pull"klonlamadan sonraki gibi bir şeye ihtiyacınız olacak
greuze

1
Ne yazık ki, ignore = allseçenek alt modülün yeni işlemlerini göz ardı etmez. Git 1.7.1 sürümünü çalıştırıyorum. Herhangi bir fikir yolu?
Romulus

10

Git 2.13 (Q2 2017), ana deposu tarafından izlenmesi gerekmeyen bir alt modülü eklemek için başka bir yol ekleyecek.

OP durumunda:

git config submodule.<name>.active false

Bkz 1b614c0 işlemek , 1f8d711 işlemek , bb62e0a işlemek , 3e7eaed tamamlama , a086f92 tamamlama (17 Mar 2017) ve ee92ab9 işlemek , 25b31f1 işlemek , e7849a9 işlemek , 6dc9f01 işlemek , 5c2bd8b tamamlama tarafından (2017 16 Mar) Brandon Williams ( mbrandonw) .
( Junio ​​C Hamano ile birleştirildi - gitster- in commit a93dcb0 , 30 Mar 2017)

submodule: url ve alt modül ilgisini ayır

Şu anda submodule.<name>.urlyapılandırma seçeneği, belirli bir alt modülün kullanıcının ilgisini çekip çekmediğini belirlemek için kullanılmaktadır. Bu, farklı alt modüllerin farklı çalışma ağaçlarında kontrol edilmesini istediğimiz bir dünyada veya hangi alt modüllerin ilgi çekici olduğunu seçmek için daha genelleştirilmiş bir mekanizma olmasını istediğimiz bir dünyada sonuçlanır.

Altmodüller için çalışma ağacı desteğinin olduğu bir gelecekte, her biri yalnızca alt modüllerin bir alt kümesinin kontrol edilmesini gerektirebilecek birden fazla çalışan ağaç olacaktır.
URL (alt modül havuzunun elde edilebildiği yer) farklı çalışan ağaçlar arasında farklılık göstermemelidir.

Ayrıca, kullanıcıların git submodule init <path>çalışma ağacında teslim almak istedikleri her alt modül üzerinde " " çalıştırmanın tersine, ilgilendikleri alt modül gruplarını daha kolay belirtmeleri de uygun olabilir .

Bu amaçla iki yapılandırma seçeneği tanıtılır submodule.activeve submodule.<name>.active.

  • submodule.activeYapılandırma altmodüller çalışma ağacında bulunmalıdır belirtir hangi bir pathspec tutar.
    • submodule.<name>.activeYapılandırma söz konusu alt modülü çalışma ağacında mevcut gerekip gerekmediğini belirtmek için kullanılan bir Boole bayrağıdır.

submodule.activeYol belirtimi aldığı için diğer yapılandırma seçeneklerinden farklı çalıştığına dikkat etmek önemlidir .
Bu, kullanıcıların en az iki yeni iş akışını benimsemelerine olanak tanır:

  1. Alt modüller önde gelen bir dizinle gruplandırılabilir, öyle ki bir yol belirtimi, örneğin ' lib/', kitaplık benzeri modüller ile ilgilenenlerin submodule.active = lib/herhangi bir ve ' lib/' içindeki tüm modüller için sadece bir kez " " ayarlamasına izin vermek için tüm kitaplık benzeri modülleri kapsayacaktır. ilginç.
  2. Yol-öznitelik özelliği icat edildiğinde, kullanıcılar alt modülleri gruplamak için özniteliklerle etiketleyebilirler, böylece öznitelik gereksinimlerine sahip geniş bir yol belirtimi :(attr:lib), " lib" özniteliğine sahip tüm modülleri ve tüm modülleri söylemek için kullanılabilir .
    Yana .gitattributesdosyası, tıpkı .gitmodulessuperproject ağacında bir alt modül hamle, proje içinde niteliğini alır hangi yolu ayarlayabilirsiniz zaman dosyaya, superproject tarafından izlenen .gitattributesiçeri submodule olan yolu ayarlayabilirsiniz gibi, .gitmodules.

<name>Mevcut bir projede bir alt modül için tam olarak nasıl bulunur ?
ideasman42

@ ideasman42 .gitmodules'deki yapılandırmayı okumak yardımcı olabilir: stackoverflow.com/a/12641787/6309
VonC

Ah bu sadece değer .git/config ->[submodule "<name>"]
ideasman42

1
Benim için çalışmıyor. İşte yaptığım şey: 1) --recursive ile git clone; 2) git config'i yanıt olarak ayarlayın; 3) git checkout yapın, son submodule checkout için git pull; Yine de "(yeni taahhütler)" alın.
Wu Baiquan

2
@VonC Size mesaj göndermeden önce, her ikisini de denedim (mevcut repo ve yeni başlatılmış repo ile), her iki durumda da işe yaramadı.
Porcupine

3

Nevik Rehnel'in cevabı kesinlikle sorduğunuz şey için doğru cevap: Bir alt modül sahibi olmak istemedim, bu durumdan nasıl kurtulabilirim ?! .

Yalnızca, masterprojeniz bookalt modülü gerektiriyorsa , onu böyle tutmak güzel bir jesttir, çünkü bu şekilde projenizi kontrol eden diğer kullanıcılar gitçalıştırmak için herhangi bir özel komuta sahip olmamanın keyfini çıkarabilirler (pekala ... kullanmak için bazı özel komutlar vardır. alt modüller, ancak genel olarak yönetmesi hala daha kolay.)

Sizin durumunuzda, bookarşivde değişiklikler yaparsınız ve bir noktada bu değişiklikleri gerçekleştirirsiniz. Bu araçlar sahip yeni hareketin yeni bir SHA1 referansı olduğunu alt modülün.

Ana dizinde yapmanız gereken, bu değişiklikleri ana depoda uygulamaktır.

cd /path/to/master
git commit . -m "Update 'book' in master"

Bu, SHA1 referansını arşivde masterbulunan en yeni sürüme güncelleyecektir book. Sonuç olarak, bu kesinleştirme, diğerlerinin uçtaki tüm master& bookdepoları kontrol etmesine izin verir .

Yani aslında bir alt modülde her değişiklik yaptığınızda bir işlem daha elde edersiniz. masterDepodaki bazı dosyalarda değişiklik yaparsanız, ikisini de aynı anda işleyeceğiniz için yarı şeffaftır .


-5

Çalıştırmak

git submodule update 

kök seviyesinde.


Sadece merak eden herkes için. Benim durumumda (ve OP'ler?), Bu git statussöylenenleri değiştirmez . Hâlâ değişikliklerin olduğunu düşünüyor.
squarism

Başkalarının yanıtlarını klonlamak çok kötü bir uygulama
Maxim
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.