idea: `stg repair` improvement

[NonLogicalDev]

I have been giving stg repair workflow a lot of thought recently and I have a few ideas on how to make it more advanced user friendly and less magic.

(The proposals and thoughts listed below are additions to repair toolkit, not replacements for auto fixup functionality)

Although for the most part repair does a decent job of fixing up mistakes I feel like we could give the user more control if they know what they are doing.

Repair operation essentially consists of fixing up the metadata to match the current stack of diffs as closely as possible.

For manual operation I propose we could add two core operations:

• stg repair --rewind
  • Which would mark all patches as popped and will sync up the metadata head to the current one.
  • The most basic simple manual option (no data loss whatsoever), and gets the user back into operational state immediately.
    • Also this will be potentially way faster on giant monorepos.
  • This opens up the ability to manually uncommit back the commits transforming them into new patches. (while keeping the old patches unapplied above in the stack for reference)
  • This sort of mimics what stg repair does today (or used to do recently) but leaves it up to deal with fixing up the stack.
• stg repair --remap PATCH_ID NEW_SHA which would only work on unapplied patches.
  • Advanced option allows changing what any given unapplied patch is mapped to.
  • Allows the user to manually sync up the stack

[jpgrayson]

Awesome.

The stg repair --rewind idea feels pretty solid. I'm going to think about it more.

Question about stg repair --remap: would the NEW_SHA be a commit id or a tree id? I assume commit, but want to double-check. Have you run into a situation where you would have used this --remap option? Any more you can say about that scenario?

[NonLogicalDev]

@jpgrayson On repair --remap tree vs commit is a very good question. If potentailly we supported both semantics will be quite different:

• commit would essentially replace the oid in stack.json for that patch, so all notes, dates, author fields will be preserved
• tree would then only replace the tree

I feel there is potential benefit to supporting trees as well. But it increases complexity, and in either case can be added later. Focusing on just allowing to natively swap out oids would go a long way.

To put all my thoughts in perspective, the overarching idea that led me down this path is two fold:

• allow advanced user to fixup bad state manually to get out of tricky situations
• potentially attempt to implement a set of git hooks that would listen for pre/post commit and post-rewrite hooks and fixup metadata automatically to bridge the gap between stg and git worlds.

The latter desperately needs something like rewind + remap to make if feasible.