Re: What's cooking in git.git (Jan 2019, #03; Fri, 18)

> On Fri, Jan 18, 2019 at 3:22 PM Junio C Hamano <gitster@pobox.com> wrote:
> > * en/rebase-merge-on-sequencer (2019-01-07) 8 commits
> >  - rebase: implement --merge via the interactive machinery
> >  - rebase: define linearization ordering and enforce it
> >  - git-legacy-rebase: simplify unnecessary triply-nested if
> >  - git-rebase, sequencer: extend --quiet option for the interactive machinery
> >  - am, rebase--merge: do not overlook --skip'ed commits with post-rewrite
> >  - t5407: add a test demonstrating how interactive handles --skip differently
> >  - rebase: fix incompatible options error message
> >  - rebase: make builtin and legacy script error messages the same
> >
> >  "git rebase --merge" as been reimplemented by reusing the internal
> >  machinery used for "git rebase -i".
> >
> >  On hold.
> >  cf. <CABPp-BFckuONYcGGkCY3BuPypRULmhsk_OFHyYA2E4jM66BfeQ@mail.gmail.com>
> 
> Is the "on hold" comment still accurate?  And if so, can I ask for
> clarification on what the hold is so I can know what action if any I
> need to take?  The two things mentioned in the linked email that I see
> are (1) the need to lower-case part of the subject (which you squashed
> in already to create commit 68aa495b590d), and (2) the semantic
> conflict between js/rebase-am and my patch, for which you already
> squashed my fix into your merge of his series and suggested I not
> resend and just let the rerere logic handle it (cf.
> <xmqqmunxluj8.fsf@gitster-ct.c.googlers.com>)

> I'm beginning to wonder if I should just resubmit patches individually
> or take some other dramatic action as the combined amount of time this
> series has been on hold has been quite a bit longer than usual for me.
> Suggestions welcome.
> 
> Thanks,
> Elijah
>