* Re: Should I try to fix rebase interactive preserve-merges bug
2018-03-25 18:07 ` Jacob Keller
2018-03-25 20:22 ` Wink Saville
@ 2018-03-26 22:00 ` Johannes Schindelin
1 sibling, 0 replies; 4+ messages in thread
From: Johannes Schindelin @ 2018-03-26 22:00 UTC (permalink / raw)
To: Jacob Keller; +Cc: Wink Saville, Git List
Hi Jake & Wink,
On Sun, 25 Mar 2018, Jacob Keller wrote:
> On Sun, Mar 25, 2018 at 10:32 AM, Wink Saville <wink@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
^ permalink raw reply [flat|nested] 4+ messages in thread