On Sun, Apr 17, 2022 at 7:23 PM Martin von Zweigbergk <martinvonz@xxxxxxxxx> wrote: > > > My (Git-compatible) VCS [1] is very relevant to this thread. It always > treats the contents of a merge commit as the diff compared to the > re-merge (auto-merged) parents. That applies to diffs (like > --remerge-diff) and rebases (what Elijah suggested in that link above) > . An important part of the solution I went with is to store > information about conflicts in the commits. Note that it's a more > high-level representation of the conflicts - not conflict *markers* - > that's stored in the commits [2]. Adding a new kind of object type is > obviously a huge step to take for Git, but perhaps you can consider it > as long as these objects are not exchanged. Also, as you have probably > noticed with your `git replay` command, this kind of rebasing without > touching the working copy or trees can get pretty fast. I didn't see > any performance numbers in your original message, but you are probably > able to rebase >1k commits per second in the git.git repo [3]. > Thanks for all your input (I mean, everybody who has jumped into the conversation). In my last experiment to get this into rebase (and still without moving the working tree), the 900+ commits that make up the segment v2.35.0..v2.36.0-rc1 are converted in some 143 ms in my computer, which is an aging dinosaur.
