Re: What's cooking in git.git (Apr 2019, #02; Wed, 10)
- Date: Thu, 11 Apr 2019 00:15:24 +0200 (DST)
- From: Johannes Schindelin <Johannes.Schindelin@xxxxxx>
- Subject: Re: What's cooking in git.git (Apr 2019, #02; Wed, 10)
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  (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 .
> 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?