Add --dirty option to process only Git-dirty files in Rector

[itxshakil]

This PR introduces a new CLI option, --dirty, that allows Rector to process only the files that have uncommitted changes according to Git, similar to Laravel Pint’s --dirty mode.

This dramatically improves performance for large projects and makes Rector more convenient to use during active development.

---

🚀 What This PR Adds

✔ New CLI flag: --dirty

vendor/bin/rector process --dirty

When enabled, Rector will:

• Run git status --porcelain

• Collect files marked as:

  • modified (M)
  • added (A)
  • untracked (??)

• Filter to existing files only

• Pass only those files to the standard Rector pipeline

❤️ Inspired by Laravel Pint

Just like Pint, the purpose is to:

“Only modify or inspect files that have uncommitted changes according to Git.”

This massively reduces Rector execution time during iterative refactoring.

---

🧠 Implementation Overview

1. Added GitDirtyFileFetcher service

Responsible for executing the git porcelain command and extracting changed file paths.

A custom callable can be injected for testing (to avoid executing real git).

2. ProcessCommand updated

Recognizes --dirty and enables dirty mode in the configuration.

---

🧹 No Breaking Changes

• Defaults remain unchanged
• Git is only executed when --dirty is used
• Behavior is fully opt-in

---

✔️ Summary

This PR brings a much-requested developer experience improvement to Rector.
Teams using Rector heavily — especially in large repositories — will benefit from:

• Faster iteration cycles
• Less noise
• A more “incremental refactoring” workflow

[TomasVotruba]

Thanks for proposal. Rector runs on such files by default. It only checks freshly edited files, the rest is cached.

[itxshakil]

When we run the rector for the first time. It runs for all files but dirty would allow us to add rector incrementally in a large codebase.

BTW, Thanks for such an awesome tool🔥

Thanks for proposal. Rector runs on such files by default. It only checks freshly edited files, the rest is cached.

[TomasVotruba]

I see.

Such approach would introduce double standards, every file would look different.

There is a better incremental way to raise quality across the whole project: https://getrector.com/documentation/levels#content-type-coverage-and-type-coverage-docblocks-levels

[itxshakil]

Thanks for the clarification, Tomas!

I understand your point about maintaining consistent standards across the entire codebase. The Levels approach definitely makes sense for long-term, project-wide quality improvements.

My goal with --dirty was mainly to provide a faster feedback loop during the initial adoption phase in very large legacy projects, where running Rector for the first time can be quite heavy. A “dirty-only” mode felt like a practical bridge for teams onboarding Rector gradually.

Still, I appreciate your perspective and the direction you want to keep Rector moving in. Thanks again for your time and for the amazing work you do with this tool! 🙌🔥