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: AS53758 23.128.96.0/24 X-Spam-Status: No, score=-3.8 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by dcvr.yhbt.net (Postfix) with ESMTP id 387E81F8C6 for ; Thu, 29 Jul 2021 10:21:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235679AbhG2KVv (ORCPT ); Thu, 29 Jul 2021 06:21:51 -0400 Received: from cloud.peff.net ([104.130.231.41]:60646 "EHLO cloud.peff.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235155AbhG2KVu (ORCPT ); Thu, 29 Jul 2021 06:21:50 -0400 Received: (qmail 8087 invoked by uid 109); 29 Jul 2021 10:21:42 -0000 Received: from Unknown (HELO peff.net) (10.0.1.2) by cloud.peff.net (qpsmtpd/0.94) with ESMTP; Thu, 29 Jul 2021 10:21:42 +0000 Authentication-Results: cloud.peff.net; auth=none Received: (qmail 18265 invoked by uid 111); 29 Jul 2021 10:21:44 -0000 Received: from coredump.intra.peff.net (HELO sigill.intra.peff.net) (10.0.0.2) by peff.net (qpsmtpd/0.94) with (TLS_AES_256_GCM_SHA384 encrypted) ESMTPS; Thu, 29 Jul 2021 06:21:44 -0400 Authentication-Results: peff.net; auth=none Date: Thu, 29 Jul 2021 06:21:41 -0400 From: Jeff King To: Philip Oakley Cc: Daniel Knittl-Frank , Git List Subject: Re: Using two-dot range notation in `git rebase`? Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Thu, Jul 29, 2021 at 10:58:15AM +0100, Philip Oakley wrote: > In summary, there are two aspect: > - first, being able to use a common short-form within the command, and > - second, that the documentation's description includes rather too many > tricky concepts to properly understand all the ramifications, leaving me > to think "why can't I just say `git rebase --onto here old..end` or `git > rebase --onto here start^..end` ? " I do think "git rebase --onto here old..end" is a sensible thing to ask for. If we were designing it today, I'd probably suggest that rebase take arbitrary revision sets (and either require "--onto", or perhaps as long as there is only one negative tip given, that becomes the "--onto" point). It might be possible to migrate to such a syntax, but we'd have to be careful of ambiguities with the current syntax. It might be possible to infer the intended use based on the presence or absence of negative tips (so "git rebase foo bar" must be "foo is the upstream, and therefore base branch", whereas "git rebase foo..bar" is a range, though the two would do the same thing). I think we did something similar with cherry-pick, which originally took only a series of single commits. I admit that I haven't thought carefully through the details, though. There may be some gotchas in how "rebase" treats the base branch. -Peff