Don't change recipe checkout on abra app deploy if there are unnamed changes #751

New Issue

iexos · 2026-01-14T16:08:59Z

iexos commented

2026-01-14 16:08:59 +00:00

As there were reports about seemingly lost changes during recipe dev, I suggest that abra should only change the checkout of a recipe if it is currently on a named tag or branch.

If I am mindful (and knowledgable) enough I know that I should not do dev in a detached HEAD, though it happens so fast...

Repro:

deploy an app without --chaos
recipe repo should now be in detached head (of deployed release tag)
make some changes, commit
again deploy to test, forget --chaos (cancel deployment)

Expected outcome:

error out like with uncommitted changes

Actual outcome:

previous tag is checked out, committed changes lost in git internals
- recoverable with git reflog if you realize what happened

As there were reports about seemingly lost changes during recipe dev, I suggest that `abra` should only change the checkout of a recipe if it is currently on a named tag or branch. If I am mindful (and knowledgable) enough I know that I should not do dev in a detached HEAD, though it happens so fast... #### Repro: - deploy an app without `--chaos` - recipe repo should now be in detached head (of deployed release tag) - make some changes, commit - again deploy to test, forget `--chaos` (cancel deployment) #### Expected outcome: - error out like with uncommitted changes #### Actual outcome: - previous tag is checked out, committed changes lost in git internals - recoverable with `git reflog` if you realize what happened

👍 1

iexos added the

enhancement

label 2026-01-14 16:08:59 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: toolshed/abra#751

Don't change recipe checkout on abra app deploy if there are unnamed changes #751

Repro:

Expected outcome:

Actual outcome:

Don't change recipe checkout on `abra app deploy` if there are unnamed changes #751