Re: [RFC] introducing git replay

From: Elijah Newren <newren@gmail.com>
Date: Apr 21, 2022, 02:33 UTC
Message-ID: <CABPp-BFh-=3E-yMDaU1TgigwriFDbd-CwXe0PJKkc422LCSP6Q@mail.gmail.com>
In-Reply-To: <CAPMMpoh9-sm57D_OSVpo4A3KdJypNZbZ2KTWURvcOW0690eviA@mail.gmail.com>

On Wed, Apr 20, 2022 at 4:27 AM Tao Klerks <tao@klerks.biz> wrote:

Show 27 quoted lines

>
> On Mon, Apr 18, 2022 at 6:28 PM Elijah Newren <newren@gmail.com> wrote:
> >
> > If you read the suggestion I made (which I'll reinclude here at [1]),
> > you'll note that I read the old thread you link to with both your and
> > Phillips' suggestions.  I dug into them with some examples, and came
> > to the conclusion that we needed something better, as I briefly
> > commented when proposing my suggested alternative (at [1]).  I
> > appreciate your suggestion and the time you put into it, but based on
> > my earlier investigation, I believe my suggestion would be a better
> > way of preserving user changes in merges and I'll be implementing it.
> > The fact that Martin (in this thread) independently came up with the
> > same basic idea and implemented it in jj (though he apparently has
> > some further tweaks around the object model) and it works well
> > suggests to me that the idea has some real world testing too that
> > gives me further confidence in the idea.
> >
> > [1] https://lore.kernel.org/git/CABPp-BGW39_5r8Lbt3ymR+F_=hWJcf=2e7O75vFNJ=3CEL5s=g@mail.gmail.com/
>
> Thank you for the clarification, and sorry I'm clearly missing
> something here - the link you provided is to a deeply threaded
> conversation about "[PATCH 08/12] merge-ort: provide a
> merge_get_conflicted_files() helper function", in the context of a
> server-side merge support patchset... I can't figure out how to relate
> that conversation to the "how can safely reusing previous merge
> outcomes when rebasing a merge work well?" topic I thought you had
> introduced here :(

Sorry, I entered the wrong link, and assumed it was right when I copied it into the response email. Whoops. The link for [1] was supposed to be https://lore.kernel.org/git/CABPp-BHp+d62dCyAaJfh1cZ8xVpGyb97mZryd02aCOX=Qn=Ltw@mail.gmail.com/

But as has been said elsewhere, what you're asking for doesn't exist yet. That other email was where I outlined a bunch of details about what someone could do to implement it, and where I pointed out that I planned to eventually implement it if Dscho didn't beat me to it. I've since started on it.

I also linked to my tree a few times where anyone can look at what I have done so far (which isn't useful to users yet). If you want to take what I've implemented and implement the rest before I can, go ahead. If you want to take the steps I outlined on how to do it in the email link I provided above, and implement it from scratch then go ahead. But otherwise, as Junio already pointed out in this thread, it just doesn't exist today.