tg pr create -B upstream/main saves upstream/main as the target branch and, in a fork setup, diffs against the source repo's default branch. I hit both of these this week sending a fork PR.
Refname recorded verbatim #
I was on a branch based on upstream/main and my local main was stale, so I ran tg pr create -B upstream/main. The patch came out right, but the pull record got targetBranch: "upstream/main" -- the refspec was resolved locally to find the base, then the string was stored as-is. The PR was against the right commit but showed "releasing-via-tangled → upstream/main", which is not a real branch on the target repo. I closed it and redid it.
gh handles this by accepting owner:branch and remote/branch syntax and normalizing to the bare branch name on the target. Even just stripping a leading <remote>/ when the remote is known would do.
Fork PRs diff against the source repo's default branch #
When --source-repo is given, the base-ancestor check seems to run against that repo's default branch, not the target repo's. My target's main was at ba93fb0 and my fork's pushed main was an older commit that was nowhere in my branch's history. -B main resolved to the old commit and failed with base "main" is not an ancestor of head, even though the branch was built directly on the target's tip and git merge-base --is-ancestor main releasing-via-tangled passed locally. I had to force-push my fork's main up to the target's tip to get past it.
The same invocation worked fine when source and target were the same repo (my earlier PR branched off the same main that was everywhere at that commit), which is why I think it's consulting the source repo's default branch. Diffing fork PRs against the target repo's --base branch instead would fix it.
I'm not set up to build tg from source or test against a knot, so I'm just reporting. Happy to add detail if useful.
I'm werkin on this (I can stop if aly or someone else already is though)