feat: New subcommands

[epage]

git-stack's development has been in limbo as I've been working on a rewrite and getting stuck on some spots. I've also been curious about applying some sapling workflows in regular git usage (git-branchless also does this but it tries to emulate sapling rather than "embracing git").

This PR is an attempt to solve both problems. This adds various new subcommands for more specific workflows. These are using the new core which allows verifying the behavior in smaller, more incremental steps rather than trying to have everything perfect.

This includes

• git stack next to move to a child commit
  • Preferring newer commits
• git stack prev to move to a parent commit
  • Preferring newer, unprotected commits
• git stack reword to reword the current commit (use the next/prev to move to the commit to reword)
• git stack amend to modify the existing commit (use the next/prev to move to the commit to amend)
• git stack run to verify a stack
• git stack sync to do a git pull --rebase

These commands do not yet show the stack.

In addition, git stack alias is added to manage the configuration / removal of aliases for the above to act as top-level commands.

These are more in prototype-phase. Tests need to be added still.

[arxanas]

Cool stuff! 🚀

You might be interested to know that I had to split up various git-branchless commands into separate crates in order to get incremental test times down to something reasonable (https://github.com/arxanas/git-branchless/pull/650). You might consider doing the same if your build times also start to suffer.

[epage]

At the moment, I don't quite feel that I need that.

However, at some point I need to look into adopting git-record for git stack amend -i. Just wanted to check in if that is something you plan to maintain in-tree for a while or if its something that should be split out into a its on repo (under gitext-rs?).

[arxanas]

I do hope to publish git-record as a package which is mature enough for consumption by others, at which point it would make sense to move to gitext-rs. Unfortunately, the current implementation has considerable performance issues, so I haven't invested more into it yet. I hope to rewrite it with a more performant UI library in the future.

[martinvonz]

FYI, jj is also likely to adopt git-record some day. I don't think we have any opinion about where it lives - whether it lives in git-branchless, gitext-rs, or in its own repo seems fine.

the current implementation has considerable performance issues

Do you know what they're caused by?

[arxanas]

• Last time I checked, there was quadratic behavior in the default LinearLayout component.
• More fundamentally, I think it renders the entire canvas eagerly and cuts out most of it to implement ScrollView, etc.
• There was a bug where checkboxes absorbed scroll events and toggled themselves, which wasn't solvable under the current event architecture.
• I think some operations like "toggle all checkboxes" force redraws for each toggled checkbox, also inducing quadratic behavior?
• It would also be hard to specify the precise scroll behavior when a panel off-screen is opened.

There are enough issues that i think it makes sense to move from cursive to tui-rs (and implement a lot more by hand).