Perbedaan antara git remote update dan fetch?

Apakah git remote updatesetara dengan git fetch?

UPDATE: informasi lebih lanjut!

Saya seharusnya melakukan ini dari awal: Saya mengambil catatan rilis Git di repo Git Git (jadi meta!)

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

Lalu saya melakukan lesspencarian --all, dan inilah yang saya temukan di bawah catatan rilis untuk Git versi 1.6.6 :

git fetchpelajari --alldan --multipleopsi, untuk menjalankan fetch dari banyak repositori, dan --pruneopsi untuk menghapus cabang pelacakan jarak jauh yang basi. Ini membuat git remote updatedan git remote prunekurang perlu (meskipun tidak ada rencana untuk menghapus remote updatejuga remote prune).

Versi 1.6.6 tidak dirilis hingga 23 Desember 2009 , dan Poster Asli mengajukan pertanyaannya pada 6 Desember 2009.

Jadi seperti yang Anda lihat dari catatan rilis, penulis Git menyadari fakta bahwa git remote updatefungsionalitas perintah digandakan oleh git fetch, tetapi mereka memutuskan untuk tidak menghapusnya, mungkin untuk kompatibilitas dengan skrip dan program yang ada, atau mungkin karena itu terlalu banyak pekerjaan dan ada item prioritas yang lebih tinggi.

Jawaban orisinal dengan lebih detail

Jawaban xenoterracide adalah 3,5 tahun sekarang, dan Git telah melalui beberapa versi sejak saat itu (sudah berubah dari v1.6.5.5 ke v1.8.3.2 pada saat tulisan ini dibuat), dan melihat dokumentasi saat ini untuk git remote updatedan git fetch, sepertinya seperti mereka berdua dapat melakukan fungsi yang sama pada dasarnya mengambil komit baru dari beberapa remote , diberikan opsi dan argumen yang tepat.

Mengambil semua remote

Salah satu cara untuk mengambil beberapa remote adalah dengan --allflag:

git fetch --all

Ini akan diambil dari semua remote yang dikonfigurasikan, dengan asumsi bahwa Anda belum remote.<name>.skipFetchAllmenyetelnya:

Jika benar, remote ini akan dilompati secara default ketika memperbarui menggunakan git-fetch (1) atau sub-perintah pembaruan git-remote (1) . - dokumentasi git-config

Ini akan setara dengan menggunakan

git remote update

tanpa menentukan grup jarak jauh mana saja yang akan diambil, dan juga tidak memiliki remotes.defaultset di konfigurasi repo Anda, dan juga bahwa tidak ada remote Anda yang remote.<name>.skipDefaultUpdatedisetel ke true.

The saat 1.8.3.2 dokumentasi untuk konfigurasi Git ini tidak menyebutkan remotes.defaultpengaturan, tapi saya berkonsultasi Yang Maha Kuasa Google tentang hal itu dan menemukan penjelasan ini bermanfaat dari Mislav Marohnić :

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

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

Anda dapat menentukan daftar remote remote yang akan diambil oleh remote updateperintah. Ini dapat berupa remote dari rekan satu tim Anda, anggota komunitas tepercaya dari proyek opensource, atau serupa.

Jadi mungkin, jika Anda telah remotes.defaultmenetapkan, dan tidak semua remote Anda terdaftar di dalamnya, maka git remote updatetidak akan mengambil semua remote yang repo Anda "sadari".

Adapun remote.<name>.skipDefaultUpdatepengaturan, dokumen Git menjelaskannya sebagai berikut:

Jika benar, remote ini akan dilompati secara default ketika memperbarui menggunakan git-fetch (1) atau sub-perintah pembaruan git-remote (1) .

Mengambil grup remote yang ditentukan

Alih-alih mengambil semua remote, keduanya fetchdan remote updatememungkinkan Anda menentukan beberapa remote dan grup remote untuk mengambil:

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

git fetch [<options>] <group>memungkinkan Anda untuk mengambil beberapa remote yang merupakan bagian dari grup (untuk meminjam contoh lain dari Mislav ):

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

git fetch --multiplememungkinkan Anda menentukan beberapa repositori dan grup repositori untuk diambil sekaligus (dari dokumen ):

Izinkan beberapa <repository>dan <group>argumen ditentukan. Tidak <refspec>sboleh ditentukan.

Ketidakjelasan dalam git remote updatedokumentasi

The sinopsis untukgit remote update menentukan bahwa sintaks perintah adalah sebagai berikut:

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

Perhatikan bagian terakhir [(<group> | <remote>)…],? Trailing dots ...menyiratkan bahwa Anda dapat menentukan beberapa grup dan mengirim ulang dengan perintah, yang akan berarti ia berperilaku dengan cara yang sama seperti git fetch --multiple... melihat bagaimana sintaks antara keduanya sangat mirip?

Namun, dalam dokumen yang sama, penjelasan untuk updateperintah tidak mengatakan apa-apa tentang menentukan beberapa argumen grup dan jarak jauh, hanya itu

Ambil pembaruan untuk set remote yang bernama dalam repositori seperti yang didefinisikan oleh remotes.<group>.

Jadi tidak jelas apakah git remote updateberfungsi identik git fetch --multipledengan menentukan beberapa remote individu dan beberapa grup jarak jauh.

Mengambil satu remote

Akhirnya, semua orang tahu kasus sederhana mengambil satu remote:

git fetch <remote>

Mungkin case yang bisa Anda gunakan juga

git remote update <remote>

untuk melakukan hal yang sama, tetapi seperti yang saya sebutkan di bagian sebelumnya, dokumentasi untuk git remote updatetidak jelas tentang apakah mungkin untuk mengambil apa pun selain satu kelompok remote dengan perintah.

Bungkus

Seperti yang telah saya jelaskan, git fetchdan git remote updateberperilaku serupa berkaitan dengan mengambil dari beberapa remote. Mereka berbagi sintaks dan argumen yang serupa, meskipun git fetchlebih pendek, sehingga orang mungkin merasa lebih mudah untuk mengetik dan menggunakan.

Mungkin ini adalah kasus yang git remote updatetidak dapat digunakan untuk mengambil hanya satu remote seperti git fetch, tetapi seperti yang saya tunjukkan, dokumentasi tidak memperjelas hal ini.

Ke samping

Duplikasi fungsi antara perintah porselen Git, dicontohkan oleh git fetchdan di git remote updateatas, tidak unik. Saya telah memperhatikan situasi yang sama dengan git rebase --ontodan git cherry-pick, di mana keduanya dapat mengambil berbagai komitmen untuk menambal ke komit basis baru.

Saya rasa Git telah berevolusi selama bertahun-tahun, beberapa fungsionalitas (pasti?) Diduplikasi, mungkin kadang-kadang sebagai kenyamanan bagi pengguna akhir (misalnya, lebih mudah untuk melewati rentang cherry-pick, daripada melewati satu komit berulang-ulang) untuk memilih rentang). Tampaknya cherry-picktidak selalu menerima serangkaian komitmen, seperti yang dijelaskan dalam catatan rilis v1.7.2 :

git cherry-pickbelajar memilih serangkaian komitmen (misalnya cherry-pick A..Bdan cherry-pick --stdin), begitu juga git revert; ini tidak mendukung kontrol urutan yang lebih baik rebase [-i].

Iya dan tidak. git remote updatemengambil dari semua remote, bukan hanya satu.

Tanpa melihat kode untuk melihat apakah remote updatehanya skrip shell (mungkin), pada dasarnya, berjalan ambil untuk setiap jarak jauh. git fetchbisa jauh lebih terperinci.