noirbizarre / noirbizarre/git-wipe

Do not treat dependency lock-file churn as a dirty worktree

Open
#68 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
Rust
Stars
5
Forks
0
Avg merge
2d 9m
Merged PRs (30d)
1

Description

Problem

Git::worktree_dirty (src/git.rs:829) is git status --porcelain non-empty. That means a single
npm install, cargo build refreshing Cargo.lock, or poetry lock is enough to classify an
otherwise finished worktree as dirty — pushing it into the force-removal multiselect
(src/cleaner.rs:530-600) where it is unselected by default and therefore silently survives every
run.

The result: worktrees whose work is fully merged accumulate forever, because a regenerable file was
rewritten by a routine command.

Proposal

Treat regenerable dependency lock files as if they were .gitignored when classifying dirtiness:

package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml, bun.lockb, bun.lock,
composer.lock, Gemfile.lock, Cargo.lock, poetry.lock, uv.lock, Pipfile.lock, go.sum,
flake.lock, gradle.lockfile, packages.lock.json.

Rules:

  • A worktree whose only changes are lock files is not dirty.
  • A lock-file change alongside any real edit is still dirty — we are not filtering the diff, only
    answering "is there anything but lock churn here".
  • Opt out with --no-ignore-locks and sync.ignorelocks = false in git-config, following the
    existing precedence (CLI > git config > default) in resolve_* (src/main.rs:424-449).

Also worth covering under the same mechanism, but unconditionally (no opt-out): session marker
files that agent harnesses drop into the worktrees they create (e.g. a .qwen-session pointer).
A session pointer is never authored work, and leaving it counted brands every agent-created
worktree dirty forever.

Acceptance

  • Only Cargo.lock modified → not dirty.
  • Cargo.lock + src/main.rs modified → dirty.
  • --no-ignore-locks restores the strict behaviour.
  • Session-marker-only change → not dirty, with or without --no-ignore-locks.
  • README option table and git sync config docs updated.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start in src/git.rs:829 to trace how worktree dirtiness is determined, then inspect the force-removal flow in src/cleaner.rs:530-600 and option precedence in src/main.rs:424-449. Update the README option table and git sync config documentation. Done means lock-only and session-marker-only changes are ignored, mixed edits remain dirty, and --no-ignore-locks restores strict lock-file behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
git, rust
Domain
cli, tooling
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
68/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.