I used to hate leaving Vim for Git’s interactive staging mode or some separate GUI to pick apart a hairy set of changes. As a result I usually tried to avoid these messy situations.
Then I discovered Vim fugitive. It allows to go through the diff and stage chunks so intuitively, it changed the way I work. Just j/k to move around, = to expand file, s to stage selection, c to commit. The process of reviewing changes became very natural and actually enjoyable. I like the feeling of control it gives and how it makes focused commits painless while not disrupting the flow.
And if you use magit for Emacs, it's also extremely easy to stage hunks selectively and easily: s to stage, cc to commit staged, ca to amend with staged, etc. This is the way: don't use the git CLI. Use your editor.
Since the OP is familiar with the Go ecosystem, they could probably use vhs[1] easily to programmatically create an interactive demo GIF. That has worked very well for me in the past.
I think it’ll fit nicely alongside scmpuff which I’ve been using for years (and at this point refuse to ever give it up): https://github.com/mroth/scmpuff
the thing i really wish existed was git add -p mode that automatically segmented unstaged changes into a series of fixups based on the blame of the surrounding area that changed. this wouldn't work in all cases, but in many cases, i've made a series of 3-4 clearly-separable changes, i then go and make fixes on top of all of them, and now i want to fixup each change.
I like the idea of 'G' to filter hunks. The perl script does not exist since git v2.40.0 so I don't think the installation instructions work for recent versions of git as there is no way to stop 'git add -p' from running the builtin version. I see this is MIT licenced but the code is very closely based on the perl script which is licensed under the GPLv2.
huh. I guess this is a prototype for features that will have be submitted to the upstream version. There was a feature in development for something like `git add -G <regex>`, maybe a decade ago, that never got completed.
As for licensing, I'm happy to change the license. I have no strong feelings on the subject, and don't know what restrictions GPLv2 imposes on a port to another language.
The one feature I would love to see and would be an instant-install, is a command that lets me revert a hunk back. It would be nice to be able to wipe out some dangling console.log() statements as I go through the changes.
And that's probably not enough: for example likely you'd need to reuse whatever Git uses to generates patch formats. It's not necessarily _hard_, but it's not "just" a language translation.
I used to do patch operations and hunk-editing for everything and really enjoyed it. It definitely helps to put a fresh view on the code and see anything missed.
Eventually I moved on to going line-by-line with a GUI tool. In my case Git-cola, but I'm not positive I'd recommend it because it's quite slow on Windows.
Then I discovered Vim fugitive. It allows to go through the diff and stage chunks so intuitively, it changed the way I work. Just j/k to move around, = to expand file, s to stage selection, c to commit. The process of reviewing changes became very natural and actually enjoyable. I like the feeling of control it gives and how it makes focused commits painless while not disrupting the flow.
I knew that you could place a `git-xyz` executable and you can call it as `git xyz`. I didn't know you could do it with flags !?!
A small video or some screenshots would help a lot. If you can record interactivity with ascii-cinema, that will be even better.
[1]: https://github.com/charmbracelet/vhs
** Commands **
What now>This allows you to either type in (p) or (5) to go into patch mode.
I think it’ll fit nicely alongside scmpuff which I’ve been using for years (and at this point refuse to ever give it up): https://github.com/mroth/scmpuff
It often did the wrong thing IME, but YMMV.
[1]: https://github.com/tummychow/git-absorb
As for licensing, I'm happy to change the license. I have no strong feelings on the subject, and don't know what restrictions GPLv2 imposes on a port to another language.
Or at least, it would require first a massive effort to align the maintainers on the idea of a new language, like Rust in the Linux kernel
Just re-write in C
And that's probably not enough: for example likely you'd need to reuse whatever Git uses to generates patch formats. It's not necessarily _hard_, but it's not "just" a language translation.
I made an alias a while ago I use frequently:
When you have a large diff, it's get unruly quickly to "add -p".This just prompts you with a fuzzy find of the files that have changed and you can just pick one to go through the "add -p" process for that file.
For the terminal averse, IDEs usually have "jump to next change" and a tab for the changed files that can achieve the same.
Eventually I moved on to going line-by-line with a GUI tool. In my case Git-cola, but I'm not positive I'd recommend it because it's quite slow on Windows.
lazygit (of course): https://github.com/jesseduffield/lazygit
git-machete: https://github.com/VirtusLab/git-machete
rebase-editor: https://github.com/sjurba/rebase-editor