Aggiorna il sottomodulo Git all'ultimo commit sull'origine

Ho un progetto con un sottomodulo Git. Viene da un URL ssh: // ... ed è in commit A. Commit B è stato inviato a tale URL e voglio che il sottomodulo recuperi il commit e lo cambi.

Ora, la mia comprensione è che git submodule updatedovrebbe farlo, ma non lo fa. Non fa nulla (nessun output, codice di uscita di successo). Ecco un esempio:

$ 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
$ ...

Ho anche provato git fetch mod, che sembra fare un fetch (ma non può assolutamente, perché non è che richiede una password!), Ma git loge git shownegare l'esistenza di nuovi commit. Finora ho appena rmaggiunto il modulo e aggiunto di nuovo, ma questo è sia sbagliato in linea di principio che noioso in pratica.

Il git submodule updatecomando in realtà dice a Git che vuoi che i tuoi sottomoduli controllino ciascuno il commit già specificato nell'indice del superprogetto. Se desideri aggiornare i tuoi sottomoduli all'ultimo commit disponibile dal loro telecomando, dovrai farlo direttamente nei sottomoduli.

Quindi in sintesi:

# 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"

Oppure, se sei una persona impegnata:

git submodule foreach git pull origin master

Git 1.8.2 presenta una nuova opzione --remote, che abiliterà esattamente questo comportamento. In esecuzione

git submodule update --remote --merge

recupererà le ultime modifiche dall'upstream in ciascun sottomodulo, le unirà e verificherà l'ultima revisione del sottomodulo. Come dice la documentazione :

--a distanza

Questa opzione è valida solo per il comando di aggiornamento. Invece di utilizzare lo SHA-1 registrato del superprogetto per aggiornare il sottomodulo, utilizzare lo stato del ramo di tracciamento remoto del sottomodulo.

Ciò equivale a funzionare git pullin ogni sottomodulo, che è generalmente esattamente quello che vuoi.

Nella directory principale del progetto, eseguire:

git submodule update --init

O se si eseguono sottomoduli ricorsivi:

git submodule update --init --recursive

A volte questo non funziona ancora, perché in qualche modo sono presenti modifiche locali nella directory del sottomodulo locale durante l'aggiornamento del sottomodulo.

Il più delle volte la modifica locale potrebbe non essere quella che desideri impegnare. Può succedere a causa della cancellazione di un file nel tuo sottomodulo, ecc. In tal caso, esegui un ripristino nella directory del sottomodulo locale e nella directory padre del progetto, esegui di nuovo:

git submodule update --init --recursive

Il tuo progetto principale punta a un impegno particolare a cui dovrebbe trovarsi il sottomodulo. git submodule updateprova a verificare quel commit in ogni sottomodulo che è stato inizializzato. Il sottomodulo è in realtà un repository indipendente: basta creare un nuovo commit nel sottomodulo e spingerlo non è sufficiente. È inoltre necessario aggiungere esplicitamente la nuova versione del sottomodulo nel progetto principale.

Quindi, nel tuo caso, dovresti trovare il commit giusto nel sottomodulo - supponiamo che sia la punta di master:

cd mod
git checkout master
git pull origin master

Ora torna al progetto principale, metti in scena il sottomodulo e commetti che:

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

Ora spingi la tua nuova versione del progetto principale:

git push origin master

Da questo punto in poi, se qualcun altro aggiorna il proprio progetto principale, allora git submodule updateper loro aggiornerà il sottomodulo, supponendo che sia stato inizializzato.

Sembra che in questa discussione si stiano mescolando due diversi scenari:

scenario 1

Utilizzando i puntatori del mio repository genitore ai sottomoduli, desidero controllare il commit in ciascun sottomodulo a cui punta il repository padre, possibilmente dopo aver prima iterato tutti i sottomoduli e aver aggiornato / estratto questi da remoto.

Questo, come sottolineato, è terminato

git submodule foreach git pull origin BRANCH
git submodule update

Scenario 2, che ritengo sia l'obiettivo del PO

Sono successe nuove cose in uno o più sottomoduli, e voglio 1) estrarre queste modifiche e 2) aggiornare il repository padre in modo da puntare al commit HEAD (più recente) di questo / questi sottomoduli.

Questo sarebbe fatto da

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

Non molto pratico, dal momento che dovresti hardcodificare n percorsi a tutti gli n sottomoduli in ad esempio uno script per aggiornare i puntatori di commit del repository principale.

Sarebbe bello avere un'iterazione automatica attraverso ogni sottomodulo, aggiornando il puntatore del repository padre (usando git add ) per puntare alla testa del sottomodulo / i.

Per questo, ho realizzato questo piccolo script Bash:

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

Per eseguirlo, esegui

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

Elaborazione

Prima di tutto, presumo che il ramo con nome $ BRANCH (secondo argomento) esista in tutti i repository. Sentiti libero di renderlo ancora più complesso.

La prima coppia di sezioni sta verificando che gli argomenti siano presenti. Quindi estraggo le ultime cose del repository principale (preferisco usare --ff (avanzamento rapido) ogni volta che sto solo facendo pull. Ho rebase off, BTW).

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

Quindi potrebbe essere necessario inizializzare un sottomodulo, se sono stati aggiunti nuovi sottomoduli o non sono ancora inizializzati:

git submodule sync
git submodule init
git submodule update

Quindi aggiorno / estraggo tutti i sottomoduli:

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

Nota alcune cose: prima di tutto, sto concatenando alcuni comandi Git usando &&- il che significa che il comando precedente deve essere eseguito senza errori.

Dopo un possibile pull riuscito (se sul telecomando sono state trovate nuove cose), faccio una spinta per garantire che un possibile merge-commit non venga lasciato indietro sul client. Ancora una volta, succede solo se un pull ha effettivamente portato nuove cose.

Infine, il finale || truesta assicurando che lo script continui sugli errori. Per far funzionare tutto ciò, nell'iterazione deve essere racchiuso tra virgolette doppie e i comandi Git sono racchiusi tra parentesi (precedenza dell'operatore).

La mia parte preferita:

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

Iterare tutti i sottomoduli - con --quiet, che rimuove l'output 'Entering MODULE_PATH'. Utilizzando 'echo $path'(deve essere tra virgolette singole), il percorso del sottomodulo viene scritto nell'output.

Questo elenco di percorsi relativi al sottomodulo viene acquisito in un array ( $(...)) - infine iterare questo e fare git add $iper aggiornare il repository padre.

Infine, un commit con qualche messaggio che spiega che il repository padre è stato aggiornato. Questo commit verrà ignorato per impostazione predefinita, se non è stato fatto nulla. Spingilo all'origine e il gioco è fatto.

Ho uno script che esegue questo in un lavoro Jenkins che in seguito si collega a una distribuzione automatica pianificata e funziona come un incantesimo.

Spero che questo possa essere d'aiuto a qualcuno.

Chiaro e semplice, per recuperare i sottomoduli:

git submodule update --init --recursive

E ora procedi ad aggiornarli all'ultimo ramo master (ad esempio):

git submodule foreach git pull origin master

Nota, mentre la forma moderna di aggiornamento del commit del sottomodulo sarebbe:

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

La forma più vecchia era:

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

Tranne ... questa seconda forma non è davvero "silenziosa".

Vedi commit a282f5a (12 apr 2019) di Nguyễn Thái Ngọc Duy ( pclouds) .
^{(Unita da Junio ​​C Hamano - gitster- in commit f1c9f6c , 25 apr 2019)}

submodule foreach: correzione " <command> --quiet" non rispettata

Robin l'ha riferito

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

non è più veramente silenzioso.
Dovrebbe essere silenzioso prima di fc1b924 ( submodule: submodulesottocomando di porta ' foreach' dalla shell a C, 2018-05-10, Git v2.19.0-rc0) perché parseoptnon può accidentalmente mangiare opzioni allora.

" git pull" si comporta come se--quiet non fosse dato.

Ciò accade perché parseoptin submodule--helpertenterà di analizzare entrambe le --quietopzioni come se fossero opzioni di foreach, non di opzioni git-pull.
Le opzioni analizzate vengono rimosse dalla riga di comando. Quindi, quando lo tiriamo più tardi, eseguiamo proprio questo

git pull origin

Quando si chiama l'helper del sottomodulo, l'aggiunta di " --" davanti a " git pull" si interromperà parseoptper le opzioni di analisi che non appartengono realmente submodule--helper foreach.

PARSE_OPT_KEEP_UNKNOWNviene rimosso come misura di sicurezza. parseoptnon dovrebbe mai vedere opzioni sconosciute o qualcosa è andato storto. Ci sono anche un paio di aggiornamenti sulla stringa di utilizzo mentre li sto guardando.

Mentre ci sono, aggiungo anche " --" ad altri sottocomandi che passano " $@" a submodule--helper. " $@" in questi casi sono percorsi e meno probabilità di esserlo --something-like-this.
Ma il punto è ancora valido, git-submoduleha analizzato e classificato quali sono le opzioni, quali sono i percorsi.
submodule--helpernon dovrebbero mai considerare i percorsi passati git-submodulecome opzioni anche se sembrano simili.

E Git 2.23 (3 ° trimestre 2019) risolve un altro problema: " git submodule foreach" non ha protetto le opzioni della riga di comando passate al comando per essere eseguite correttamente in ciascun sottomodulo, quando il "--recursive era in uso l'opzione ".

Vedi commit 30db18b (24 giu 2019) di Morian Sonnet ( momoson) .
^{(Unita da Junio ​​C Hamano - gitster- in commit 968eecb , 09 lug 2019)}

submodule foreach: risolve il problema della ricorsione delle opzioni

Calling:

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

porta a un errore che indica che l'opzione --<option>è sconosciuta submodule--helper.
Questo è ovviamente solo quando <option>non è un'opzione valida per git submodule foreach.

Il motivo di ciò è che la chiamata sopra è tradotta internamente in una chiamata a sottomodulo - helper:

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

Questa chiamata inizia eseguendo il sottocomando con la sua opzione all'interno del sottomodulo di primo livello e continua chiamando la successiva iterazione della submodule foreachchiamata

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

all'interno del sottomodulo di primo livello. Si noti che manca il doppio trattino davanti al sottocomando.

Questo problema inizia a manifestarsi solo di recente, poiché il PARSE_OPT_KEEP_UNKNOWNflag per l'analisi dell'argomento è git submodule foreachstato rimosso nel commit a282f5a .
Quindi, l'opzione sconosciuta è ora contestata, poiché l'argomento dell'analisi non è terminato correttamente dal doppio trattino.

Questo commit risolve il problema aggiungendo il doppio trattino davanti al sottocomando durante la ricorsione.

git pull --recurse-submodules

Questo tirerà tutti gli ultimi commit.

Nel mio caso, volevo gitaggiornare all'ultimo e allo stesso tempo ripopolare tutti i file mancanti.

Di seguito sono stati ripristinati i file mancanti (grazie ai --forcequali non sembra essere stato menzionato qui), ma non è stato eseguito alcun nuovo commit:

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

Questo ha fatto:

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

@Jason è corretto in un certo senso, ma non del tutto.

aggiornare

Aggiorna i sottomoduli registrati, ovvero clona i sottomoduli mancanti e verifica il commit specificato nell'indice del repository contenente. Questo farà staccare i sottomoduli HEAD a meno che non venga specificato --rebase o --merge o il sottomodulo chiave. $ Name.update è impostato su rebase o merge.

Quindi, git submodule updatefa il checkout, ma è per il commit nell'indice del repository contenente. Non è ancora a conoscenza del nuovo commit a monte. Quindi vai al tuo sottomodulo, ottieni il commit che desideri e impegna lo stato del sottomodulo aggiornato nel repository principale e quindi esegui git submodule update.

Ecco un fantastico one-liner per aggiornare tutto all'ultimo sul master:

git submodule foreach 'git fetch origin --tags; git checkout master; git pull' && git pull && git submodule update --init --recursive

Grazie a Mark Jaquith

Se non conosci il ramo host, procedi come segue:

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

Otterrà un ramo del repository Git principale e quindi per ogni sottomodulo farà un pull dello stesso ramo.

Se stai cercando di verificare il masterramo per ciascun sottomodulo, puoi utilizzare il seguente comando a tale scopo:

git submodule foreach git checkout master