Apakah aman untuk melakukan clone dangkal dengan --depth 1, membuat commit, dan menarik pembaruan lagi?


280

The --depth 1pilihan di git clone:

Buat klon dangkal dengan riwayat terpotong ke jumlah revisi yang ditentukan. Repositori dangkal memiliki sejumlah keterbatasan (Anda tidak dapat mengkloning atau mengambil darinya, atau mendorong dari atau ke dalamnya), tetapi cukup jika Anda hanya tertarik pada sejarah baru-baru ini dari proyek besar dengan sejarah panjang, dan ingin kirim perbaikan sebagai tambalan.

Tapi saya telah berhasil melakukan klon dangkal, melakukan beberapa perubahan dan mendorong perubahan itu kembali ke asal (bare clone).

Masuk akal bagi saya - maksud saya mengapa tidak? ketika KEPALA hasil kloning dapat diidentifikasi asal, dan komit saya datang di atas ini, sepertinya tidak ada alasan. Namun manual mengatakan sebaliknya.

Saya suka ide kloning dangkal - misalnya inti drupal: tidak ada cara saya perlu tahu apa yang terjadi di drupal 4 ketika saya mulai dari 7. - tapi saya tidak ingin menembak diri sendiri di kaki.

Jadi apakah aman untuk melakukan dangkal klon, mengembangkan komitmen di dalamnya, menarik lagi untuk mengikuti pembaruan dari asal?


13
Berikut adalah diskusi yang layak tentang kedalaman klon
Andy

Ya, saya juga sudah membacanya, terima kasih Andy. yang --orphankonsep tampaknya mirip dan saya berniat untuk memiliki bermain. Masih agak kaget bahwa dokumen tidak cocok dengan kenyataan [karena siapa yang mengatakan dokumen --orphanitu benar ?!]
artfulrobot

Temukan diskusi hebat lainnya tentang bekerja dengan sejarah yang terpotong . Tapi itu tidak membantu saya.
artfulrobot

1
Git 1.9 (Q1 2014) akan sepenuhnya mendukung kloning repo dangkal! Lihat jawaban saya di bawah ini
VonC

1
Git 2.5 (Q2 2015) mendukung komit pengambilan tunggal! Saya telah mengedit jawaban saya, merujuk " Tarik komit tertentu dari repositori git jarak jauh ".
VonC

Jawaban:


304

Perhatikan bahwa Git 1.9 / 2.0 (Q1 2014) telah menghapus batasan itu.
Lihat commit 82fba2b , dari Nguyễn Thái Ngọc Duy ( pclouds) :

Sekarang git mendukung transfer data dari atau ke klon yang dangkal, keterbatasan ini tidak berlaku lagi.

The dokumentasi sekarang berbunyi :

--depth <depth>::

Buat klon 'dangkal' dengan riwayat terpotong ke jumlah revisi yang ditentukan.

Itu berasal dari commit seperti 0d7d285 , f2c681c , dan c29a7b8 yang mendukung klon, kirim-bungkus / terima-bungkus dengan / dari klon dangkal.
smart-http sekarang mendukung pengambilan dangkal / klon juga .

Semua detail ada di " shallow.c: 8 langkah untuk memilih komit baru untuk.git/shallow ".

Pembaruan Juni 2015: Git 2.5 bahkan akan memungkinkan untuk mengambil satu komit !
(Kasing dangkal)


Pembaruan Januari 2016: Git 2.8 (Mach 2016) sekarang mendokumentasikan secara resmi praktik mendapatkan sejarah minimal.
Lihat komit 99487cf , komit 9cfde9e (30 Des 2015), komit 9cfde9e (30 Des 2015), komit bac5874 (29 Des 2015), dan komit 1de2e44 (28 Des 2015) oleh Stephen P. Smith (``) .
(Digabung oleh Junio ​​C Hamano - gitster- dalam komit 7e3e80a , 20 Jan 2016)

Ini " Documentation/user-manual.txt"

A <<def_shallow_clone,shallow clone>>dibuat dengan menentukan git-clone --depthsakelar.
Kedalaman nanti dapat diubah dengan git-fetch --depthsakelar, atau riwayat lengkap dipulihkan dengan --unshallow.

Penggabungan di dalam <<def_shallow_clone,shallow clone>>akan bekerja selama basis penggabungan ada dalam sejarah baru-baru ini.
Kalau tidak, itu akan seperti menggabungkan sejarah yang tidak terkait dan mungkin harus mengakibatkan konflik besar.
Batasan ini dapat membuat repositori seperti itu tidak cocok untuk digunakan dalam alur kerja berbasis gabungan.

Pembaruan 2020:

  • git 2.11.1 opsi yang diperkenalkan git fetch --shallow-exclude=untuk mencegah pengambilan semua riwayat
  • git 2.11.1 opsi yang diperkenalkan git fetch --shallow-since=untuk mencegah pengambilan commit lama.

Untuk lebih lanjut tentang proses pembaruan klon dangkal, lihat " Cara memperbarui git clone dangkal? ".


Seperti yang dikomentari oleh Richard Michael :

untuk mengisi ulang sejarah: git pull --unshallow

Dan Olle Härstedt menambahkan dalam komentar :

Untuk pengurukan bagian dari sejarah: git fetch --depth=100.


3
Begitu banyak teks hanya untuk mengatakan " ya , selama versi git Anda belum berumur 4+ tahun dan basis penggabungan ada dalam sejarah baru-baru ini"
Boris

3
@Boris jawaban ini banyak membantu saya karena saya skeptis menggunakan klon dangkal. Sebelumnya terkadang rusak ketika saya melakukan komit dan penggabungan. jawaban ini adalah sejarah singkat, mengapa sekarang bekerja ketika itu terjadi, dan bagaimana melakukannya dengan benar.
Yana Agun Siswanto

6

Lihat beberapa jawaban untuk pertanyaan saya yang sama mengapa-cant-i-push-from-a-shall-clone dan tautan ke utas terbaru di daftar git.

Pada akhirnya, pengukuran 'kedalaman' tidak konsisten di antara repo, karena mereka mengukur dari masing-masing KEPALA, daripada (a) Kepala Anda, atau (b) komit yang Anda kloning / ambil, atau (c) sesuatu yang lain Anda ada dalam pikiran.

Bagian yang sulit adalah menggunakan Use Case seseorang dengan benar (mis. Konsisten sendiri), sehingga didistribusikan, dan karenanya repo yang mungkin berbeda akan tetap bekerja dengan bahagia bersama.

Memang terlihat seperti checkout --orphanini adalah tahap 'set-up' yang tepat, tetapi masih kurang bersih (yaitu perintah satu baris yang mudah dimengerti) pada langkah "clone". Alih-alih sepertinya Anda harus initrepo, membuat remotecabang pelacakan (Anda ingin satu cabang saja?), Dan kemudian fetchcabang tunggal itu, yang terasa panjang lebar dengan lebih banyak peluang untuk kesalahan.

Sunting: Untuk langkah 'klon' lihat jawaban ini


1
Tank Philip. Mengambil cabang jarak jauh masih akan menarik seluruh sejarah (AFAIK). Anda benar tentang kedalaman relatif, sungguh saya ingin titik yang cocok dalam sejarah (seperti git merge-base 7.x 7.0 dalam kasus saya)
artfulrobot

@artfulrobot: metode '--orphan' memungkinkan Anda membuat 'klon' sempit pendek (yaitu segmen yang difokuskan) dan kemudian menggunakannya seolah-olah itu adalah repo yang tepat. Itu adalah sesuatu yang belum saya coba dalam kemarahan, tetapi itu sesuatu yang perlu saya buktikan segera.
Philip Oakley
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.