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=-3.9 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE 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 5C9C21F487 for ; Tue, 31 Mar 2020 00:00:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729138AbgCaAAf (ORCPT ); Mon, 30 Mar 2020 20:00:35 -0400 Received: from mx.sdf.org ([205.166.94.20]:57005 "EHLO mx.sdf.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727553AbgCaAAf (ORCPT ); Mon, 30 Mar 2020 20:00:35 -0400 Received: from sdf.org (IDENT:lkml@sdf.lonestar.org [205.166.94.16]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 02V00KiI025915 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Tue, 31 Mar 2020 00:00:20 GMT Received: (from lkml@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 02V00KI4010913; Tue, 31 Mar 2020 00:00:20 GMT Date: Tue, 31 Mar 2020 00:00:18 +0000 From: George Spelvin To: Johannes Schindelin Cc: Junio C Hamano , git@vger.kernel.org, Philip Oakley , lkml@sdf.org Subject: Re: Feature request: rebase -i inside of rebase -i Message-ID: <20200331000018.GD9199@SDF.ORG> References: <20200320223015.GA19579@SDF.ORG> <20200320233528.GB19579@SDF.ORG> <20200321175612.GC19579@SDF.ORG> <20200326001821.GB8865@SDF.ORG> <20200328163024.GA26885@SDF.ORG> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200328163024.GA26885@SDF.ORG> Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Thinking about Philip Oakley's suggestion, it dawned on me that we can *already* do a nested rebase manually, and having a less manual alias for the procedure would be reasonable. Suppose the last four commits are O-A-B-C, and whether they were created by this rebase or existed before is irrelevant. If I want to rebase --nested -i O, then I --edit-todo and prepend the following four lines: reset O pick A pick B pick C If a nested rebase command does just that, I think it would cover my use case. If it adds a comment saying "nested rebase ends here", it's easy to cancel the nested rebase if there was a mistake. A slightly fancier thing a nestrd rebase could do is see if any of the newly created picks are also used in merges that were already in the todo list. In that case, follow the pick by a label command and update the later merge to refer to the label.