Re: [RFC/PATCH v2 0/8] rebase: new cherry-pick mode

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: May 30, 2013, 02:37 UTC
Message-ID: <CAMP44s2QtqgfuhyvJ=aZKaFHJzvwdWPkpyWjXOfAHACwTagOow@mail.gmail.com>
In-Reply-To: <7vehcpqsk4.fsf@alter.siamese.dyndns.org>

On Wed, May 29, 2013 at 6:23 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 21 quoted lines

> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> We already rely on cherry-pick for the 'am' mode, but only when using the
>> --keep-empty option, and when in such mode the behavior of 'git rebase' changes
>> completely; more specifically; it's completely broken. Manually enabling
>> --keep-empty to be the default and running the test-suite shows a huge lot of
>> failures.
>>
>> After fixing the --keep-empty option by creating a new cherry-pick mode, this
>> patch series uses this new mode instead of the 'am' mode, and everything works.
>
> This may be a stupid question, but does --keep-empty only fail with
> the "am" mode?
>
> More specifically, how well does "rebase -i --keep-empty" work?
>
> If the answer is "very well", then it might make sense not to
> introduce yet another cherry-pick mode, but do exactly the same
> thing as what -p mode does, namely, to internally delegate the
> processing to "rebase -i" codepath.  After all, multi-pick mode of
> cherry-pick uses the same sequencer machinery as rebase -i uses,

No, that's not true. 'rebase -i' implements sequencing completely on it's own, and cherry picks commits one by one, it never uses the sequencer.c code.

Also, there's the issue of the 'git am' options, that of course only the am mode respects. I personally wouldn't mind getting rid of them for consistency purposes, but I know you would disagree.

But the real issue is that we would be detracting from the goal even more; to replace script code with C code.

> so if we are already producing a correct "rebase todo" sequencer
> insn list for "rebase -i" anyway, it should be the matter of not
> launching the editor to edit the initial insn sheet to make it
> non-interactive, isn't it?

Sure, and make 'git rebase' extremely much more complicated (and probably inefficient) in the process.

I don't mind going that way, but I want to rewrite 'git-rebase--interactive.sh' to use 'git cherry-pick' more, and maybe 'git-rebase--merge.sh' too, and the first step was to replace the simplest mode.

-- 
Felipe Contreras