Hi Jake & Wink, On Sun, 25 Mar 2018, Jacob Keller wrote:
> On Sun, Mar 25, 2018 at 10:32 AM, Wink Saville <w...@saville.com> wrote: > > There is a "TODO known breakage" in t3404-rebase-interactve.sh: > > > > not ok 24 - exchange two commits with -p # TODO known breakage > > > > I'm contemplating trying to fix it. But with --recreate-merges coming > > maybe it's not worth the effort. Should I proceed with attempting a > > fix or is --preserve-merges going to be a synonym for > > --recreate-merges? > > AFAIK this breakage of preserve-merges is a design flaw which isn't > really fixable, which is why --recreate-merges is being added. > > I believe the plan is to deprecate preserve-merges once > recreate-merges has landed. Indeed, my plan is to deprecate preserve-merges once recreate-merges landed and proved robust. The problem with the `pick` overloading in preserve-merges is many-fold: - `pick` is used for merge commits, too. Therefore, the parents of the picked commits are *implicit*: a rebased commit will always have the rebased parents (or the original parents, for commits that were not (yet) rebased). The only way to fix this would be to break the current syntax, and thereby break existing users' scripts. (I know of a few users, and I know better than assuming that there are no power users out there scripting *everything* on top of Git, as I am such a power user myself). - One might be tempted to special-case that implicit parent-keeping for the cases where merge commits are picked, and respect order for non-merge commits. However, *nothing* in the todo list (apart from the commit messages, which can easily be edited however) indicates whether a `pick` has a merge or a non-merge commit as parameter. That makes this "solution" a highly unintuive and inconsistent one. - Even worse: if you ever found yourself editing long-ish todo lists in an alternative of preserve-merges (such as Git for Windows' garden shears [*1*]), you will know that it is *important* to know when you cross a merge commit line. Reordering within a linear list of non-merge commits is relatively safe. Moving a `pick` across a merge commit line is definitely causing a lot of grief, generally speaking. In short: my hard-won experience tells me that a todo list *needs* a visual cue that lets users tell apart the sequences of non-merge commits from the merge commit lines. So there is more than just a technical problem with the design of the preserve-merges feature. Its UI is fundamentally broken. Which makes sense, as I intended preserve-merges to be non-interactive only, and there was a single reason why it was piggy-backed on top of the interactive rebase: this was the easiest way to implement that feature. I was never a fan of enabling -p with -i, and I am fairly certain that I warned against this. Turns out I was right. Strange, I know. Ciao, Johannes Footnote *1*: https://github.com/git-for-windows/build-extra/blob/master/shears.sh
