gitがダメないくつかの理由

gitのダメなところを記載する

• 品質が悪い

  • pythonのパッケージ？とかもともと突っ込んで、普通に使ってたら3000？10000コミットとかになったらcloneで固まるようになった。こんなん仕事で使えるの？
    ※ 下は試しにcloneを分解して実行してみたところctrl-cたまにfetch完了してる

    $ git fetch --depth 1
    remote: Counting objects: 727, done
    remote: Finding sources: 100% (727/727)
    remote: Total 727 (delta 31), reused 554 (delta 31)
    Receiving objects: 100% (727/727), 1.21 GiB | 13.53 MiB/s, done.
    Resolving deltas: 100% (31/31), done.
    

    → これあれだな、リモートをsshで拾うときの問題だな
    → あれかsshの何かのタイムアウトかてことはsshプロトコルのエラー実装がごみざるなgitがギルティ

  • 設計思想がだめ
    なんだろうな、ワーキングコピー、ステージング、ローカルリポジトリのHEAD、リモートリポジトリのHEADとfetchされたリモートリポジトリのHEADがあってそれぞれのコマンドがどれにアクセスしてるかわからんgit diffはどれとどれを比較してるんだい？

  • git diff の引数でもわかる

    git diff ファイル名
    git diff コミットID1 コミットID2 ファイル名
    

    → git statusがワーキングとリモートとのチェックをしないのが感覚とずれてるんだな
    ことごとく感覚と違う動きをする

CUIじゃなかったらそんなに違和感は無いのだろうか

(2025年3月1日)追記
重複するところはあるけれどいまいまの感想を書いてみる

• 設計思想がゴミ

  • ワーキングディレクトリの内容を全くまったく大事にしないのがだめ
  • ブランチの切り替えでどのファイルが継続されてどのファイルが切り替わるのか意味不明。恐怖しかない
  • コマンドが不明、複雑すぎるのでそれを改善するまとめたコマンドを追加してさらに意味不明になっている。
  • svn lsの代替がない。このファイルがどのコミットと認識されているか分からんvscodeがあればなんとか
    結局編集しててどこかの過去コミットと同じファイルになったらそれになる？いままでのコミットすっ飛ばして最新の内容にしたら最新のコミットとして扱ってくれるの？rebaseかけると壊すけど？

• なんか最新の断面を管理というよりチェンジセットの管理をしている訳でそれが周知されていない

カーネルだけに使ってろ