On Fri, Sep 23, 2016 at 2:13 PM, Johannes Schindelin <johannes.schinde...@gmx.de> wrote: > Hi Stefan, > > On Fri, 23 Sep 2016, Stefan Haller wrote: > >> Stefan Beller <sbel...@google.com> wrote: >> >> > On Thu, Sep 22, 2016 at 12:48 PM, Kevin Daudt <m...@ikke.info> wrote: >> > > On Thu, Sep 22, 2016 at 07:33:11PM +0000, Anatoly Borodin wrote: >> > >> Hi Stefan, >> > >> >> > >> this section was added to the manual in the commit >> > >> cddb42d2c58a9de9b2b5ef68817778e7afaace3e by "Jonathan Nieder" >> > >> <jrnie...@gmail.com> 6 years ago. Maybe he remembers better? >> > >> >> > > >> > > Just to make it clear, this section explicitly talks about 'bugs' with >> > > preserve-merges and interactive rebase. Without the --preserve-merges >> > > option, those operations works as expected. >> > > >> > > The reason, as that section explains, is that it's not possible to store >> > > the merge structure in the flat todo list. I assume this means git >> > > internally remembers where the merge commit was, and then restores it >> > > while rebasing. >> > > >> > > Changing the order, or dropping commits might then give unexpected >> > > results. >> > > >> > >> > The commit message may help as well: >> > >> > rebase -i -p: document shortcomings >> > >> > The rebase --preserve-merges facility presents a list of commits >> > in its instruction sheet and uses a separate table to keep >> > track of their parents. Unfortunately, in practice this means >> > that with -p after most attempts to rearrange patches, some >> > commits have the "wrong" parent and the resulting history is >> > rarely what the caller expected. >> > >> > Yes, it would be nice to fix that. But first, add a warning to the >> > manual to help the uninitiated understand what is going on. >> >> Thanks, but all of this still talks about the issues in very generic >> terms ("most attempts to rearrange patches"). I'm interested in more >> details as to exactly what kind of attempts do or don't work. In >> particular, I'm interested in fixup/squash commands (without reordering >> anything else), or dropping (non-merge) commits. >> >> I could of course experiment with these and try to find out myself, but >> I was hoping someone would just know the answer off the top of their >> head, saving me some time. > > The fundamental problem here is the underlying design of bolting on the > "recreate a merge" functionality onto the "pick" command. > > That is, if you try to rebase non-linear commit history, it will still > generate a linear list of "pick <commit-name>" lines, as if it were > linear, except that it will include the merge commits, too.
Which on a more fundamental design level would be ok. (C.f. your shell history is a linear list of git commands, but it deals just fine with non linear DAGSs) > > It then will try to guess what you want to do by recording which commit > was rewritten as which commit. And when it encounters a "pick" with a > merge commit, it will try to merge the *rewritten* commit. Instead of guessing we'd need to differentiate between "pick" and "pickmerge", whereas the later describes creating commits with more than one parent (i.e. the prior pick line). I could imagine the "pickmerge" to list all additional parents (The first parent being the previously picked commit) via symbolic naming: pick 1234affe implement foo pickmerge 3456feed origin/js/new-feature-1 # Merge origin/js/new-feature-1 pick 45678ead implement feature-2 The "pickmerge" would have first the merge tips, and then the old subject line after a # character. > > In other words, the design does not allow for changing the tip of any > merged branch. Not reordering, not dropping. I see how the current design is problematic as there is no argument possible that allows the user to correct the wrong guess. > > And I do not think that there is a way to fix that design. That is why I > came up with the Git garden shears (see the link I sent elsewhere in this > thread). I'll look into that. Thanks, Stefan