Johannes Schindelin <johannes.schindelin@xxxxxx> writes:
> After all of these patch series y'all had to review, this is finally the
> one that switches things over.
>
> Please note that it does not (yet) handle the `git rebase -i --root`
> invocation; I tried to focus on the common case, and I rarely use --root
> myself.
As long as the longer-term goal is clear enough and the short-term
approach does not conflict with the goal, solving the most common
problem that yields the largest payback first is absolutely the
right thing to do, and omitting "--root" and/or "-p" and getting the
main use of "-i" right is a great way to start.
> .gitignore | 1 +
> Makefile | 1 +
> builtin.h | 1 +
> builtin/rebase--helper.c | 40 ++++++++++++++++++++++++++++++++++++++++
> git-rebase--interactive.sh | 13 +++++++++++++
> git.c | 1 +
> t/t3404-rebase-interactive.sh | 2 +-
> 7 files changed, 58 insertions(+), 1 deletion(-)
> create mode 100644 builtin/rebase--helper.c
And it is surprisingly short and sweet ;-)
Will queue as js/rebase-helper topic, forked at 6e3a7b3398 ("Git
2.12-rc0", 2017-02-03).
Thanks.
PS. in case if anybody is wondering after reading [*1*], at this
point, I _have_ read the patches not just the cover letter, looked
at the branch name the original author gave to the topic, chose the
local topic name I use, and chose where to fork the topic from, but
have not applied the patches (so I may later end up saying "the
patch does not apply cleanly", "the compiler complains on this
line", or "the new code is inconsistent with this existing code that
is a bit beyond the context of the patch that I did not notice when
I reviewed the patches alone" in a separate message). I do not have
a new entry for this topic in the draft of "What's cooking" report
yet, or have not decided if the topic would hit 'jch' or 'pu' yet
either.
[Reference]
*1* http://public-inbox.org/git/xmqq7f4zqiyj.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx