On Mon, Oct 12, 2026 at 05:34:49PM -0400, Sasha Levin wrote:
> +Resolve revisions against the repository being inspected. For example, with
> +``fix`` set to the supplied revision::
> +
> + git rev-parse --show-toplevel
> + git rev-parse --verify --end-of-options "$fix^{commit}"
> + git show --no-patch --format=fuller "$fix"
> + git rev-list --parents -n 1 "$fix"
> + git show --format= --find-renames "$fix"
> +
> +Use ``git diff --cached`` and ``git diff`` to inspect staged and unstaged
> work.
> +Read the surrounding code at the pre-fix base with ``git show
> <base>:<path>``.
> +Do not assume the current checkout contains the historical implementation.
I don't really like having "how to use git" in here. Especially not "how
to figure out what the staged diff is". That is way off topic.
> +Useful read-only searches include the following. Here ``base``, ``path``,
> +``old_path``, ``new_path``, and ``candidate`` refer to identified revisions
> or
> +paths; replace the example line range and expressions with relevant ones::
> +
> + git blame -M -C -L 100,140 "$base" -- "$path"
> + git log --follow -p "$base" -- "$path"
> + git log -p -S 'relevant expression' "$base" -- "$old_path" "$new_path"
> + git log -p -G 'relevant.*pattern' "$base" -- "$old_path" "$new_path"
> + git show --find-renames "$candidate" -- "$old_path" "$new_path"
> + git rev-list --parents -n 1 "$candidate"
For example, using -S and -G here can be *extremely* slow. I think it's
best to keep this skill as short as it can possibly be. Adding these
"off topic" diversions seems like a token-eating mistake to me.
The overall guidance about how/why and where a short-cut isn't workable
all read well, though.
-Kees
--
Kees Cook
