Re: [PATCH v4 0/8] Reimplement rebase --merge via interactive machinery

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Elijah,

On Mon, 7 Jan 2019, Elijah Newren wrote:

> On Mon, Jan 7, 2019 at 12:11 PM Junio C Hamano <gitster@xxxxxxxxx> wrote:
> >
> > Junio C Hamano <gitster@xxxxxxxxx> writes:
> >
> > > Elijah Newren <newren@xxxxxxxxx> writes:
> > >
> > >> On Tue, Dec 11, 2018 at 8:11 AM Elijah Newren <newren@xxxxxxxxx> wrote:
> > >>>
> > >>> This series continues the work of making rebase more self-consistent
> > >>> by removing inconsistencies between different backends.  In
> > >>> particular, this series focuses on making the merge machinery behave
> > >>> like the interactive machinery (though a few differences between the am
> > >>> and interactive backends are also fixed along the way), and ultimately
> > >>> removes the merge backend in favor of reimplementing the relevant
> > >>> options on top of the interactive machinery.
> > >>
> > >> Friendly ping...let me know if you want me to simply resend v4.
> > >>
> > >
> > > If you have anything newer than 90673135 ("rebase: Implement --merge
> > > via the interactive machinery", 2018-12-11), then yeah, I haven't
> > > seen it.
> > >
> > > Thanks.
> > >
> > > P.S. even if that one is latest, I would need to downcase Implement
> > > before it hits 'next' ;-)
> >
> > Ah, one thing I forgot to mention.  Some of the tests updated in
> > this series are unhappy with Dscho's "drive 'am' directly from the
> > built-in code, bypassing git-rebase--am.sh scriptlet" topic.
> 
> 2018-12-11 is the newest (and is almost the same as the version from
> mid November); it's just been waiting for review.  I'll fix up the
> casing of 'Implement' along with any other feedback, if any...maybe
> including rebasing on Dscho's series depending on how he wants to take
> it.
> 
> 
> 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. Thank you!
Dscho

> 
> 
> Elijah
> 
> 



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux