Starting a new ticket while there are loose edits on trunk works, and works well: the edits come along into the new branch. "I started typing, then realised which ticket this is" is a real sequence, and the app handles it.
Resuming a ticket that already exists does not. The edits have nowhere to go — trunk is never committed to, since it is the base every ticket's patch is measured against — and the checkout that swaps the files would overwrite them. So the switch is refused.
The refusal is right. What is missing is the option a contributor actually wants: take these edits with me to that ticket.
The manual route exists today and is now offered where the refusal appears: save the edits as a patch, discard them, switch, then apply the patch from the "Apply a patch or PR" panel. Four steps, one of which is destructive, and it only stays safe if the contributor does them in order. That is a workaround, not a feature.
Doing it in one action needs no rebase — there is none available, and none is needed. The pieces are all here: generate the patch of what is loose, switch, apply it on the other side. Applying is already solved, with rollback and path containment.
The design question is the failure case, and it is the whole of the work. If the target ticket's own changes touch the same files, the apply fails. That is not rare — two tickets in the same area of core is exactly when someone is juggling them. What should happen then is the decision to make: put the edits back on trunk and stay put, complete the switch and hand back the patch file with an explanation, or keep both and say where each one is. A contributor who has never resolved a conflict should not be handed one, and should never be left unsure which copy of their work is the real one.
Also worth deciding: whether this is the default behaviour of resuming a ticket from a dirty trunk, or an offer next to the refusal. The refusal is honest and cheap; silently moving someone's work is not something to do without them asking.
Related: the app also cannot replay an old branch onto an updated trunk, for the same absence of a rebase and with the same apply-based route.
Starting a new ticket while there are loose edits on trunk works, and works well: the edits come along into the new branch. "I started typing, then realised which ticket this is" is a real sequence, and the app handles it.
Resuming a ticket that already exists does not. The edits have nowhere to go — trunk is never committed to, since it is the base every ticket's patch is measured against — and the checkout that swaps the files would overwrite them. So the switch is refused.
The refusal is right. What is missing is the option a contributor actually wants: take these edits with me to that ticket.
The manual route exists today and is now offered where the refusal appears: save the edits as a patch, discard them, switch, then apply the patch from the "Apply a patch or PR" panel. Four steps, one of which is destructive, and it only stays safe if the contributor does them in order. That is a workaround, not a feature.
Doing it in one action needs no rebase — there is none available, and none is needed. The pieces are all here: generate the patch of what is loose, switch, apply it on the other side. Applying is already solved, with rollback and path containment.
The design question is the failure case, and it is the whole of the work. If the target ticket's own changes touch the same files, the apply fails. That is not rare — two tickets in the same area of core is exactly when someone is juggling them. What should happen then is the decision to make: put the edits back on trunk and stay put, complete the switch and hand back the patch file with an explanation, or keep both and say where each one is. A contributor who has never resolved a conflict should not be handed one, and should never be left unsure which copy of their work is the real one.
Also worth deciding: whether this is the default behaviour of resuming a ticket from a dirty trunk, or an offer next to the refusal. The refusal is honest and cheap; silently moving someone's work is not something to do without them asking.
Related: the app also cannot replay an old branch onto an updated trunk, for the same absence of a rebase and with the same apply-based route.