[HN Gopher] Show HN: Git-Add-Interactive with Enhancements
___________________________________________________________________
Show HN: Git-Add-Interactive with Enhancements
I created a replacement for the perl git-add--interactive that adds
a few enhancements: - S to automatically split all hunks - G to
set a global filter on hunks to show - A to automatically accept
all hunks (after auto-splitting and global filter are applied)
Author : xn
Score : 58 points
Date : 2025-05-30 12:54 UTC (10 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| Ayesh wrote:
| 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.
| zacharytamas wrote:
| 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
| xn wrote:
| Good thinking. I added a vhs tape:
| https://github.com/cwarden/git-add--
| interactive/blob/main/RE...
| xn wrote:
| Good idea. I'll try to throw something together.
| sevg wrote:
| 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
| wapeoifjaweofji wrote:
| 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.
| foobarbaz33 wrote:
| Another tig user! Proof there are 1's of us out there.
| zacharytamas wrote:
| 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
| G1N wrote:
| Been looking for something like git machete for the longest
| time, thanks for sharing!
| lucasoshiro wrote:
| Question: why not send this to the Git mailing list, and
| hopefully get this in upstream?
| xn wrote:
| After banging on it a bit more, yes, it would be nice to
| replace the upstream version.
| lucasoshiro wrote:
| Nice!
| williamdclt wrote:
| 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
| xn wrote:
| I updated my calendar to revisit in 2045.
| lucasoshiro wrote:
| > I don't think the Git maintainers will consider adding Go
| as a dependency
|
| Just re-write in C
| williamdclt wrote:
| 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.
| derintegrative wrote:
| "Just"
| xn wrote:
| Maybe someone will create modernperl, a la modernc, to
| automatically port go to perl.
| imiric wrote:
| Or just improve the Perl version? There's no reason this
| needs to be written in Go.
| jdlyga wrote:
| It would be nice if this had the same interface for `git add -i`
| allowing you to type in numbers or letters.
|
| ** Commands ** 1: status 2: update 3: revert
| 4: add untracked 5: patch 6: diff 7: quit 8:
| help
|
| What now>
|
| This allows you to either type in (p) or (5) to go into patch
| mode.
| xn wrote:
| Thanks for the feedback. The latest version improves
| compatiblity with the perl version:
| https://github.com/cwarden/git-add--interactive/releases/tag...
| jasonjmcghee wrote:
| 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:
| af => !f() { git add -p $(git diff --name-only | fzf); }; f
|
| 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.
| Night_Thastus wrote:
| 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.
| h1fra wrote:
| same I just wish it would split things even more by default
| muxxa wrote:
| My 2c: I'd like to see git add interactive go through the hunks
| in order of most recent first!
| treve wrote:
| 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.
| strogonoff wrote:
| 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.
| kccqzy wrote:
| 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.
| pi-rat wrote:
| Frankly, it's so good I use emacs just for git even when
| coding in other editors.
| p_wood wrote:
| 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.
| xn wrote:
| 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.
| loevborg wrote:
| This is my favorite alias: i = !git add -N . &&
| git add -p
|
| `git i` lets you interactively add new files as well as existing
| ones
| areusch wrote:
| 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.
| imiric wrote:
| 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
___________________________________________________________________
(page generated 2025-05-30 23:00 UTC)