Re: What's cooking in git.git (Apr 2019, #02; Wed, 10)

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi Phillip,

On Wed, 10 Apr 2019, Phillip Wood wrote:

> On 09/04/2019 19:08, Junio C Hamano wrote:
> > Here are the topics that have been cooking.  Commits prefixed with
> > '-' are only in 'pu' (proposed updates) while commits prefixed with
> > '+' are in 'next'.  The ones marked with '.' do not appear in any of
> > the integration branches, but I am still holding onto them.
> >
> > * pw/rebase-i-internal-rfc (2019-03-21) 12 commits
> >   - rebase -i: run without forking rebase--interactive
> >   - rebase: use a common action enum
> >   - rebase -i: use struct rebase_options in do_interactive_rebase()
> >   - rebase -i: use struct rebase_options to parse args
> >   - rebase -i: use struct object_id for squash_onto
> >   - rebase -i: use struct commit when parsing options
> >   - rebase -i: remove duplication
> >   - rebase -i: combine rebase--interactive.c with rebase.c
> >   - rebase: use OPT_RERERE_AUTOUPDATE()
> >   - rebase: rename write_basic_state()
> >   - sequencer: always discard index after checkout
> >   - Merge branch 'ag/sequencer-reduce-rewriting-todo' into
> >   pw/rebase-i-internal-rfc
> >   (this branch uses ag/sequencer-reduce-rewriting-todo.)
> >
> >   The internal implementation of "git rebase -i" has been updated to
> >   avoid forking a separate "rebase--interactive" process.
> >
> >   Comments?  Is this ready?
>
> It is more or less ready, there weren't many comments. I'm planning to send a
> re-roll but am waiting to see what happens with dl/merge-cleanup-scissors-fix
> and [1] (which you don't seem to have picked up yet) as we discussed rebasing
> this series on top of a merge of the current base with
> dl/merge-cleanup-scissors-fix which currently conflicts with [1].
>
> Also now ab/drop-scripted-rebase is going to be in master I could add a patch
> to this series that drops a bunch of unneeded options from rebase--interactive
> as it will only be called by git-rebase--preserve-merges.sh which only uses a
> subset of the current options but that could always come separately later.

Or we wait with this until we can drop preserve-merges altogether?

Ciao,
Dscho