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

stevensting commented

2026-01-28 12:06:30 +00:00

I also stumbled on this lately. I wrote some notes on it. Would it make sense to add those to the docs?

Developing coop cloud features shall not be done on the main branch, but working frmo a branch is not that simple as abra manages the git working copies of the recipes itself. Currently (version 0.12) abra will also regularly reset the WC to the main branch when executing commands.

Therefore this is the recommended approach:
cd ./abra/recipies/<recipe>
git checkout <feature-branch>
from there on use --chaos for all commands where it is possible and make sure you commit very regularly to your feature branch, as abra might reset your local modifications.

If it happens anyways, you can use git reflog to restore your changes.

I also stumbled on this lately. I wrote some notes on it. Would it make sense to add those to the docs? > Developing coop cloud features shall not be done on the main branch, but working frmo a branch is not that simple as abra manages the git working copies of the recipes itself. Currently (version 0.12) abra will also regularly reset the WC to the main branch when executing commands. > > Therefore this is the recommended approach: > > ``` > cd ./abra/recipies/<recipe> > git checkout <feature-branch> > ``` > > from there on use --chaos for all commands where it is possible and make sure you commit very regularly to your feature branch, as abra might reset your local modifications. > > If it happens anyways, you can use git reflog to restore your changes.

👍 2

iexos commented

2026-01-28 12:57:48 +00:00

Thank you, that would be a great addition to the docs!

❤️ 1

notplants commented

2026-02-20 17:31:38 +00:00

I think I also stumbled into this haha https://matrix.to/#/!DfXPgKLoYCvjHithgS:autonomic.zone/$ElSMkpD1hzrRKRBwetZWAaDdGHvetXOtu5pikfne7vs?via=autonomic.zone&via=matrix.org&via=pub.solar

notplants commented

2026-02-20 17:39:09 +00:00

as an alternative/additional solution, I could imagine having env config for abra in addition to cli?

ABRA_ENSURE_CHAOS (lol at this name)

and when true, then abra just never does the checkout thing

then when you are doing recipe dev work you can set this environment variable and you are safe from confusion

as an alternative/additional solution, I could imagine having env config for abra in addition to cli? ABRA_ENSURE_CHAOS (lol at this name) and when true, then abra just never does the checkout thing then when you are doing recipe dev work you can set this environment variable and you are safe from confusion

stevensting commented

2026-02-21 07:37:36 +00:00

How about this: when warning the user about the modifications and hinting --chaos, could Abra just ask if the user wants to switch to hack mode? And in hack mode, the recipes head will be attached to a selectable branch or create a new one based on main.
And to make sure people are aware when using Abra, they need to pass --hack to every Abra command to wor k in hack mode.

How about this: when warning the user about the modifications and hinting --chaos, could Abra just ask if the user wants to switch to hack mode? And in hack mode, the recipes head will be attached to a selectable branch or create a new one based on main. And to make sure people are aware when using Abra, they need to pass --hack to every Abra command to wor k in hack mode.

decentral1se commented

2026-02-21 12:26:39 +00:00

Another idea, following the initial report in #751 (comment):

deploy an app without --chaos

recipe repo should now be in detached head (of deployed release tag)

Why doesn't abra store where the checkout is before it does something and always return to it at the end of the operation? This would mean that if you're on main and then do an abra app deploy, it will always return to main once it is finished.

If there are unstaged changes it should always bail unless the command does not touch the git repository.

Another idea, following the initial report in https://git.coopcloud.tech/toolshed/abra/issues/751#issue-5456: > * deploy an app without --chaos > * recipe repo should now be in detached head (of deployed release tag) Why doesn't `abra` store where the checkout is *before* it does something and always return to it at the end of the operation? This would mean that if you're on `main` and then do an `abra app deploy`, it will always return to `main` once it is finished. If there are unstaged changes it should always bail unless the command does not touch the git repository.

notplants commented

2026-02-21 13:32:09 +00:00

I like "always return to where you were before end of operation" idea, but fwiw having an environmental variable that ensures chaos mode maybe also provides one additional safeguard in addition to "sending you back where you were":

it also prevents you from accidentally running abra cmd or abra secret using different code than you intended (which could happen in the "always return" model)

I like "always return to where you were before end of operation" idea, but fwiw having an environmental variable that ensures chaos mode maybe also provides one additional safeguard in addition to "sending you back where you were": it also prevents you from accidentally running `abra cmd` or `abra secret` using different code than you intended (which could happen in the "always return" model)

iexos commented

2026-02-21 15:02:13 +00:00

I like it to, the ideal outcome would be to never have the repo in detached HEAD unless doing that manually. The main problem is that we are not used to this state and wouldn't choose it consciously. So we should make sure it just doesn't happen.

decentral1se commented

2026-02-21 23:15:01 +00:00

Related: #742

Related: https://git.coopcloud.tech/toolshed/abra/pulls/742

decentral1se added this to the Abra "next" project 2026-02-27 15:48:25 +00:00

Sign in to join this conversation.

4 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