LLM suggests `git rm` for emptied but tracked file (should be `git add`)

[gr33kurious]

Summary

When a tracked text file is manually emptied (all lines deleted, file remains present on disk), gitmeup suggests removing the file with git rm and a "Remove " commit, instead of treating this as a normal modification and suggesting git add.

Environment

• OS: Ubuntu 22.04 (WSL)
• Python: 3.10
• gitmeup: 1.0.1 (installed via pip install gitmeup)
• Git: 2.x
• Repository: regular Git repo, nothing special about the file

Steps to reproduce

1. Start from a clean working tree:

   git status
   # On branch main
   # nothing to commit, working tree clean

2. Open a tracked text file and delete all its contents, leaving the file empty.
   Example:

   $ ls data/some.txt
   # file exists and is tracked

3. Confirm Git sees it as modified, not deleted:

   git status --short
    M data/some.txt

4. Run gitmeup:

   gitmeup

Actual behaviour

gitmeup proposes to remove the file:

Proposed commands:

git rm data/some.txt
git commit -m 'chore: Remove some.txt'

When running with --apply:

+ git rm data/some.txt
error: the following file has local modifications:
    data/some.txt
(use --cached to keep the file, or -f to force removal)
Command failed with exit code 1. Aborting.

Git correctly refuses to remove the file because it is a modified tracked file, not a deleted one.

If I manually stage the file:

git add data/some.txt
gitmeup --apply

then gitmeup proposes a normal update commit:

Proposed commands:

git add data/some.txt
git commit -m 'chore: Emptied some.txt file'

and the resulting commit is:

1 file changed, 124 deletions(-)
rewrite data/some.txt (100%)

Expected behaviour

For a file that:

• still exists on disk, and
• is reported as M data/some.txt in git status --short, and
• has a diff consisting only of deletions,

gitmeup should:

• treat it as a modified file, and
• propose git add data/some.txt and an "Update" commit, not git rm and a "Remove" commit.

Only files that are actually deleted ( D path in git status --short) should be candidates for git rm.

Notes

This looks like the LLM misclassifying a "100 % deletions" diff as a file removal. A small guard based on git status --short in the executor (or a stronger instruction in the system prompt) would probably be enough to prevent git rm from ever being suggested/executed for files that Git itself still treats as modified rather than deleted.

[ikramagix]

Hi @gr33kurious 👋

You are right: this is a bug in how gitmeup interprets the situation where a tracked file is emptied but not actually deleted.

Internally, gitmeup passes three inputs to the LLM:

• git status --short
• git diff --stat
• git diff (text only)

In your case:

• git status --short reports M config/whitelist.txt (modified, not deleted)
• The diff is "124 deletions, 0 insertions"

The model currently sees a "100 % deletions" diff and sometimes infers "file removed", hence the git rm config/whitelist.txt suggestion. Git then correctly rejects this because the file still exists and has local modifications.

Two concrete changes will be made:

1. Execution guard in the CLI

   Before executing any git rm <path> suggested by the model, the CLI will check git status --short and only allow git rm when the path is marked as deleted ( D in the status line). For example:

   • M config/whitelist.txt → treat as update, never execute git rm
   • D config/whitelist.txt → allow git rm config/whitelist.txt

   This prevents wrong removals even if the model suggests them.

2. Prompt hardening

   The system prompt will be updated to explicitly say:

   • "Only use git rm for paths that appear with a D status in git status --short."
   • "If a file is listed as modified (M) and its content becomes empty, treat this as an update and use git add, not git rm."

Until a patched version is released, the recommended workaround is:

• For intentionally emptied files, rely on git status --short as the source of truth:
  • M path → stage and commit with git add path
  • D path → removal is appropriate
• Optionally run gitmeup in dry-run mode and sanity-check any git rm proposals against git status.

I will link the fix to this issue when it lands and include it in the next published version.

— @ikramagix