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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Mar 15, 2016, 19:45 UTC
Message-ID: <alpine.DEB.2.20.1603152041090.4690@virtualbox>
In-Reply-To: <CACRoPnRhhMM0e3S23KVnEANwNRDPq0P3hSqn5Zs1ksZxeaAoiA@mail.gmail.com>

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).

Show 11 quoted lines

> 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