Il sottomodulo git ha "nuovi commit" quando eseguo il checkout del master

Question

Ho un sottomodulo chiamato Helpers. Quando clono il mio progetto principale con --recursive, il sottomodulo Helpers è in uno stato di testa distaccato (come dicono tutti i tutorial dovrebbe essere). Se adesso 'git status' nella directory principale del progetto, tutto è pulito. Se metto in aiuto gli Helpers; git checkout master ', mi aspetterei che non cambi nulla tranne che ora sono su un ramo con nome a cui posso impegnarmi. Comunque, senza fare altro, se io 'cd ..; git status ', vedo

modified: Helpers (new commits) 

Perché pensa che ci siano nuovi commit? Il sottomodulo dovrebbe essere ancora allo stesso punto di quando è stato aggiornato (in questo caso, clonato), no?

Answer 1

Se il HEAD del proprio submodulo non corrisponde al commit specificato nell'indice del repository principale, git vi darà il messaggio "new commits". È possibile controllare che impegnano specificato nell'indice eseguendo git ls-tree:

$ git ls-tree master:<path_to_folder_containing_my_submodule> 
160000 commit ba9d11670daf5109a52e5a2b01bca8a344897338 my_submodule 

Quando si esegue un clone git ricorsiva, git preleverà la più recente e quindi puntare HEAD per il commit specificato. Se il commit specificato non corrisponde all'ultimo commit nel master remoto, allora master non sarà uguale a HEAD durante la clonazione.

Un altro modo per controllare dopo aver fatto un clone ricorsiva è quello di cd nel vostro modulo e quindi utilizzare git log:

$ git log --decorate --all 
commit 6a75034cc78fc637e2437bba9f5834835f56bd8f (origin/master, origin/HEAD, master) 
... 
commit ba9d11670daf5109a52e5a2b01bca8a344897338 (HEAD) 

Se HEAD e master puntano alla stessa impegnarsi allora è possibile verifica padrone e non sarà vedere il messaggio "nuovi commit" nel repository padre.

Answer 2

Quello che probabilmente sta succedendo è che il master del sottomodulo non è la versione richiesta dal repository proprietario.

impostare il proprio modulo per la versione che il repo tenendo vuole:

holding/ $ git submodule update 

Controllare lo SHA1 desiderata del modulo:

holding/ $ git submodule  # (1) 
<list of all submodules, with the desired SHA1> 

Verificare qual è il vostro modulo master:

holding/ $ cd sub 
holding/sub $ git checkout master 
holding/sub $ git log -1  # (2) 

Il numero SHA1 in (2) è uguale a quello visto in (1)? Se no, questo è il tuo problema. Qualcosa è accaduto nel master del sottomodulo, ma questi nuovi cambiamenti non sono stati inclusi nel repository.

Il repository di mantenimento mantiene un SHA1 come riferimento alla versione del sottomodulo da utilizzare. Se si verifica ulteriore sviluppo nel repository del sottomodulo, il repository di mantenimento mantiene la stessa versione, non aggiorna automaticamente il sottomodulo.

Se si esegue il checkout di una versione più recente (ad es. master) del sottomodulo e quindi si torna al repository di mantenimento, git status indica che è stato estratto un nuovo commit nel sottomodulo. Questo modifica del commit del sottomodulo corrente può essere impegnato nel repository di tenuta. Ciò aggiornerebbe la versione del sottomodulo da utilizzare con questo commit di holding.

---

Se si desidera continuare a lavorare sul modulo, dalla versione che il repo tenendo vuole, avrete bisogno di creare un nuovo ramo. master riflette lo sviluppo ulteriore nel repository del sottomodulo, quindi o lavori dal master (e includi sia questo ulteriore sviluppo che il tuo nuovo lavoro), oppure crei un nuovo ramo dalla testa staccata a cui si riferisce l'azienda.

Se si dovesse forzare master sulla testata staccata che si desidera tenere, cosa accadrebbe ai commit (ulteriore dev) che sono stati creati tra la testina staccata e master? Sarebbero persi. E cosa succederebbe la prossima volta che spingi il tuo spostato da master a origin? Ci sarebbe un conflitto dal momento che il tuo locale master avrebbe dovuto divergere da origin.