{"thread":{"id":"48141","subject":"Should I try to fix rebase interactive preserve-merges bug","startedAt":"2018-03-25T17:33:02Z","lastAt":"2018-03-26T22:00:27Z","messageCount":4,"participants":["Wink Saville","Jacob Keller","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"342912","messageId":"CAKk8isqvfhiMPCdNBW5WNN4BfN1sLszekQscpy5M2Okh2YmbZg@mail.gmail.com","threadId":"48141","inReplyTo":null,"subject":"Should I try to fix rebase interactive preserve-merges bug","fromName":"Wink Saville","fromEmail":"wink@saville.com","sentAt":"2018-03-25T17:32:34Z","receivedAt":"2018-03-25T17:33:02Z","isPatch":false,"sender":{"key":"wink@saville.com","avatar":"https://avatars.githubusercontent.com/u/1024284?v=4"},"body":"There is a \"TODO known breakage\" in t3404-rebase-interactve.sh:\n\n not ok 24 - exchange two commits with -p # TODO known breakage\n\nI'm contemplating trying to fix it. But with --recreate-merges coming\nmaybe it's not worth the effort. Should I proceed with attempting a\nfix or is --preserve-merges going to be a synonym for\n--recreate-merges?\n\n-- Wink\n"},{"id":"342915","messageId":"CA+P7+xqqLU-J5hv=yioMxMvp40hz_S9GfimjE7bp1Pj_TP-k3w@mail.gmail.com","threadId":"48141","inReplyTo":"CAKk8isqvfhiMPCdNBW5WNN4BfN1sLszekQscpy5M2Okh2YmbZg@mail.gmail.com","subject":"Re: Should I try to fix rebase interactive preserve-merges bug","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2018-03-25T18:07:32Z","receivedAt":"2018-03-25T18:07:58Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Sun, Mar 25, 2018 at 10:32 AM, Wink Saville wrote:\n> There is a \"TODO known breakage\" in t3404-rebase-interactve.sh:\n>\n> not ok 24 - exchange two commits with -p # TODO known breakage\n>\n> I'm contemplating trying to fix it. But with --recreate-merges coming\n> maybe it's not worth the effort. Should I proceed with attempting a\n> fix or is --preserve-merges going to be a synonym for\n> --recreate-merges?\n>\n> -- Wink\n\nAFAIK this breakage of preserve-merges is a design flaw which isn't\nreally fixable, which is why --recreate-merges is being added.\n\nI believe the plan is to deprecate preserve-merges once\nrecreate-merges has landed.\n\nThanks,\nJake\n"},{"id":"342937","messageId":"CAKk8isp_oFNRNbO0fSJx5GC_QKKiojsL=TxBJu2Z54xp5NCFDA@mail.gmail.com","threadId":"48141","inReplyTo":"CA+P7+xqqLU-J5hv=yioMxMvp40hz_S9GfimjE7bp1Pj_TP-k3w@mail.gmail.com","subject":"Re: Should I try to fix rebase interactive preserve-merges bug","fromName":"Wink Saville","fromEmail":"wink@saville.com","sentAt":"2018-03-25T20:22:50Z","receivedAt":"2018-03-25T20:23:17Z","isPatch":false,"sender":{"key":"wink@saville.com","avatar":"https://avatars.githubusercontent.com/u/1024284?v=4"},"body":"> AFAIK this breakage of preserve-merges is a design flaw which isn't\n> really fixable, which is why --recreate-merges is being added.\n>\n> I believe the plan is to deprecate preserve-merges once\n> recreate-merges has landed.\n>\n> Thanks,\n> Jake\n\n\nTxs for the info, hopefully others will respond.\n"},{"id":"343076","messageId":"nycvar.QRO.7.76.6.1803262348080.77@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz","threadId":"48141","inReplyTo":"CA+P7+xqqLU-J5hv=yioMxMvp40hz_S9GfimjE7bp1Pj_TP-k3w@mail.gmail.com","subject":"Re: Should I try to fix rebase interactive preserve-merges bug","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2018-03-26T22:00:14Z","receivedAt":"2018-03-26T22:00:27Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Jake & Wink,\n\nOn Sun, 25 Mar 2018, Jacob Keller wrote:\n\n> On Sun, Mar 25, 2018 at 10:32 AM, Wink Saville wrote:\n> > There is a \"TODO known breakage\" in t3404-rebase-interactve.sh:\n> >\n> > not ok 24 - exchange two commits with -p # TODO known breakage\n> >\n> > I'm contemplating trying to fix it. But with --recreate-merges coming\n> > maybe it's not worth the effort. Should I proceed with attempting a\n> > fix or is --preserve-merges going to be a synonym for\n> > --recreate-merges?\n> \n> AFAIK this breakage of preserve-merges is a design flaw which isn't\n> really fixable, which is why --recreate-merges is being added.\n> \n> I believe the plan is to deprecate preserve-merges once\n> recreate-merges has landed.\n\nIndeed, my plan is to deprecate preserve-merges once recreate-merges\nlanded and proved robust.\n\nThe problem with the `pick` overloading in preserve-merges is many-fold:\n\n- `pick` is used for merge commits, too. Therefore, the parents of the\n picked commits are *implicit*: a rebased commit will always have the\n rebased parents (or the original parents, for commits that were not\n (yet) rebased).\n\n The only way to fix this would be to break the current syntax, and\n thereby break existing users' scripts. (I know of a few users, and I\n know better than assuming that there are no power users out there\n scripting *everything* on top of Git, as I am such a power user\n myself).\n\n- One might be tempted to special-case that implicit parent-keeping for\n the cases where merge commits are picked, and respect order for\n non-merge commits.\n\n However, *nothing* in the todo list (apart from the commit messages,\n which can easily be edited however) indicates whether a `pick` has a\n merge or a non-merge commit as parameter. That makes this \"solution\" a\n highly unintuive and inconsistent one.\n\n- Even worse: if you ever found yourself editing long-ish todo lists in an\n alternative of preserve-merges (such as Git for Windows' garden shears\n [*1*]), you will know that it is *important* to know when you cross a\n merge commit line. Reordering within a linear list of non-merge commits\n is relatively safe. Moving a `pick` across a merge commit line is\n definitely causing a lot of grief, generally speaking.\n\n In short: my hard-won experience tells me that a todo list *needs* a\n visual cue that lets users tell apart the sequences of non-merge commits\n from the merge commit lines.\n\nSo there is more than just a technical problem with the design of the\npreserve-merges feature. Its UI is fundamentally broken.\n\nWhich makes sense, as I intended preserve-merges to be non-interactive\nonly, and there was a single reason why it was piggy-backed on top of the\ninteractive rebase: this was the easiest way to implement that feature. I\nwas never a fan of enabling -p with -i, and I am fairly certain that I\nwarned against this. Turns out I was right. Strange, I know.\n\nCiao,\nJohannes\n\nFootnote *1*:\nhttps://github.com/git-for-windows/build-extra/blob/master/shears.sh\n"}]}