git-absorb VS misc-gitology

Nice, no need to look up past commits ! Didn't know about this, I had to look it up.

It's a separate project from git [0].

[0]: https://github.com/tummychow/git-absorb

Boy have I got the thing for you. git absorb - https://github.com/tummychow/git-absorb

The way to work with it is:

    git add file1

You can also manage via a holistic UI: - Bisection - Log and reflog, stashes - subtrees, submodules - certain third party subcommands like git-absorb, and extend it with your own - interact with issues and pull requests via forge - pretty much all of the hundreds of CLI flags via a modal UI that got generalized and extracted to a lib called transient - well-integrated diff and conflict resolution (which is mostly just smerge) - the rebase/cherry-pick workflows I liked the best, including support for --update-refs - at any time you can always press a key to see the raw commands and output that it's using, which taught me a ton of corner cases - IMO it has a great manual

I sometimes use git-absorb to help me if I made a tonne of changes, and can't be arsed to manually make the fixups

If done well, your git history carries the information of your process in a very similar way.

You have to be somewhere in the middle, so I'd say to do a semantic rebase at last step before merge. A fantastic tool that is not so well-known is git-absorb, which helps a lot doing that cleanly and automatically.

https://github.com/tummychow/git-absorb

Squash merge is like a sledge hammer, interactive rebase + git reset -N HEAD^ + git-absorb + git add -p (or even better, Magit) are surgical tools.

@jpgrayson (since I see you lurking around here) Thanks for maintaining stgit! I've been a recent convert and it's a great workflow improvement. I used to be a big `git rebase -i` user and stgit works so much more fluidly and fits great with my mental model of how I want git to behave. Thanks!

I'd love to add functionality that mimics `git rebase -i`. That is, you would open an editor and be able to select which patches you want on your stack as well as possibly designate patches as 'squash' or 'fix' from your editor. Think of it as `stg sink`, but able to operate on multiple patches at once.

Prior art: this script[1] already performs a re-ordering of commits but in a pretty hacky way. I'd like to productize it!

I'd love to have this new `stg rebase --interactive` be part of the main repo to enjoy the benefits of the existing test suite. My question for you is around how to include the new command with the rest of the tools. Would you want it to integrate with the existing rebase command (`stg rebase --interactive`) or is it something more appropriate for `contrib` (so a new independent command like `stg-rebase-interactive`)?

[1] https://github.com/da-x/misc-gitology/blob/master/stg-rebase...