# looseオブジェクトの確認
$ find .git/objects -type f | grep -v pack | grep -v info | head -5
.git/objects/55/7db03de997c86a4a028e1ebd3a1ceb225be238
.git/objects/8f/94139338f9404f26296befa88755fc2598c289
.git/objects/a1/b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0

# looseオブジェクトの手動読み取り
$ python3 -c "
import zlib, sys
with open('.git/objects/55/7db03de997c86a4a028e1ebd3a1ceb225be238', 'rb') as f:
    data = zlib.decompress(f.read())
    print(repr(data))
"
# 出力: b'blob 12\x00Hello, Git!\n'
# 形式: <type> <size>\0<content>
 
# オブジェクトタイプ別のヘッダー
# blob:   "blob <size>\0<content>"
# tree:   "tree <size>\0<binary entries>"
# commit: "commit <size>\0<commit data>"
# tag:    "tag <size>\0<tag data>"

# SHA-1ハッシュの計算過程
$ echo -n "blob 12\0Hello, Git!\n" | shasum
557db03de997c86a4a028e1ebd3a1ceb225be238  -
# → ファイルパスはSHA-1から直接導出される
 
# Git 2.42+ ではSHA-256もサポート
$ git init --object-format=sha256
# → オブジェクトのハッシュが256ビットになる

# リポジトリのオブジェクト数を確認
$ git count-objects -v
count: 1847          # looseオブジェクト数
size: 15280          # looseオブジェクトの合計サイズ(KB)
in-pack: 45231       # packfile内のオブジェクト数
packs: 2             # packfileの数
size-pack: 28456     # packfileの合計サイズ(KB)
prune-packable: 0    # pack済みで削除可能なlooseオブジェクト数
garbage: 0           # 不正なファイル数
size-garbage: 0

# looseオブジェクト数が多い場合の性能影響の確認
$ time git status
# looseオブジェクトが10万個以上 → 数秒かかる場合がある
# packfile化後 → ほぼ即座に返る
 
# ファイルシステムのinode使用状況
$ df -i .git
# looseオブジェクトはinode枯渇の原因になりうる

# 手動でpackfileを生成
$ git repack -a -d
# -a: 全オブジェクトを1つのpackfileにまとめる
# -d: 不要になったlooseオブジェクトとold packを削除
 
# 自動生成のトリガー
# - git gc の実行
# - git push 時（サーバーへの転送用）
# - looseオブジェクト数が閾値を超えた場合（gc.auto, デフォルト6700）
 
# repackのオプション一覧
$ git repack -a -d -f --window=250 --depth=50
# -f: 既存のdeltaを破棄して再計算（より良いdeltaを見つける可能性）
# --window: delta候補を探すウィンドウサイズ
# --depth: deltaチェーンの最大深さ
 
# クルーシブ（cruft）packの作成（Git 2.37+）
$ git repack --cruft -d
# → 到達不可能オブジェクトを専用のcruft packにまとめる
# → GCでの到達可能性チェックが高速化される

# packfileの中身を確認
$ git verify-pack -v .git/objects/pack/pack-abc123.idx
SHA-1    type  size  size-in-pack  offset  depth  base-SHA-1
abc123   commit 234  156           12
def456   tree   89   67            168
789abc   blob   5280 1340          235
fedcba   blob   45   38            1575    1     789abc  ← deltaオブジェクト
 
# 各列の意味
# SHA-1:        オブジェクトのハッシュ
# type:         オブジェクトタイプ
# size:         展開後のオブジェクトサイズ
# size-in-pack: packfile内のサイズ（圧縮後）
# offset:       packfile内のバイトオフセット
# depth:        deltaチェーンの深さ
# base-SHA-1:   deltaのbaseオブジェクト

# deltaチェーンの統計情報を確認
$ git verify-pack -v .git/objects/pack/pack-*.idx | \
    awk '/^[a-f0-9]/ && NF==7 {print $7}' | sort -n | tail -5
# → 最も深いdeltaチェーンの深さを確認
 
# チェーン深さの分布
$ git verify-pack -v .git/objects/pack/pack-*.idx | \
    awk '/^[a-f0-9]/ && NF==7 {depth[$7]++} END {for(d in depth) print d, depth[d]}' | sort -n
# 出力例:
# 1 4523
# 2 2341
# 3 1230
# ...

# idxファイルの内容を確認
$ git verify-pack -v .git/objects/pack/pack-abc123.idx | head

# リバースインデックスの生成（Git 2.31+）
$ git config pack.writeReverseIndex true
$ git repack -a -d
 
# リバースインデックスの用途:
# - packfile内のオフセットからSHA-1を逆引き
# - ネットワーク転送時のオブジェクト列挙に使用
# - .revファイルがないと、idxファイル全体をソートし直す必要がある

# GCの実行
$ git gc
# → repack + reflog expire + prune + rerere gc
 
# 積極的なGC（より強力な圧縮）
$ git gc --aggressive
# → window=250, depth=250 で再圧縮（時間がかかる）
 
# 自動GCの設定
$ git config gc.auto 6700          # looseオブジェクト数の閾値
$ git config gc.autoPackLimit 50   # packfile数の閾値
 
# 自動GCを明示的に無効化
$ git config gc.auto 0
# → CI/CD環境やパフォーマンスが重要な場合

# Step 1: prune（到達不可能オブジェクトの削除）
$ git prune --dry-run           # 削除対象の確認（実行しない）
$ git prune --expire=2.weeks.ago  # デフォルトの猶予期間
$ git prune --expire=now          # 即座に削除（危険！）
 
# pruneの猶予期間の設定
$ git config gc.pruneExpire "2 weeks ago"
# → 2週間より新しい到達不可能オブジェクトは保護
# → 進行中の操作（rebase等）で一時的に到達不可能になったオブジェクトを保護
 
# Step 2: reflog expire
$ git reflog expire --all
# → 全refのreflogを期限切れ処理
 
$ git config gc.reflogExpire 90.days      # 到達可能エントリの保持期間
$ git config gc.reflogExpireUnreachable 30.days  # 到達不可能エントリの保持期間
 
# Step 3: repack
$ git repack -d -l --keep-unreachable
# -l: ローカルオブジェクトのみ（alternatesは除外）
# --keep-unreachable: 到達不可能オブジェクトもpackに含める
 
# Step 5: pack-refs
$ git pack-refs --all --prune
# → .git/refs/heads/*, .git/refs/tags/* の個別ファイルを
#   .git/packed-refs に統合
# → ファイル数を削減、refの読み取りを高速化

# cruft packの有効化
$ git config gc.cruftPacks true
$ git gc
 
# cruft packの動作:
# 1. 到達可能オブジェクト → 通常のpackfileに格納
# 2. 到達不可能オブジェクト → cruft packに格納
# 3. cruft pack内の各オブジェクトにmtime（最終参照時刻）を記録
# 4. 猶予期間（gc.pruneExpire）を過ぎたオブジェクトのみ削除
 
# cruft packのメリット:
# - pruneの高速化（到達可能性チェックの範囲が狭まる）
# - 到達不可能オブジェクトの管理が効率的
# - 大規模リポジトリでのGC時間が大幅に短縮

# リポジトリ全体のサイズ
$ du -sh .git
248M    .git
 
# オブジェクトの統計
$ git count-objects -vH
count: 234
size: 1.20 MiB
in-pack: 89432
packs: 3
size-pack: 245.80 MiB
 
# 最も大きいオブジェクトを特定
$ git rev-list --objects --all \
  | git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' \
  | sort -k3 -n -r \
  | head -10
blob abc123... 52428800 data/huge-dataset.csv
blob def456... 10485760 assets/video.mp4
 
# オブジェクトタイプ別の統計
$ git rev-list --objects --all \
  | git cat-file --batch-check='%(objecttype)' \
  | sort | uniq -c | sort -rn
  45231 blob
  12345 tree
   8765 commit
    234 tag

# git-filter-repo を使用（推奨）
$ pip install git-filter-repo
$ git filter-repo --path data/huge-dataset.csv --invert-paths
 
# 特定サイズ以上のblobを全て削除
$ git filter-repo --strip-blobs-bigger-than 10M
 
# パスの書き換え（ディレクトリの移動）
$ git filter-repo --path-rename old/path/:new/path/
 
# BFG Repo-Cleaner を使用
$ java -jar bfg.jar --strip-blobs-bigger-than 10M
$ git reflog expire --expire=now --all
$ git gc --prune=now --aggressive
 
# filter-repo後の後処理
$ git reflog expire --expire=now --all
$ git gc --prune=now --aggressive
# → 全ての到達不可能オブジェクトを即座に削除
# → リポジトリサイズが大幅に縮小

# 巨大ファイルを見つけるための追加コマンド
# packfile内の大きなオブジェクトを直接確認
$ git verify-pack -v .git/objects/pack/pack-*.idx \
  | sort -k3 -n -r | head -20
 
# 特定のblobがどのcommitで追加されたかを特定
$ git log --all --find-object=abc123def456
# → abc123def456 というblobを含むcommitを表示
 
# Git LFS への移行を検討
$ git lfs install
$ git lfs track "*.psd" "*.mp4" "*.zip"
$ git add .gitattributes
# → 以降の大きなバイナリファイルはLFSで管理

# ウィンドウサイズとdelta深さの調整
$ git repack -a -d --window=250 --depth=50
 
# マルチパックインデックス（Git 2.34+）
$ git multi-pack-index write
$ git multi-pack-index verify
 
# コミットグラフの生成（高速化）
$ git commit-graph write --reachable
# → .git/objects/info/commit-graph に生成
# → git log, git merge-base等が大幅に高速化
 
# コミットグラフのチェーン管理
$ git commit-graph write --reachable --split
# → 増分更新が可能（全体を再生成せずに済む）

# ビットマップの生成
$ git repack -a -d --write-bitmap-index
 
# ビットマップの効果:
# - git clone/fetchの高速化
# - 到達可能性チェックの高速化
# - reachability bitmapで各commitの到達可能オブジェクトを記録
 
# ビットマップの仕組み
# - 各commitに対して、到達可能な全オブジェクトを1ビットずつ記録
# - ビット演算（AND, OR）で到達可能性を高速に計算
# - clone時に「どのオブジェクトを送るか」の判定が高速化

# 最新のN件のコミットのみ取得
$ git clone --depth=1 https://github.com/user/repo.git
# → .git/shallow ファイルにshallow境界を記録
 
# 履歴を後から深化
$ git fetch --deepen=10
$ git fetch --unshallow    # 全履歴を取得
 
# shallowの制限事項
# - git log で全履歴を辿れない
# - git bisect が制限される
# - git merge-base が不正確になる可能性がある
# - git push --all が期待通り動かない場合がある
 
# shallow境界の確認
$ cat .git/shallow
abc123def456789abcdef1234567890abcdef1234
# → この行のcommit以降の履歴のみ保持

# blobを取得せずにクローン（Git 2.22+）
$ git clone --filter=blob:none https://github.com/user/repo.git
# → checkout時に必要なblobをオンデマンドで取得
 
# 一定サイズ以上のblobを除外
$ git clone --filter=blob:limit=1m https://github.com/user/repo.git
 
# treeも除外（最も軽量だが機能制限あり）
$ git clone --filter=tree:0 https://github.com/user/repo.git
 
# 複合フィルター（Git 2.27+）
$ git clone --filter=combine:blob:none+tree:0 https://github.com/user/repo.git

# partial cloneではリモートが "promisor" として登録される
$ git config remote.origin.promisor true
$ git config remote.origin.partialclonefilter "blob:none"
 
# オンデマンド取得の動作
$ git checkout feature-branch
# → 必要なblobが自動的にoriginから取得される
 
# 手動でのオブジェクト取得
$ git fetch origin --filter=blob:none
# → 新しいcommitとtreeのみ取得
 
# 全blobの事前取得（オフライン作業前に）
$ git fetch --unshallow
# → 全オブジェクトを取得してfull cloneに変換

# commit-graphの生成
$ git commit-graph write --reachable
# → .git/objects/info/commit-graph に生成
 
# 効果:
# - git log の祖先関係の計算が高速化（O(1)でparent参照）
# - git merge-base の計算が高速化
# - generation number による効率的なDAGトラバーサル
 
# commit-graphの内容確認
$ git commit-graph verify

# multi-pack-indexの生成
$ git multi-pack-index write
 
# multi-pack-indexの検証
$ git multi-pack-index verify
 
# 効果:
# - 複数のpackfileを横断する統合インデックス
# - オブジェクト検索が1回のインデックス参照で完了
# - repackせずに検索性能を改善
 
# MIDXベースのrepack（Git 2.38+）
$ git multi-pack-index repack --batch-size=100M
# → 指定サイズ単位でpackfileを再構成
# → 全体をrepackするより高速

# リポジトリの整合性チェック
$ git fsck
# → 壊れたオブジェクト、到達不可能オブジェクト、不正な参照を検出
 
$ git fsck --full
# → packfile内のオブジェクトも含めて完全チェック
 
$ git fsck --unreachable
# → 到達不可能オブジェクトの一覧を表示
 
$ git fsck --dangling
# → 「dangling」（どこからも参照されない）オブジェクトを表示

# packfileの検証
$ git verify-pack -v .git/objects/pack/pack-abc123.idx
 
# 壊れたpackfileの修復手順
# Step 1: 壊れたpackfileを特定
$ git fsck
# error: packfile .git/objects/pack/pack-abc123.pack index CRC mismatch
 
# Step 2: リモートからの回復（最も安全）
$ git clone --mirror origin-url backup-repo
# → リモートの正常なデータで復旧
 
# Step 3: packfileの再構築（リモートがない場合）
$ mv .git/objects/pack/pack-abc123.* /tmp/
$ git unpack-objects < /tmp/pack-abc123.pack
# → packをlooseオブジェクトに展開（壊れた部分はエラー）
$ git repack -a -d
# → 残ったオブジェクトを新しいpackfileに再構築

# 到達不可能なオブジェクトの確認
$ git fsck --lost-found
# → .git/lost-found/commit/ と .git/lost-found/other/ に復旧
 
# 復旧したcommitの確認
$ ls .git/lost-found/commit/
$ git show abc123def456  # 復旧したcommitの内容を確認
$ git branch recovered abc123def456  # ブランチとして復元

# 大規模リポジトリ向けの推奨設定
$ git config core.preloadIndex true         # インデックスの並列読み込み
$ git config core.fsmonitor true            # ファイルシステムモニター（macOS/Windows）
$ git config core.untrackedCache true       # 未追跡ファイルのキャッシュ
$ git config feature.manyFiles true         # 多ファイルリポジトリ最適化
 
# packfile関連の最適化
$ git config pack.writeReverseIndex true    # リバースインデックスの有効化
$ git config gc.cruftPacks true             # cruft packの有効化
$ git config fetch.writeCommitGraph true    # fetch時にcommit-graphを更新
 
# maintenance（Git 2.31+）
$ git maintenance register
# → 定期的な自動メンテナンスを設定
# → prefetch, loose-objects, incremental-repack, pack-refs, commit-graph等を実行

# maintenanceの設定
$ git maintenance start
# → バックグラウンドで定期的にメンテナンスを実行
 
# 実行されるタスク一覧
$ git maintenance run --task=prefetch         # リモートの事前取得
$ git maintenance run --task=loose-objects    # looseオブジェクトのpack化
$ git maintenance run --task=incremental-repack  # 増分repack
$ git maintenance run --task=pack-refs        # ref圧縮
$ git maintenance run --task=commit-graph     # commit-graph更新
$ git maintenance run --task=gc               # GC
 
# maintenanceの設定ファイル
$ git config maintenance.auto false
$ git config maintenance.strategy incremental
# → incremental: 小さな操作を頻繁に実行
# → gc: 従来のgit gc方式

# NG: 毎日git gc --aggressiveを実行
$ crontab -e
0 3 * * * cd /repo && git gc --aggressive
# → 数時間CPUを占有、実際の効果は初回以降ほとんどない
 
# OK: 通常のgit gcで十分、aggressiveは大規模な履歴整理後のみ
$ git gc                           # 通常のGC
$ git gc --aggressive              # filter-repo等の後に一度だけ

# NG: packfileを直接削除
$ rm .git/objects/pack/pack-abc123.*
# → オブジェクトが見つからなくなりリポジトリが破損
 
# OK: Gitコマンドを通じて操作
$ git repack -a -d        # 全オブジェクトを再パック
$ git prune-packed         # pack済みlooseオブジェクトの削除

# NG: 猶予期間なしでpruneを常時実行
$ git config gc.pruneExpire now
$ git gc
# → 進行中のrebase/mergeのオブジェクトが削除されるリスク
 
# OK: デフォルトの猶予期間を維持
$ git config gc.pruneExpire "2 weeks ago"
# → 2週間の猶予で安全にGC
# → filter-repo等の後のみ一時的にnowを使用

# NG: 大きなバイナリファイルをGitに直接コミット
$ git add assets/design-mockup-v3.psd  # 50MB
$ git commit -m "update design"
# → 履歴に50MBのblobが永久に残る
# → バージョンごとに差分が取れない（バイナリは差分圧縮の効果が低い）
# → リポジトリサイズが急速に肥大化
 
# OK: Git LFS を使用
$ git lfs track "*.psd" "*.mp4" "*.zip"
$ git add .gitattributes
$ git add assets/design-mockup-v3.psd
$ git commit -m "update design"
# → 実際のファイルはLFSサーバーに保存
# → Gitリポジトリにはポインタファイルのみ（数百バイト）

# 演習1: 基本実装のテンプレート
class Exercise1:
    """基本的な実装パターンの演習"""
 
    def __init__(self):
        self.data = []
 
    def validate_input(self, value):
        """入力値の検証"""
        if value is None:
            raise ValueError("入力値がNoneです")
        return True
 
    def process(self, value):
        """データ処理のメインロジック"""
        self.validate_input(value)
        self.data.append(value)
        return self.data
 
    def get_results(self):
        """処理結果の取得"""
        return {
            'count': len(self.data),
            'data': self.data
        }
 
# テスト
def test_exercise1():
    ex = Exercise1()
    assert ex.process(1) == [1]
    assert ex.process(2) == [1, 2]
    assert ex.get_results()['count'] == 2
 
    try:
        ex.process(None)
        assert False, "例外が発生するべき"
    except ValueError:
        pass
 
    print("全テスト合格!")
 
test_exercise1()

# 演習2: 応用パターン
from typing import List, Dict, Optional
from datetime import datetime
 
class AdvancedExercise:
    """応用パターンの演習"""
 
    def __init__(self, max_size: int = 100):
        self._items: List[Dict] = []
        self._max_size = max_size
        self._created_at = datetime.now()
 
    def add(self, key: str, value: any) -> bool:
        """アイテムの追加（サイズ制限付き）"""
        if len(self._items) >= self._max_size:
            return False
        self._items.append({
            'key': key,
            'value': value,
            'timestamp': datetime.now().isoformat()
        })
        return True
 
    def find(self, key: str) -> Optional[Dict]:
        """キーによる検索"""
        for item in reversed(self._items):
            if item['key'] == key:
                return item
        return None
 
    def remove(self, key: str) -> bool:
        """キーによる削除"""
        for i, item in enumerate(self._items):
            if item['key'] == key:
                self._items.pop(i)
                return True
        return False
 
    def stats(self) -> Dict:
        """統計情報"""
        return {
            'total_items': len(self._items),
            'max_size': self._max_size,
            'usage_percent': len(self._items) / self._max_size * 100,
            'uptime': str(datetime.now() - self._created_at)
        }
 
# テスト
def test_advanced():
    ex = AdvancedExercise(max_size=3)
    assert ex.add("a", 1) == True
    assert ex.add("b", 2) == True
    assert ex.add("c", 3) == True
    assert ex.add("d", 4) == False  # サイズ制限
    assert ex.find("b")['value'] == 2
    assert ex.remove("b") == True
    assert ex.find("b") is None
    stats = ex.stats()
    assert stats['total_items'] == 2
    print("応用テスト全合格!")
 
test_advanced()

# 演習3: パフォーマンス最適化
import time
from functools import lru_cache
 
# 最適化前（O(n^2)）
def slow_search(data: list, target: int) -> int:
    """非効率な検索"""
    for i in range(len(data)):
        for j in range(i + 1, len(data)):
            if data[i] + data[j] == target:
                return (i, j)
    return (-1, -1)
 
# 最適化後（O(n)）
def fast_search(data: list, target: int) -> tuple:
    """ハッシュマップを使った効率的な検索"""
    seen = {}
    for i, num in enumerate(data):
        complement = target - num
        if complement in seen:
            return (seen[complement], i)
        seen[num] = i
    return (-1, -1)
 
# ベンチマーク
def benchmark():
    import random
    data = list(range(5000))
    random.shuffle(data)
    target = data[100] + data[4000]
 
    start = time.time()
    result1 = slow_search(data, target)
    slow_time = time.time() - start
 
    start = time.time()
    result2 = fast_search(data, target)
    fast_time = time.time() - start
 
    print(f"非効率版: {slow_time:.4f}秒")
    print(f"効率版:   {fast_time:.6f}秒")
    print(f"高速化率: {slow_time/fast_time:.0f}倍")
 
benchmark()

# commit-graphの有効化
$ git config fetch.writeCommitGraph true
$ git commit-graph write --reachable