From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Jacob Keller <jacob.keller@gmail.com>
Cc: Wink Saville <wink@saville.com>, Git List <git@vger.kernel.org>
Subject: Re: Should I try to fix rebase interactive preserve-merges bug
Date: Tue, 27 Mar 2018 00:00:14 +0200 (DST) [thread overview]
Message-ID: <nycvar.QRO.7.76.6.1803262348080.77@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz> (raw)
In-Reply-To: <CA+P7+xqqLU-J5hv=yioMxMvp40hz_S9GfimjE7bp1Pj_TP-k3w@mail.gmail.com>
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
prev parent reply other threads:[~2018-03-26 22:00 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-25 17:32 Should I try to fix rebase interactive preserve-merges bug Wink Saville
2018-03-25 18:07 ` Jacob Keller
2018-03-25 20:22 ` Wink Saville
2018-03-26 22:00 ` Johannes Schindelin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=nycvar.QRO.7.76.6.1803262348080.77@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz \
--to=johannes.schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=jacob.keller@gmail.com \
--cc=wink@saville.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).