Stop file processing when git repository is locked#107
Conversation
Adds git lock detection to prevent unnecessary processing during branch switches, merges, and rebases. When a git lock is detected: - Sets isRepositoryLocked flag to stop all file processing - Clears pending files queue to prevent stale injections - Notifies user that rebuild is required to resume - Automatically resets when app reconnects (after rebuild) This prevents injection attempts when the app state no longer matches the source code, improving reliability during git operations. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
|
Hi @karim-alweheshy, I wonder if rather than adding still more processing each time a file is injected we could use the FileWatcher.INJECTABLE_PATTERN to detect .lock files in real time and when they are modified spike the processing of files in InjectionHybrid.inject(source:) rather than modifying NextCompiler.swift. This filtering of changes is long overdue but we only need to be doing it for the FileWatching version of injection. I've created branch |
Based on review feedback, moved git lock detection to use FileWatcher pattern matching instead of checking on every injection: - Extend FileWatcher.INJECTABLE_PATTERN to include .lock files - Detect lock files in InjectionHybrid.inject(source:) only - Keep NextCompiler unchanged - no overhead on SourceKit monitoring path - Clear pending queue and stop processing when lock detected - Auto-reset on client reconnect (rebuild) This approach is more efficient and only affects the FileWatcher code path, making it long-overdue filtering for file watching injection. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
5ca03e7 to
3ff85cf
Compare
|
That was quick and exactly what I meant! If you change the base branch to git-locks I can merge this straight away. |
|
Was thinking it might be better to print that processing has been stopped each time you try to inject rather than just once. Also better perhaps to say they have to "relaunch" than "rebuild". |
- Show message on every injection attempt while locked (not just once) - Change "rebuild" to "relaunch" for clarity - Users see feedback each time they save a file during git operations 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
|
LGTM, tell me you've tested that it works and I'll merge. |
|
Branch switches/merges/rebases update source files while git locks are active. Attempting injection during these transitions wastes CPU and causes errors since the running app no longer matches the source. Commits: Lock created/removed quickly → processing continues ✅ |
Replaced time-based window with deterministic lock existence check: - When git lock detected, store path for later checking - When source file changes, check if lock still exists on disk - If lock exists: source changing during git op = lock processing - If lock gone: was just a commit = allow processing This avoids false positives from commits while accurately detecting branch switches, merges, and rebases without arbitrary timeouts.
2cc64a8 to
87b73b1
Compare
|
I'm wondering if it was bad advice to switch to file watching. You can implement this how you like as long as it doesn't slow down injection. |
|
i think it works fine now. we wait until a file changes after lock changes to detect a rebase, pull, merge |
|
OK, use it for a while and let me know when it has bedded in. |
Adds git lock detection to prevent unnecessary processing during branch switches, merges, and rebases. When a git lock is detected:
This prevents injection attempts when the app state no longer matches the source code, improving reliability during git operations.