Hi Elijah,
On Fri, 18 Jan 2019, Johannes Schindelin wrote:
> On Mon, 7 Jan 2019, Elijah Newren wrote:
>
> > Dscho: Looks like our series conflicts slightly. Would you like me to
> > rebase mine on top of yours and squash the following change into
> > commit c91c944a068e ("rebase: define linearization ordering and
> > enforce it", 2018-12-11), or do you want to rebase your series on mine
> > and either make a new commit out of this change or squash it in
> > somewhere?
> >
> > diff --git a/builtin/rebase.c b/builtin/rebase.c
> > index 0317280f83..54023547ff 100644
> > --- a/builtin/rebase.c
> > +++ b/builtin/rebase.c
> > @@ -578,7 +578,8 @@ static int run_am(struct rebase_options *opts)
> > argv_array_pushl(&format_patch.args, "format-patch", "-k", "--stdout",
> > "--full-index", "--cherry-pick", "--right-only",
> > "--src-prefix=a/", "--dst-prefix=b/", "--no-renames",
> > - "--no-cover-letter", "--pretty=mboxrd", NULL);
> > + "--no-cover-letter", "--pretty=mboxrd",
> > + "--topo-order", NULL);
> > if (opts->git_format_patch_opt.len)
> > argv_array_split(&format_patch.args,
> > opts->git_format_patch_opt.buf);
>
> I can easily squash that in.
Actually, I take that back. This is tested-for in the regression test
suite, and I need to keep the built-in and the scripted rebase in sync for
that test suite to pass, so that single-liner would incur more changes
than I am comfortable with adopting into the builtin-rebase--am patch
series...
I am about to submit a new iteration of my patch series, would it be too
much trouble for you to rebase on top? If it would be, let me know, then I
will rebase on top of yours.
Ciao,
Dscho
