From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-4.1 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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.2 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by dcvr.yhbt.net (Postfix) with ESMTP id 90701202BB for ; Fri, 29 Mar 2019 17:53:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729843AbfC2Rwz (ORCPT ); Fri, 29 Mar 2019 13:52:55 -0400 Received: from mail-pg1-f194.google.com ([209.85.215.194]:40304 "EHLO mail-pg1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728977AbfC2Rwz (ORCPT ); Fri, 29 Mar 2019 13:52:55 -0400 Received: by mail-pg1-f194.google.com with SMTP id u9so1554492pgo.7 for ; Fri, 29 Mar 2019 10:52:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=tNAgGkdGUcAin8Q3RnlfQ5nLDmRA6zRfKfbbw68wEsc=; b=Mzvl4wB99PqxY6Ylvf2lg8XiY1eMre4dfkIQ7IwHfTxbkH1JugdCKSjjRAm52MCrtP qYWv3tPBAUJJZX4O3h1Lh3ix5V/u9NorpKwbjP85myjf6kMzsuaawIGrFAnK/xZ+wLyZ D4vvXDu9Q/laWesn0CC0TRjdWpruLIkdfeHd3FUvWK+6mUHgIwO882cLxwcLkFtd3VjR 5jZ8ghaTW3T1kSM4imSUhBwfdR4GpAflypy4tWbHYGRtPSnpHDUpBKY1eY3B1KHTQ/+8 W6Z5Xb4+blyoXJIJ3ur6SsvmlADEMUwYvAbf8UEXojlwg9Hwn0oqt84HQYhr3k0gVPry /J0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=tNAgGkdGUcAin8Q3RnlfQ5nLDmRA6zRfKfbbw68wEsc=; b=dzyiWwQBOhpBy5JNCNI27KyEPWH2YFNdFGMmjkUDoxRw8sDo3BP8f5BS1u9/Efgnrv MG6vf3wMvYawO5Qwo+KKVO/f1HE5/L3aPm/Ic+GtTXBuNe4AdwB8RNvCklBEJ6whcr+c mazaXbN1NBBDouNuALKNOM+ZK/pzwkZeHuHpn6XTLVwOpElPxdR47i4JqrqppkCLJVmB KLjGmeT9BHL2LmCwmYTEaB0mDprE3Z7AkKnuIY/ZOedL8slNQypQd2wTx2h//UrpBhg+ crS/W+I440++EyTJY3p4dsPoDIv+xIIfo+bzIFKIEZWj7k6yw4TbBdM11HuUdcPzqTDl ioXQ== X-Gm-Message-State: APjAAAV26EViOdjktbTN0DfBxv1d1JPEfeGMZnlqv6ovjecOPJhA3vAO +gWrSl+drrffSV7bbb3pq50= X-Google-Smtp-Source: APXvYqzz0JyifmF8XzwG3BEFcLSWisfJCzKNyqawGRKffCZ3f2q9lnUi+/3LeV9YdaJSETRFNgs2XA== X-Received: by 2002:a63:6a42:: with SMTP id f63mr20602820pgc.207.1553881973858; Fri, 29 Mar 2019 10:52:53 -0700 (PDT) Received: from dev-l ([149.28.200.39]) by smtp.gmail.com with ESMTPSA id j20sm3361790pff.22.2019.03.29.10.52.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Mar 2019 10:52:52 -0700 (PDT) Date: Fri, 29 Mar 2019 10:52:50 -0700 From: Denton Liu To: Johannes Schindelin Cc: Git Mailing List , Eric Sunshine , Junio C Hamano , =?iso-8859-1?Q?=C6var_Arnfj=F6r=F0?= Bjarmason Subject: Re: [PATCH v2] rebase: teach rebase --keep-base Message-ID: <20190329175250.GA18702@dev-l> References: <20190328221745.GA3941@dev-l> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Hi Johannes, On Fri, Mar 29, 2019 at 04:47:42PM +0100, Johannes Schindelin wrote: > Hi Denton, > > On Thu, 28 Mar 2019, Denton Liu wrote: > > > A common scenario is if a user is working on a topic branch and they > > wish to make some changes to intermediate commits or autosquash, they > > would run something such as > > > > git rebase -i --onto master... master > > > > in order to preserve the merge base. This prevents unnecessary commit > > churning. > > Maybe an example would clarify what you try to do here? Something like: > > Example: When contributing a patch series to the Git mailing list, > one often starts on top of the current `master`. However, while > developing the patch series, `master` is also developed further, > and it is sometimes not the best idea to keep rebasing on top > of `master`, but to keep the base commit as-is. In such a case, > the user can call > > git rebase -i --onto master... master > > as a shortcut to using the merge base between `master` and the > current branch as base commit. Will do, I'll include an example in the next reroll (probably in the docs too). > > I wonder, however, whether it makes sense to introduce a shorter, sweeter > way to do this: > > git rebase -i master... > > I.e. if we detect that the `` argument is not a valid ref, that > it ends with three dots, and that stripping those dots off makes it a > valid ref, then we internally convert that to the same as `--onto > master... master`. There's one use-case that this syntax wouldn't cover. Currently, if isn't specified, rebase automatically uses 'git merge-base --fork-point @{u} HEAD' as . This is even true for an invocation of 'git rebase --keep-base'. As a result, suppose we have the following graph o - f - o - U' origin/master \ U - A master where U used to be in origin/master (when we forked off) but upstream was rewound to drop it. If we run 'git rebase --keep-base', we'll get the following graph: o - f - o - U' origin/master \ A master i.e. we'll drop the commit dropped by upstream. I'm not entirely sure how useful this is, though, so if we decide to drop support for this use-case, then your proposed syntax will be fine. Thanks, Denton > > What do you think? > > Ciao, > Dscho > > > Alternatively, a user wishing to test individual commits in a topic > > branch without changing anything may run > > > > git rebase -x ./test.sh master... master > > > > Since rebasing onto the merge base of the branch and the upstream is > > such a common case, introduce the --keep-base option as a shortcut. > > > > This allows us to rewrite the above as > > > > git rebase -i --keep-base master > > > > and > > > > git rebase -x ./test.sh --keep-base master > > > > respectively. > > > > Add tests to ensure --keep-base works correctly in the normal case and > > fails when there are multiple merge bases, both in regular and > > interactive mode. Also, test to make sure conflicting options cause > > rebase to fail. While we're adding test cases, add a missing > > set_fake_editor call to 'rebase -i --onto master...side'. > > > > While we're documenting the --keep-base option, change an instance of > > "merge-base" to "merge base", which is the consistent spelling. > > > > Helped-by: Eric Sunshine > > Helped-by: Junio C Hamano > > Helped-by: Ævar Arnfjörð Bjarmason > > Signed-off-by: Denton Liu > > --- > > > > Ævar, I have a feeling that we're still miscommunicating and we don't > > fully understand each other. I'm putting up v2 to hopefully clear things > > up a little but I welcome more feedback. > > > > This patch now depends "[PATCH 1/8] tests (rebase): spell out the > > `--keep-empty` option" which is the first patch of Johannes's "Do not > > use abbreviated options in tests" patchset[1]. (Thanks for catching > > that, Johannes!) > > > > Changes since v1: > > > > * Squashed old set into one patch > > * Fixed indentation style and dangling else > > * Added more documentation after discussion with Ævar > > > > [1]: https://public-inbox.org/git/a1b4b74b9167e279dae4cd8c58fb28d8a714a66a.1553537656.git.gitgitgadget@gmail.com/ > > > > Documentation/git-rebase.txt | 25 ++++++++++++-- > > builtin/rebase.c | 32 ++++++++++++++---- > > t/t3416-rebase-onto-threedots.sh | 57 ++++++++++++++++++++++++++++++++ > > 3 files changed, 105 insertions(+), 9 deletions(-) > > > > diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt > > index 6363d674b7..27be1f48ff 100644 > > --- a/Documentation/git-rebase.txt > > +++ b/Documentation/git-rebase.txt > > @@ -8,8 +8,8 @@ git-rebase - Reapply commits on top of another base tip > > SYNOPSIS > > -------- > > [verse] > > -'git rebase' [-i | --interactive] [] [--exec ] [--onto ] > > - [ []] > > +'git rebase' [-i | --interactive] [] [--exec ] > > + [--onto | --keep-base] [ []] > > 'git rebase' [-i | --interactive] [] [--exec ] [--onto ] > > --root [] > > 'git rebase' --continue | --skip | --abort | --quit | --edit-todo | --show-current-patch > > @@ -217,6 +217,19 @@ As a special case, you may use "A\...B" as a shortcut for the > > merge base of A and B if there is exactly one merge base. You can > > leave out at most one of A and B, in which case it defaults to HEAD. > > > > +--keep-base:: > > + Set the starting point at which to create the new commits to the > > + merge base of . Running > > + 'git rebase --keep-base ' is equivalent to > > + running 'git rebase --onto ... '. > > ++ > > +Although both this option and --fork-point find the merge base between > > + and , this option uses the merge base as the _starting > > +point_ on which new commits will be created, whereas --fork-point uses > > +the merge base to determine the _set of commits_ which will be rebased. > > ++ > > +See also INCOMPATIBLE OPTIONS below. > > + > > :: > > Upstream branch to compare against. May be any valid commit, > > not just an existing branch name. Defaults to the configured > > @@ -364,6 +377,10 @@ ends up being empty, the will be used as a fallback. > > + > > If either or --root is given on the command line, then the > > default is `--no-fork-point`, otherwise the default is `--fork-point`. > > ++ > > +If your branch was based on but was rewound and > > +your branch contains commits which were dropped, this option can be used > > +with `--keep-base` in order to drop those commits from your branch. > > > > --ignore-whitespace:: > > --whitespace=