Re: [RFC] introducing git replay
- From
Tao Klerks <tao@klerks.biz>
- Date
- Apr 20, 2022, 11:27 UTC
- Message-ID
- <CAPMMpoh9-sm57D_OSVpo4A3KdJypNZbZ2KTWURvcOW0690eviA@mail.gmail.com>
- In-Reply-To
- <CABPp-BGQSN2iRWco4pQCVKA3AM6J0L0vyFMnYdrOgK0Pa26tWw@mail.gmail.com>
On Mon, Apr 18, 2022 at 6:28 PM Elijah Newren <newren@gmail.com> wrote:
Show 16 quoted lines
> > 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 :(