[henrikeh]

Well, since you ask. `git add -i` has different "escape"/"exit" semantics for different actions.

If I want to quit/escape adding a patch in the interactive mode I type `q` and then enter.

If I want to quit/escape the interactive add subcommand I type `q` and then enter.

But if I want to quit the `update`, `untracked` etc. I have to enter nothing and then press enter. It would be such a wonderful thing if it also accepted `q` so my muscle "memory" is correct.

I looked into changing this once, but it is written in shell and Perl, which I don't know enough about to figure out.

[harrisi]

I actually just ran into this yesterday and completely agree! I ended up just C-c-ing out and used -p.

The other thing that was frustrating with that was that the help text for what commands do is printed before everything, so if your window is small and there's a lot of output, it's not obvious that the ? you typed did anything other than re-print the hunk. It seems odd to not print the help information at the end so you will always see it (unless your window is less than one row tall, but.. you're probably here for dragons anyway in that situation).

[avar]

Aside from the UX question you've got, which I haven't had time to look at (sorry). We've shipped a pure C version of "add -i" that's been on if you've enabled feature.experimental=true since v2.29.0.

It looks like the ball may have been dropped on opting users in to it by default, but in any case there's numerous bugs in "git add -p" and "git add -i" that got fixed along the way, and fixing existing ones should be a lot easier now.

Note: I've also worked on the perl compiler/interpreter in a past life, so it's not that I'm afraid of hacking on Perl, but doing so in the context of the Git project is and was always particularly painful. If something's written in C you could use all the APIs git had internally, but anything in .sh or .perl was usually stuck parsing text, or reinventing the wheel.