Mengapa SQLite Tidak Menggunakan Git

 (sqlite.org)
2 poin oleh GN⁺ 2023-07-24 | 1 komentar | Bagikan ke WhatsApp
  • Kode sumber SQLite dikelola dengan Fossil, bukan Git, dan Fossil adalah sistem kontrol versi yang dirancang dan ditulis khusus untuk mendukung SQLite
  • Fossil menyediakan fitur kesadaran situasional (situational awareness) yang menampilkan perubahan terbaru di semua branch dalam satu layar, dan juga dapat diakses dari ponsel
  • Git hanya melacak riwayat sebelumnya dari sebuah check-in dan sulit melacak turunan (descendents) setelahnya, sedangkan Fossil mudah menampilkan check-in turunan dan struktur percabangan
  • Git mengharuskan pengguna memikirkan 5 status seperti direktori kerja, staging, head lokal/remote, sementara Fossil hanya mempertimbangkan direktori kerja dan check-in, sehingga memberi beban 60% lebih sedikit
  • Pengguna yang terbiasa dengan Git tetap dapat mengakses sumber SQLite dengan cara yang sama melalui mirror GitHub, unduhan web, atau instalasi Fossil

Gambaran Umum dan Premis Tulisan

  • SQLite menggunakan Fossil, bukan Git, dan Fossil adalah sistem kontrol versi yang dibuat langsung untuk tujuan mendukung SQLite
  • Tulisan ini bukan perbandingan Fossil dan Git, juga tidak menganjurkan penghentian penggunaan Git
    • Jika Anda puas dengan Git, tidak masalah untuk terus menggunakannya
    • Jika Git tidak cocok bagi Anda, atau Anda sedang memikirkan perbaikan maupun alternatif, tulisan ini menawarkan sudut pandang sebagai referensi
  • Dokumen ini telah direvisi beberapa kali untuk meningkatkan kejelasan dan memperbaiki kesalahan, dan seluruh riwayat penyuntingannya dapat dilihat

Alasan SQLite Tidak Menggunakan Git

Git Tidak Memberikan Kesadaran Situasional yang Baik

  • Timeline Fossil menyediakan ringkasan perubahan terbaru dari semua branch dalam satu layar, memungkinkan detail dilihat hanya dengan beberapa klik, dan dapat digunakan juga dari ponsel
  • GitHub dan GitLab tidak memiliki fitur yang sebanding
    • Tampilan network lambat dirender (sebelum cache), informasinya sedikit, dan hampir tidak berfungsi di mobile
    • Tampilan commits cepat dan berfungsi di mobile, tetapi hanya menampilkan satu branch pada satu waktu, sehingga sulit mengetahui apakah semua perubahan sudah diperiksa
    • GitHub dan GitLab adalah layanan pihak ketiga, bukan komponen inti Git, sehingga menambah dependensi
  • Pengguna Git sering memasang viewer grafis pihak ketiga, tetapi itu perlu instalasi dan pengelolaan terpisah serta bergantung pada platform
    • Salah satu alat yang bagus, GitUp, hanya berjalan di Mac
    • Semua alat mengharuskan sinkronisasi repository lokal lalu menjalankan GUI desktop, sehingga tidak mungkin memeriksa status proyek dari luar melalui ponsel

Git Sulit Menemukan Kelanjutan (Turunan) dari Check-in

  • Git dapat melihat kembali ke masa lalu, tetapi sulit melacak apa yang terjadi setelahnya
    • Untuk check-in tertentu di masa lalu, riwayat sebelumnya terlihat, tetapi sulit memastikan apa yang datang setelahnya
  • Fossil menyediakan layar yang menampilkan semua check-in yang diturunkan dari rilis mayor terbaru
  • Menemukan turunan di Git bukan tidak mungkin, tetapi sulit
    • Ada rangkaian perintah untuk Unix di stackoverflow, tetapi perintah ini hanya mencetak daftar turunan tanpa struktur percabangan
    • Perintah tersebut hanya berfungsi jika ada clone lokal, dan turunan tidak dapat diperiksa melalui antarmuka web seperti GitHub atau GitLab
  • Fossil mencerminkan informasi turunan di seluruh halaman web
    • Setiap halaman informasi check-in menampilkan grafik kecil "Context" yang menunjukkan check-in tepat sebelum dan sesudahnya
    • Menyediakan fitur yang membantu kesadaran situasional, seperti berpindah dengan klik ke check-in berikutnya
  • Di Git, hal ini secara teori mungkin dilakukan dengan ekstensi, alat, atau perintah yang tepat, tetapi tidak mudah sehingga hampir tidak pernah dilakukan; akibatnya, kesadaran developer terhadap perubahan kode menurun

Model Mental Git Terlalu Rumit Tanpa Perlu

  • Pengguna Git harus selalu mengingat 5 hal berikut
    1. Direktori kerja (working directory)
    2. "index" atau area staging
    3. head lokal
    4. Salinan lokal dari head remote
    5. Head remote yang sebenarnya
  • Pengguna Fossil hanya perlu mempertimbangkan direktori kerja dan check-in yang sedang dikerjakan, yaitu pengalihan perhatian 60% lebih sedikit
    • Ini menghemat konsentrasi developer yang terbatas (brain-cycles) dan membantu mereka fokus pada perangkat lunak yang sedang dikembangkan
  • Seorang pengguna yang memakai Git dan Fossil pernah menyebutkan di HN bahwa "Fossil memberi rasa tenang bahwa semuanya sudah tersinkron ke server dengan satu perintah, tetapi saya tidak mendapatkan rasa tenang seperti itu di git"

Git Tidak Melacak Nama Branch di Masa Lalu

  • Git mempertahankan seluruh DAG dari urutan check-in, tetapi tag branch adalah informasi lokal yang tidak disinkronkan, dan tidak dipertahankan setelah branch ditutup, sehingga meninjau branch lama menjadi merepotkan
  • Contoh: ketika menanyakan nasib branch 'prefer-coroutine-sort-subquery' dari 2 tahun lalu
    • Fossil: Menampilkan dengan jelas bahwa branch tersebut akhirnya digabungkan ke trunk, titik awalnya, dan indikasi bahwa perubahan trunk digabungkan dua kali ke branch tersebut
    • GitHub: Sama sekali tidak dapat menunjukkan informasi semacam ini dan praktis tidak berguna untuk memahami apa yang terjadi
  • GUI pihak ketiga mungkin lebih baik, tetapi tetap dibatasi oleh fakta bahwa Git tidak mempertahankan nama branch lama saat sinkronisasi
    • Fakta bahwa informasi yang diinginkan memerlukan alat pihak ketiga itu sendiri merupakan kelemahan pada sistem inti

Git Membutuhkan Lebih Banyak Dukungan Administrasi

  • Git adalah perangkat lunak yang kompleks; instalasi dan upgrade di workstation memerlukan installer, dan membangun server Git juga tidak sederhana
    • Kebanyakan orang menggunakan layanan pihak ketiga seperti GitHub atau GitLab, sehingga menambah dependensi
  • Fossil adalah binary mandiri tunggal yang selesai diinstal begitu diletakkan di $PATH
    • Satu binary ini mencakup fungsi inti Git sekaligus fungsi GitHub dan GitLab
    • Dapat mengelola server komunitas dengan wiki, pelacakan bug, dan forum, menyediakan unduhan paket, mengelola login, dan lainnya tanpa perangkat lunak tambahan
    • Membangun server komunitas memerlukan beberapa menit
    • Berjalan lancar bahkan di VPS $5/bulan atau Raspberry Pi, sementara GitLab dan sejenisnya membutuhkan spesifikasi lebih tinggi
  • Semakin kecil beban administrasi, semakin banyak waktu yang dapat dicurahkan developer untuk mengerjakan perangkat lunak (SQLite), bukan sistem kontrol versi

Git Memberikan Pengalaman Pengguna yang Buruk

  • Komik xkcd 1597 memang berlebihan, tetapi mendekati kenyataan
  • Tidak banyak yang membantah bahwa Git memberikan pengalaman pengguna di bawah optimal, dan implementasi internalnya terekspos langsung ke antarmuka
    • Antarmukanya cukup buruk hingga ada situs parodi yang membuat halaman man git palsu
  • Sistem kontrol versi yang baik seharusnya memberi dukungan, bukan frustrasi; Git telah membaik selama 10 tahun terakhir, tetapi masih jauh dari selesai

Panduan Mengakses Kode Sumber SQLite untuk Pengguna Git

Mirror GitHub Resmi

  • Sejak 2019-03-20, ada mirror Git resmi dari sumber SQLite di GitHub
  • Mirror ini merupakan ekspor inkremental dari repository Fossil resmi, dengan cron job yang memperbarui repository GitHub sekali per jam
    • Ini adalah mirror satu arah dan hanya-baca yang tidak menerima pull request atau perubahan
    • Semua perubahan hanya dimasukkan melalui Fossil
  • Hash identifikasi check-in dan file berbeda antara mirror Git dan Fossil
    • Alasan utamanya adalah Fossil menggunakan hash SHA3-256, sedangkan Git menggunakan SHA1
    • Saat ekspor, hash Fossil asli ditambahkan sebagai footer komentar check-in, dan untuk menghindari kebingungan saat merujuk check-in SQLite, disarankan selalu menggunakan hash Fossil asli

Akses Web

  • Repository Fossil SQLite menyediakan tautan unduhan Tarball, ZIP Archive, dan SQLite Archive untuk versi lama mana pun
  • Format URL-nya sederhana sehingga mudah diintegrasikan ke alat otomasi
    • Format dasar: https://sqlite.org/src/tarball/VERSION/sqlite.tar.gz
    • VERSION dapat diisi dengan prefiks hash, nama branch, atau tag (misalnya "version-3.23.1")
    • Gunakan "release" untuk rilis terbaru, dan "trunk" untuk trunk terbaru
    • Untuk ZIP dan SQLite Archive, ganti "/tarball/" menjadi "/zip/" atau "/sqlar/"

Akses Fossil

  • Fossil mudah dipasang dan digunakan, dengan prosedur untuk Unix disediakan (Windows juga serupa)
    • Unduh executable fossil lalu letakkan di $PATH
    • Gandakan repository dengan fossil clone, lalu buka dengan fossil open
    • Setelah itu dapat menjalankan ./configure; make (untuk Windows MSVC, nmake /f Makefile.msc)
  • Dengan perintah fossil update VERSION, checkout dapat diganti ke versi lain (VERSION dapat diisi trunk, prefiks hash, branch, atau tag)
  • Di dalam checkout, perintah fossil ui menjalankan situs web lokal
    • Tanpa login, perubahan tidak dapat di-push sehingga proyek tidak dapat dirusak; Anda bebas menjelajah dan bereksperimen

Verifikasi Integritas Kode Sumber

  • Di root source tree terdapat file "manifest"
    • File ini berisi semua nama file serta hash SHA1 atau SHA3-256 untuk tiap file (file lama memakai SHA1, file baru memakai SHA3-256)
    • Hash dapat diekstrak dengan skrip lalu dibandingkan dengan file sumber untuk verifikasi
  • Nama hash check-in adalah hash SHA3-256 dari file "manifest" itu sendiri, dan jika baris terakhir dimulai dengan "# Remove this line...", baris tersebut dapat dihilangkan

Bacaan terkait

1 komentar

 
GN⁺ 2023-07-24
Komentar Hacker News

  • Saya mencoba merangkum alat version control yang pernah saya pakai selama puluhan tahun, beserta tahun dibuatnya dan tahun terakhir saya memakainya: sccs 1973~2000, rcs 1982~2000, cvs 1990~2004, clearcase 1992~2004, perforce 1995~2011, subversion 2000~2015, mercurial 2005~2015, git 2005~sekarang
    Setidaknya bagi saya, umur alat-alat seperti ini kira-kira sekitar 15 tahun
    Tapi kalau saya bilang kepada para junior, “ketika kalian seusia saya nanti, git akan menjadi kenangan yang jauh dan aneh,” mereka menatap saya dengan aneh
    git adalah alat yang hebat dan memang pantas sukses, tetapi rasanya sayang kalau masalah ini berakhir di git

    • Agar adil, untuk jenis alat apa pun, begitu ruang masalahnya sudah cukup dipahami, laju perubahan akan melambat
      Ada tulisan di Joel on Software yang mengatakan bahwa software pada umumnya hampir selesai di sekitar versi 4, dan contohnya adalah software perkantoran, khususnya Excel
      Kalau sekarang membuka Excel 4, fitur intinya pada dasarnya memang sudah bisa melakukan semuanya, jadi sepertinya itu benar
      git tampaknya akan bertahan setidaknya dua kali lebih lama daripada alat version control sebelumnya
    • Subversion pada dasarnya adalah CVS yang dibuat dengan benar
      Masalahnya, CVS adalah jalan buntu yang tidak bisa diperluas ke model pengembangan terdistribusi
      Git kembali ke model RCS lokal lalu menambahkan commit atomik, sehingga berhasil keluar dari optimum lokal bernama Subversion
      Ada juga pilihan-pilihan kontroversial seperti tidak melacak rename atau tidak adanya nomor revisi linear, tetapi itu tidak menjadi masalah besar, dan git memungkinkan pekerjaan yang sangat efisien tanpa masalah performa seperti darcs
      Melihat banyaknya upaya untuk memperbaiki version control antara 1995~2010, model data dasar git tampaknya sangat sulit diperbaiki lebih lanjut, bahkan dengan fitur tambahan seperti git-lfs
      Antarmuka command-line baru bisa saja muncul, tetapi makin sulit menggusur pemain dominan yang sudah ada, dan tidak ada orang di sekitar saya yang memakai git switch dan git restore alih-alih git checkout yang kelebihan beban dan membingungkan
    • Saya tidak tahu apa yang akan dipakai 15 tahun lagi, tetapi hal yang benar-benar menyedihkan dari daftar itu adalah pada 2015 saya berhenti memakai mercurial dan masih memakai git sampai sekarang
    • Di perusahaan pertama saya, kami memindahkan proyek dari clearcase ke git, dan bahkan saya yang tidak suka clearcase pun merasa sebelum itu tidak banyak alasan untuk bersusah payah menggantinya dengan yang lain
      Di departemen lain perusahaan ada sedikit svn, tapi hanya sebatas itu
      Sistem version control tidak berubah secepat itu
      Alat-alat dalam daftar sebelum version control terdistribusi muncul sebenarnya punya banyak kesamaan, dan git tampaknya akan bertahan cukup lama
    • Internet cenderung memakukan sesuatu pada tempatnya
      Secara historis ada banyak bahasa yang dominan, tetapi bahasa Inggris akan menjadi bahasa final; ada banyak bahasa skrip, tetapi javascript akan menjadi bahasa final; ada banyak protokol jaringan, tetapi TCP/IP akan menjadi protokol final
      Menurut saya git juga sama
      Yang mungkin bisa menggusur git hanyalah kasus seperti glitch[1], ketika sebuah lingkungan untuk programmer baru sudah dilengkapi sistem version control-nya sendiri
      [1]: https://medium.com/glitch/reinventing-version-control-with-g...

  • Menurut saya git punya reputasi buruk karena tidak ada yang bisa sepakat soal cara memakainya
    Lihat saja GitHub PR dan push branch, rebase dan merge; semuanya adalah alat untuk melakukan hal yang pada dasarnya sama dengan cara yang benar-benar berbeda
    Masalahnya, tidak ada pihak yang salah
    Me-rebase commit kecil mengurangi kompleksitas yang tidak perlu dalam riwayat, sementara merge mempertahankan apa yang sebenarnya terjadi dan membantu memahami alasan perubahan
    Tentu saja reverse merge adalah yang terburuk, tapi itu masalah lain lagi
    Saat push ke branch, Anda bisa saja tidak pernah melakukan force push, tetapi pada branch PR Anda hampir selalu akhirnya melakukan force push
    Bahkan hal-hal yang mudah pun menciptakan perpecahan yang tidak bisa diselesaikan
    Saya belajar menyebut repositori utama sebagai origin dan fork saya sebagai fork, tetapi sebagian orang belajar menyebut repositori utama sebagai upstream dan fork mereka sebagai origin
    Keduanya tidak mesti salah, tetapi kalau origin bisa menunjuk ke dua lokasi yang sama sekali berbeda, komunikasi yang jelas menjadi sangat sulit

    • Mengadaptasi Bjarne Stroustrup, hanya ada dua jenis sistem version control: yang dikeluhkan orang, dan yang tidak dipakai siapa pun
    • Filosofi yang membantu adalah “lakukan hal yang sesuai dengan tujuan langsung saat ini, lalu evaluasi ulang dan beradaptasi”
      Dalam praktiknya, saya secara aktif me-rebase commit di dalam PR hanya dengan fokus pada “apa yang membuat review paling mudah?”
      Setelah review selesai, saya bertanya “bentuk seperti apa yang paling mudah dioperasikan dan dipahami ke depannya?”, lalu bisa saja semuanya di-squash, atau disusun ulang menjadi bagian-bagian yang bisa dideploy secara independen agar rollback mudah dilakukan
      Intinya, pekerjaan-pekerjaan seperti ini bisa memiliki kebutuhan yang berbeda, dan tidak apa-apa memakai cara berbeda pada waktu yang berbeda
      Hanya saja, ini membutuhkan lebih banyak penilaian pribadi, dan sulit diajarkan serta dipaksakan ke seluruh tim besar
    • Penting untuk membedakan ketidaksesuaian lokal dan ketidaksesuaian sosial
      Yang pertama adalah hal-hal yang tidak memengaruhi orang lain
      Misalnya, apakah nama remote repository Anda origin dan upstream, atau fork dan origin, rekan kerja tidak akan peduli
      Yang kedua adalah hal-hal yang harus dikoordinasikan dengan orang lain
      Misalnya, seperti apa bentuk riwayat git akhir yang akan ditinggalkan
    • Alasan git punya reputasi buruk adalah karena antarmuka command-line-nya sangat berantakan
      Jika Apple yang merancang antarmuka command-line git, pengalaman penggunanya mungkin akan sejuta kali lebih baik, sementara kekuatannya hanya berkurang sekitar 10%

  • Bagus kalau Fossil cocok untuk mereka, tetapi kalimat ini terasa mengganjal: “Fossil adalah satu binary mandiri yang bisa dipasang cukup dengan menaruhnya di $PATH, dan di dalam satu file itu ada semua fungsi inti Git serta fungsi GitHub/GitLab…”
    Walau git punya berbagai masalah, ia bukan pendekatan memasukkan semuanya sampai wastafel dapur
    Saya lebih suka pendekatan “lakukan satu hal dengan baik”

    • Sebenarnya Git juga menggabungkan banyak hal yang tidak banyak diketahui orang
      Misalnya, kalau menjalankan git instaweb, ia akan menyalakan server CGI lokal dan skrip Perl CGI untuk menyediakan UI web yang sangat sederhana: https://git-scm.com/docs/git-instaweb
      Dalam hal ini, tidak jauh berbeda dari fungsi inti Fossil
      Git juga punya banyak fitur integrasi klien email yang mungkin orang yang hanya memakai GitHub bahkan tidak tahu ada, apalagi tahu untuk apa
      Contohnya git send-email, untuk mengirim patch lewat email langsung dari git: https://git-scm.com/docs/git-send-email
    • Gagasan bahwa kita bisa mengisolasi “satu hal” dan menganggapnya bukan “kumpulan dari hal-hal lain” adalah mitos yang cukup berbahaya di dunia pemrograman
      Segalanya adalah komposisi, segalanya adalah pipeline perintah, dan dibuat dari berbagai hal
      “Pekerjaan yang harus dilakukan” bukan sesuatu yang mutlak, melainkan bergantung pada sudut pandang orang yang melihatnya
      Prinsip tanggung jawab tunggal tidak bisa diterapkan begitu saja di dunia nyata; itu hanya kompromi untuk menjaga keseimbangan antara kohesi dan modularitas
      Di mana kita memotong lalu menyebutnya “satu” bergantung pada kita dan kebutuhan kita
      Bagi banyak orang, alat-alat GitHub sudah begitu terintegrasi ke dalam alur kerja sehingga Git saja sama sekali tidak bisa dipakai
      Bagi mereka, GitHub adalah “satu hal”, dan SQLite punya “satu hal”-nya sendiri
    • SQLite memang hebat dan Richard jelas seorang genius, tetapi obsesinya terhadap monolit binary tunggal selalu terasa aneh bagi saya
      Seperti yang disebutkan, itu bertentangan dengan filosofi Unix: lakukan satu hal dengan baik
      Bagi saya, jauh lebih rapi jika sistem dipecah menjadi komponen-komponen yang nantinya bisa diganti atau dimodifikasi secara independen
    • git di lingkungan *nix aslinya memang tidak memasukkan semuanya sampai wastafel dapur, tetapi Git untuk Windows melakukannya
      Installernya lebih dari 50 MB, dan kalau ingatan saya benar, bahkan menyertakan terminal
      Sebaliknya, Fossil menyediakan binary mandiri 3,3 MB untuk tiap platform yang didukung
    • Karena git tidak menyertakan hal-hal itu, orang akhirnya bergantung pada GitHub atau GitLab untuk menyediakan bagian-bagian yang hilang tetapi sebenarnya dibutuhkan oleh sistem manajemen kode sumber modern

  • https://git-man-page-generator.lokaltog.net adalah hal paling lucu yang saya lihat setelah sekian lama

    • Deskripsi git-erase-working-tree berbunyi “menghapus dengan hati-hati working tree saat ini dari root upstream dan konfigurasi, dan sebaiknya dipakai ketika ingin melakukan quiltimport ke GUI aktif”, terdengar berguna
    • git-molest-head berbunyi “secara keliru mengganggu head upstream menggunakan indeks remote, dan menjalankan hook yang sesuai untuk membuat tabel dari head yang diberikan”, agak terlalu provokatif
    • Saya butuh waktu terlalu lama untuk sadar bahwa ini tidak nyata
      Git punya perintah-perintah yang canggung, jadi sekarang rasanya tidak mengejutkan lagi
    • Perintah favorit saya adalah git-tease-chain, git-scrub-dangling-object, git-seize-mailmap, git-dress-graft, git-strangle-tree, git-satisfy-daemon, dan git-pat-tree-object
    • Tidak terlalu terdengar meyakinkan
      Untuk membuat omong kosong yang lebih bagus, perlu lebih banyak bumbu LLM

  • Diskusi sebelumnya:
    2021, 356 komentar: https://news.ycombinator.com/item?id=29125934
    2018, 608 komentar: https://news.ycombinator.com/item?id=16806114
    Seharusnya masih ada lagi, tetapi dokumen yang sama bisa ditemukan lewat beberapa path, baik tanpa domain www, tanpa path /drafts/, maupun tanpa path /matrix/, sehingga makin sulit menemukan posting lama

  • Di sini ada kritik yang sah terhadap Git, tetapi beberapa di antaranya agak aneh
    Saya sudah memakai Git dalam berbagai situasi, dari repositori pribadi lokal sampai repositori perusahaan yang sangat besar, dan jujur saja sekitar separuh dari masalah ini belum pernah saya alami
    Begitu juga bagian yang mengatakan “network lambat dirender, jauh lebih sedikit detailnya, dan hampir tidak berfungsi di mobile”; saya berharap tidak akan tiba hari ketika tim kami harus mempertimbangkan perangkat mobile sebagai cara untuk memeriksa status branch
    Saya bahkan tidak pernah terpikir use case seperti itu
    Apakah ini sering terjadi pada orang lain?

    • Terjadi terus-menerus
      Sepertinya setidaknya 50% eksplorasi kode saya lakukan dari ponsel
      Untuk itu saya banyak memakai antarmuka web GitHub mobile, dan dukungan untuk mencari referensi benar-benar sangat membantu
      Search masih kurang bagus, dan saya tidak suka bagaimana tersendat-sendat khas SPA terus merusak fitur find-in-page bawaan
      Saat harus mengulik kode Firefox, saya memakai Searchfox [0], cepat dan bagus, hampir tidak ada keluhan
      Hanya saja blame di mobile masih bisa dibuat lebih baik
      Sebagai konteks, saya mahasiswa pascasarjana, meneliti bahasa pemrograman dan sistem, dan di waktu pribadi juga cukup banyak melakukan hacking IoT
      Tergantung di mana garis batas generasi ditarik, saya Gen Z yang tua atau Millennial termuda yang mungkin
      [0] https://searchfox.org
    • Saya pernah mencoba mengecek proyek di kereta komuter untuk menambah jam kerja
      Selain cakupan data yang tidak stabil, GitHub berfungsi baik dan code review ringan juga mudah dilakukan
      GitHub pulse[1] adalah UI yang bagus untuk melihat aktivitas terbaru
      Mirror SQLite tidak dikerjakan di GitHub, jadi hanya ada riwayat commit dan halaman ini kosong, tetapi proyek Caddy yang ditautkan adalah contoh yang lebih baik
      Secara pribadi, ini terlihat lebih berguna daripada timeline
      Saya penasaran apakah sudah ada yang membuat tampilan setara untuk git/GitHub
      Sepertinya tidak terlalu sulit
      [1] https://github.com/caddyserver/caddy/pulse
    • Saya memakai git untuk mengelola blog
      Saya membuat editor Android agar bisa mengedit di GitHub, lalu kemudian memodifikasinya agar juga bekerja di GitLab
      Alasannya banyak, tetapi kebanyakan karena git, entah GitHub atau GitLab, hampir mustahil dipakai di mobile
      Memeriksa status masih bisa, tetapi lebih dari itu hampir sulit
      Tulisan ini juga sangat mengena dalam aspek lain
      Saya menulis buku O’Reilly tentang GitHub, tetapi setelah memakai git lebih dari 10 tahun pun saya masih merasa belum sepenuhnya memahaminya
      Poin-poin di sini terasa relatable
    • Tidak ada alasan fitur itu tidak seharusnya berfungsi di mobile
      Kalau dirancang dan diimplementasikan dengan lebih baik, tentu saja semestinya berfungsi juga di mobile
      Orang sering mengakses GitHub dari mobile karena alasan yang sama seperti mengakses GitHub dari platform lain
      Saya sendiri jelas pernah melakukannya
      Observasi seperti ini tentang git lebih merupakan penilaian nilai terhadap fitur daripada “masalah” mutlak
      Anda bisa setuju atau tidak setuju, tetapi itu bukan jenis hal yang pasti harus Anda hadapi
    • Banyak cara yang memang tidak optimal tetapi tetap bernilai jika dibiarkan sebagai opsi, dan lebih baik opsi-opsi seperti itu berfungsi sebaik mungkin daripada tidak ada opsi sama sekali
      Rasanya ini seperti perbedaan antara degradasi performa bertahap dan gagal seketika
      Sebagus apa pun opsi berlapis emas yang benar-benar bagus, jika itu satu-satunya opsi, ia rapuh dan karena itu jadi sampah

  • Beberapa hari lalu saya menonton video yang menjelaskan alternatif Git, dan Fossil tentu saja termasuk salah satunya
    Saya pernah memakai Fossil di beberapa proyek dan rasanya cukup bagus
    Pijul https://pijul.org/ yang dijelaskan dalam presentasi ini sangat menarik, dan sebelumnya juga pernah dibahas di HN
    Sumber: https://www.youtube.com/watch?v=M4KktA_jbOE

    • Saya masih berusaha memahaminya, tetapi jj juga menarik: https://github.com/martinvonz/jj
    • Pijul selalu terasa memikat
      Rasanya seperti cawan suci version control
      Namun di proyek pribadi saya toh mengembangkan secara linear, dan di kantor saya tidak punya kendali atas apa yang dipakai, jadi belum pernah benar-benar menggunakannya
    • Pijul bisa dianggap siap ketika mendukung pengiriman patch via email sebagai sarana pengganti umum, agar orang yang tidak ingin membuat akun layanan tertentu tetap bisa mengirim patch ke upstream

  • Saya pernah memakai Fossil untuk proyek lokal pribadi
    Ini sistem kontrol versi yang cukup mumpuni, dan UI web-nya juga lumayan bagus
    Namun yang perlu diperhatikan adalah sering-seringlah mencadangkan database repositori SQLite yang menjadi dasarnya
    Setelah meng-upgrade Fossil dan membuat beberapa commit, lalu tanpa sengaja melakukan commit dengan versi Fossil yang lebih lama, database repositori Fossil rusak sampai tidak bisa dipulihkan dan saya kehilangan pekerjaan beberapa hari
    Selama 10 tahun dipakai setiap hari, Git tidak pernah sekalipun merusak repositori saya, apa pun versinya

    • Sebagai contoh tandingan, saya sudah memakai Fossil dengan cara yang benar-benar semau saya
      Di berbagai sistem ada versi yang berbeda-beda, terpaut bertahun-tahun, dan saya terus memakai binary yang memang ada saat sistem itu disiapkan
      Ada macOS, beberapa varian Linux, kotak FreeBSD, dan kalau ditarik lebih jauh sepertinya dulu juga ada Windows
      Saya menyinkronkannya di antara semua itu dengan cara-cara darurat
      Beberapa repositori sudah berumur lebih dari 10 tahun, salah satunya punya lebih dari 10 ribu commit, dan yang lain berukuran beberapa GB karena seluruh environment pengembangan di-check-in
      Sesekali Fossil bilang perlu rebuild, dan setiap kali itu berhasil
      Kalau menemukan salah ketik di tengah commit, saya juga sering menghentikannya dengan ctrl-c karena kebiasaan
      Meski begitu, Fossil tidak pernah sekalipun mengecewakan saya
      Fossil sejauh ini adalah program paling andal yang pernah saya pakai
    • Klaim itu sulit saya setujui
      Format artefak dasar Fossil kompatibel dari awal sampai sekarang
      Memang ada perbaikan, tetapi tidak ada perubahan yang memutus kompatibilitas, dan di antara banyak pengguna Fossil Forum pun tidak ada laporan kerusakan seperti itu
      Dugaan saya, kemungkinan besar Anda men-check-in sesuatu dengan Fossil yang lebih baru menggunakan fitur yang ditingkatkan, lalu mencoba mengekstraknya dengan Fossil lama yang tidak memahami fitur baru itu sehingga menerima error
      Misalnya, awalnya Fossil hanya memakai hash SHA1, tetapi setelah serangan SHAttered, Fossil ditingkatkan agar mendukung SHA1 dan SHA3
      Tentu ini hanya dugaan, tetapi tampaknya paling masuk akal
      Saya tidak pernah membuat backup murni satu kali pun untuk repositori SQLite, repositori self-hosting Fossil, maupun lebih dari 100 repositori Fossil yang saya punya
      Untuk antisipasi bencana, saya membuat clone di mesin lain
      Bahkan di berbagai mesin di seluruh dunia ada cron job yang berjalan untuk melakukan sync setiap jam pada repositori Fossil penting seperti SQLite
      Tetapi backup murni tidak pernah saya buat
      Beberapa tahun lalu, repositori SQLite utama pernah sekali rusak
      Entah bagaimana file descriptor 2 tertutup, dan saat database SQLite yang menjadi repositori dibuka, ia terbuka sebagai file descriptor 2
      Setelah itu, suatu bug di Fossil memicu assert(), lalu menulis ke file descriptor 2 dan menimpa sebagian database
      Kami memulihkan repositori dari clone, memperbaiki cacat assertion di Fossil, dan memperkuat SQLite agar tidak memakai file descriptor yang lebih kecil dari 3
      Materi yang juga layak dibaca: https://fossil-scm.org/home/doc/trunk/www/selfcheck.wiki
    • Apakah itu perilaku yang diketahui?
      Mengingat pendekatan reliabilitas para pengembang SQLite, rasanya itu harus dianggap bug fatal yang perlu diperbaiki
    • Saya pernah mengalami repositori git rusak
      Hanya saja biasanya tidak sampai tidak bisa dipulihkan

  • Wah, karena ini saya jadi menyelam cukup dalam
    Mungkin ini salah satu hal terbaik yang saya lihat belakangan ini
    Tampaknya kita bisa memakai Fossil sekaligus melakukan mirroring ke Git/GitHub: https://fossil-scm.org/home/doc/trunk/www/inout.wiki
    UI bawaannya terlihat bagus, benar-benar bisa dipakai, dan mudah dijelajahi
    Namun saya berharap UI itu juga mendukung commit, tetapi saya tidak menemukannya
    Dengan begitu, kita tidak perlu mencampur command line dan antarmuka web untuk menyelesaikan pekerjaan
    Jika bisa membuat UI wrapper di atas Fossil yang mendukung open, init, commit, sync, sync-with-git, start-web-interface, atau memasukkannya ke Fossil sendiri, sepertinya ini akan cukup berguna bagi orang yang kurang teknis atau bukan developer tetapi menangani kode, misalnya orang-orang di biologi, matematika, dan data science untuk mengelola Jupyter notebook dan sebagainya
    Tentu klien UI git yang sederhana juga bisa dipakai untuk tujuan itu, tetapi dengan begitu kita kehilangan wiki dan tiket bawaan
    Kemampuan bekerja secara lokal juga berguna, tetapi git pun bisa melakukan itu
    Bagaimanapun, saya pernah melihat orang yang kurang teknis enggan memakai git, atau kontrol versi secara umum
    Saya bisa melihat potensi adanya wiki dan tiket bawaan dalam repositori yang sama
    Fakta bahwa hanya ada satu file yang perlu di-backup juga menarik

  • Bagi developer software, sistem kontrol versi adalah alat seperti IDE atau sistem operasi dasar
    Semakin sedikit kita perlu mengutak-atik alat seperti ini, semakin produktif kita
    Dari pengalaman memakai beberapa sistem kontrol versi, Fossil bagi saya tepat berada di sweet spot
    Secara harfiah, cukup disiapkan lalu dilupakan