Cherrypick Log

Cherry-pick log: update + AI review

Everything for this tool lives in this folder (.claude/skills/cherrypick-log/):

The output is cherrypick_log.md in the repo root. The script is the source of truth for the list, its order and statuses found by hash or PR. It also flags commits that cancel each other out: a commit and its revert (or a longer revert chain) that the fork has none of get ? with a Cancels out (script): note on every update. These flags are recomputed on every run until the row gets an AI checked note or a status set by hand (see README "Revert chains"). The AI's job is narrow:

• decide the rows the script could not (?, and empty rows only if the user asks) by comparing the code itself (sections 2-4);
• when asked to clean the log, omit the commits that only bump the app version (section 5).

1. Update the list

python3 .claude/skills/cherrypick-log/update_cherrypick_log.py          # fetch + regenerate
python3 .claude/skills/cherrypick-log/update_cherrypick_log.py update --no-fetch   # offline

Report the summary line (commits / new / status changes / gone) and the summary table at the top of cherrypick_log.md. If the user only asked to update, stop here.

2. Get the rows to review

P=.claude/skills/cherrypick-log/update_cherrypick_log.py
python3 $P uncertain --json                      # '?' rows not yet AI-reviewed
python3 $P uncertain --json --repo mihon --limit 20
python3 $P uncertain --json --include-empty --repo mihon --limit 30   # only when the user asks

Rows whose Notes already contain AI checked are skipped (use --include-reviewed to redo them). A ↳ tachiyomiSY row is SY's copy of the mihon row directly below it. Both share one status, so review the mihon commit once and mark both rows.

3. Review each row

A row with a Cancels out (script): note is part of a revert pair or chain: review all of its rows together (the hashes in the notes) and give them consistent verdicts. Leave them ? with an AI checked note when the pair cancels out and the fork has neither side, since dropping the pair (X) is the maintainer's decision.

For upstream commit H (already fetched locally):

1. git show --stat --format=fuller H and then the diff (git show H -- <path>) for the main files.
2. If Details names target commits (master `abc` [title], [pr only …]), inspect them: git show --stat abc, then compare the hunks with the upstream change.
3. Otherwise, search master for the change itself:
   • git grep -n -F '<distinctive added line>' master -- <path> (Komikku keeps most upstream paths; changes may be wrapped in // KMK / // SY markers or be in a renamed file).
   • git log master --oneline -S'<distinctive snippet>' --since=<upstream date - 6 months>.
   • For removals, check that the removed code is gone from master.
4. Decide:
   • O: the change is in master (cherry-picked, squashed into another commit, or re-implemented).
   • ?: partly present, conflicts with a Komikku rework, or you can't tell.
   • empty: not present. Never set X here. That is the maintainer's "won't pick" decision. The only exception is section 5 (version-bump-only commits).

4. Record the verdict (never hand-edit the table)

python3 $P mark <hash> --status O    --note "AI checked YYYY-MM-DD: present in master <kmk-hash or file> - <why>"
python3 $P mark <hash> --status '?'  --note "AI checked YYYY-MM-DD: partial - <what is missing>"
python3 $P mark <hash> --status none --note "AI checked YYYY-MM-DD: not found - <what you searched>"

• Every AI note must start with AI checked <date>:. The script uses this marker to keep an AI "not found" verdict and to leave reviewed rows out of uncertain.
• mark refuses to change O / X rows. Do not pass --force unless the user explicitly asks.
• Keep notes to one line. Mention the evidence (target commit hash, file, or search done).