[FIX] Status Bar Triggers

[Avni2000]

• Status bar triggers on git merge now, checking for conflicted .ipynb files with git UU
• Closes Merge should TRIGGER check for conflicted notebooks #82

Summary by CodeRabbit

• New Features

  • Integrates with VS Code Git extension to monitor repository state.
  • Adds a test-mode command to report status bar visibility and text.

• Improvements

  • Status bar and file decorations now update more reliably on repository and editor changes.
  • Activation updated to perform status updates non-blockingly and handle missing/disabled Git support gracefully.

[coderabbitai]

Warning

Rate limit exceeded

@Avni2000 has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 23 minutes and 49 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

📝 Walkthrough

Walkthrough

Adds VS Code Git extension API integration: new TypeScript typings, registerGitStateWatchers() in src/extension.ts, activation wiring to the Git API, removal of the old .git/index filesystem watcher, status bar state refactor, and a test command exposing status bar state. Also adds vscode.git extension dependency in package.json.

Changes

Cohort / File(s)	Summary
Extension core src/extension.ts	Integrated with VS Code Git API: added registerGitStateWatchers(context), replaced filesystem index watcher with Git API-driven repository/state listeners, refactored status bar state to statusBarVisible, updated activation to register Git watchers and call updateStatusBar non-blocking, and added merge-nb.getStatusBarState test command.
Git typings src/typings/git.d.ts	Added TypeScript declarations for Git integration: RepositoryState, Repository, API, and GitExtension interfaces used internally for the Git API wiring.
Manifest package.json	Added extensionDependencies: ["vscode.git"] to declare explicit dependency on the built-in Git extension.

Sequence Diagram

sequenceDiagram
    participant Ext as Extension
    participant GitExt as VSCode Git Extension
    participant Repo as Repository
    participant Deco as Decoration/Status Manager

    Ext->>GitExt: request getAPI(1)
    alt Git API available
        GitExt-->>Ext: Git API
        Ext->>Ext: registerGitStateWatchers(context)
        Git API->>Ext: onDidOpenRepository / repository.state.onDidChange
        Ext->>Deco: refresh decorations & update status bar
        Repo->>Ext: state.onDidChange events
        Ext->>Deco: refresh decorations & update status bar
    else Git API unavailable
        GitExt-->>Ext: unavailable -> log warning, do not register watchers
        Ext->>Deco: rely on editor/file events only
    end

Loading

Estimated Code Review Effort

🎯 3 (Moderate) | ⏱️ ~22 minutes

Poem

🐇 I hopped through code with eager paws,
I listened for the Git extension's calls.
When repos awake, I flash and sing,
Status and marks — I tip my spring.
A tiny hop for tests and awe ✨

🚥 Pre-merge checks | ✅ 5 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 25.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title '[FIX] Status Bar Triggers' is concise and directly related to the main change—integrating Git API to trigger status bar updates on git merge events.
Linked Issues check	✅ Passed	The PR addresses issue #82 by implementing Git API watchers to detect repository state changes, including merge events, and trigger status bar updates when conflicted notebooks are detected.
Out of Scope Changes check	✅ Passed	All changes are in scope: Git API integration, type definitions, extension dependency declaration, and status bar triggering logic directly support the objective of detecting conflicted notebooks on merge.
Merge Conflict Detection	✅ Passed	✅ No merge conflicts detected when merging into main

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch status-bar-updates

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In `@src/extension.ts`:
- Around line 137-146: The function registerGitStateWatchers currently returns
true immediately when extension.activate() is fired asynchronously; change it so
that when the Git extension is not active you return false (so the caller will
create the .git/index fallback) and attach a .catch() to the promise from
extension.activate() to handle activation failure and log or fall back;
specifically, update the branch where extension.isActive is false to call
extension.activate().then(exports => onGitReady(exports as GitExtensionExports |
undefined)).catch(err => { /* handle/log and ensure fallback remains */ }) and
return false instead of true, leaving the existing immediate-return-true only
for the extension.isActive path so callers can rely on the boolean to decide
whether to set up the filesystem fallback.

🧹 Nitpick comments (1)

src/extension.ts (1)

165-165: Floating promise: prefix with void for consistency.

Other call sites (lines 111, 125, 312) use void updateStatusBar() to explicitly discard the promise. This call should match.

-	updateStatusBar();
+	void updateStatusBar();

[coderabbitai]

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

src/extension.ts (1)

304-316: ⚠️ Potential issue | 🟡 Minor

Floating promises from updateStatusBar() in file-watcher callbacks.

Lines 306, 310, and 314 call updateStatusBar() without void or .catch(), creating unhandled-promise-rejection risk if gitIntegration.isUnmergedFile throws. The Git-watcher callbacks on lines 115 and 325 already use void updateStatusBar() correctly — apply the same pattern here (and on line 170) for consistency.

Proposed fix

 		fileWatcher.onDidChange(uri => {
 			decorationChangeEmitter.fire(uri);
-			updateStatusBar();
+			void updateStatusBar();
 		}),
 		fileWatcher.onDidCreate(uri => {
 			decorationChangeEmitter.fire(uri);
-			updateStatusBar();
+			void updateStatusBar();
 		}),
 		fileWatcher.onDidDelete(uri => {
 			decorationChangeEmitter.fire(uri);
-			updateStatusBar();
+			void updateStatusBar();
 		})

And on line 170:

-	updateStatusBar();
+	void updateStatusBar();

🧹 Nitpick comments (2)

src/extension.ts (2)

318-328: Dual watchers active when deferred Git activation succeeds.

When registerGitStateWatchers returns false (extension not yet active), the fallback .git/index watcher is created. If the Git extension later activates successfully, onGitReady will register the API-based watchers too — both mechanisms then fire simultaneously, causing redundant decoration refreshes and updateStatusBar calls.

This is not harmful but worth being aware of. If you want to tighten it up later, you could store the fallback watcher's Disposable and dispose it inside onGitReady once the API watchers are confirmed.

---

35-50: Consider using the VS Code Git extension's official type definitions.

The VS Code Git extension ships type definitions (git.d.ts) available in the VS Code repository. The recommended approach is to vendor this file into your extension (e.g., src/typings/git.d.ts) and import the canonical types:

import type { GitExtension, API as GitAPI } from './typings/git';

Also add "extensionDependencies": ["vscode.git"] to package.json to ensure activation order. This approach keeps types in sync with API changes automatically and avoids manual interface maintenance.

The current hand-rolled interfaces are sufficient for your use case, but adopting the shipped types aligns with VS Code extension best practices.