Harden `pr_finish()` against subkeys created by VS Code / Positron / GitHub Pull Requests extension

[jennybc]

The GitHub Pull Requests extension does some funny business with branches that it perceives to be PR-related. I haven't delved into the details re: whether it's temporarily changing branch names or shimming some git command or some other third thing.

But whatever malarkey it is, it causes pr_finish() to fail like so:

✔ Switching back to default branch ("main").
✔ Pulling changes from "origin/main".
✔ Deleting local "switch-r-pkg-testing-shortcut" branch.
Error in libgit2::git_branch_delete : 
  could not find key 'branch.switch-r-pkg-testing-shortcut.github-pr-owner-number' to delete

What the heck is this?

branch.switch-r-pkg-testing-shortcut.github-pr-owner-number
                                    ^^^^^^^^^^^^^^^^^^^^^^^

The extension seems to assume that it will be mediating all of your git(hub) work and it can do something like this, which then breaks other tools.

Not sure if it's my / usethis's problem to solve but it's conceivable it would be worth detecting that suffix and trimming it off if this problem persists.

[jennybc]

I just experienced this while trying to use pr_finish() from R running in a terminal inside GitKraken (so not from inside VS Code or Positron). Which suggests the extension really has done something to the local branches. Next time I'm in position to do so, I will try to investigate that.

I also confirmed that closing the VS Code window open to the affected workspace (it was ark) makes pr_finish() magically work again. So simply having a git repo open in VS Code with the GitHub Pull Requests extension enabled is enough to cause this problem.

[jennybc]

I was in position to experience this again, so I did debug(pr_finish) and walked through it manually. And the problem did not occur 🤔

And then I had another chance to use pr_finish() and I removed the debug() and the problem happened as usual 😬

This suggests there something about the timing / order of something the extension is doing in reaction to the git/github operations happening in pr_finish().

[jennybc]

Had another chance to experience. This time I put some debugging print statements in. I also paused a few seconds when contemplating the "Proceed anyway?" question:

> pr_finish()
✔ Setting active project to "/Users/jenny/rrr/ark".
✔ Identifying the associated PR.
✔ PR local branch is "feature/copilot-instructions".
! Local branch "feature/copilot-instructions" has no associated remote branch.
ℹ If we delete "feature/copilot-instructions", any work that exists only on this branch may be hard for you to recover.
  Proceed anyway?

1: Yes
2: Not now
3: No

Selection: 1
✔ Switching back to default branch ("main").
✔ Pulling changes from "origin/main".
✔ Deleting local "feature/copilot-instructions" branch.
# A tibble: 3 × 6
  name                         local ref     upstream commit updated            
* <chr>                        <lgl> <chr>   <chr>    <chr>  <dttm>             
1 feature/copilot-instructions TRUE  refs/h… NA       1073d… 2025-04-04 14:45:02
2 main                         TRUE  refs/h… refs/re… 367aa… 2025-04-07 08:25:16
3 time-travel                  TRUE  refs/h… NA       3851f… 2025-04-03 08:15:13

Did not experience the problem. Was it my pause that "fixed" it?

[jennybc]

No matter what, perhaps it is a good idea to tryCatch() the attempt to delete the local branch:

usethis/R/pr.R

Line 612 in a653d6e

gert::git_branch_delete(pr_local_branch, repo = repo)

If that fails, we could report that more gracefully and do any remaining work.

[jennybc]

Another usage of pr_finish() with a debug(usethis:::pr_clean). Just walked through at a leisurely pace and all is well. More evidence that it's a timing issue related to something the extension is doing.

[jennybc]

@hadley has now bumped into this and we discussed in Slack. His theory is that it's a race condition where multiple tools are working with the repo git config and I think that looks pretty likely.

Here's a bit of .git/config in a repo where I've currently got a PR branch checked out and this repo is open in a VS Code window with the GitHub Pull Requests extension enabled:

[branch "bugfix/completing-nothing"]
	created-by = usethis::pr_init
	github-pr-base-branch = "posit-dev#ark#main"
	vscode-merge-base = origin/main
	vscode-merge-base = origin/main
	remote = origin
	merge = refs/heads/bugfix/completing-nothing
	github-pr-owner-number = "posit-dev#ark#772"
	pr-url = https://github.com/posit-dev/ark/pull/772

In particular, note the key branch.BRANCHNAME.github-pr-owner-nuber which appears in the error message I'm seeing.

In contrast, here's branch metadata in a repo where I've got an open PR but have never touched this repo with VS Code or Positron:

[branch "here-i-am-thoughts"]
	created-by = usethis::pr_init
	remote = origin
	merge = refs/heads/here-i-am-thoughts

• remote and merge are plain vanilla git stuff
• created-by and pr-url are from usethis's pr_*() functions
• github-pr-base-branch, vscode-merge-base (both of them 😬), and github-pr-owner-number presumably all come from the GitHub Pull Requests extension

The error is happening in this call to gert::git_branch_delete():

usethis/R/pr.R

Lines 608 to 613 in a653d6e

	if (!is.na(pr_local_branch)) {
	ui_bullets(c(
	"v" = "Deleting local {.val {pr_local_branch}} branch."
	))
	gert::git_branch_delete(pr_local_branch, repo = repo)
	}

✔ Deleting local "switch-r-pkg-testing-shortcut" branch.
Error in libgit2::git_branch_delete : 
  could not find key 'branch.switch-r-pkg-testing-shortcut.github-pr-owner-number' to delete

It must to something like this:

• Deleting the branch triggers the deletion of this whole set of metadata, i.e. everything associated with the branch
• libgit2 reads the config and notes all of the keys that need to be deleted
• But before it gets a chance to delete them, some other process, under control of the extension, deletes the keys created by the extension, causing the failure to find one of the keys

I note that, even when I see this error message, the branch has actually been deleted.

[jennybc]

Probably happening right around here:

https://github.com/libgit2/libgit2/blob/21a351b0ed207d0871cb23e09c027d1ee42eae98/src/libgit2/config_file.c#L403-L411

[gadenbuie]

This happens to me a lot and I find that calling pr_finish(pr_number) again when it fails cleans everything up nicely. The problem is that calling pr_finish() from with the branch doesn't tell me which PR I'm in, and by the time it fails the UI has already updated.

So one super simple thing you could do to make the problem less ouchy is to print the PR number earlier in the process, for example:

pr_finish()
#> i Finishing PR posit-dev/shinychat/#56
#> ✔ Switching back to default branch ("main").
#> ✔ Pulling changes from "origin/main".
#> ✔ Deleting local "monorepo" branch.
#> Run `rlang::last_trace()` to see where the error occurred.
#> Error:
#> ! could not find key 'branch.monorepo.vscode-merge-base' to delete
#> i Try running `pr_finish(56)` again to complete the operation.

pr_finish(56)
#> ✔ Deleting local "monorepo" branch.
#> ✔ PR posit-dev/shinychat/#56 has been merged, deleting remote branch "origin/monorepo".

[Aariq]

I'm running into this too in Positron, but I get

! could not find key 'branch.<branch name>.vscode-merge-base' to delete

(insert the PR branch name where <branch name> is)

Thanks @jennybc for documenting this so well and thanks @gadenbuie for the workaround!

[jennybc]

I instrumented a local usethis installation to write the exact error to file, when this happens, and it looks like this:

> x <- readRDS("oops.rds")
> x
<GIT_ERROR in libgit2::git_branch_delete: could not find key 'branch.use-localized-message.vscode-merge-base' to delete>
> str(x)
List of 2
 $ message: chr "could not find key 'branch.use-localized-message.vscode-merge-base' to delete"
 $ call   : language libgit2::git_branch_delete
 - attr(*, "class")= chr [1:4] "GIT_ERROR" "libgit2_error" "error" "condition"

I will use this (ha!) to create some sort of a diaper for this problem.

[jennybc]

I have a first draft of a fix for this merged into main now. If folks on this thread would like to try it out and give feedback, please install dev usethis. I will also exercise it a bit.