From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-3.7 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, SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.6 Received: from out1.vger.email (out1.vger.email [IPv6:2620:137:e000::1:20]) by dcvr.yhbt.net (Postfix) with ESMTP id 9993A1F452 for ; Tue, 4 Apr 2023 21:15:03 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=QhfJJzyx; dkim-atps=neutral Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236033AbjDDVPB (ORCPT ); Tue, 4 Apr 2023 17:15:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51706 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232269AbjDDVPA (ORCPT ); Tue, 4 Apr 2023 17:15:00 -0400 Received: from mail-yw1-x1133.google.com (mail-yw1-x1133.google.com [IPv6:2607:f8b0:4864:20::1133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 209E8170E for ; Tue, 4 Apr 2023 14:14:58 -0700 (PDT) Received: by mail-yw1-x1133.google.com with SMTP id 00721157ae682-545e907790fso524934927b3.3 for ; Tue, 04 Apr 2023 14:14:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680642897; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=r6gxlXrgptADu/RlV/6WWqUkuRYhZwusmMmm5NDCv5c=; b=QhfJJzyxmyGIRK8D1rs73ot3kGgQFI5o6mMgoMVo9YNn7a3EIANwLfQ/ZTUYmxLofw h6HMt8tRawYfi492VjBTk2/sw7Lxx5lRsGUZap4OWzuR+wRqzeDJc0c5ChSWUueFkMc5 ddJ4iXA82KAitKXbSeETBnm9hduFhyYniWQviJgTUDdoNm5AJrVslH6qtJ20yQM3oCkG +gzFXvJa7hl5X6MF5jfVeOiXTTLhvr5mhClRc3MgL/jB7FjhVD7woWnQM5aGY6Czg1LI l7itMAHxOqtPtuGiu4lpiCn/eEEaWPTmc/NmrR1eNkYAxuR8vXUcgwhWiGij5V3Rp2mL QcYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680642897; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=r6gxlXrgptADu/RlV/6WWqUkuRYhZwusmMmm5NDCv5c=; b=xSV2fRpUwkgRZCCfrrQc1BFxI0gp1GB20ADqE2uingky2EWt6y6Pz2ML5TwDH1pEsv 0c5kOzDm/m2lwCpkidN8VkIkq3zYgMYMbdIxi4DeB5MqvRrCpYAD0XcdCzq7CzSaTvzE FBZ/kT0SLK1eMX/zcEiAmKVeJaEcefHMMyVU+xxufYrQFMSoofKvyzUN4MjsplK/qBz4 n294envQpf3gPWDrfFXn27WMP/cEA+jgchJMMunxwLPoHNkG6Jfty0A05quZ8ArnFBzb me59EW3yRYuyjJ13nXiFCiN2rK4mcORrz819+Gn4MRiSJ5XbNIx8r55noSCQQNVIUaPC JTCw== X-Gm-Message-State: AAQBX9eJ1tGMJGHzHc94Y+EQ+EW2R8VJXoBUkIzMslFw4oW3nHnKTYoV 6o74K7FgPSuGVqOruuhUiMjbFOJ2Ixd+0t1Lles= X-Google-Smtp-Source: AKy350bMSJ/Fx2x+E1xKjsFGJJGUJGp3UWGH7CBgXNDA8qIT4g/9tQRacqqZfe+96RddPTcAaRWEpquQVgpQw0MyMSU= X-Received: by 2002:a81:b283:0:b0:549:2cc8:6e3e with SMTP id q125-20020a81b283000000b005492cc86e3emr2292786ywh.9.1680642897303; Tue, 04 Apr 2023 14:14:57 -0700 (PDT) MIME-Version: 1.0 References: <87edp0ak45.fsf@vps.thesusis.net> <87lej7zhpt.fsf@osv.gnss.ru> <877curzb9u.fsf@osv.gnss.ru> In-Reply-To: <877curzb9u.fsf@osv.gnss.ru> From: Felipe Contreras Date: Tue, 4 Apr 2023 16:14:46 -0500 Message-ID: Subject: Re: git revert with partial commit. To: Sergey Organov Cc: Junio C Hamano , Chris Torek , Hongyi Zhao , Phillip Susi , Git List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Tue, Apr 4, 2023 at 3:08=E2=80=AFPM Sergey Organov = wrote: > > Junio C Hamano writes: > > > Sergey Organov writes: > > > >>> This kind of operation produces a new commit, so there's no such > >>> thing as a partial revert or partial cherry-pick, at least in > >>> terms of "things Git can do by itself". But we, as humans writing > >>> programs, wish to *achieve* such things. > >> > >> So, why Git can't help us achieving it by supporting paths limiting in > >> (all) merge operations? There seems to be no absolute obstacles, just = a > >> luck of support. > > > > I think there is no fundamental reason to forbid an optional > > pathspec to "cherry-pick" and "revert", given that a commit that > > results from either "git cherry-pick" or "git revert" is called a > > "cherry-pick" or a "revert" merely by convention and there is no > > tool-level support to treat them any specially at merge or rebase > > time [*1*]. It would make it harder to design tool-level support > > for full cherry-picks or reverts, but that is a problem for future > > generation, not ours ;-) Allowing pathspec to "merge" and recording > > the result as a merge of two (or more) parents is an absolute no-no > > but that is not what we are discussing. > > If I got this right, you believe that "git merge" should never have > support for "partial merges", whereas it makes sense for cherry-pick and > revert? If so, I disagree. There is no reason for Git to strictly > prevent me from using the feature specifically in "git merge" (once it's > otherwise implemented), provided I do mean it and didn't do it by > mistake. > > Please notice that I can do it right now already (and I did a few > times), only with a more pain than necessary, and I don't see why this > pain is to be preserved (provided we do have the feature implemented in > the future). Besides, "git merge" is only a helper, and it'd be an > improvement if it'll be capable to help in more cases. This sounds awfully familiar to Mercurial's reluctance to support rewriting history. It wasn't the tool's place to prescribe what the users should or shouldn't do. If the user wants to do it, the tool should help him do it, not pontificate about what is heretic. The user is still going to do it, like with a rebase plugin on Mercurial, or with `git filter-branch` and then merge the result. All the tool is achieving is being annoying by not helping the user. > > But I do not think Chris meant to say "you should not expect such a > > feature"; what we heard was a reasonable explanation of how the > > current world works, and I do not see a reason to react strongly to > > such a statement as if you were unreasonably forbidden from doing > > something sensible. > > Nice, so I figure I may allow myself to still keep a weak hope for the > feature, and thus stop being forbidden, even if not unreasonably, from > doing something sensible. ;-) I wouldn't. Features agreed by everyone decades ago never got merged, even features already agreed by the maintainer. Cheers. --=20 Felipe Contreras