From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#52349: 29.0.50; vc-git and diff-mode: stage hunks Date: Fri, 10 Dec 2021 02:17:18 +0300 Message-ID: <95d2d999-49ad-13c4-9f25-0935650a1e42@yandex.ru> References: <268cee0d-465d-b862-d1d6-f5da4d69e737@inventati.org> <9106387a-98cf-396f-bf45-ccb04581787b@yandex.ru> <864k7kfd56.fsf@mail.linkov.net> <86fsr3uen2.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26504"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 Cc: Manuel Uberti , 52349@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Dec 10 00:19:14 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mvSgz-0006nk-LG for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 10 Dec 2021 00:19:13 +0100 Original-Received: from localhost ([::1]:42858 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mvSgy-0001Bn-Ib for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 09 Dec 2021 18:19:12 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:47034) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mvSgo-0001BP-Nc for bug-gnu-emacs@gnu.org; Thu, 09 Dec 2021 18:19:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33454) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mvSgo-0006lB-FE for bug-gnu-emacs@gnu.org; Thu, 09 Dec 2021 18:19:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mvSgo-0005QJ-Am for bug-gnu-emacs@gnu.org; Thu, 09 Dec 2021 18:19:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 09 Dec 2021 23:19:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 52349 X-GNU-PR-Package: emacs Original-Received: via spool by 52349-submit@debbugs.gnu.org id=B52349.163909190020797 (code B ref 52349); Thu, 09 Dec 2021 23:19:02 +0000 Original-Received: (at 52349) by debbugs.gnu.org; 9 Dec 2021 23:18:20 +0000 Original-Received: from localhost ([127.0.0.1]:45000 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mvSg7-0005PN-Kd for submit@debbugs.gnu.org; Thu, 09 Dec 2021 18:18:19 -0500 Original-Received: from mail-lf1-f46.google.com ([209.85.167.46]:39737) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mvSg6-0005PA-71 for 52349@debbugs.gnu.org; Thu, 09 Dec 2021 18:18:18 -0500 Original-Received: by mail-lf1-f46.google.com with SMTP id d10so14962192lfg.6 for <52349@debbugs.gnu.org>; Thu, 09 Dec 2021 15:18:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=MMoZVCx3kiwchafhLcazmgw9MaJWrZplZ2E5kLfIuuI=; b=Xa2nJtE6PdwfowRufeBdvcZHray0vwt6P0ijrp9pWCP+QSfz+sL7OvheNPuBvvSLId 3lp3J5DjVAwQ+0RysrkK9a2QBiTYFXuVY/VHVmR+d+F62REtOENOoDyzdY40roQi5bPv +lr61FBLOnIL81PDblBI6HO+vo2mGIjU16X8CXj8MnqRVen2MO+m2j6fFWuWBeFsCOu1 RSWoCiMldpRSlg99EMSi0rAq/VuH35sM+TFscI3bEP6cdu7HSanIv/BIw3FZ5eOmuXqW 1dEsl61qirD9ACUt8NQtT8R3nVxXDA9pBBnKvW7/I21DInwRNN8It47h3igpR9v/ewLh Tl1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=MMoZVCx3kiwchafhLcazmgw9MaJWrZplZ2E5kLfIuuI=; b=4M/mhNqstXR/27OfE1fOi3butkHNUn1gGIBCBjB1ZgD2StgIRR+ot5UF3tlOLQWDxM dFdBXccxp41BJnavAYF+b3XITbGHfLygqVcHI1w2JnNf+ExRETyHTMmcFP0MQfQ39yvg 7zYAY4GJ+mYwair3LsO7qNiPfo1SLh2a2mmX9xRh9cs8+o16Jw90FMxzOpalO1xX2Ppc EnweNs++JiVNL198abqbiplcAivsUEYUU4CqLDzOngM+XvOOHUVEtKc+e9AUjTe9Qyjs vod6xnWhr0dF3q6cY1Flm51CWWdTGKJ6kcw9/miomFTARwkQcZepynK/xv3ON4W0B6ej kovQ== X-Gm-Message-State: AOAM530TYGEtapy6LNABgyeE1RP5ugJpsp2BL+Lc447PlvnQebCXJIZE Rn5zgbz3iGn37OV7KzYNzUSJAZMTAN4= X-Google-Smtp-Source: ABdhPJy5zuMhdahnRqT/UYgFo9hZt4xK4EglWNDiShmjNs7MKT9TkZa8TbSiddSlorMx3Lv4pQ4i5Q== X-Received: by 2002:a05:6512:3213:: with SMTP id d19mr8886296lfe.519.1639091892188; Thu, 09 Dec 2021 15:18:12 -0800 (PST) Original-Received: from [192.168.0.103] ([5.18.233.185]) by smtp.googlemail.com with ESMTPSA id n9sm133767lji.131.2021.12.09.15.18.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Dec 2021 15:18:11 -0800 (PST) In-Reply-To: <86fsr3uen2.fsf@mail.linkov.net> Content-Language: en-US X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:222024 Archived-At: On 08.12.2021 21:57, Juri Linkov wrote: >>> The problem is that 'git apply --cached' doesn't perform the merge >>> with other changes in the same file, whereas 'git stash pop' >>> merges committed changes with uncommitted changes. >> >> This seems to address our previous discussion, rather than the difference >> vs. diff-hl. >> >> Anyway, I don't know if it is a problem. >> >> E.g., you might want to edit a diff (if you know how, which is >> a significant "if") to commit a slightly different change than what the >> current file contents show. > > Actually, not quite edit, but only to delete unneeded hunks with ‘k’. Then it will probably be fine, most of the time? > The intention is to emulate the interactive command `git add --patch` > that has many keys: > > y - stage this hunk > n - do not stage this hunk > q - quit; do not stage this hunk or any of the remaining ones > a - stage this hunk and all later hunks in the file > d - do not stage this hunk or any of the later hunks in the file > g - select a hunk to go to > / - search for a hunk matching the given regex > j - leave this hunk undecided, see next undecided hunk > J - leave this hunk undecided, see next hunk > k - leave this hunk undecided, see previous undecided hunk > K - leave this hunk undecided, see previous hunk > s - split the current hunk into smaller hunks > e - manually edit the current hunk > ? - print help > > Instead of these numerous keys, in Emacs it should be sufficient > just to type ‘k’ (diff-hunk-kill) a few times on the output of ‘C-x v D’ > in the *vc-diff* buffer (and maybe some splitting). Yes, the commit-patch (external package) workflow. It totally sounds fine to me, though it might require some additional explanation when a random user tries to take advantage of it (Git's interactive command UI is more self-explanatory). >> But then, I'm not sure you'll want the applied change to be reflected in >> the file on disk too (as opposed to being saved in the commit). I probably >> won't (and it would let us avoid the awkward step of seeing the stashing >> operation temporarily reflected in the file contents, as well as any >> possible conflicts). >> >> Either way, the editing of the diff that's more complex than splitting >> hunks and deleting some of them will probably be very rare. So the behavior >> in this scenario doesn't have to affect our choice of implementation. > > I had in mind a different scenario: when you have uncommitted changes > in one part of the file, and receive an external patch from outside of the repo > with changes in another part of the file, and need to commit it. Couldn't you 'git apply external/patch/file/name.ext' first? > But I admit such scenario is very rare. > > So if using ‘git apply --cached’ is the preferred solution, > then I could finish the patch with it. I don't have a particularly strong opinion, but the approach with 'git apply --cached' followed by 'git commit' seems easier to implement and avoids changing the file contents on disk, or risking any of the stashes. So I'd try implementing it first and then see if the remaining problems are worth the trouble of doing it in a more difficult way.