Re: [RFC] introducing git replay

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

 



On Mon, Apr 18, 2022 at 6:28 PM Elijah Newren <newren@xxxxxxxxx> 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@xxxxxxxxxxxxxx/

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 :(



[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