Hello, W dniu 01.09.2016 o 15:12, Johannes Schindelin pisze: > On Wed, 31 Aug 2016, Jakub Narębski wrote: >> W dniu 31.08.2016 o 21:10, Junio C Hamano pisze: >>> So I am not sure if we want a parsed commit there (I would not >>> object if we kept the texual object name read from the file, >>> though). The "one sequencer to rule them all" may even have to say >>> "now give name ':1' to the result of the previous operation" in one >>> step and in another later step have an instruction "merge ':1'". >>> When that happens, you cannot even pre-populate the commit object >>> when the sequencer reads the file, as the commit has not yet been >>> created at that point. >> >> True, --preserve-merges rebase is well, different. > > It is mis-designed. And I can be that harsh because it was my design. > > In the meantime I came up with a much better design, and implemented it as > a shell script on top of rebase -i. Since shell scripts run like slow > molasses, even more so on Windows, I have a loose plan to implement its > functionality as a new --recreate-merges option, and to deprecate > --preserve-merges when that new option works. > > It needs to be a new option (not a --preserve-merges=v2) because it is a > totally different beast. For starters, it does not need its own code path > that overrides pick_one, as --preserve-merges does. Better preserving for merges (with cleanly defined sematics) would be certainly nice to have. > But I get way ahead of myself. First we need to get these last few bits > and pieces in place to accelerate (non --preserve-merges) rebase -i. But it can wait, right. -- Jakub Narębski