Re: [PATCH/RFC/GSoC 17/17] rebase-interactive: introduce interactive backend for builtin rebase

Hi Paul,

On Wed, 16 Mar 2016, Paul Tan wrote:

Even with interactive rebase out-of-bounds,

It is not really "out-of-bounds". It's more like: hold off integrating it
until I'm done with v1 of the rebase--helper that does interactive
rebase's heavy lifting (which should happen pretty soon).

I don't think it's a dead end though:

1. git-rebase--am.sh, git-rebase--merge.sh and git-rebase.sh can be
rewritten to C, and call git-rebase--interactive.sh externally, like
what Duy demonstrated in his patch series. The timings show that am
and merge rebase still benefit, and that way we will be closer to a
git-rebase in full C.

2. git-commit can be libified, so that we can access its functionality
directly. (sequencer.c runs it once per commit, rebase-interactive
uses it for squashes etc.)

Both look sound. With 1) I would also suggest a rebase--helper approach,
though. That way, you do not need to break the test suite at all but can
flip the switch at the end of the patch series.

Or would that be stepping on your toes?

Nope. 2) is related to what I do, but I modified sequencer.c's
run_git_commit() (which uses run_command()). Your plan would make that
even better (although the edit phase is of course not the
performance-critical part that we want to enhance).

Ciao,
Dscho