git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [RFC] introducing git replay

From
Sergey Organov <sorganov@gmail.com>
Date
Apr 18, 2022, 17:33 UTC
Message-ID
<87czhewb3m.fsf@osv.gnss.ru>
In-Reply-To
<CABPp-BGQSN2iRWco4pQCVKA3AM6J0L0vyFMnYdrOgK0Pa26tWw@mail.gmail.com>
Elijah Newren <newren@gmail.com> writes:
Show 48 quoted lines
> Hi Sergey,
>
> On Mon, Apr 18, 2022 at 12:30 AM Sergey Organov <sorganov@gmail.com> wrote:
>>
>> Elijah Newren <newren@gmail.com> writes:
>>
> [...]
>> > Replaying merges is something I've put a little thought into, so allow
>> > me to provide some pointers that may help.  Merges need special
>> > handling for replaying, and in my opinion, doing either just a new
>> > merge of the new trees (what rebase --rebase-merges does), or just
>> > reusing existing trees (what you proposed to start this thread) are
>> > both suboptimal, though the former is likely to just be annoying and
>> > require potentially unnecessary user refixing,
>>
>> It silently drops user changes as well, and that's the worst thing about
>> it, not annoyance.
>
> Yes, I mentioned that later in the email, but omitted it in the
> summary you highlight here just because the fixed-tree case was so
> much more likely to do it.  Anyway, sorry for the inaccuracy in the
> summarized version.
>
>> > whereas the latter can silently discard changes or reintroduce
>> > discarded changes and could be dangerous. More details on both of
>> > these...
>>
>> Please consider yet another option:
>
> I linked to where I had given another option.
>
>> https://public-inbox.org/git/87r2oxe3o1.fsf@javad.com/
>>
>> that at least is safe with respect to user changes.
>
> 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.

Yep, whoever is going to actually implement something always wins, and that's a good thing. I'm looking forward for the outcome of all this with a hope.

Thanks, -- Sergey Organov

Previous: Elijah NewrenNext: Tao Klerks
Message 14 of 25 in “[RFC] introducing git replay”
  1. Edmundo Carmona AntoranzApr 13, 2022
  2. Junio C HamanoApr 13, 2022
  3. Edmundo Carmona AntoranzApr 15, 2022
  4. Junio C HamanoApr 15, 2022
  5. Edmundo Carmona AntoranzApr 16, 2022
  6. Junio C HamanoApr 16, 2022
  7. Edmundo Carmona AntoranzApr 16, 2022
  8. Elijah NewrenApr 17, 2022
  9. Edmundo Carmona AntoranzApr 17, 2022
  10. Martin von ZweigbergkApr 17, 2022
  11. Edmundo Carmona AntoranzApr 18, 2022
  12. Sergey OrganovApr 18, 2022
  13. Elijah NewrenApr 18, 2022
  14. Sergey OrganovApr 18, 2022
  15. Tao KlerksApr 20, 2022
  16. Elijah NewrenApr 21, 2022
  17. rsbecker@nexbridge.comApr 13, 2022
  18. Edmundo Carmona AntoranzApr 13, 2022
  19. Edmundo Carmona AntoranzApr 13, 2022
  20. Phillip SusiApr 13, 2022
  21. Edmundo Carmona AntoranzApr 13, 2022
  22. Ævar Arnfjörð BjarmasonApr 13, 2022
  23. Junio C HamanoApr 13, 2022
  24. Edmundo Carmona AntoranzApr 13, 2022
  25. Eric SunshineApr 13, 2022

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.