This is something a bit like git-add -i, except not depending on perl,
and partially crossed with git-commit.

Usage: $0 [arg [arg ...]]

Runs git diff with the same arguments.  Any non-text diffs, new files,
or deleted files cause an immediate error out.  Text diffs are
accumulated; each diff hunk is remembered separately.  The user
interface allows the user to, repeatedly, choose from:

- Choose a diff hunk to be included.
- Commit chosen hunks.
- Split hunks.

Committing works by constructing a git-fast-import pack for the new
commit, then running git-commit --amend to let the user supply (edit,
really) the commit message.  If the commit --amend is aborted, the
commit created by git-fast-import is backed out.  (There are lots of
race conditions with unpleasant consequences if other commits are
happening to the same branch at the same time.  This is not intended
for workflows that do that.)

There is a potential issue when splitting hunks: the portions have to
be committed in order.  This is because, when splitting, the second
part of a split is relative to the output of the first part.  Since
arbitrarily complex changes can be introduced when splitting, it is not
in general possible to automatically figure out what the diff
corresponding to the second part of a split would be if applied to the
initial contents, rather than to the output of the first part.  Thus,
this isn't really fixable even in principle.  Since split hunks can be
merged and re-split, you can re-split it so the part you want to commit
next is first; it's annoying to have to, though, so be careful to split
in the correct direction.

The UI is curses-based.  You move the cursor up and down with j and k
(to move by lines) and f (or space) and b (to move by screens).  J and
K move by "large" amounts, which usually means "the next line of the
type you're on", but when within a hunk it moves to the appropriate end
of that hunk.  l expands the file or hunk the cursor is on; h
collapses (if a file or hunk is expanded), or moves to the containing
object (if not).  a toggles whether a hunk is included in the next
commit (indicated by a > marking); C commits the marked hunks.  S
splits a hunk, letting you edit the diff with $EDITOR; the resulting
diff becomes one part of the split, with the remaining changes becoming
the other.  m allows you to merge split hunks, though you can merge
only adjacent pieces (for, basically, the same reason mentioned above
that prevents committing arbitrary pieces of a split hunk - it's
impossible, in general, to figure out what the diff would be to apply a
part of a split to something other than the result of applying all the
previous parts).  To merge two parts of a split, type m on one of them,
then on the other; if you change your mind after the first m, type m on
the already-marked one to cancel the merge.  You can't do splits or
commits while a hunk part is merge-marked.

The Makefile is unlikely to work for you out of the box, but this is
arguably a feature, because (because of the way I have it set up) it
installs a copy into ../git-interactive, which is likely to not be what
you want.  If you want to use the Makefile, you'll need <local-prog>,
from (eg) ftp.rodents-montreal.org:/mouseware/local-src/makefiles/.
But there's really no need; just compile the .c files and link with
-lcurses -ltermcap.  You will need lcs-cvt (or a patched compiler) to
handle four of the seven files (git-intf.c, memstream.c, subproc.c, and
ui.c); see ftp.rodents-montreal.org:/mouseware/local-src/lcs-cvt/.