@gitkraken/core-gitlens 0.7.1 → 0.8.0

package/CHANGELOG.md

@@ -6,6 +6,51 @@ The format is based on [Keep a Changelog](http://keepachangelog.com/) and this p
 
 ## [Unreleased]
 
+## [0.8.0] - 2026-09-27
+
+### Added
+
+- Adds compare-and-swap reference updates and a reference delete, so a consumer can move a ref only if it still points where it last saw it. `refs.updateReference(repoPath, ref, sha, { expected })` passes git's own old-value check (`update-ref <ref> <new> <old>`) when `expected` is a sha, and the empty old value — git's spelling of "must not exist yet" — when it is `'absent'`; `refs.deleteReference(repoPath, ref, { expected })` is the `update-ref -d --no-deref` form — it deletes a symbolic ref itself, never the ref it points to, and refuses `HEAD` — and deletes a local branch the way `git branch -d` leaves things apart from its merged check: refused while checked out in any worktree, with its `branch.<name>` config section and GitLens's per-branch metadata removed alongside. Both throw a typed `ReferenceUpdateError` (`conflict`, `invalidRef`, `invalidObject`, `notFound`, `checkedOut`) and fire the cache and repository hooks a branch, remote-tracking, tag or `HEAD` move fires; a ref in another namespace announces nothing, since nothing core caches can observe it. A cancelled call rejects as `CancellationError`, never `ReferenceUpdateError`, so a host serving `@gitkraken/sync-tools`' compare-and-swap `updateRef` op can tell a refusal from a cancellation (git, git-cli)
+- Adds `worktrees.pruneWorktrees(repoPath, { expire })` and `worktrees.lockWorktree(repoPath, path, { reason })`, the `git worktree prune` and `worktree lock --reason` forms beside the existing `unlockWorktree`, both firing the worktree hooks, and a prune unregistering the worktrees it removed from the cache as `deleteWorktree` does; and gives `createWorktree` and `deleteWorktree` a trailing `runOptions`, so a large worktree's checkout or removal can run without the default per-command timeout and can be cancelled. The thrown `WorktreeDeleteError` keeps git's raw output on `original` for a consumer that classifies a platform-specific failure itself (git, git-cli)
+- Adds `staging.clean(repoPath, { paths, directories, force, ignored })` — `git clean` — the one way to discard untracked files, which `ops.restore` cannot do (git, git-cli)
+- Adds `provider.notifyChanged(repoPath, changes, { cache })` for a consumer that ran a mutation through the raw `git.run` escape hatch. Core invalidates its caches inside its own typed mutators only, so a raw rebase, clean or ref write left every typed read serving the pre-mutation answer until a file watcher's debounce caught up — or forever with no watcher. This clears the named caches (all by default) and fires the same `cache.onReset` / `repository.onChanged` hooks a typed mutator would, so the host's listeners run too; a consumer no longer has to classify git verbs itself to know what to invalidate (git, git-cli)
+- Adds `branch.<name>.remote`, `branch.<name>.merge` and `core.hooksPath` to the documented `GitConfigKeys`, so `config.getConfig` / `setConfig` read and write a branch's upstream pair (including one whose remote ref does not exist yet, which `--set-upstream-to` refuses) and the hooks directory. Writing either upstream key also resets the cached branch list, which reports the upstream (git, git-cli)
+- Adds `fastForward: 'only'` to `ops.pull` (`--ff-only`), spelled as `ops.merge` spells it, with a refused fast-forward reported as `PullError` reason `noFastForward` (as `FetchError` names it) instead of falling through to `other`; a `branch` checked out nowhere is fast-forwarded by fetching `<upstream>:<branch>` rather than only fetching, without `--update-head-ok` so git still refuses a branch that turns out to be checked out. A pull of a branch with no upstream is now `PullError` reason `noUpstream` (git, git-cli)
+- Adds `commits.createCommitFromTree(repoPath, tree, { parents, message, author, committer, sign, source })`, a `commit-tree` with any number of parents and an explicit identity, for a consumer assembling merge commits or replaying commits under their original author. It is now the one path that writes a commit object: the patch sub-provider's commits go through it, and with `sign` it reports a signing failure as `SigningError` and fires the signing hooks, as the patch path did (git, git-cli)
+- Adds `provider.init(path, { defaultBranch, bare })` beside `clone` (git, git-cli)
+- Adds `force` to `refs.validateReference`, `refs.getReference`, `branches.getBranch` and `revision.resolveRevision`, for a read that must reflect a change core was not told about, such as a ref another process moved. A forced read skips the cached answer, never joins a read that started before it, and stores its fresh answer for later reads; `getBranch({ force })` first evicts the branch cascade a branch move clears (git, git-cli, plus/git-github)
+- Documents the decisions above, and what was deliberately left on the raw escape hatch, in `docs/kepler-git-write-api-parity.md`, the write-path sibling of the read-API parity record (core)
+- Adds `getPullRequestsBatch`, which resolves pull requests by coordinate — `(owner, repo, number)`, plus `project` on Azure DevOps — in any state (open, closed or merged). It is the pull request counterpart of `getIssuesBatch`. Until now the manager had only list, search, count and sweep reads for pull requests, so finding one meant scanning its repository's most recently updated pull requests and matching the URL, and an older merged pull request could be neither found nor proven gone. `pullRequest: undefined` means proven absent and is safe to cache; a target whose read failed returns no item and sets `fetchFailed`, while the other targets still answer. On GitHub and GitHub Enterprise, a target GitHub refuses on its own — e.g. in an org enforcing SAML SSO the token isn't authorized for — fails only that target, with GitHub's own message. Rows carry the same fields as the list reads' rows, except on Bitbucket Cloud, where provider-apis has no single pull request read: those rows come from GitLens' own REST read instead and lack `commentsCount`, `isDraft` and the clone URLs. On GitLab, a miss the confirming read then contradicts fails the target rather than answering with the confirming read's own, differently-identified row. Every git host is supported: GitHub and GitHub Enterprise resolve up to 25 targets per request, while GitLab, Bitbucket, Bitbucket Data Center and Azure DevOps cost one request per target. A GitLab miss costs a second request, because provider-apis' GitLab read reports a reply carrying only GraphQL errors the same way as a missing merge request. An Azure DevOps miss is trusted only when Azure itself says the pull request, repository or project doesn't exist, so a 404 from a misconfigured server path is a failure rather than an absence. The read is uncached and does not go through `IntegrationCacheProvider.getPullRequest`, so the caller's cache is the only one holding the answer (plus/integrations, plus/git-github)
+- Adds `getPullRequestsForBranches`, which finds, for each branch, every pull request whose head is that branch, in any state (open, closed or merged), most recently updated first, up to 10 per branch. A target names the repository the pull requests are opened against, the branch's short name and, for a branch in a fork, `headOwner`; a `headOwner` equal to the target's owner means the base repository, so a caller can pass the owner of whichever remote the branch was pushed to. Until now a consumer found a local branch's pull requests by matching the account-wide sweeps, which hold only pull requests the user authored, is assigned or reviews — so a teammate's pull request from the user's branch never correlated — and a cold consumer paid for a whole sweep before it could show one. This read carries no relationship to the user. It matches on the head branch name rather than looking the branch up, so a merged pull request whose branch was since deleted is still found. It also matches the head repository — the base repository itself, or the fork `headOwner` owns — so a `main` in the base repository never claims every fork's `main`. An empty list without `truncated` is a proven none, safe to cache, and a missing base repository reads as one; `truncated` means more may match than were returned; a target whose read failed returns no item and sets `fetchFailed`, while the other targets still answer. GitHub and GitHub Enterprise answer up to 25 branches per request, fetching up to 10 full pull requests each, through the new `GitHubApi.getPullRequestsForBranches`; GitLab, Bitbucket, Bitbucket Data Center and Azure DevOps cost one request per branch, since provider-apis has no source-branch filter on any host and each answers from GitLens' own branch query. On GitLab and Azure DevOps that query only finds the matching numbers, which are then resolved through `getPullRequestsBatch`'s own read, typically 0–1 per branch at that read's cost, so a pull request comes back identical — `url` and `authoredByMe` included — whichever of the two reads found it; one it can't check fails its whole branch rather than leaving a partial list. Rows carry the list reads' fields on GitHub, GitHub Enterprise and Bitbucket Data Center and the by-id read's fields on Bitbucket Cloud. Bitbucket asks for every state explicitly, since it answers only open pull requests otherwise. Bitbucket Data Center and Azure DevOps serve branches in the base repository only and refuse a `headOwner` naming another owner: Data Center finds a branch's pull requests only through the repository the branch lives in, and an Azure DevOps fork shares its organization, so neither can find a fork by its owner. Azure DevOps also requires `project`, and trusts a missing repository only on Azure's own not-found body. The read is uncached and does not go through `IntegrationCacheProvider.getPullRequestForBranch`, so the caller's cache is the only one holding the answer (plus/integrations, plus/git-github)
+- Adds `getCurrentAccount`, answering who a git host connection is signed in as, on demand. Until now the account was knowable only as a side effect of some other read resolving it. It goes through the host-supplied `IntegrationManagerCacheProvider.getCurrentAccount` cache rather than adding a second one. `account` is never absent without a warning: no session, a failed request, or an issue tracker, which has only a per-resource account and refuses (plus/integrations)
+- Adds GitLab (including self-managed) and Azure DevOps (including Server) to `getIssuesBatch`'s coordinate form, which served only GitHub and GitHub Enterprise, so a consumer no longer walks a scoped issue list for them, where a miss could never be proven. A coordinate target gains an optional `project`: Azure DevOps requires it, since work items belong to the project, and ignores `repo`; a call with a target missing it is refused. Each target costs one request, and rows are converted exactly as the repository-scoped `listIssuesPage` converts them, except that an Azure DevOps row has no `project`, which only the account-wide list fills from project discovery. A GitLab issue is proven absent only when GitLab answers a null project or issue, and a miss costs a second request to confirm it, because provider-apis reports a reply carrying only GraphQL errors the same way; any error, a 404 or an empty response fails the target. An Azure DevOps work item is proven absent only when Azure's own 404 body says so — `WorkItemUnauthorizedAccessException` (TF401232, which Azure uses both for a missing work item and for one this connection cannot read) or `ProjectDoesNotExistWithNameException`. An HTML 404, a 410, any other `typeKey`, or any other failure fails the target. Bitbucket and Bitbucket Data Center have no issues and still refuse (plus/integrations)
+
+### Changed
+
+- **Breaking (git, git-cli)** — `refs.updateReference` now THROWS on failure instead of logging and resolving. A ref writer whose failures are invisible by default is the bug, not a mode to opt out of; no caller in this repository relied on the old behavior. Its signature is now `(repoPath, ref, sha, options?, cancellation?)`
+- Every staging mutation (`stageFile(s)`, `stageDirectory`, `stageAll`, `unstage*`, `removeFile(s)`) now fires `cache.onReset('status', 'diff', 'tracking')` and the `index` repository change, except when it targets a temporary index, which is not the repository's. Before this the sub-provider fired nothing, so a consumer that staged through the typed API and then read the status could be answered from the index as it stood before the stage (git-cli)
+- Raises the git process queue's default `maxConcurrent` from 7 to 20, the default of GitLens' own `advanced.git.maxConcurrentProcesses`, so a consumer that configures nothing no longer runs with a third of the concurrency GitLens uses (git-cli)
+- Core now clears its own caches and pending git commands whenever it announces a write through `cache.onReset`, rather than leaving that to each host's handler. A host with no handler kept serving pre-write reads after every typed write, and one that forwarded to `Cache.clearCaches` could still hand a caller that arrived after the write a read, or a git run, that started before it, because `clearCaches` keeps sharing an entry that is still in flight. A write now hard-evicts through the new `Cache.evictCaches`; clears from a file watcher keep sharing in-flight reads. A handler that forwards to `clearCaches` keeps working and is now redundant (git, git-cli)
+- **Breaking (git, git-cli, plus/git-github)** — `refs.validateReference` takes an options object in place of its `relativePath` parameter, `validateReference(repoPath, ref, { relativePath, force }, cancellation)`, and `branches.getBranch` / `refs.getReference` take `options` before `cancellation`. A caller passing a relative path or a cancellation positionally must move it
+- **Breaking (git, git-cli)** — `commits.createUnreachableCommitFromTree(repoPath, tree, parent, message)` is removed in favor of `createCommitFromTree(repoPath, tree, { parents: [parent], message })`, which writes the same commit object
+- **Breaking (plus/integrations)** — Changes `getIssuesBatch` to resolve Jira Cloud, Jira Data Center and Linear issues too, and removes `getTrackerIssue` and `TrackerIssueResult`, which it replaces. A tracker call takes tracker targets, `{ key, resourceId, resourceUrl?, identifier }`, in place of `(owner, repo, number)` coordinates, with the guarantees `getTrackerIssue` gave: `issue: undefined` is a proven absence, a failed read returns no item and sets `fetchFailed`, `resourceId` is trusted and triggers no resource discovery, Jira Cloud requires `resourceUrl`, Trello refuses, and a Jira Data Center call is refused unless `domain` or a configured `connectionId` names its host. A call carrying the other target form is refused whole. Migrate `getTrackerIssue({ providerId, resourceId, resourceUrl, key, connectionId, domain })` to `getIssuesBatch({ providerId, connectionId, domain, targets: [{ key: '…', resourceId, resourceUrl, identifier: key }] })`, where `domain` is needed only for Jira Data Center. Issues now have one identity read, as pull requests do with `getPullRequestsBatch`; a key asked of several resources is answered in one call, one target per resource, rather than one call per resource; and failures are isolated per target within it, so a failing target drops only itself and a call costs the integration at most one strike toward its disconnect budget. Like the other batch reads it is uncached, where `getTrackerIssue` went through `IntegrationCacheProvider.getIssue`, so the caller's cache is the only one holding the answer. `IssueBatchTarget` and `IssueBatchResult` are now exported (plus/integrations)
+
+### Fixed
+
+- Fixes a git command that never started because its cancellation had already fired — the signal was aborted when the call was made, or while the command waited in the queue — rejecting as a `GitError` instead of a `CancellationError`. A typed mutator took that as git refusing the operation and reported a failure of its own, such as a `ReferenceUpdateError` with no reason, where its caller expected a cancellation. An `errors: 'ignore'` run still reports it as `failed`/`unstarted` (git-cli)
+- Fixes a git command given an empty stdin waiting for input until the command timeout killed it. The spawn path only closed git's stdin for a non-empty value, so `patch.createEmptyInitialCommit`, which hashes the empty tree from an empty stdin, failed this way every time, and a commit given an empty message hung for the full timeout instead of being refused (utils, git-cli)
+- Fixes concurrent git runs with the same arguments but a different per-call `env` sharing one result. The executor's in-flight dedup keyed on the command line and ignored the environment, so a run against a temporary index (`GIT_INDEX_FILE`) or with config injected through `GIT_CONFIG_*` could be handed another run's answer. A run with a per-call `env` is now never shared, as one with stdin already wasn't (git-cli)
+- **Breaking (plus/integrations, plus/git-github)** — Fixes `getIssuesBatch` failing every target in its request when one target refuses on its own — e.g. an org enforcing SAML SSO the token isn't authorized for. GitHub answers that case with HTTP 200: the other aliases' data, plus a FORBIDDEN error scoped to the one alias that refused. The read classified the first error in the response and threw for the whole batch, which also ran the integration's auth handling — expiring a cloud session or adding a disconnect strike — for a token that had, in fact, worked. An error whose `path[0]` names one of the read's own generated aliases is now scoped to that alias's target: NOT_FOUND still reads as a PROVEN ABSENCE, anything else fails only that target with GitHub's own message, and the other targets in the request still answer. An error with no `path`, or naming something the read never asked for — rate limits, bad credentials, query-cost errors — still fails the whole request exactly as before. `getIssuesBatch` (on `GitHubApi`, published) now returns one `PromiseSettledResult` per coordinate instead of a plain array — `rejected` for a failed target, `fulfilled` with `undefined` for a proven absence — so a consumer reading the old plain-array return must switch to `.status`/`.value`/`.reason`. An issue that can't be mapped, or a response carrying no data at all, now fails instead of reading as absent, since a false absence would be cached. `getIssuesBatchResult` and the GitHub batch hook behind it change the same way in `plus/integrations`, but `GitHostIntegration` is reachable through neither `index.js` nor `lite.js`, so that side is not a published break (plus/integrations, plus/git-github)
+- Fixes three ways `getIssuesBatch` on GitHub and GitHub Enterprise could misreport a target. A call with no session on the primary connection was reported as the host not supporting the read; it is now a connection warning. More than 25 targets were sent as one integration call per 25, so a batch that failed outright spent one strike toward disconnecting per 25 targets; the whole call is now one integration call and spends at most one. A target with a blank `owner` or `repo` went upstream and came back as a missing repository, a proven absence a caller would cache, and a `number` that isn't a positive integer failed every other target in its request; both now refuse the call, as `getPullRequestsBatch` does. A `number` above 2147483647 — GitHub's GraphQL `Int` is 32-bit — raised a variable-coercion error with no `path`, also failing every other target; it now refuses the call too, on GitHub and GitHub Enterprise only (plus/integrations)
+- Fixes `PullRequestShape.authoredByMe` always being `false` for GitHub and GitHub Enterprise pull requests from the account-wide pull request reads and the sweeps. GitLens' own GitHub GraphQL reads key a pull request's people by their login, while the current account's `id` is GitHub's numeric database id, so an id-only comparison never matched on that path. Authorship now also matches when the two logins agree (plus/integrations)
+- Fixes the batch reads — `getIssuesBatch`, `getPullRequestsBatch` and `getPullRequestsForBranches` — treating a batch whose every target was refused by its own scope as a dead token ([#5890](https://github.com/gitkraken/vscode-gitlens/issues/5890)), e.g. targets all in an Azure DevOps organization that blocks third-party OAuth apps or doesn't accept this PAT, which expired a cloud session or added a disconnect strike. The credential is now confirmed first, with the same cached check the account-wide reads use, and the session is left alone when it passes. A refused target's `auth` warning now carries the `scope` its target names — the Azure DevOps organization and project, the repository on other git hosts, or the tracker's resource — and a `cause` where the provider names one, including when other targets answered (plus/integrations)
+
+## [0.7.2] - 2026-09-25
+
+### Fixed
+
+- Fixes a `ProviderWarning` from a scoped authentication failure being indistinguishable from an account-wide one ([#5890](https://github.com/gitkraken/vscode-gitlens/issues/5890)). A fan-out read that records a failure against one organization, project or repository (for example an Azure DevOps organization with third-party OAuth access disabled answering its project discovery with a 401) produced the same `{ kind: 'auth', isAuth: true }` warning as a dead token, with the scope only in the English `message`, so a consumer could only prompt to reconnect, which can never fix it. Warnings derived from a structured scope failure now carry an optional `scope` (the new `ProviderWarningScope`: `resourceId`, `projectId`, `repositoryId`) naming the part of the read that failed. `kind` and `isAuth` are unchanged, and an absent `scope` still means account-wide or unattributed, so existing consumers keep their behavior. Azure DevOps, Bitbucket and Jira Cloud serve discovery from a per-token cache, where a revoked token would reach only the scopes still requested and look like one scope's refusal. Bitbucket Data Center's repo-scoped pull request read, an SDK fan-out with no request to the connection first, has the same shape. When a read's only authentication failures are scoped, these providers now confirm the credential with one uncached check (at most once a minute for a credential that passed it), and a refused credential fails the read as a connection failure instead, so a scoped `auth` warning means the credential itself was accepted. A refusal the provider pins on the credential, like Bitbucket's or Jira Cloud's for a token missing required OAuth scopes, which a reconnect fixes, is published unscoped too, once for the connection, while the scopes that answered keep their results. Such a warning now also says why the scope refused, through an optional `cause` (the new `ProviderWarningCause` and `ProviderWarningCauseReason`): `reason` is `oauth-app-not-allowed` (the organization's "Third-party application access via OAuth" policy is off, which is the default for new Azure DevOps organizations), `access-denied` or `conditional-access` (`VS403463`), with the provider's `code` and, for the OAuth policy, a `remedyUrl` to the organization's policy page, so a consumer can recommend the fix rather than a reconnect that could never heal it. It is named only once the credential is confirmed, because Azure DevOps answers a disallowed OAuth app with the same bare `401` as an expired token, and only Azure DevOps names causes today. A scope failure's `message` now also carries the provider's own explanation, or the error its response raised (a page reduced to its status), instead of the generic "credentials are either invalid or expired", which said the opposite of a scope refusing a sound credential. Failures of two scopes also stay two warnings rather than relying on their messages differing (plus/integrations)
+
 ## [0.7.1] - 2026-09-24
 
 ### Added
@@ -372,7 +417,9 @@ The format is based on [Keep a Changelog](http://keepachangelog.com/) and this p
 
 - Initial release. Bundles `@gitlens/utils`, `@gitlens/git`, `@gitlens/git-cli`, `@gitlens/ai`, and `@gitlens/git-github` into a single core npm package with subpath exports.
 
-[unreleased]: https://github.com/gitkraken/vscode-gitlens/compare/releases/core/v0.7.1...HEAD
+[unreleased]: https://github.com/gitkraken/vscode-gitlens/compare/releases/core/v0.8.0...HEAD
+[0.8.0]: https://github.com/gitkraken/vscode-gitlens/compare/releases/core/v0.7.2...gitkraken:releases/core/v0.8.0
+[0.7.2]: https://github.com/gitkraken/vscode-gitlens/compare/releases/core/v0.7.1...gitkraken:releases/core/v0.7.2
 [0.7.1]: https://github.com/gitkraken/vscode-gitlens/compare/releases/core/v0.7.0...gitkraken:releases/core/v0.7.1
 [0.7.0]: https://github.com/gitkraken/vscode-gitlens/compare/releases/core/v0.6.0...gitkraken:releases/core/v0.7.0
 [0.6.0]: https://github.com/gitkraken/vscode-gitlens/compare/releases/core/v0.5.116...gitkraken:releases/core/v0.6.0

package/dist/git/cache.d.ts

@@ -124,13 +124,26 @@ export declare class Cache implements Disposable {
   get trackedPaths(): RepoPromiseCacheMap<string, [string, string] | false>;
   get worktrees(): PromiseMap<RepoPath, GitWorktree[]>;
   clearCaches(repoPath: string | undefined, ...types: CachedGitTypes[]): void;
+  /**
+   * Hard-evicts the same cache keys {@link clearCaches} would clear for `repoPath`, but a shared
+   * (commonPath-keyed) entry that is still in flight is deleted outright instead of soft-invalidated —
+   * a caller after this call never joins a read that started before it. Use for a forced read/write
+   * that must not be answered from pre-change work; `clearCaches` remains the right call whenever
+   * letting an in-flight read complete and share its answer with new callers is fine.
+   */
+  evictCaches(repoPath: string, ...types: CachedGitTypes[]): void;
+  private clearCachesCore;
   /**
    * Evicts a single shared (commonPath-keyed) cache entry for `repoPath` and its sibling worktrees.
-   * Prefers `invalidate` where supported so in-flight work is shared across new callers and
-   * self-evicts on settle rather than spawning a duplicate factory. `invalidate` does the right
-   * thing per-entry: entries with a `CacheController` (created via `getOrCreate`) are marked
-   * invalidated; entries without one (created via plain `.set()`, e.g. per-worktree mapper results)
-   * are hard-deleted. Caches that don't support `invalidate` fall back to `delete`.
+   * When `inFlight` is `'share'` (the default), prefers `invalidate` where supported so in-flight work
+   * is shared across new callers and self-evicts on settle rather than spawning a duplicate factory.
+   * `invalidate` does the right thing per-entry: entries with a `CacheController` (created via
+   * `getOrCreate`) are marked invalidated; entries without one (created via plain `.set()`, e.g.
+   * per-worktree mapper results) are hard-deleted. Caches that don't support `invalidate` fall back to
+   * `delete`.
+   *
+   * When `inFlight` is `'evict'`, always hard-deletes regardless of `invalidate` support — a new caller
+   * must never join a read that started before this eviction (see {@link evictCaches}).
    */
   private evictShared;
   /**

package/dist/git/cache.js

@@ -334,6 +334,19 @@ var Cache = class Cache {
 		return this._caches.worktrees ??= new PromiseMap();
 	}
 	clearCaches(repoPath, ...types) {
+		this.clearCachesCore("share", repoPath, ...types);
+	}
+	/**
+	* Hard-evicts the same cache keys {@link clearCaches} would clear for `repoPath`, but a shared
+	* (commonPath-keyed) entry that is still in flight is deleted outright instead of soft-invalidated —
+	* a caller after this call never joins a read that started before it. Use for a forced read/write
+	* that must not be answered from pre-change work; `clearCaches` remains the right call whenever
+	* letting an in-flight read complete and share its answer with new callers is fine.
+	*/
+	evictCaches(repoPath, ...types) {
+		this.clearCachesCore("evict", repoPath, ...types);
+	}
+	clearCachesCore(inFlight, repoPath, ...types) {
 		const keysToClear = /* @__PURE__ */ new Set();
 		if (!types.length) {
 			for (const key of Object.keys(this._caches)) keysToClear.add(key);
@@ -407,6 +420,7 @@ var Cache = class Cache {
 				keysToClear.add("refTips");
 				keysToClear.add("commit");
 				keysToClear.add("commitCount");
+				keysToClear.add("resolvedRevisions");
 			}
 			if (types.includes("tracking")) {
 				keysToClear.add("fileExistence");
@@ -419,23 +433,27 @@ var Cache = class Cache {
 			const cache = this._caches[key];
 			if (cache == null) continue;
 			if (repoPath == null) cache.clear();
-			else if (sharedCacheKeys.has(key)) this.evictShared(key, repoPath);
+			else if (sharedCacheKeys.has(key)) this.evictShared(key, repoPath, inFlight);
 			else cache.delete(repoPath);
 		}
 	}
 	/**
 	* Evicts a single shared (commonPath-keyed) cache entry for `repoPath` and its sibling worktrees.
-	* Prefers `invalidate` where supported so in-flight work is shared across new callers and
-	* self-evicts on settle rather than spawning a duplicate factory. `invalidate` does the right
-	* thing per-entry: entries with a `CacheController` (created via `getOrCreate`) are marked
-	* invalidated; entries without one (created via plain `.set()`, e.g. per-worktree mapper results)
-	* are hard-deleted. Caches that don't support `invalidate` fall back to `delete`.
+	* When `inFlight` is `'share'` (the default), prefers `invalidate` where supported so in-flight work
+	* is shared across new callers and self-evicts on settle rather than spawning a duplicate factory.
+	* `invalidate` does the right thing per-entry: entries with a `CacheController` (created via
+	* `getOrCreate`) are marked invalidated; entries without one (created via plain `.set()`, e.g.
+	* per-worktree mapper results) are hard-deleted. Caches that don't support `invalidate` fall back to
+	* `delete`.
+	*
+	* When `inFlight` is `'evict'`, always hard-deletes regardless of `invalidate` support — a new caller
+	* must never join a read that started before this eviction (see {@link evictCaches}).
 	*/
-	evictShared(key, repoPath) {
+	evictShared(key, repoPath, inFlight = "share") {
 		const cache = this._caches[key];
 		if (cache == null) return;
 		const commonPath = this.getCommonPath(repoPath);
-		const invalidate = cache.invalidate;
+		const invalidate = inFlight === "share" ? cache.invalidate : void 0;
 		if (typeof invalidate === "function") {
 			invalidate.call(cache, commonPath);
 			for (const worktreePath of this.getWorktreePaths(commonPath)) {