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? 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? Thanks, Jake > IMHO that was severe mistake in the original --preserve-merges, and you > bring with you to this new --recreate-merges... It's sad. Even more sad > as solution is already known for years: > > bc00341838a8faddcd101da9e746902994eef38a > Author: Johannes Sixt <j...@kdbg.org> > Date: Sun Jun 16 15:50:42 2013 +0200 > > rebase -p --first-parent: redo merge by cherry-picking first-parent > change > > and it works like a charm. > > -- Sergey >
