Differenze tra git remote update e fetch?

È git remote updatel'equivalente di git fetch?

AGGIORNAMENTO: maggiori informazioni!

Avrei dovuto farlo dall'inizio: ho inserito le note di rilascio di Git nel repository Git's Git (quindi meta!)

grep --color=always -R -C30 fetch Documentation/RelNotes/* | less

Poi ho fatto una lessricerca --alle questo è quello che ho trovato nelle note di rilascio di Git versione 1.6.6 :

git fetchappreso --alle --multipleopzioni, per eseguire il recupero da molti repository e l' --pruneopzione per rimuovere i rami di tracciamento remoti che sono diventati obsoleti. Questi rendono git remote updatee git remote prunemeno necessari (non vi è alcun piano da rimuovere remote updatené remote prune, però).

La versione 1.6.6 non è stata rilasciata fino al 23 dicembre 2009 e il Poster originale ha posto la sua domanda il 6 dicembre 2009.

Quindi, come puoi vedere dalle note di rilascio, gli autori di Git erano consapevoli del fatto che la git remote updatefunzionalità del comando era stata in qualche modo duplicata git fetch, ma hanno deciso di non rimuoverlo, forse per compatibilità con gli script e i programmi esistenti, o forse perché è troppo lavoro e ci sono elementi con priorità più alta.

Risposta originale con maggiori dettagli

La risposta di xenoterracide ha ormai 3,5 anni e Git ha passato diverse versioni da allora (è passato dalla v1.6.5.5 alla v1.8.3.2 al momento della stesura di questo documento), e guardando la documentazione corrente per git remote updatee git fetch, sembra come se entrambi potessero svolgere sostanzialmente la stessa funzione di recuperare nuovi commit da più telecomandi , date le giuste opzioni e argomenti.

Recupero di tutti i telecomandi

Un modo per recuperare più telecomandi è con la --allbandiera:

git fetch --all

Questo verrà recuperato da tutti i telecomandi configurati, supponendo che non li abbia remote.<name>.skipFetchAllimpostati:

Se vero, questo telecomando verrà ignorato di default quando si aggiorna usando git-fetch (1) o il sottocomando update di git-remote (1) . - documentazione git-config

Questo sarebbe equivalente all'utilizzo

git remote update

senza specificare alcun gruppo remoto da recuperare, e anche non aver remotes.defaultimpostato nella configurazione del repository, e anche che nessuno dei telecomandi è remote.<name>.skipDefaultUpdateimpostato su true.

L' attuale documentazione 1.8.3.2 per la configurazione di Git non menziona l' remotes.defaultimpostazione, ma ho consultato l'Onnipotente Google e ho trovato questa utile spiegazione da Mislav Marohnić :

$ git config remotes.default 'origin mislav staging'
$ git remote update

# fetches remotes "origin", "mislav", and "staging"

È possibile definire un elenco predefinito di telecomandi che devono essere recuperati dal remote updatecomando. Questi possono essere telecomandi dei tuoi compagni di squadra, membri della comunità fidati di un progetto opensource o simili.

Quindi presumibilmente, se hai remotes.defaultimpostato, e non tutti i telecomandi sono elencati in esso, allora git remote updatenon recupererai tutti i telecomandi di cui il tuo repository è "consapevole".

Per quanto riguarda l' remote.<name>.skipDefaultUpdateimpostazione, i documenti Git lo spiegano così:

Se vero, questo telecomando verrà ignorato di default quando si aggiorna usando git-fetch (1) o il sottocomando update di git-remote (1) .

Recupero di un gruppo specificato di telecomandi

Invece di recuperare tutti i telecomandi, entrambi fetche remote updateconsentono di specificare più telecomandi e gruppi di telecomandi da recuperare:

git fetch [<options>] <group>
git fetch --multiple [<options>] [(<repository> | <group>)…]

git fetch [<options>] <group>consente di recuperare più telecomandi che fanno parte di un gruppo (per prendere in prestito un altro esempio da Mislav ):

$ git config remotes.mygroup 'remote1 remote2 ...'
$ git fetch mygroup

git fetch --multipleconsente di specificare diversi repository e gruppi di repository da recuperare contemporaneamente (dai documenti ):

Consentire diversi <repository>e <group>gli argomenti da specificare. No <refspec>spuò essere specificato.

Ambiguità nella git remote updatedocumentazione

La sinossi pergit remote update specifica che la sintassi del comando è la seguente:

git remote [-v | --verbose] update [-p | --prune] [(<group> | <remote>)…]

Notare l'ultima parte [(<group> | <remote>)…],? I punti finali ...implicano che puoi specificare più gruppi e telecomandi con il comando, il che significherebbe che si comporta allo stesso modo di git fetch --multiple... vedi come la sintassi tra i due è così simile?

Tuttavia, nello stesso documento, la spiegazione del updatecomando non dice nulla sulla specifica di più gruppi e argomenti remoti, solo che

Scarica gli aggiornamenti per un set denominato di telecomandi nel repository come definito da remotes.<group>.

Quindi non è chiaro se git remote updatefunziona in modo identico per git fetch --multiplequanto riguarda la specifica di più telecomandi individuali e più gruppi remoti.

Recupero di un singolo telecomando

Infine, tutti conoscono il semplice caso di recuperare un singolo telecomando:

git fetch <remote>

Potrebbe essere il caso che tu possa anche usare

git remote update <remote>

per fare la stessa cosa, ma come ho detto nella sezione precedente, la documentazione per git remote updatenon è chiara sul fatto che sia possibile recuperare qualsiasi cosa diversa da un singolo gruppo di telecomandi con il comando.

Incartare

Come ho spiegato, git fetche si git remote updatecomportano in modo simile per quanto riguarda il recupero da più telecomandi. Condividono sintassi e argomenti simili, anche se git fetchè più breve, quindi le persone probabilmente trovano più facile digitare e usare.

Può essere il caso che git remote updatenon può essere utilizzato per recuperare un solo telecomando come con git fetch, ma come ho sottolineato, la documentazione non lo chiarisce.

A parte

La duplicazione delle funzionalità tra i comandi Git di porcellana, esemplificata da git fetche git remote updatesopra, non è unica. Ho notato una situazione simile con git rebase --ontoe git cherry-pick, in quanto entrambi possono richiedere una serie di commit per applicare un nuovo commit di base.

Immagino che, man mano che Git si è evoluto nel corso degli anni, alcune funzionalità sono state (inevitabilmente?) Duplicate, forse a volte per comodità degli utenti finali (ad esempio, è più semplice passare un intervallo a cherry-pick, piuttosto che passare un singolo commit più e più volte) per scegliere un intervallo). Apparentemente cherry-picknon ha sempre accettato una serie di commit, come spiegato nelle note sulla versione v1.7.2 :

git cherry-pickimparato a scegliere una serie di commit (es. cherry-pick A..Be cherry-pick --stdin), così ha fatto git revert; questi, tuttavia, non supportano il migliore controllo del sequenziamento rebase [-i].

Sì e no. git remote updaterecupera da tutti i telecomandi, non solo uno.

Senza guardare il codice per vedere se remote updateè solo uno script di shell (possibile), fondamentalmente, esegue il recupero per ogni telecomando. git fetchpuò essere molto più granulare.