From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-3.2 required=3.0 tests=AWL,BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI shortcircuit=no autolearn=ham autolearn_force=no version=3.4.0 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by dcvr.yhbt.net (Postfix) with ESMTP id 61CA41F42D for ; Sat, 21 Apr 2018 10:35:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752757AbeDUKfK (ORCPT ); Sat, 21 Apr 2018 06:35:10 -0400 Received: from mout.gmx.net ([212.227.17.20]:45173 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751496AbeDUKfI (ORCPT ); Sat, 21 Apr 2018 06:35:08 -0400 Received: from [192.168.0.129] ([37.201.195.116]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MQ2Tn-1f4aer05jP-005JAr; Sat, 21 Apr 2018 12:35:02 +0200 Date: Sat, 21 Apr 2018 12:34:46 +0200 (DST) From: Johannes Schindelin X-X-Sender: virtualbox@MININT-6BKU6QN.europe.corp.microsoft.com To: git@vger.kernel.org cc: Junio C Hamano , Jacob Keller , Stefan Beller , Philip Oakley , Eric Sunshine , Phillip Wood , Igor Djordjevic , Johannes Sixt , Sergey Organov , =?UTF-8?Q?Martin_=C3=85gren?= Subject: [PATCH v8 09/16] rebase: introduce the --rebase-merges option In-Reply-To: Message-ID: <0c92bdd1829328544269722cbbd3edcd169bb148.1524306547.git.johannes.schindelin@gmx.de> References: User-Agent: Alpine 2.21.1 (DEB 209 2017-03-23) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Provags-ID: V03:K1:S2IFJQDO9BE0rSvrBWQ/4yyPWemScaqwGA5eCzH8+kBmKXWMj07 MzAnfIMhqAqtGPnIkQ/qoc06JOc6vOrQUVHJtLQw8jy7wr5qairmYKcJo0OTn3wKLGEFOR5 UT2ECUUBPpoq4vZkN/czMcSFVn5/eR77AwxyHhpoJ1feWVqVARox0JmaI561K2q4pZ2EMps PHFJ9aKI4nxemw0WCdo+g== X-UI-Out-Filterresults: notjunk:1;V01:K0:mqg/Qv3jroo=:q7AMg62gXB2OIdUYaOGWjV 67+oBCL9FnJcK4LXV/sSjhX+K9rjJNoWdMOD7iaScy1Gv2bYySQiyh/sL/S0UdMUwBUEae5z0 yQq0XF+VEYFlsjGosctwh3mjsKj/A4dCaSXivQphOWarL6AOzkESxe7qFwdwd1zjONMVEp6Tv YP1m+tj18TvBTVFSjOSv4PMqGB1HVKUWmP1Lawu5fX4L6iDZQHROP+emiyWCDOjQDY84aNoGR uJt/A7WZmh9ZnESnXjbop/3c0cEszxUiTE635hFBplQHhSqRsdQed4U8rSAgPqJQY3J16Y4m2 2sTwnQPEL79fvAen/BKiDVEDNJQx7kLdkUqQiN4/8DvS+HZyzbBbcEzfSCWKDv6cZz6ld9/Nf 9NndTpw07dXXUF7vDNRkG0bi9jyKqHYCGGdVK1+x4cZhY8HeGtoqf5FMJI8Z+11BI8+kg1JH5 yugmn+QYVKWWK6GF0aeli2fqDmmpfdICpVdPQwvZuD/jFiVs5krhVtThxVLmBZlwIm+PC+tMx 35AE1mtmatiqM4nUYcRw3XoD2h9d3JtN4AYnvtjNJ1fo/2qZoX7B1Yuf315w1nw0eAz5SrMBp no9T2zqCqxorviUubFTuV3Nz7yA3YYR6oeXMsjLcavVgfyuOghFHZaG318MtsNuG0d9b/1h22 Fmi9bxEN194ZaBWGEYPaexDjpqmIbq5TQegLLQDvsd4ieSo31xVGGhaDqzUU5dZdrpHcjYjFC ZFDyLv0O1WDl7bjzqkzo6K5l+DLX65kRQn4uk13R4w2B/H72aqyDgX84iDma2emNd85Ongisa 1snEoLA11svjqrIrRcvYgnF0shbPzTRG6bJotNPRkUt7jOYg4Q= Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Once upon a time, this here developer thought: wouldn't it be nice if, say, Git for Windows' patches on top of core Git could be represented as a thicket of branches, and be rebased on top of core Git in order to maintain a cherry-pick'able set of patch series? The original attempt to answer this was: git rebase --preserve-merges. However, that experiment was never intended as an interactive option, and it only piggy-backed on git rebase --interactive because that command's implementation looked already very, very familiar: it was designed by the same person who designed --preserve-merges: yours truly. Some time later, some other developer (I am looking at you, Andreas! ;-)) decided that it would be a good idea to allow --preserve-merges to be combined with --interactive (with caveats!) and the Git maintainer (well, the interim Git maintainer during Junio's absence, that is) agreed, and that is when the glamor of the --preserve-merges design started to fall apart rather quickly and unglamorously. The reason? In --preserve-merges mode, the parents of a merge commit (or for that matter, of *any* commit) were not stated explicitly, but were *implied* by the commit name passed to the `pick` command. This made it impossible, for example, to reorder commits. Not to mention to flatten the branch topology or, deity forbid, to split topic branches into two. Alas, these shortcomings also prevented that mode (whose original purpose was to serve Git for Windows' needs, with the additional hope that it may be useful to others, too) from serving Git for Windows' needs. Five years later, when it became really untenable to have one unwieldy, big hodge-podge patch series of partly related, partly unrelated patches in Git for Windows that was rebased onto core Git's tags from time to time (earning the undeserved wrath of the developer of the ill-fated git-remote-hg series that first obsoleted Git for Windows' competing approach, only to be abandoned without maintainer later) was really untenable, the "Git garden shears" were born [*1*/*2*]: a script, piggy-backing on top of the interactive rebase, that would first determine the branch topology of the patches to be rebased, create a pseudo todo list for further editing, transform the result into a real todo list (making heavy use of the `exec` command to "implement" the missing todo list commands) and finally recreate the patch series on top of the new base commit. That was in 2013. And it took about three weeks to come up with the design and implement it as an out-of-tree script. Needless to say, the implementation needed quite a few years to stabilize, all the while the design itself proved itself sound. With this patch, the goodness of the Git garden shears comes to `git rebase -i` itself. Passing the `--rebase-merges` option will generate a todo list that can be understood readily, and where it is obvious how to reorder commits. New branches can be introduced by inserting `label` commands and calling `merge