Kebiasaan Git yang Ikut Pindah Rumah ke jj

Hari kedua pakai jj di repo internal core kami, saya menjalankan squash --into ke sebuah commit. Perintahnya sukses, tidak ada error. Kontennya tidak pindah ke mana-mana. Setelah dicek, target yang saya tulis adalah hash yang saya salin lima menit sebelumnya, dan di antara lima menit itu ada rebase. Hash-nya sudah basi. Saya pulihkan dengan jj restore --from <commit lama>, lalu duduk sebentar.

jj-nya tidak salah. Tangan saya masih bekerja dengan logika git: commit itu benda mati, hash-nya alamat tetap. Di jj, yang stabil adalah change ID. Hash berubah setiap kali isinya ditulis ulang.

Kesalahan orang pindahan jarang soal lupa perintah. Lebih sering soal refleks yang ikut terbawa. Di bawah ini enam yang paling sering, disusun dari panduan LazyJJ plus apa yang saya injak sendiri.

1. Mutasi lewat git

Repo colocated punya .jj dan .git sekaligus, jadi git rebase atau git pull tetap jalan. Masalahnya, operasi itu tidak tercatat di op log jj. Artinya jj undo tidak bisa membatalkannya, dan jaring pengaman yang kita bahas di artikel sebelumnya bolong tepat di situ.

Padanannya:

• rebase: jj rebase
• merge: jj new A B, satu commit baru dengan dua parent
• pull: jj git fetch, lalu rebase ke trunk()

Kalau sudah terlanjur, jalankan jj git import supaya jj tahu apa yang berubah, baru putuskan mau jj undo atau jj op restore <op-id>. Aturan di tim kami sederhana: git boleh untuk baca, mutasi hanya lewat jj.

2. Mengira bookmark ikut maju

Di git, branch ikut maju setiap kali commit. Di jj, bookmark diam di tempat kamu menaruhnya. Kamu bikin tiga commit baru, push, dan reviewer cuma melihat yang pertama.

Geser manual sebelum push:

jj bookmark set fix/nama-branch -r @-

Perlakukan bookmark sebagai label pengiriman, bukan tempat kerja. Bookmark cuma perlu ada saat sesuatu mau keluar dari laptopmu.

3. Takut commit kosong

Refleks git: jangan commit kalau belum ada isinya. Di jj, urutannya terbalik. Kamu bikin commit dulu, kasih niat, baru kerja:

jj new -m "fix(api): validasi tanggal invoice"

Commit kosong di jj bukan sampah, itu slot yang menunggu diisi. Yang sampai akhir tetap kosong, buang dengan jj abandon <change-id>.

4. Mencari git add

Tidak ada. Setiap file yang kamu edit sudah masuk ke commit yang sedang kamu duduki. Alurnya jadi jj diff untuk lihat, jj describe -m untuk menamai, jj new untuk mulai berikutnya.

Kalau di git kamu biasa add -p untuk memilih sebagian perubahan, di jj pemilahannya dilakukan belakangan dengan jj split. Satu sore berantakan di repo kami jadi delapan MR lewat jj split per kelompok file. Satu catatan buat yang kerja bareng agen: selalu pakai -m. Tanpa itu jj split membuka editor, dan agen akan menunggu editor itu selamanya. Kejadian beneran, bukan teori.

5. Lupa jj new sesudah jj describe

Ini kebalikan dari nomor 3, dan jauh lebih licin. jj describe cuma memberi nama, commit-nya belum disegel. Kamu merasa “sudah commit”, lanjut edit file lain, dan semua perubahan berikutnya masuk ke commit yang kamu kira sudah beres.

Kebiasaan yang saya pakai sekarang: anggap jj new sebagai tombol “selesai, mulai yang baru”. Atau pakai jj commit -m "...", yang melakukan describe dan new sekaligus. Kalau sudah terlanjur campur, jj split memisahkannya lagi.

6. Tidak percaya op log

Yang ini bukan perintah, tapi sikap. Orang pindahan dari git membawa trauma rebase -i yang gagal di tengah jalan, jadi mereka tetap bekerja pelan dan penuh upacara. Backup branch dulu, baru berani sentuh history.

Di jj itu buang tenaga. Coba reorganisasi yang kamu mau. Kalau hasilnya jelek, jj undo. Kalau mau lebih aman, catat ID operasi terakhir dengan jj op log --limit 1 sebelum mulai, supaya selalu ada titik untuk jj op restore.

Bonus dari lapangan: working copy stale

Satu lagi yang tidak ada di panduan LazyJJ tapi saya temui di hari kedua. Kalau kamu pakai beberapa workspace (di tim kami satu agen, satu workspace), lalu workspace lain menulis ulang graph, working copy-mu bisa jadi stale. jj akan bilang terus terang. Jangan diabaikan:

jj workspace update-stale

Saya sendiri mendapat peringatan ini justru saat sedang menulis soal betapa rapinya graph kami.

Enam kesalahan tadi sebenarnya satu: memperlakukan jj sebagai git dengan nama perintah lain. Begitu model mentalnya pindah, sebagian besar kesalahan itu hilang sendiri.

Satu hal yang perlu diingat

Di jj, commit itu murah, bisa berubah, dan bisa dibatalkan, jadi berhentilah memperlakukannya seperti benda yang harus dijaga.

Berikutnya: Stacked PR tanpa Graphite, karena begitu commit terasa murah, menumpuknya jadi deret MR juga ikut murah.

---

Bahan dasar: panduan Common Mistakes di lazyjj.dev oleh Ernesto Jiménez.