On Mon, Jan 29, 2018 at 2:54 PM, Johannes Schindelin <johannes.schindelin@xxxxxx> wrote: > Once upon a time, I dreamt of an interactive rebase that would not > flatten branch structure, but instead recreate the commit topology > faithfully. > > My original attempt was --preserve-merges, but that design was so > limited that I did not even enable it in interactive mode. > > Subsequently, it *was* enabled in interactive mode, with the predictable > consequences: as the --preserve-merges design does not allow for > specifying the parents of merge commits explicitly, all the new commits' > parents are defined *implicitly* by the previous commit history, and > hence it is *not possible to even reorder commits*. > > This design flaw cannot be fixed. Not without a complete re-design, at > least. This patch series offers such a re-design. > > Think of --recreate-merges as "--preserve-merges done right". It > introduces new verbs for the todo list, `label`, `reset` and `merge`. > For a commit topology like this: > > A - B - C > \ / > D > > the generated todo list would look like this: > > # branch D > pick 0123 A > label branch-point > pick 1234 D > label D > > reset branch-point > pick 2345 B > merge 3456 D C > > There are more patches in the pipeline, based on this patch series, but > left for later in the interest of reviewable patch series: one mini > series to use the sequencer even for `git rebase -i --root`, and another > one to add support for octopus merges to --recreate-merges. > > Changes since v1: > > - reintroduced "sequencer: make refs generated by the `label` command > worktree-local" (which was squashed into "sequencer: handle autosquash > and post-rewrite for merge commands" by accident) > > - got rid of the universally-hated `bud` command Sorry if you got the impression for that. Maybe I was imprecise. I had no strong opinion one way or another, I merely pointed out the collision in abbreviation letters with the potential new 'break', IIRC. 'bud' was a special case for resetting to a specific revision (and labeling it?) Maybe we can have default labels, such that there is no need to reset to the first revision manually, but can just use these defaults in the merge. (I haven't thought about this in the big picture, just food for thought) > > - as per Stefan's suggestion, the help blurb at the end of the todo list > now lists the syntax > > - the no-rebase-cousins mode was made the default; This not only reflects > the experience won from those years of using the Git garden shears, but > was also deemed the better default in the discussion on the PR at > https://github.com/git/git/pull/447 > > - I tried to clarify the role of the `onto` label in the commit message of > `rebase-helper --make-script: introduce a flag to recreate merges` > > - fixed punctuation at the end of error(...) messages, and incorrect > upper-case at the start > > - changed the generated todo lists to separate the label and the oneline in > the `reset` command with a `#`, for readability > > - dropped redundant paragraph in the commit message that talked about > support for octopus merges > > - avoided empty error message when HEAD could not be read during do_label() > > - merge commits are fast-forwarded only unless --force-rebase was passed > > - do_merge() now errors out a lot earlier when HEAD could not be parsed > > - the one-letter variables to hold either abbreviated or full todo list > instructions in make_script_recreating_merges() were renamed to clearer > names > > - The description of rebase's --recreate-merge option has been reworded; > Hopefully it is a lot more clear now. > > > Johannes Schindelin (9): > sequencer: introduce new commands to reset the revision > sequencer: introduce the `merge` command > sequencer: fast-forward merge commits, if possible > rebase-helper --make-script: introduce a flag to recreate merges > rebase: introduce the --recreate-merges option > sequencer: make refs generated by the `label` command worktree-local > sequencer: handle autosquash and post-rewrite for merge commands > pull: accept --rebase=recreate to recreate the branch topology > rebase -i: introduce --recreate-merges=[no-]rebase-cousins > > Stefan Beller (1): > git-rebase--interactive: clarify arguments No need to honor me with authorship, as I just wrote that patch in a quick hurry to express the idea. But this is fine, too. The interdiff looks good to me, I'll review the patches now. Thanks, Stefan
