Jacob Keller <jacob.kel...@gmail.com> writes: > On Tue, Feb 6, 2018 at 10:16 PM, Sergey Organov <sorga...@gmail.com> wrote: >> Johannes Schindelin <johannes.schinde...@gmx.de> writes: >> >> [...] >> >>> +--recreate-merges:: >>> + Recreate merge commits instead of flattening the history by replaying >>> + merges. Merge conflict resolutions or manual amendments to merge >>> + commits are not preserved. >> >> I wonder why you guys still hold on replaying "merge-the-operation" >> instead of replaying "merge-the-result"? The latter, the merge commit >> itself, no matter how exactly it was created in the first place, is the >> most valuable thing git keeps about the merge, and you silently drop it >> entirely! OTOH, git keeps almost no information about >> "merge-the-operation", so it's virtually impossible to reliably replay >> the operation automatically, and yet you try to. >> > > I'm not sure I follow what you mean here? > > You mean that you'd want this to actually attempt to re-create the > original merge including conflict resolutions by taking the contents > of the result?
I mean just cherry-pick the merge the same way all other commits are essentially cherry-picked during rebase. That's what Johannes Sixt did in his patch I was reffering to. > How do you handle if that result has conflicts? What UX do you present > to the user to handle such conflicts? I don't think the normal 3-way > conflicts would even be possible in this case? No problem here. It goes exactly the same way as for non-merge commits that are being rebased. You can try it right now using $ git cherry-pick -m1 <merge_commit> that will induce conflicts. The (somewhat tricky) functional difference is only in recording correct additional parents to the final commit, but that part is hidden from the user. -- Sergey
