Skip to content

Conversation

@NonLogicalDev
Copy link
Contributor

@NonLogicalDev NonLogicalDev commented Nov 20, 2025

Introduce alternative to stg repair for more manual control over stack metadata repair process.

Example usage:

  • Run stg branch --reset to force mark all patches in the stack as unapplied without changing HEAD.
  • Manually reconcile the stack state by running stg push --merged or stg uncommit.

issue: #181

…all patches as unapplied

Introduce an alternative to `stg repair` for more manual control over stack metadata repair process.

Example usage:
  * Run `stg branch --reset` to force mark all patches in the stack as unapplied without changing HEAD.
  * Manually reconcile the stack state by running `stg push --merged` or `stg uncommit`.
@NonLogicalDev
Copy link
Contributor Author

NonLogicalDev commented Nov 20, 2025

Hello @jpgrayson, I have been using a private fork with this command for a few months now. It can come in handy in cases where stg repair either takes too long or you just expect it to get confused.

I think stg branch --reset + stg uncommit is probably the simplest and most extensible building block for building custom repair workflows.

@NonLogicalDev NonLogicalDev changed the title feat: add stg branch --reset command to reset the stack without losin… feat: add stg branch --reset command to soft reset the stack Nov 20, 2025
Copy link
Collaborator

@jpgrayson jpgrayson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't fully understand the use case for this, but I'll accept the feature. I know this is something you've been thinking about for a long time. Very much appreciate the PR.

Also, the code is clean, thank you.

However, what I need is a couple tests that exercise this code path.

@NonLogicalDev
Copy link
Contributor Author

NonLogicalDev commented Dec 1, 2025

Will add the tests and resubmit! Thank you @jpgrayson

As for the usecase: In my company we have lots of tools that very eagerly re-write local history.

Say I have a stack of changes:

GIT_HEAD_SHA: abc003, STG_EXPECTS: abc003
+ patch-1          # patch 1 changeset (abc001)
+ patch-2          # patch 2 changeset (abc002)
> patch-3          # patch 3 changeset (abc003)
- uapplied-patch-4 # patch-4 changeset (abc004)
- uapplied-patch-5 # patch-5 changeset (abc005)

I run bespoke-tool submit, and it goes ahead and re-writes the currently applied patches, and perhaps also pull from upstream:

++ [10 new commits from upstream got pulled in]
GIT_HEAD_SHA: abc017, STG_EXPECTS: abc003
+ patch-1          # patch 1 changeset rebased (abc015)
+ patch-2          # patch 2 changeset rebased (abc016)
> patch-3          # patch 3 changeset rebased (abc017)
- uapplied-patch-4 # patch-4 changeset (abc004)
- uapplied-patch-5 # patch-5 changeset (abc005)

There are currently two ways to recover:

  • stg repair which will attempt to reconcile the mismatches patches
  • git reset --hard $(stg id $(stg top)) to blow away the changes made by the rebase and return to the previous good state according to stg

I am introducing third more explicit way with this change:

  • stg branch --reset -- trust git, and pretend all patches are now unapplied, and punt further reconcile to the user or a script

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants