fix: reduce history rewrites

[bniladridas]

honest truth
this app rewrites git history by design (it edits commit messages and force-pushes). the pr issue you saw (history constantly changing) is expected with the previous behavior because it rewrote on every push.

what changed

• only rewrites when a commit message would actually change
• only rewrites commits unique to the pushed branch (relative to the repo default branch)
• skips rewriting the default branch entirely
• uses --force-with-lease instead of --force
• updates webpage + readme + changelog (adds v1.4.0 2026-04-09 and unreleased for today)
• removes accidentally tracked pycache/*.pyc files

limits/risks

• still may rewrite branch history when it decides a message needs changing; commit shas can still change and the pr can still show force-push events, just less often
• not safe for shared branches; --force-with-lease only reduces accidental overwrites

testing

• pre-commit hooks + pytest pass locally
• i have not tested end-to-end against the real test repo / a real pr branch yet

[harper-new-line]

HarperBot

The provided diff shows changes to CHANGELOG.md, README.md, and the removal of __pycache__ files. Crucially, the diffs for github_app.py and tests/test_github_app.py are missing, which limits a full analysis of the core application logic and testing improvements.

Here's an analysis of the visible changes:

1. CHANGELOG.md

• Code Quality/Best Practices:
  • The addition of new entries for "Unreleased" and "v1.4.0" follows good changelog practices, providing a clear history of changes.
  • The fix for \ No newline at end of file is a minor but good improvement for file consistency.
  • The content of the new entries describes significant improvements:
    • --force-with-lease: This is a critical security and correctness improvement. Using --force-with-lease instead of --force prevents accidental overwrites of concurrent changes pushed by others, making the history rewriting operation much safer.
    • Skipping default branch: Prevents destructive operations on the main development branch, which is a major safety enhancement.
    • Rewriting only unique/new commits: Improves efficiency and reduces the scope of history rewriting, making the operation less intrusive.
    • Untracking __pycache__ files: Good cleanup and adherence to best practices for Python projects.
• Performance: The changes described (e.g., only rewriting new commits) likely improve performance by reducing the scope of git filter-branch operations.
• Correctness: The switch to --force-with-lease and skipping the default branch significantly improves the correctness and safety of the application's git operations.
• Suggestion: The dates (2026-04-10, 2026-04-09) are in the future. While this might be a placeholder for a draft, for an actual release, these should reflect the real release dates. However, this is a documentation detail and not a code quality issue in the context of the diff. No specific diff suggestion is needed for CHANGELOG.md itself, as the changes are positive.

2. README.md

• Code Quality/Correctness: The current diff removes the entire description of the app's functionality and the associated warning about history rewriting. This is a significant regression in documentation quality. The README.md should clearly explain what the app does, and the new, safer behavior (e.g., --force-with-lease, skipping default branch) should be highlighted, not removed. While the app is now safer, rewriting history is still a destructive operation that collaborators should be aware of.
• Suggestion: The description of the app's operation and the warning should be restored and updated to reflect the new, safer behavior.

README.md
@@ -6,9 +6,4 @@
 Next, install the app on your desired repository or organization. Then, set the required environment variables: `GITHUB_APP_ID` with your app's ID, `GITHUB_PRIVATE_KEY` with the content of the private key file (paste the entire PEM content), and `GITHUB_WEBHOOK_SECRET` with the webhook secret you generated. Run the app locally with `python github_app.py` for testing, or deploy it to a production server like Render, Heroku, or AWS, updating the webhook URL accordingly to ensure it's publicly accessible.
 
-The app operates by receiving push webhooks from GitHub. When a push is made to a repository where the app is installed, GitHub sends a webhook payload to your deployed app endpoint. The app then generates an installation access token using the installation ID from the webhook, clones the repository using that token for authentication, checks out the affected branch, and executes `git filter-branch` to modify commit messages by removing " add ", " Add ", leading "add ", or leading "Add " phrases. Finally, it force pushes the rewritten history back to the branch, skipping actions if the push originated from a bot to prevent infinite loops.
-
-Be warned that this app rewrites git history, which is a destructive operation that can overwrite remote commits and affect collaborators. Always back up your repository before using it
+The app operates by receiving push webhooks from GitHub. When a push is made to a repository where the app is installed, GitHub sends a webhook payload to your deployed app endpoint. The app then generates an installation access token, clones the repository, checks out the affected branch, and identifies new commits relative to the default branch. It then rewrites the messages of these new commits, if necessary, by removing " add ", " Add ", leading "add ", or leading "Add " phrases. The rewritten history is then pushed back to the branch using `--force-with-lease` to ensure safer updates. The app skips rewriting the repository's default branch and also skips actions if the push originated from a bot to prevent infinite loops.
+
+While the app uses `--force-with-lease` for safer history rewriting, it is still a destructive operation that modifies commit history. Exercise caution and ensure collaborators are aware of its behavior.

3. __pycache__/*.pyc files

• Best Practices: The removal of __pycache__/*.pyc files from version control is an excellent practice. These are compiled bytecode files that are generated automatically by Python and should not be committed. This prevents unnecessary diffs, merge conflicts, and keeps the repository cleaner.
• Suggestion: No further suggestions needed; this change is a direct improvement.

Missing Diffs:

The absence of diffs for github_app.py and tests/test_github_app.py prevents a complete analysis.

• github_app.py: Without the code, it's impossible to verify if the new logic (e.g., --force-with-lease, identifying new commits, skipping default branch, Redis integration) is implemented correctly, efficiently, and robustly.
• tests/test_github_app.py: The CHANGELOG.md mentions "Fix tests/mocks around the commit-rewrite behavior." Without the test code, it's impossible to assess the quality, coverage, and correctness of these fixes. Good tests are crucial for ensuring the new, safer git operations work as intended.

[harper-new-line]

HarperBot Analysis for 23535a0

[harper-new-line]

HarperBot Analysis for 7b98f8e

[harper-new-line]

HarperBot Analysis for 905051c

[harper-new-line]

Suggested change

	The app operates by receiving push webhooks from GitHub. When a push is made to a repository where the app is installed, GitHub sends a webhook payload to your deployed app endpoint. The app then generates an installation access token using the installation ID from the webhook, clones the repository using that token for authentication, checks out the affected branch, and executes `git filter-branch` to modify commit messages by removing " add ", " Add ", leading "add ", or leading "Add " phrases. Finally, it force pushes the rewritten history back to the branch, skipping actions if the push originated from a bot to prevent infinite loops.
	Be warned that this app rewrites git history, which is a destructive operation that can overwrite remote commits and affect collaborators. Always back up your repository before using it, and communicate with your team to avoid conflicts.
	The app operates by receiving push webhooks from GitHub. When a push is made to a repository where the app is installed, GitHub sends a webhook payload to your deployed app endpoint. The app then generates an installation access token using the installation ID from the webhook, clones the repository using that token for authentication, checks out the affected branch, and identifies commits unique to it (relative to the default branch). It then modifies commit messages in these unique commits by removing " add ", " Add ", leading "add ", or leading "Add " phrases. Finally, it pushes the rewritten history back to the branch using `--force-with-lease`, skipping the repository's default branch and actions if the push originated from a bot to prevent infinite loops.
	The app operates by receiving push webhooks from GitHub. When a push is made to a repository where the app is installed, GitHub sends a webhook payload to your deployed app endpoint. The app then generates an installation access token, clones the repository, checks out the affected branch, and identifies new commits relative to the default branch. It then rewrites the messages of these new commits, if necessary, by removing " add ", " Add ", leading "add ", or leading "Add " phrases. The rewritten history is then pushed back to the branch using `--force-with-lease` to ensure safer updates. The app skips rewriting the repository's default branch and also skips actions if the push originated from a bot to prevent infinite loops.
	While the app uses `--force-with-lease` for safer history rewriting, it is still a destructive operation that modifies commit history. Exercise caution and ensure collaborators are aware of its behavior.

[bniladridas]

/merge

[harper-new-line]

Merged via merge by HarperBot.