Partlet

Git plugin for inspecting commit history, changed files, and patches

git clone https://code.vhata.net/git-work

Download: tar.gz ยท zip

Commit b9a691159e80, updated 2026-11-03T21:56:12-08:00

README.md4.7 KiB
git-work10.2 KiB

git work

A shared interface for inspecting commit history, changed files, and patches. Requires Bash 4+ and Git with --diff-merges=first-parent support. No network access, Python dependencies, package installation, or repository setup required.

Commands

git work log                         # compact history from HEAD
git work log main..HEAD               # selected history
git work log --work                   # outstanding commits and published boundary
git work log -n 10                    # ten recent commits

git work files                       # files changed in HEAD
git work files abc123 --status        # specific commit, including change types
git work files HEAD~3..HEAD --stat     # statistics for each selected commit
git work files --work                 # net changes in unpublished work

git work diff                        # HEAD's patch
git work diff abc123                  # a specific commit's patch
git work diff main..HEAD --word       # individual word diffs for a range
git work diff --work                  # aggregate unpublished diff
git work diff --work --word -- src/   # word diff filtered to paths

git work files --staged --status
git work diff --unstaged
git work status                      # branch, baseline, outstanding count, status
git work base                        # machine-readable baseline ref

Scope options and positional revisions are mutually exclusive. Git revision syntax includes single commits, ranges, and exclusions such as HEAD^!. Files/diff default to the one HEAD commit; log defaults to history from HEAD. Ranges produce individual commit outputs, oldest first. Merge patches compare against the first parent, including when paths are supplied. Root patches compare against an empty tree. Empty commit selections produce no output.

The files view defaults to names; --status and --stat are alternative views. Diff defaults to line patches; --word uses Git's colored word diff. Paths after -- are relative to the directory where you invoked the command. Native Git configuration controls rename detection, diff algorithms, and ordinary coloring. Only the options documented by git work --help are supported.

--work includes committed changes plus net staged/unstaged changes in tracked files. Opposing changes can cancel out in the aggregate diff while the log still shows both commits. Untracked files appear in status; add them to the index to include them in diffs. Staged means index versus HEAD (empty tree before the first commit); unstaged means working tree versus index.

Published baseline

For --work, status, and base, --base REF overrides git config work.base. Explicit invalid refs fail rather than falling back. Otherwise:

  1. Identify the integration branch from work.mainBranch, a valid locally cached origin/HEAD, then existing main or master refs in that order.
  2. On a feature branch or detached HEAD, use the local integration branch, falling back to origin/<branch>.
  3. On the integration branch, use its valid remote-tracking upstream, falling back to origin/<branch>. A local upstream is not evidence of publication.
  4. With no baseline, all history is unpublished. With an unrecognizable integration branch, configure work.mainBranch or explicitly choose a base.

For example:

git config work.mainBranch trunk
git config work.base upstream/main
git work diff --work --base release

The log heading identifies the published baseline tip. The graph's o marks published ancestry connecting to outstanding commits; that boundary can be older than the baseline tip. When caught up, the baseline tip is always displayed as context, even when a path filter would exclude it. A log limit or a path filter can omit graph boundaries; the heading still identifies the baseline.

Aggregate diffs use the common ancestor of HEAD and the baseline, avoiding unrelated changes made on the integration branch after branching. Missing or multiple common ancestors produce an error asking for an explicit base. Shallow history may require fetching more history manually. An unborn HEAD with an existing baseline cannot produce an aggregate diff until ancestry exists.

Nothing fetches automatically: remote refs represent the last locally observed remote state. Publication is based on ancestry, not patch matching; squash merges and cherry-picks cannot automatically prove an old commit has landed. The helper never writes refs, objects, the index, or working files itself; configured Git external diff tools retain their normal behavior.

base prints a full ref name for an automatically selected base, or the exact explicit revision. If there is no baseline it prints a notice on stderr and exits

  1. Usage and baseline errors exit 2; other Git errors retain Git's exit status.