Repository navigation
Post 19.4: sync main and core - #6034
Merged
Merged
Conversation
Keeps the scope list in line with identity-service, which now requests read:attachment:jira so a connection can download issue attachments.
- Skips a merge target whose branch git confirms is gone, whether the user's pick, the detected target or the pull request's base, so resolution falls through to the base and default branch. Kepler is about to record stacked-parent PR bases in the shared gk config key, which would otherwise strand GitLens on the parent once it merges and is pruned - Keeps a target whose check can't complete (timeout, error, cancellation, or a provider without the check) and never clears the stored keys; an unchanged detected target isn't rewritten either - Adds the optional getSymbolicReferenceNameOrMissing to the refs provider, reusing the cached rev-parse so a target that exists costs no extra git call
* fix(integrations): resolve viewer identity for Jira, Linear and Trello getProviderCurrentAccount (the hook getCurrentAccount's cache relies on) was only implemented for the git hosts and Azure DevOps, so consumers had no way to know which issues in a Jira/Linear/Trello read belonged to the current user even though the underlying issue fetch worked fine. Jira resolves the account against its first visible resource (there's no account-wide "who am I" endpoint there); Linear and Trello's own account lookups already ignore the resource argument, so their per-resource and current-account paths now share one implementation. listIssueTrackerIssuesPage also fires (but doesn't await) getCurrentAccount once per read: PR and sweep reads already trigger it via getCurrentAccountId, but issue reads never did, so nothing populated the cache for any provider on that path. * fix(integrations): warm current-account cache after the forced refresh The background getCurrentAccount trigger ran before forceRefreshIfRequested, so a forced sync could populate the account cache from the pre-refresh session and spuriously record a stale-token failure. * fix: await viewer-identity warmup instead of firing it and forgetting listIssueTrackerIssuesPage's mapper reads getCurrentAccount's cache synchronously right after the read call returns. A fire-and-forget call races that read, so the first page's assignedToMe/authoredByMe can stay unresolved with nothing to remap it later. * fix(integrations): align tracker current-account with main's read and drop extra requests - main's getCurrentAccount read refused trackers by design; Jira Cloud, Linear and Trello now answer it, so the test, doc comments, capability matrix and core docs say so, and only Jira Data Center refuses - drops Jira's private per-token account map: it pinned a failed lookup as undefined and survived re-sync and disconnect, while the base getCurrentAccount already caches through the host cache - Linear and Trello share one viewer request between the issue-read warmup and the per-resource lookup, keeping the team-search request count at two - the warmup stays awaited because hosts (Kepler's getViewerAccount) read the current-account cache synchronously while mapping the page; the comment that pointed at an in-package mapper is gone * fix(integrations): let the host cache own Linear and Trello viewer freshness The host-path viewer lookup now always asks the provider, so the host's current-account cache (expiry, forced refresh) decides when a profile is re-read. The answer is lent to the per-resource lookup a tracker read makes right after it, for at most a minute, and the loan is dropped on invalidateDiscoveryCaches. Only resolved accounts are lent.
- `watch()` and `getSession()` keyed sessions on the raw path a host passed, while status reads fence on `getRepositoryKey(path)`, so on Windows a drive-letter case or separator mismatch advanced the status clock under the wrong key and left in-flight reads joinable after a change - Every session, event and hook now carries the normalized key, so two spellings of one repository share a session and no host has to pre-normalize
- The shared `.git` watcher matched every linked worktree's index, HEAD and paused-operation files and reported them as `worktrees` to every worktree of the repository, so one `git add` woke all its siblings. Each worktree already watches its own gitdir, so those files now reach only their owner - `worktrees` now means the worktree list, or what `git worktree list` reports per worktree (HEAD, lock, location), changed; a sibling's HEAD change still reaches the others because their cached worktree lists are stale - A main checkout stops receiving every shared `.git` change twice (its own watcher plus the shared one) once a linked worktree is watched
- The repo and working-tree debounces re-armed on every event and had no ceiling, so a steady stream (a long rebase, a build writing into the working tree) deferred every flush until it stopped. A flush now happens no later than a max-wait after the first pending change: 2 s for repo changes and 10 s for the working tree by default, per subscriber via `maxWaitMs`, with the shortest winning like the delay - Recording a raw event costs a timestamp and a Set add: the timer is a trailing deadline armed once per window, and the change event is built at flush instead of copied per event
- Change events said only that some branch, remote or tag moved, so a host watching a linked worktree had to wake on every sibling's commit. Events now carry the ref names whose files changed, with `mayHaveChangedRef` treating nameless changes (a `packed-refs` rewrite, a config change, an injected change) as moving every ref of that kind
- `subscribe({ relevantRefs })` narrows one subscription's events to changes that may move a listed ref. It's per subscription because GitLens shares sessions between consumers; the debounce, other subscribers and cache invalidation still see every change
- FETCH_HEAD maps to no repository change, so it reached only the per-watch `onFetchHeadChanged` hook. GitLens's `Repository` force-fires `lastFetched` from that hook, but a standalone `createCliGitService` host has no such model, so its cached last-fetched time was never re-read after a fetch - `RepositoryWatchService.onDidChangeFetchHead` fires before the hooks, and the standalone service bridges it to the cache. GitLens keeps its forced route, so it doesn't see `lastFetched` twice
- Kepler counts a task branch's own commits against the base it was cut from with a rule core's merge-target tiers don't match: only recorded bases (never a reflog guess, which on a long-lived checkout names whatever branch was last visited), stale targets fall through, and each base is measured as itself or its tracking ref, whichever forked nearer HEAD. Moving it into core lets the worktree summary carry the count and recompute it only when a ref it depends on moves - `dependsOn` names those refs in full and comes with every answer, a no-base one included, so a watcher can skip every other ref change and still hears when a fetch makes a base appear; core's existing merge-target tiers and their reflog write-back are unchanged - A base that is the branch itself, by name or as its copy on one of the repo's remotes, at HEAD's own commit answers no base, as Kepler's rule does: an up-to-date `main` targeting `origin/main` is no signal, not "0 ahead", which task-stage rules read very differently - A count that can't be read rejects with git's error rather than answering no base, so a host keeps its last value instead of showing a wrong one. The shared count cache keeps a failed count, so a failure is re-counted uncached before it rejects
- The working-tree post-filter read only the root `.gitignore`, so files ignored by a nested one (a package's `dist/`, generated code) still woke every subscriber with a refresh. It now loads every `.gitignore` git reads and decides the way git does: deeper files override shallower ones, and nothing beneath an ignored directory can be re-included. An edited nested `.gitignore` reloads the rules (a burst of edits costs one trailing reload) and still reaches subscribers as a changed file - `info/exclude` was read from a linked worktree's own git dir, where it never exists, and the three root sources were added in whichever order their reads finished, so precedence was random - `core.excludesFile` was read raw, so a `~/` path never resolved, and nothing was read when it was unset, though git then reads `$XDG_CONFIG_HOME/git/ignore` (else `~/.config/git/ignore`) - Matching was always case-insensitive; it now follows `core.ignorecase` (else the platform default), so in a case-sensitive repository a real change under `Build/` is no longer dropped by a `build/` rule - Where its matcher can't tell (a deeper file re-including a directory a shallower one ignored), it answers "not ignored", which costs a refresh rather than a missed change
- The working-tree watcher was `createWatcher(repoPath, '**')` with no way to say what to skip, so a native recursive watcher put an OS watch on every directory of `node_modules`, build output and every other ignored tree, then dropped their events in JS. `createWatcher` now takes `excludes`, and a provider that prunes natively says so with `supportsExcludes` - Core computes the set: `**/node_modules` and `.git` always, the unread `.git` subtrees (objects, logs, hooks, …) for `.git` watchers, and for a pruning provider the directories an ignore rule matches. That list comes from git, confirmed with `check-ignore`, because `ls-files --directory` also lists directories whose contents merely happen to be ignored today, and pruning one of those would hide the next real file created there - When ignore rules change, the working-tree watcher is re-created (new before old, so nothing is missed), and a directory that stops being excluded is reported as an incomplete change since its files changed unseen. GitLens's VS Code provider ignores the option, so it pays no new git reads - An ignored directory created after the watcher started (a first build's `dist/`) is noticed from its first filtered events and pruned too, so the build's output stops crossing into JS
- A native watcher can drop events (an inotify queue overflow, FSEvents' "must rescan", a Windows buffer overflow) and the seam had no way to say so, leaving caches and subscribers stale until the next unrelated change. `FileWatchEvent` gains an `overflow` reason - A working-tree overflow becomes an incomplete batch, which consumers already treat as "refresh everything", and reloads the ignore rules, since a lost `.gitignore` edit would leave them stale. A `.git` overflow delivers every kind a watcher can report rather than `unknown`, which the cache treats as a close and would unregister the repository - A reported directory stands for everything beneath it, since a watcher only sees a new directory after its create event and can miss its first files, so `RepositoryWorkingTreeChangeEvent.changed` matches files under a changed directory - `RepositoryInitWatcher` reports an overflowed path as a possible new repository, so the host rescans it rather than missing a `git init` or clone
- Hosts that show a worktree's branch, upstream, ahead/behind, dirty state and distance from its base (Kepler's task board today, GitLens's views later) re-read all of it on a timer or on any change, because only core knows which change can move which field. `GitService.summaries` keeps one summary per subscribed worktree and re-reads only the affected fields: an edit runs only the dirty probe, the upstream moving reads only the branch, an unrelated branch or tag moving reads nothing - One read runs per worktree at a time with later events merged into a single follow-up, subscribers hear only actual value changes, and a failed read keeps the last values marked `stale` (re-read in full on the next event); a base that alone fails to read keeps its last value without holding back the fields that read fine. It watches only while subscribed - A `gk` config write re-reads only the branch's stored merge targets and recorded base, and the base itself only when one changed, since most of those writes are bookkeeping timestamps shared by every worktree of the repository
- The watcher reports `gkConfig` for every `.git/gk/config` write, and GitKraken tools rewrite that file with activity timestamps on each branch visit, so a host treating `gkConfig` as "merge target changed" refetched base-relative views constantly; Kepler kept its own gk/config watcher and key snapshot to avoid that. The cache's reconcile already knew which branches' merge keys actually changed, so `onDidChangeMergeTargets` (on `Cache`, `GitProvider` and `GitService`) reports exactly that, once per repository, after the derived caches are cleared - It never fires for timestamp-only rewrites or core's own writes. A branch delete's or rename's section rewrite wasn't recorded in the merge-key snapshot, so the reconcile read core's own change as external; it's recorded now. `refs` is `undefined` (any branch may have changed) for the coarse fallback or when there's no earlier snapshot to diff against
- Kepler memoizes whether a branch's work has landed in its base per worktree, and without commit IDs it could only key that on the branch, base ref and counts. A commit plus a fast-forward of the base inside one refresh window leaves every count the same, so it served a stale answer. `WorktreeSummary.sha` (HEAD's commit) and `base.sha` (the base ref's tip) let a host key on commits, and a changed commit alone now fires - HEAD's commit comes from the branch read's `for-each-ref`. The base tip comes from the same cached ref list, resolved in git's own order so it is the commit the count was measured against (`AheadOfBase.base.sha`); only a recompute of the base alone re-reads that list, when the ref move that triggered it cleared it - A base named like a tag resolves to the tag, as git does, so `dependsOn` now names `refs/tags/<name>` too and the tag moving recomputes the base
- A batch read drops a target it can't check and reports why in a warning, but the warning named only the provider and connection. A caller that merges several callers' targets into one call (Kepler coalesces concurrent link checks) couldn't tell whose target was refused, so one org refusing the credential failed every caller in the call. Each warning `getPullRequestsBatch`, `getIssuesBatch` and `getPullRequestsForBranches` raise while reading now names the keys it concerns in `targetKeys`: the target refused or failed, or every target of an integration call that failed as a whole - A warning without keys refused the whole call before any target was read, so absence still means "every target". Keys aren't part of a warning's identity: equal warnings merge their keys rather than one being dropped, which would lose a target's failure
- `getAheadOfBase` measured a tag-named base against a commit count cached by the tag's name, and a tag change cleared the ref list but not that count, so after a force-moved tag it kept answering the old count. The worktree summary, which now re-reads the base when its tag moves, published the tag's new commit beside that stale count. A tag change now clears the cached counts, and the merge bases the GitHub provider caches the same way, as a branch move already did
- Kepler's watch bridge narrows each linked worktree's subscription to the refs that can move its base, and the summary kept that list private, so Kepler called `getAheadOfBase` again on every attach and head, heads or config change, repeating the summary's own base read. `WorktreeSummary.baseDependsOn` exposes it, taken from that read and given with or without a base, and a change to the list alone fires - The summary value is now the only copy of the list; the service decides which ref moves re-read the base from it rather than from a private duplicate
* Forwards Jira page metadata through the paged reads and drains
provider-apis drops a Jira issue it can't normalize and reports it in the
search page's `metadata` (GKDEV-3652). The paged wrappers kept only
`{ data, hasMore, nextCursor }` and `drainJiraIssues` only `data`, so the
issue vanished from every project read with no warning.
- Types the Jira search fns with the `metadata` the SDK's `PagedResult`
declares, so this works on the current 0.63.0 pin, whose client methods
infer it only from the release that ships GKDEV-3652
- Maps every Jira search page through one `toJiraIssuePage`, keeping
`metadata` when the SDK reported something
- A page that dropped issues makes the drain `incomplete` without stopping
it, with its failures scoped to what the drain reads (the project); a
user-scoped search across projects that hits one is read project by
project, as Linear does for an incomplete search
- An all-unreadable page (GKDEV-3653's empty `partial` page) keeps its
failure when a later page throws or names a missing project
Refs #5992
* Reports dropped issues and failed sites in the Jira account-wide reads
Both account-wide loops now merge each page's SDK metadata, so an issue
provider-apis dropped because it couldn't read it reaches
`searchMyIssuesWithTruncationResult` as a `partial` result with its
failure, instead of vanishing. Data Center records it under the read's own
scope, as its other failures are.
Jira Cloud drains each site with `collectProviderPagedResult` scoped to
that site instead of a hand loop that swallowed any site that threw (which,
until provider-apis reports an all-unreadable page as `partial`, is what
one such page does). A failed site keeps what it read and is recorded as
that site's failure, so a refused site goes through the scoped auth check
rather than expiring the connection; a backstop or a stalled continuation
makes the read `truncated`. The values-only `searchMyIssues` path logs
those failures, as the old loop did.
Closes #5992
…hunks (#6002) * Addresses Jira projects and sites by their keys Jira Cloud's per-project read passed the project's display name, which JQL resolves against project keys first, so a project named like another project's key read that project's issues. It now reads by key, as the multi-project search does, and attributes its failures to the key. listProjects publishes a Jira project's key as its name and its site's id as the new orgId, and listIssueTrackerIssuesPage selects Jira sites and projects only by those keys, so a remembered selection whose site or project was removed no longer resolves through an old name or id to another one. Linear and Trello keep matching any identifier. * Adds a CANCELED issue state category that closes like DONE Abandoned work (canceled, duplicate, removed) gets its own category so a consumer can tell it apart from finished work, and toIssueShape and fromProviderIssue close it as they close DONE, keeping Jira's gate on an untrusted category. No provider emits it on the pinned provider-apis yet (GKDEV-3655). * Reads a single Jira Cloud project on its own instead of searching it Now that the per-project read addresses the project by key, a one-project search is that project's read at the same cost, and the read attributes a failure to the project and drops a project list that no longer has it. * Fixes Linear's cheap etag check treating duplicate issues as open provider-apis maps Linear's duplicate state to DONE, as it does canceled, so the full read closes a duplicate issue; the cheap check left it open and the two computed different etags.
…s and CANCELED (#6003) * Bumps provider-apis to 0.65.0 0.65.0 reads Jira issues whose type hides a field such as Fix versions, which failed their whole search page (GKDEV-3652), reports an issue it still can't read as page metadata, and returns a page whose every issue is unreadable as partial instead of rejecting it (GKDEV-3653). Linear's canceled and duplicate states are now CANCELED (GKDEV-3655). Its client methods type that metadata, so the provisional search type #5993 added is gone, and the Linear comments and tests describe the CANCELED mapping. * Addresses Jira Data Center projects by their keys provider-apis 0.65.0 reports the project key from /rest/api/2/project (GKDEV-3654), so a Data Center project carries it as its key, the value listProjects publishes and listIssueTrackerIssuesPage selects by, where it carried the display name. A project without a key falls back to its numeric id, never its name; the issue reads keep addressing the id.
…eled (#6004) No Azure work item read carried a workflow category, so a Removed (abandoned) work item could not be told apart from a done one, and a work item in a Completed state without a closed date read as open (GKDEV-3655). Every work item read now classifies its rows from the work item type's states endpoint (api-version 6.0-preview.1, which Azure DevOps Server 2020 requires): the point read, the cheap etag read and the project list, keyed on the raw System.State, which is valid because core passes the SDK no state-name map. Removed maps to CANCELED, Completed and Resolved to DONE, and both close. The states reads are cached on ProvidersApi for five minutes per host, project, type and credential (coalesced, at most 256, failures evicted), and distinct types load within the provider fan-out limit. The cheap etag read selects System.State and System.WorkItemType and closes on the same category, so the full and cheap reads keep computing the same etag. A failed states read fails the point and etag reads; a project list keeps its rows instead, as a partial collection with a failure scoped to the project, which the repository-scoped issue read now forwards along with the project read's truncation. provider-apis selects open work items by their closed and resolved dates, so a Removed work item with neither date came back in an open list; the list now keeps only the work items in the states it asked for.
Bumps @gitkraken/provider-apis to 0.65.1, which maps a Jira status category from its stable key rather than its localized name and no longer reads an unknown one as DONE (GKDEV-3656), and drops the Jira gate in toIssueShape (#5864) that the old mapping required. Both land together: either one alone either keeps done issues open or closes every open issue on a non-English instance. Refs gitkraken/kepler#4010
- In a fork whose `main` tracks `origin`, a branch cut from a newer `upstream/main` with no stored target was measured against `main`, so its ahead count included upstream commits `origin` hadn't caught up on - A branch with no stored target or recorded base now uses the start point git's own reflog names (`branch: Created from <name>`), as tier `'created'`, unless the default branch forked strictly nearer (its parent since merged); the default branch itself keeps measuring against its upstream - The created-from and default bases are also compared with the `upstream` remote's copy, which wins only when strictly nearer, so a branch cut from a detached `upstream/main` or rebased onto it counts only its own commits - The reflog is read once per branch per session and only when no stored target resolves; nothing is written back
- The lock line matched anywhere in stderr, so a commit hook whose own `git add` lost the race made core re-run the whole commit, hooks and all - Git takes the lock before doing anything else, so its own failure is the first thing it prints; a lock line further down now fails the run as is
…econds - Kepler expected 0.12's retry on the next read; 0.13.0 deliberately keeps a failure for 30 seconds so a listing's pages and per-type reads fail fast instead of each asking a failing server again - Callers still see the error, never a guessed category, so the behavior stays and the 0.13.0 notes now say so
- `ls-files --directory` collapses an untracked folder to one entry and drops everything ignored inside it, so a new package's `node_modules/` or `debug.log` was missing though `git status --ignored` lists it - A whole-repository `git status --ignored` would fix it but walks every ignored tree, several times the cost on a large repo; instead two cheap `ls-files` reads run side by side and `status --ignored` is asked only about the new untracked folders, never taking `index.lock`
…retried - Core retries an index write only while another process holds `index.lock`, i.e. while it is changing the index, so a retried `commit` can record files an agent or terminal staged during the wait - Kepler used to own that retry and re-verified its staged set before each attempt; `beforeIndexLockRetry` gives it that check back, rejecting to give up or throwing the lock error back to opt out - Opt-in and unset for GitLens, so nothing changes for it
…pstream - `team/fork/feature` split at its first `/` as remote `team`, so a push, a branch fetch or an ff-only pull of a branch on remote `team/fork` went to the wrong remote and branch; a PR-base merge target and the graph's remote tips had the same flaw - The remote is now the longest of the repository's remotes prefixing the name, and the (cached) remote list is read only when a second `/` makes the split ambiguous; push, fetch, pull and the PR-base lookup share one helper for it
- `check-ignore --stdin` reads each line as a pathspec, so a file named `:secret` was answered as `secret` and could come back ignored; a path starting with `:` now goes in as `./:secret` and comes back as given - Takes a `priority` option so a host opening a file can ask for an interactive run, as its own raw `check-ignore` did; `cancellation` moves to the fourth argument
…eams - A host renaming a branch with its remote counterpart had to split the upstream itself, and `remoteName`'s first-`/` split names remote `team` for a branch on remote `team/fork` - Branch reads now carry git's own `%(upstream:remotename)` (Git 2.23+, free beside `%(upstream)`), which `remoteName`, the tracking name and the push/fetch/pull resolution use before any remote-list read - Audited every core caller that splits an upstream: the rest take the remote explicitly or already resolve it; adds coverage for the ff-only pull and the graph's remote tips
- Kepler's "All files" tree reads every tracked and ignored path up front; a `paths` option on `getTrackedFiles`, `getIgnoredEntries` and `getTreeForRevision` lets it load per expanded folder, with git walking only that folder - Scoped ignored listings match `git status --ignored` for the same scope, including a folder inside a new untracked folder - `getIgnoredEntries` takes the same `options` shape as `getIgnoredPaths`, so `cancellation` moves to the third argument
- The default `status --ignored` mode walks every file of an ignored folder to decide it is wholly ignored, so a new package's `node_modules/` cost thousands of file-system calls per listing - On Git 2.16+ the scoped `status` uses `--ignored=matching`, which reports a folder an ignore rule matches without entering it, and folds folders ignored only by file rules back to one entry, so the listing is unchanged; older git keeps the previous mode
…complete (#6025) A Jira Cloud site, Linear organization or Trello board discovery that resolved a session yet answered with no data and no error read as an account with nothing to read. It now carries completeness 'unknown': the issues page is truncated with a retry cursor, and listOrgs / listProjects mark the provider fetchFailed. A discovery answering [] and an unconnected tracker keep their behavior.
* Fixes #6021 - Reports Azure DevOps Server unsettled scope misses When the collections of an Azure DevOps Server connection can't be read, a repository scope named as collection `{vdir}` and project `{collection}` is read as parsed. Since #6009 a batch or branch read that then finds nothing for it fails that target, but the repo-scoped lists published an empty result for it as complete, so a consumer could cache the miss. Azure DevOps Server 2020 answers the issue list's work item query without a project context with 200 and no work items. `resolveRepositoryInputs` now reports which scopes it couldn't settle. `listPullRequestsPage` and `listIssuesPage` keep the other scopes' items but report an unsettled scope that read nothing in a warning and mark the page incomplete. The searches and their counts re-read the collections and refuse a scope whose collection isn't one of them, so they read a listed scope as settling would and need no flag. Refs #6021 * Adds mixed-scope Azure discovery regression tests - #6021
…6019) Jira Data Center project failures named the project by its numeric id in `scope.projectId`, while Jira Cloud and every selector name it by key, so a consumer could not match a Data Center failure to the project it had selected. They now carry the key; the project is still read by id. An `org` or `project` passed to `listIssueTrackerIssuesPage` that matched nothing the connection discovered returned an empty page with no warning, indistinguishable from a project with no issues. It now returns one `kind: 'not-found'` warning carrying `selector: { kind, value }`, with no `fetchFailed` and no cursor. Only a complete discovery reports it: when listing the resources or their projects failed, answered with an error, or was truncated, the read reports that instead. A Linear team read that returns no data now counts as incomplete rather than as an empty team list. Discovery can come from a cache that predates a site or project created since, so a miss is checked once against this connection's lists read past the cache, without clearing any cache or joining a read already in flight, and a match there reads as usual. A cached list that still names a project deleted since is reported from Jira's refusal of its search on the first read, once the lists read past the cache no longer name it, so a project recreated under the same key (a new id on Jira Data Center) is read, and one they still name (a Data Center project an administrator can list but not browse) reads as empty. A miss is reported only once an account lookup, made past any lookup in flight, names the connection's user. On Jira Data Center a refusal counts only when `X-AUSERNAME` names the authenticated user, since the server serves a rejected token as the anonymous user with the same refusal, which is now a failed read with a cursor. Jira Data Center serves a token it rejects as the anonymous user rather than refusing it, answering its project list with `200 []`, which read as complete discovery with no projects and reported a selected project as removed. A response to a credentialed request that names `anonymous` in `X-AUSERNAME`, in any casing, is now an authentication failure for every Jira Data Center read (and any other read through provider-apis); a 401 keeps its own error and body, and a 429 or 5xx its own error. Bitbucket Data Center's credential check no longer takes `anonymous` as a user that authenticated. Jira Cloud project discovery returns the lists the call read rather than reading its cache back after the reads, which a concurrent clear could empty and another read refill with an older list. The cursor tracks projects by resource and id only, so a project whose key is renamed between pages is neither read again nor dropped; a cursor minted with the key still resumes its projects. Fixes #6014
- `commit` and the other typed writes mapped a `beforeIndexLockRetry` rejection to their own error, so a host refusing a retry got a generic "Unable to commit" back instead of the reason it gave - Git.run marks the hook's rejection, and each typed write rethrows a marked failure before classifying git's own
- `getTreeForRevision` took no `cancellation`, unlike the other scoped reads, so a host lazy-loading a folder tree couldn't stop the read for a folder the user collapsed - Concurrent identical reads now share a run only with the same signal, so one caller's abort can't cancel another's
- With a custom fetch refspec (`origin` fetching into `mirror/*`) the upstream's local name isn't its name on the remote, so push, branch fetch, ff-only pull and `trackingWithoutRemote` could name the wrong remote branch; branch reads now carry git's own `%(upstream:remoteref)` as `remoteBranch` - Changes GitLens's push of a single commit too: it now lands on the current branch's upstream rather than a remote branch named like the local one, which differ when local `foo` tracks `origin/bar`
…otes` - Git before 2.23 can't report an upstream's remote, so a branch on remote `team/fork` still read as remote `team`; branch reads there now match the upstream against the remote list, read only when ambiguous - `splitRemoteBranchName` stripped a leading `remotes/` from every name, so a remote named `remotes` never matched; it now strips it only when the name as given matches no remote
- A silent pre-commit hook whose own `git add` lost `index.lock` printed git's lock line first, so the whole commit, hook included, ran again (PR #6029 review) - A retry now also needs git's own exit code 128, which a failed hook never produces: `commit` exits 1 then
- `ls-files --directory` answers a scope inside an ignored folder with the enclosing folder (`node_modules/` for `node_modules/pkg`), and dies on a trailing `/` or a file there, so the 0.14 `paths` option threw on ordinary input - Scopes git's ignore check reports as ignored are answered directly as one entry each and kept out of the listing; a folder still holding tracked files isn't reported, so it lists as before - An ignored folder with no file anywhere below it isn't listed, as git lists none
…ush without one - A branch tracking local `release/2.0` read as being on remote `release`, so a branch fetch or ff-only pull ran against a remote that doesn't exist and `remoteName` named it; publishing a branch tracking local `main` pushed it as the remote's `main` - `%(upstream)` already says `refs/heads/...` for a local upstream, so branch reads keep that as `upstream.local`, unless git reports a real remote (a fetch refspec into `refs/heads/`); the current-branch read used before the branch list loads now reads full names to agree - A reference a host builds without `local` or `remote` on its upstream is looked up in the branch list rather than guessed from its name - A push with no resolvable remote ran a bare `git push` that follows `push.default`, and a reference held from before its remote was removed made git push to a folder of that name; both now reject with `PushError` `noUpstream` before running git, as does pushing the current branch with no upstream (was `other`)
… mix - The graph classified `%D`'s short names by prefix, so a local `team/fork/work` beside remote `team/fork` read as remote, and a local and remote branch of the same short name resolved to one of them, losing the local branch's current and worktree markers (PR #6029 review) - The graph's log now passes `--decorate=full`, so each tip is exactly `refs/heads/`, `refs/remotes/` or a tag, looked up in local- or remote-only maps; a branch tracking a local branch gets its local upstream id - Re-pointing a branch's upstream between a local branch and a remote one of the same short name rebuilds the graph rather than reusing rows with the old upstream, and GitLens's overview-bar upstream jump only takes a branch of the upstream's kind - A local upstream no longer marks a remote branch of the same name as tracked, and showing only the current branch keeps its local upstream
- The summary split the upstream's name against the remote list itself, so a local `release/2.0` beside remote `release` got that remote and a custom fetch refspec got none, unlike the branch read it came from - It now uses `local`, `remote` and `remoteBranch`, reading the remotes only when git reported neither
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| // itself ignored is answered here, as one entry, and left out of the listing | ||
| const scopedEntries = new Set<string>(); | ||
| if (paths != null) { | ||
| const scopes = [...new Set(paths.map(p => (p.length > 1 ? p.replace(/\/+$/, '') : p)))]; |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.