Should I try to fix rebase interactive preserve-merges bug

Should I try to fix rebase interactive preserve-merges bug

[Wink Saville]

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?

-- Wink

Re: Should I try to fix rebase interactive preserve-merges bug

[Jacob Keller]

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?
>
> -- Wink

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.

Thanks,
Jake

Re: Should I try to fix rebase interactive preserve-merges bug

[Wink Saville]

> 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.
>
> Thanks,
> Jake


Txs for the info, hopefully others will respond.

Re: Should I try to fix rebase interactive preserve-merges bug

[Johannes Schindelin]

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