Show HN: Git-Add–Interactive with Enhancements

[xn]

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)

[strogonoff]

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]

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]

Frankly, it’s so good I use emacs just for git even when coding in other editors.

[Ayesh]

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]

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]

Good thinking. I added a vhs tape: https://github.com/cwarden/git-add--interactive/blob/main/RE...

[xn]

Good idea. I'll try to throw something together.

[loevborg]

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

[jdlyga]

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]

Thanks for the feedback. The latest version improves compatiblity with the perl version: https://github.com/cwarden/git-add--interactive/releases/tag...

[sevg]

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

[p_wood]

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]

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.

[p_wood]

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.

[areusch]

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]

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

[lucasoshiro]

Question: why not send this to the Git mailing list, and hopefully get this in upstream?

[williamdclt]

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]

I updated my calendar to revisit in 2045.

[imiric]

Or just improve the Perl version? There's no reason this needs to be written in Go.

[lucasoshiro]

> I don’t think the Git maintainers will consider adding Go as a dependency

Just re-write in C

[williamdclt]

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.

[xn]

Maybe someone will create modernperl, à la modernc, to automatically port go to perl.

[derintegrative]

"Just"

[xn]

After banging on it a bit more, yes, it would be nice to replace the upstream version.

[lucasoshiro]

Nice!

[treve]

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.

[muxxa]

My 2c: I'd like to see git add interactive go through the hunks in order of most recent first!

[yencabulator]

How do you define hunk recency when comparing a staged file vs file on disk?

[jasonjmcghee]

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]

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]

same I just wish it would split things even more by default

[zacharytamas]

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]

Been looking for something like git machete for the longest time, thanks for sharing!

[wapeoifjaweofji]

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.

[29athrowaway]

I have been using tig for years. Great software

[foobarbaz33]

Another tig user! Proof there are 1's of us out there.