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.1 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 3DCC41F404 for ; Mon, 9 Apr 2018 21:32:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752467AbeDIVcT (ORCPT ); Mon, 9 Apr 2018 17:32:19 -0400 Received: from mout.gmx.net ([212.227.17.21]:36903 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751543AbeDIVcS (ORCPT ); Mon, 9 Apr 2018 17:32:18 -0400 Received: from [192.168.0.129] ([37.201.195.115]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Mg0IT-1etC2q3M8b-00NTBB; Mon, 09 Apr 2018 23:32:13 +0200 Date: Mon, 9 Apr 2018 23:32:14 +0200 (DST) From: Johannes Schindelin X-X-Sender: virtualbox@MININT-6BKU6QN.europe.corp.microsoft.com To: Junio C Hamano cc: git@vger.kernel.org Subject: Re: What's cooking in git.git (Apr 2018, #01; Mon, 9) In-Reply-To: Message-ID: 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:aFz5Sgyo1Yr+DtS97ldXN769OibCUGjMssGrf/mi0Nza0HrL/p/ DkZ5pNgrN9qT8K4ZGNRjHO1y5xbAZDoPR9ykW6OaJ1XKVLjDOqGNMoHqjbYR90l6bUrfeK8 39mgYk9KmmTYk231t9hH8BY05TD6gGS/iGxtSRbbgJslPnoyAVzyuMAujHm28I0ioJCs8Ms qWXxSU6xxGGBEFsStO2rw== X-UI-Out-Filterresults: notjunk:1;V01:K0:sRMYwawc46I=:NtGotHOyC92Xw9+f3k5oH/ P5PoDec6vlcx1tqP4gqiWyXGqoFViGKc26EndOfln/vb0lDp5hpq41FQqelVfb+3VhSyHn2BQ o3Sp/BGWn7nwKCmtuJKsoL+F1AUYV0YkrDjlz2AGMyZL3tFpfs+5ahuPq2N/jCiXyFAFOMjW+ Inrlf6vRcahRqzHDzFTg+iVFphGqq1BQD07i+a0jeYF9JW2ZJBPjVcwn50ZET3Bxh/ZTfShLs Ua9m3EDQXoa0Wy6Nc0zcEKGIjofNUEOXUZZ56vbVDz2EWmgzcGm7GUSbEYLGNOoclOKTaeLQq SaSzUIU17IjcD+VO+1Pno675zB62mwJ+8rlCLf3tFOo5WoSC/V+VB0M8MykfavUaM/o9vKlLJ VctS+PI4oowb4d7nSUG0HVdeUGnsw+zepc2G0FNhXXpMqQAJHqoFt/LjqP52GPQGcVexuF9Eq Obybl9UrTBC/ZQwz1jlo1/VtO1c0sjLYQ0OWnHysdC6nLP3AzAC4KS5rs512ffuON93bF9MCd mKQUwMYvo7pVuJhrs8Q4siUomdcAoG87j4h6KatnnQJ2mXFH24azY9Nj/aO93up0mTXG3J7yn 3kYKeIjTQ0NG4fo3aiHRIpJkPE5o02v8LnqU7j0re60JMcbZVvPsnbrm+tnAXvlta+KySLkIV DuGS9W99PUJbE7w8EzhPPAxyio1ZxRYPO6MIY/iUkAqCruBSrn8RUbNyYtp6444sgmqi4wdkt OHCLXMha94+vrALETG3Aoiipru5TjywESN/OQNRgTy/PFmer/SV9hsrc0wguUR94j2EllR9ZS zBZQjtkhQ7V7lSMpY+iK8Qxv74DoqMXkQVqr1+3P8+GBNAPIsA= Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Hi, On Mon, 9 Apr 2018, Johannes Schindelin wrote: > On Mon, 9 Apr 2018, Junio C Hamano wrote: > > > * js/rebase-recreate-merge (2018-02-23) 12 commits (merged to 'next' > > on 2018-03-15 at 3d1671756f) + rebase -i: introduce > > --recreate-merges=[no-]rebase-cousins + pull: accept --rebase=recreate > > to recreate the branch topology + sequencer: handle post-rewrite for > > merge commands + sequencer: make refs generated by the `label` command > > worktree-local + rebase: introduce the --recreate-merges option + > > rebase-helper --make-script: introduce a flag to recreate merges + > > sequencer: fast-forward merge commits, if possible + sequencer: > > introduce the `merge` command + sequencer: introduce new commands to > > reset the revision + git-rebase--interactive: clarify arguments + > > sequencer: make rearrange_squash() a bit more obvious + sequencer: > > avoid using errno clobbered by rollback_lock_file() > > > > "git rebase" learned "--recreate-merges" to transplant the whole > > topology of commit graph elsewhere. > > > > This serise has been reverted out of 'next', expecting that it will > > be replaced by a reroll on top of a couple of topics by Phillip. > > [.,..] I will send out a new iteration of the patch series (the > --rebase-merges one, formerly known as --recreate-merges) soon > (hopefully still today). I encountered one more scenario I need to handle: when all the patches in a topic branch were already applied upstream, I typically want to skip merging a now-empty branch. Since upstream might have changed the patches subtly (so that --cherry-pick does not skip them), the user may have had to `git rebase --skip` the unmodified version of the now-upstream patches. Therefore, we cannot test at todo list generation time whether a merge can be skipped because it would merge an ancestor of its first parent. I plan on introducing a flag similar to "rebase-cousins" for this: probably "skip-empty-merges", defaulting to skipping them (because why would you want to merge something that is already part of the HEAD's commit history?). However, I won't be able to finish this today. Thanks for your patience, Dscho