fix: "-" returns to the list you came from #23

Merged

barrettruth merged 1 commit from fix/up-remembers into main

2026-07-27 23:50:07 +00:00

barrettruth commented

2026-07-27 23:49:06 +00:00

Owner

Checklist

I have read CONTRIBUTING.md.
No AI was used to generate, edit, or review any part of this contribution.

Problem

:CI          ->  ci://neovim/neovim/pr/41010
<CR>         ->  ci://neovim/neovim/job/89964653996
-            ->  ci://neovim/neovim/checks/8739bc59…     ← not where you were

#20 moved this rather than fixing it. The cause is that a job has more than
one parent — the pull request lists it, the commit lists it, its run lists it,
and all three are real places to have come from. A parent derived from the
job's own data can only ever name one of them, and it named the commit.

So - out of a pull request landed on the same set of checks under a different
name, which is a worse answer than the run it used to give.

Solution

Remember it instead of deriving it. Entering a job records the list that was on
screen:

pr/41010          <CR>->  job/89964653996   -->  pr/41010
checks/master     <CR>->  job/90126323325   -->  checks/master
run/30278897599   <CR>->  job/90019927064   -->  run/30278897599
job/90019927064   (opened by URL)           -->  checks/fbcb7a05…

A job opened straight from a URL has no history, so it still falls back to its
commit. The value survives R, since a reload carries the remembered parent
across.

On `ci://…/checks/{oid}`

Worth writing down, since it looked invented: it is the commit-scoped list, and
it is the only name :CI master, :CI HEAD~3, :CI {sha} and a pasted
/commit/{sha}/checks URL can produce. It maps to a real page —
github.com/{owner}/{repo}/commit/{sha}/checks — which is exactly what gX
opens there since #21. pr/{n} is the same content scoped to a pull request,
and it tracks that PR's head as it moves; checks/{oid} is fixed to one commit.

## Checklist - [x] I have read [CONTRIBUTING.md](https://forge.barrettruth.com/barrettruth/ci.nvim/src/branch/main/CONTRIBUTING.md). - [ ] No AI was used to generate, edit, or review any part of this contribution. ## Problem ``` :CI -> ci://neovim/neovim/pr/41010 <CR> -> ci://neovim/neovim/job/89964653996 - -> ci://neovim/neovim/checks/8739bc59… ← not where you were ``` #20 moved this rather than fixing it. The cause is that **a job has more than one parent** — the pull request lists it, the commit lists it, its run lists it, and all three are real places to have come from. A parent *derived* from the job's own data can only ever name one of them, and it named the commit. So `-` out of a pull request landed on the same set of checks under a different name, which is a worse answer than the run it used to give. ## Solution Remember it instead of deriving it. Entering a job records the list that was on screen: ``` pr/41010 <CR>-> job/89964653996 --> pr/41010 checks/master <CR>-> job/90126323325 --> checks/master run/30278897599 <CR>-> job/90019927064 --> run/30278897599 job/90019927064 (opened by URL) --> checks/fbcb7a05… ``` A job opened straight from a URL has no history, so it still falls back to its commit. The value survives `R`, since a reload carries the remembered parent across. ## On `ci://…/checks/{oid}` Worth writing down, since it looked invented: it is the commit-scoped list, and it is the only name `:CI master`, `:CI HEAD~3`, `:CI {sha}` and a pasted `/commit/{sha}/checks` URL can produce. It maps to a real page — `github.com/{owner}/{repo}/commit/{sha}/checks` — which is exactly what `gX` opens there since #21. `pr/{n}` is the same content scoped to a pull request, and it tracks that PR's head as it moves; `checks/{oid}` is fixed to one commit.

barrettruth added 1 commit

2026-07-27 23:49:06 +00:00

fix: "-" returns to the list you came from

quality / Test (pull_request) Successful in 6s

Details

quality / Format (pull_request) Successful in 10s

Details

quality / Lint (pull_request) Successful in 10s

Details

062578ac0d

A job has more than one parent. The same job is listed by the pull request,
by the commit, and by its run, and all three are real places to have come
from. Deriving the parent from the job could only ever name one of them, so
"-" out of a job opened from a pull request landed on the commit: the same
checks under a different name, which is a worse answer than the run it used
to give.

So it is remembered rather than derived. Entering a job records the list that
was on screen, and that is where "-" goes. A job opened straight from a URL
has no such history and still falls back to its commit.

barrettruth merged commit 461eca4d5a into main

2026-07-27 23:50:07 +00:00

barrettruth deleted branch fix/up-remembers

2026-07-27 23:50:07 +00:00

barrettruth referenced this pull request from a commit

2026-07-27 23:50:08 +00:00

fix: "-" returns to the list you came from (#23)

barrettruth referenced this pull request

2026-07-28 00:01:47 +00:00

docs: say what the log renderer actually removes #26

barrettruth referenced this pull request

2026-07-28 05:30:47 +00:00