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.
It would be really nice to have this upstream - I don't know if the upstream implementation being in C now makes that easier or harder. As for the license I think because this is so closely based on GPL code it would be safer to use the same license.
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.
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.
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.
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.
Frankly, it’s so good I use emacs just for git even when coding in other editors.
Congratulations on publishing this. I use `git add -p` quite a lot, and this project looks interesting!
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.
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.
[1]: https://github.com/charmbracelet/vhs
Good thinking. I added a vhs tape: https://github.com/cwarden/git-add--interactive/blob/main/RE...
Good idea. I'll try to throw something together.
This is my favorite alias:
`git i` lets you interactively add new files as well as existing onesIt would be nice if this had the same interface for `git add -i` allowing you to type in numbers or letters.
** Commands **
What now>This allows you to either type in (p) or (5) to go into patch mode.
Thanks for the feedback. The latest version improves compatiblity with the perl version: https://github.com/cwarden/git-add--interactive/releases/tag...
This looks neat!
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.
Have you taken a look at git-absorb[1]?
It often did the wrong thing IME, but YMMV.
[1]: https://github.com/tummychow/git-absorb
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.
It would be really nice to have this upstream - I don't know if the upstream implementation being in C now makes that easier or harder. As for the license I think because this is so closely based on GPL code it would be safer to use the same license.
Question: why not send this to the Git mailing list, and hopefully get this in upstream?
I don’t think the Git maintainers will consider adding Go as a dependency and having commands in a new 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
I updated my calendar to revisit in 2045.
Or just improve the Perl version? There's no reason this needs to be written in Go.
> I don’t think the Git maintainers will consider adding Go as a dependency
Just re-write in C
This "just" carries a lot of weight.
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.
Maybe someone will create modernperl, à la modernc, to automatically port go to perl.
"Just"
After banging on it a bit more, yes, it would be nice to replace the upstream version.
Nice!
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.
My 2c: I'd like to see git add interactive go through the hunks in order of most recent first!
How do you define hunk recency when comparing a staged file vs file on disk?
I'm a serial "git add -p" user. (Micro-review before every commit is super healthy imo).
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.
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.
same I just wish it would split things even more by default
I always love to see these little git extensions. For anyone else interested in this stuff, here are some others I like:
lazygit (of course): https://github.com/jesseduffield/lazygit
git-machete: https://github.com/VirtusLab/git-machete
rebase-editor: https://github.com/sjurba/rebase-editor
Been looking for something like git machete for the longest time, thanks for sharing!
[dead]
I've used `tig` for this sort of thing for well over a decade. `tig status` lets you see all files, interactively add things, whatever.
I have been using tig for years. Great software
Another tig user! Proof there are 1's of us out there.
[flagged]