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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html