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

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?

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.

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