Hi there - I am having some issues with a branch. I have removed it as a trunk via config and when running logs and listing trunk branches it is no longer displayed. However running gt commands like move or track will not work because gt still thinks it is a trunk and returns this error:

ERROR: Cannot perform this operation on the trunk branch.

I’d like to avoid the nuclear reset if at all possible. Any thoughts? Thanks!

(If applicable) To help us repro, please send the following if you haven't already: - PR links, screenshots, and/or debug output if applicable - Repro steps - Does this happen consistently? Just to you or others on your team also? - Is this a regression? Is the problem new? - If you're having an issue with the CLI, please send us debug logs using

gt feedback --with-debug-context <any message>

I also ran gt feedback before submitting this message if that helps.

Hey Rene! Thanks for the report. I dug into your debug logs and can see whats happening. When you removed

check-in_choose_paired_or_non-paired_customer_check-in_flow

as a trunk via

gt config

, the config change was saved correctly. That is why

gt trunk --all

and

gt log

show the right thing. The issue is that

gt

also caches per-branch metadata in git. That cached metadata still had this branch tagged as a trunk from before the config change. Since the branch revision had not changed,

gt

kept reusing the stale cached result instead of re-evaluating the branch. That is a bug on our side and we’ll fix it. In the meantime, you can force

gt

to re-evaluate the branch by changing its revision:

git checkout check-in_choose_paired_or_non-paired_customer_check-in_flow

git commit --allow-empty -m "force gt cache refresh"

gt track

When

gt track

prompts you, choose the intended parent/trunk. Once it completes successfully and prints

Tracked branch check-in_choose_paired_or_non-paired_customer_check-in_flow with parent ...

, the branch metadata should be repaired and commands like

gt move

and

gt untrack

should work normally again. This empty commit is just a temporary workaround to force the cache refresh. If you don’t want it in the PR, you can remove or squash it later after the metadata is fixed. Until we ship a fix, if you need to remove a branch as a trunk in the future, first move it onto another trunk with

gt move --onto <other-trunk>

before removing it from the trunk config via

gt config

. That should let

gt

update the cached metadata before the trunk designation is removed, which avoids this stale-cache state.

Thanks for that info @Brett Bedevian! I’ll give that a go.