Wypychanie podmodułu Git

Jeśli zmodyfikuję podmoduł, czy mogę przesunąć zatwierdzenie z powrotem do źródła podmodułu, czy może to wymagać klonu? Jeśli klonuje, czy mogę przechowywać klon w innym repozytorium?

Podmoduł to nic innego jak klon repozytorium git w innym repozytorium z dodatkowymi metadanymi (wpis drzewa gitlink, plik .gitmodules)

$ cd your_submodule
$ git checkout master
<hack,edit>
$ git commit -a -m "commit in submodule"
$ git push
$ cd ..
$ git add your_submodule
$ git commit -m "Updated submodule"

Zauważ, że ponieważ git1.7.11 ( [ ANNOUNCE ] Git 1.7.11.rc1 i informacja o wydaniu , czerwiec 2012) wspomina:

" git push --recurse-submodules" nauczył się opcjonalnie zaglądać do historii podmodułów związanych z superprojektem i wypychać je.

Prawdopodobnie zrobione po tym patchu i --on-demandopcji:

recurse-submodules=<check|on-demand>::

Upewnij się, że wszystkie zatwierdzenia podmodułów używane przez publikowane wersje są dostępne w gałęzi zdalnego śledzenia.

• Jeśli checkjest używany, zostanie sprawdzone, czy wszystkie zatwierdzenia podmodułów, które uległy zmianie w wersjach do przesłania, są dostępne na pilocie.
  W przeciwnym razie wypychanie zostanie przerwane i zakończone ze statusem niezerowym.
• Jeśli on-demandjest używany, wszystkie podmoduły, które uległy zmianie w wersjach do przekazania, zostaną wypchnięte.
  Jeśli na żądanie nie był w stanie przesłać wszystkich niezbędnych wersji, zostanie również przerwany i zakończony z niezerowym statusem.

Możesz więc przesłać wszystko za jednym razem (z repozytorium nadrzędnego) a:

git push --recurse-submodules=on-demand

Ta opcja działa tylko dla jednego poziomu zagnieżdżenia. Zmiany w module podrzędnym w innym module podrzędnym nie będą wprowadzane.

Z git 2.7 (styczeń 2016), proste wypychanie git wystarczy, aby wypchnąć repozytorium nadrzędne ... i wszystkie jego moduły podrzędne.

Zobacz commit d34141c , commit f5c7cd9 (03 grudnia 2015), commit f5c7cd9 (03 grudnia 2015) i commit b33a15b (17 listopada 2015) autorstwa Mike Crowe ( mikecrowe) .
^{(Scalone przez Junio ​​C Hamano - gitster- w zatwierdzeniu 5d35d72 , 21 grudnia 2015 r.)}

push: dodaj recurseSubmodulesopcję konfiguracji

--recurse-submodulesParametr linii poleceń istniejący od pewnego czasu, ale to nie ma odpowiednika plik konfiguracyjny.

Podążając za stylem odpowiedniego parametru for git fetch, wymyślmy push.recurseSubmoduleswartość domyślną dla tego parametru.
Wymaga to również dodania, --recurse-submodules=noaby umożliwić zastąpienie konfiguracji w wierszu poleceń, gdy jest to wymagane.

Wydaje się, że najprostszym sposobem implementacji tego jest pushużycie kodu w submodule-configpodobny sposób jak fetch.

Dokument git configzawiera teraz :

push.recurseSubmodules:

Upewnij się, że wszystkie zatwierdzenia podmodułów używane przez publikowane wersje są dostępne w gałęzi zdalnego śledzenia.

• Jeśli wartość to „ check”, Git sprawdzi, czy wszystkie zatwierdzenia podmodułów, które uległy zmianie w wersjach do przekazania, są dostępne na co najmniej jednym zdalnym module podrzędnym. Jeśli brakuje jakichkolwiek zatwierdzeń, wypychanie zostanie przerwane i zakończone ze statusem niezerowym.
• Jeśli wartość to „ on-demand”, wszystkie podmoduły, które uległy zmianie w wersjach do przekazania, zostaną wypchnięte. Jeśli na żądanie nie był w stanie przesłać wszystkich niezbędnych wersji, zostanie również przerwany i zakończony z niezerowym statusem. -
• Jeśli wartość to „ no”, to domyślne zachowanie polegające na ignorowaniu modułów podrzędnych podczas wypychania jest zachowywane.

Możesz zmienić tę konfigurację w momencie wypychania, określając „ --recurse-submodules=check|on-demand|no”.

Więc:

git config push.recurseSubmodules on-demand
git push

Git 2.12 (I kwartał 2017)

git push --dry-run --recurse-submodules=on-demand faktycznie zadziała.

Zobacz zatwierdzenie 0301c82 , zatwierdzenie 1aa7365 (17 listopada 2016 r.) Autorstwa Brandona Williamsa ( mbrandonw) .
^{(Scalone przez Junio ​​C Hamano - gitster- w zatwierdzeniu 12cf113 , 16 grudnia 2016 r.)}

push run with --dry-runw rzeczywistości (Git 2.11 grudzień 2016 i niższy / wcześniej) nie wykonuje próby uruchomienia, gdy push jest skonfigurowany do wysyłania podmodułów na żądanie.
Zamiast tego wszystkie podmoduły, które muszą zostać przesłane, są faktycznie wypychane do ich pilotów, podczas gdy wszelkie aktualizacje superprojektu są wykonywane jako próba uruchomienia.
Jest to błąd, a nie zamierzone zachowanie podczas próbnego przebiegu.

Naucz pushrespektować --dry-runopcję, gdy jest skonfigurowana do rekurencyjnego wypychania podmodułów „na żądanie”.
Odbywa się to poprzez przekazanie --dry-runflagi procesowi potomnemu, który wykonuje wypychanie podmodułów podczas wykonywania testu na sucho.

I nadal w Git 2.12 masz teraz --recurse-submodules=onlyopcję " " wypychania podmodułów bez wypychania superprojektu najwyższego poziomu .

Zobacz commit 225e8bf , commit 6c656c3 , commit 14c01bd (19 grudnia 2016) autorstwa Brandona Williamsa ( mbrandonw) .
^{(Scalone przez Junio ​​C Hamano - gitster- w zatwierdzeniu 792e22e , 31 stycznia 2017 r.)}