From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 10 Apr 2015 12:57:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 20292@debbugs.gnu.org Cc: "Eric S. Raymond" X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Reply-To: Eli Zaretskii Received: via spool by submit@debbugs.gnu.org id=B.142867056323770 (code B ref -1); Fri, 10 Apr 2015 12:57:02 +0000 Received: (at submit) by debbugs.gnu.org; 10 Apr 2015 12:56:03 +0000 Received: from localhost ([127.0.0.1]:51930 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgYTZ-0006BG-Hk for submit@debbugs.gnu.org; Fri, 10 Apr 2015 08:56:02 -0400 Received: from eggs.gnu.org ([208.118.235.92]:42586) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgYTW-0006Ax-HU for submit@debbugs.gnu.org; Fri, 10 Apr 2015 08:55:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YgYTQ-0001td-2R for submit@debbugs.gnu.org; Fri, 10 Apr 2015 08:55:53 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:60248) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YgYTQ-0001tZ-0J for submit@debbugs.gnu.org; Fri, 10 Apr 2015 08:55:52 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56066) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YgYTO-00075V-LK for bug-gnu-emacs@gnu.org; Fri, 10 Apr 2015 08:55:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YgYTJ-0001s6-T7 for bug-gnu-emacs@gnu.org; Fri, 10 Apr 2015 08:55:50 -0400 Received: from mtaout25.012.net.il ([80.179.55.181]:41950) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YgYTJ-0001rl-DV for bug-gnu-emacs@gnu.org; Fri, 10 Apr 2015 08:55:45 -0400 Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NML00100CTDIV00@mtaout25.012.net.il> for bug-gnu-emacs@gnu.org; Fri, 10 Apr 2015 15:51:10 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NML001R8D1AE200@mtaout25.012.net.il>; Fri, 10 Apr 2015 15:51:10 +0300 (IDT) Date: Fri, 10 Apr 2015 15:55:44 +0300 From: Eli Zaretskii X-012-Sender: halo1@inter.net.il Message-id: <83fv88ta5r.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) >From the shell prompt type "git stash save" to stash uncommitted changes. Then "git pull" or "git merge" from upstream, and finally type "git stash pop" to restore your original changes. If "git stash pop" encounters merge conflicts, then resolving these conflicts in Emacs and saving the buffer will run "git add" for the file whose conflicts were resolved. But that is not TRT in this case; the user likely does not expect to have her uncommitted changes staged for the next commit. Therefore, I think vc-git-resolve-when-done should not run "git add" if the merge conflict was due to "git stash pop". In GNU Emacs 24.5.1 (i686-pc-mingw32) of 2015-03-27 on HOME-C4E4A596F7 Windowing system distributor `Microsoft Corp.', version 5.1.2600 Configured using: `configure --prefix=/d/usr 'CFLAGS=-Og -gdwarf-4 -g3'' Important settings: value of $LANG: ENU locale-coding-system: cp1255 Major mode: RMAIL Minor modes in effect: diff-auto-refine-mode: t desktop-save-mode: t show-paren-mode: t display-time-mode: t tooltip-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t temp-buffer-resize-mode: t buffer-read-only: t line-number-mode: t Recent messages: Getting mail from d:/usr/eli/data/mail.new... Counting new messages...done (12) Saving file d:/usr/eli/rmail/INBOX... Wrote d:/usr/eli/rmail/INBOX [2 times] Computing summary lines...done 12 new messages read Mark set No following nondeleted message Saving file d:/usr/eli/rmail/INBOX... Wrote d:/usr/eli/rmail/INBOX [2 times] Load-path shadows: d:/usr/share/emacs/site-lisp/soap-inspect hides d:/usr/share/emacs/24.5/lisp/net/soap-inspect d:/usr/share/emacs/site-lisp/soap-client hides d:/usr/share/emacs/24.5/lisp/net/soap-client Features: (shadow emacsbug etags smerge-mode cc-awk bug-reference add-log misearch multi-isearch dabbrev shr-color color mule-util rmailout shr browse-url network-stream starttls tls mail-extr smtpmail auth-source eieio byte-opt bytecomp byte-compile cconv eieio-core password-cache mailalias sendmail help-mode cl-extra texinfo ld-script tcl conf-mode org-element org-rmail org-mhe org-irc org-info org-gnus gnus-util org-docview doc-view image-mode dired-x dired org-bibtex bibtex org-bbdb org-w3m org advice org-macro org-footnote org-pcomplete pcomplete org-list org-faces org-entities org-version ob-emacs-lisp ob ob-tangle ob-ref ob-lob ob-table ob-exp org-src ob-keys ob-comint comint ansi-color ring ob-core ob-eval org-compat org-macs org-loaddefs find-func cal-menu calendar cal-loaddefs arc-mode archive-mode parse-time diff-mode vc-bzr sh-script smie executable generic make-mode noutline outline easy-mmode vc-cvs jka-compr bat-mode vc-dispatcher vc-svn flyspell info vc-git cc-langs rmailsum qp rmailmm message format-spec rfc822 mml mml-sec mm-decode mm-bodies mm-encode mailabbrev gmm-utils mailheader mail-parse rfc2231 rmail rfc2047 rfc2045 ietf-drums mm-util help-fns mail-prsvr mail-utils desktop frameset server filecache mairix cus-edit cus-start cus-load wid-edit cl-loaddefs cl-lib saveplace midnight ispell generic-x cc-mode cc-fonts easymenu cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs paren battery time time-date tooltip electric uniquify ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp w32-common-fns disp-table w32-win w32-vars tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment lisp-mode prog-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote make-network-process w32notify w32 multi-tty emacs) Memory information: ((conses 8 1513834 148516) (symbols 32 42131 0) (miscs 32 5809 4393) (strings 16 105774 18210) (string-bytes 1 3133483) (vectors 8 37368) (vector-slots 4 1563878 83782) (floats 8 326 1158) (intervals 28 269674 1601) (buffers 508 358)) From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 10 11:26:22 2015 Received: (at control) by debbugs.gnu.org; 10 Apr 2015 15:26:22 +0000 Received: from localhost ([127.0.0.1]:52540 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ygap3-0001lv-Oe for submit@debbugs.gnu.org; Fri, 10 Apr 2015 11:26:21 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:36499 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ygap2-0001lo-9u for control@debbugs.gnu.org; Fri, 10 Apr 2015 11:26:20 -0400 Received: from rgm by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1Ygap1-0006Sj-PS for control@debbugs.gnu.org; Fri, 10 Apr 2015 11:26:19 -0400 Date: Fri, 10 Apr 2015 11:26:19 -0400 Message-Id: Subject: control message for bug 20292 To: X-Mailer: mail (GNU Mailutils 2.1) From: Glenn Morris X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) merge 20151 20292 From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 18 Apr 2015 19:18:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii , 20292@debbugs.gnu.org Cc: "Eric S. Raymond" Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.142938462326596 (code B ref 20292); Sat, 18 Apr 2015 19:18:01 +0000 Received: (at 20292) by debbugs.gnu.org; 18 Apr 2015 19:17:03 +0000 Received: from localhost ([127.0.0.1]:60186 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YjYEh-0006ut-1f for submit@debbugs.gnu.org; Sat, 18 Apr 2015 15:17:03 -0400 Received: from mail-wg0-f43.google.com ([74.125.82.43]:35957) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YjYEe-0006uJ-MR for 20292@debbugs.gnu.org; Sat, 18 Apr 2015 15:17:01 -0400 Received: by wgsk9 with SMTP id k9so142108116wgs.3 for <20292@debbugs.gnu.org>; Sat, 18 Apr 2015 12:16:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=THxeIJKdsqDiVU3QNCXZxHRsJ+Qjv+gIV8gSdTt9geo=; b=uHlr8kT7tLt7Y+NvCyhnoJPZ4Y+3+yB1gPDXCgR8GKLQ7ncBVLPyHUwZs3Oq6V3/VQ SUcyELBMO7FEFyEMs8KwIzkW5AbF4DefRV4mpDejzRlYOY7PZxnaAFsEMCv3h+jGX8WF 6av9rGnrep4dMnTJe7mNKIdB7X9Zq46lgMVIw06AHd2nDLlWkEXZxA8eIsaruOMiDQU2 2BdrmEoHivyD/kR9K3UudFKxXLfqx9t3xrwer9XsZWyJNWr9JvxLPNgxxx1YjC859ZIV +0iJR4rNLJf8tEVRWOQWguzt52aX+8JgQKB4BgueF+HkkFpukJaVcTGXqjzcixXOtw4K RiMQ== X-Received: by 10.180.96.65 with SMTP id dq1mr11828869wib.46.1429384614987; Sat, 18 Apr 2015 12:16:54 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id ax10sm20064806wjc.26.2015.04.18.12.16.53 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Apr 2015 12:16:54 -0700 (PDT) Message-ID: <5532ADA3.5000006@yandex.ru> Date: Sat, 18 Apr 2015 22:16:51 +0300 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 MIME-Version: 1.0 References: <83fv88ta5r.fsf@gnu.org> In-Reply-To: <83fv88ta5r.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 04/10/2015 03:55 PM, Eli Zaretskii wrote: > If "git stash pop" encounters merge conflicts, then resolving these > conflicts in Emacs and saving the buffer will run "git add" for the > file whose conflicts were resolved. But that is not TRT in this case; > the user likely does not expect to have her uncommitted changes staged > for the next commit. Apparently, to both mark the conflict as resolved and not stage the file, the best we can do is 'git add ...; git reset ...', which would not DTRT if the file had some changes, and they were staged before you did 'git stash pop' (if the file had unstaged changes, 'git stash pop' would abort). Should we be concerned about that? > Therefore, I think vc-git-resolve-when-done should not run "git add" > if the merge conflict was due to "git stash pop". Maybe we can detect this case (as well as any similar ones) by the absence of .git/MERGE_HEAD. But what's the justification for vc-git-resolve-when-done? I think vc-git-checkin will work well enough without that. Further, if there's a conflict, 'git stash pop' doesn't actually remove the stash from the list. Would we expect vc-git-resolve-when-done to call 'git stash drop' at the end of conflict resolution? From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 18 Apr 2015 19:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: esr@snark.thyrsus.com, 20292@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.142938552528244 (code B ref 20292); Sat, 18 Apr 2015 19:33:02 +0000 Received: (at 20292) by debbugs.gnu.org; 18 Apr 2015 19:32:05 +0000 Received: from localhost ([127.0.0.1]:60202 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YjYTF-0007LS-1Z for submit@debbugs.gnu.org; Sat, 18 Apr 2015 15:32:05 -0400 Received: from mtaout23.012.net.il ([80.179.55.175]:59684) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YjYTA-0007KJ-Bw for 20292@debbugs.gnu.org; Sat, 18 Apr 2015 15:32:02 -0400 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0NN000400OKGVZ00@a-mtaout23.012.net.il> for 20292@debbugs.gnu.org; Sat, 18 Apr 2015 22:31:53 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NN00045YOX4T850@a-mtaout23.012.net.il>; Sat, 18 Apr 2015 22:31:53 +0300 (IDT) Date: Sat, 18 Apr 2015 22:31:41 +0300 From: Eli Zaretskii In-reply-to: <5532ADA3.5000006@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <834mod6xnm.fsf@gnu.org> References: <83fv88ta5r.fsf@gnu.org> <5532ADA3.5000006@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Sat, 18 Apr 2015 22:16:51 +0300 > From: Dmitry Gutov > CC: "Eric S. Raymond" > > On 04/10/2015 03:55 PM, Eli Zaretskii wrote: > > > If "git stash pop" encounters merge conflicts, then resolving these > > conflicts in Emacs and saving the buffer will run "git add" for the > > file whose conflicts were resolved. But that is not TRT in this case; > > the user likely does not expect to have her uncommitted changes staged > > for the next commit. > > Apparently, to both mark the conflict as resolved and not stage the > file, the best we can do is 'git add ...; git reset ...', which would > not DTRT if the file had some changes, and they were staged before you > did 'git stash pop' (if the file had unstaged changes, 'git stash pop' > would abort). It's best not to run "git add" in the first place in this case. > > Therefore, I think vc-git-resolve-when-done should not run "git add" > > if the merge conflict was due to "git stash pop". > > Maybe we can detect this case (as well as any similar ones) by the > absence of .git/MERGE_HEAD. Why not detect that the conflict was from stashed changes? This is clearly stated at the last conflict marker. The find-file-hook could detect that and record the information. > But what's the justification for vc-git-resolve-when-done? So that "git commit" would "just work", I presume. > I think vc-git-checkin will work well enough without that. That would mean VC behaves wit Git differently than it does with other VCSes (bzr, at least). > Further, if there's a conflict, 'git stash pop' doesn't actually remove > the stash from the list. Would we expect vc-git-resolve-when-done to > call 'git stash drop' at the end of conflict resolution? Yes. Although IME, Git itself does that when you resolve the last conflict. But I'm not going to claim that this is 100% accurate, just that it happened to me when I needed to resolve conflicts from stash. From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 18 Apr 2015 21:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: esr@snark.thyrsus.com, 20292@debbugs.gnu.org Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.142939433914427 (code B ref 20292); Sat, 18 Apr 2015 21:59:02 +0000 Received: (at 20292) by debbugs.gnu.org; 18 Apr 2015 21:58:59 +0000 Received: from localhost ([127.0.0.1]:60249 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YjalO-0003kc-He for submit@debbugs.gnu.org; Sat, 18 Apr 2015 17:58:58 -0400 Received: from mail-wi0-f178.google.com ([209.85.212.178]:37327) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YjalM-0003kQ-Rv for 20292@debbugs.gnu.org; Sat, 18 Apr 2015 17:58:57 -0400 Received: by widdi4 with SMTP id di4so54141299wid.0 for <20292@debbugs.gnu.org>; Sat, 18 Apr 2015 14:58:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ypNy9zbcHoY/9P9RB55N9H8qcUxAnCvTq29uEhfxShY=; b=HrAtKBze1lgfd2XopgPyRAVDCl9A+vhX1km0jNHI287p1raj8yxxzk6z9Vm3wk/d7O D/aSBViKNLo/IBqCZxhm6daQ5D5BmsV0BM7EnDTRVSv9MpARKsAw5bSU/xhxj5dAT9RY bl0QlhsrMUw7fQM4EvqsB5O+X9xVgFie54rMOw4O1JBSAmUPPJyjgpzxot7+4qorspT5 GAtyWgJtsTafNfU1umK3wMIc2B5520hN1aVyBgCq08pLd3lK38UDtend+O3h4fKXTSYQ 4Y8dWOhn/UwJ3yvGITMSpoY82ITLszo72WWrtq2vXRMJQeSee31qkRSbTzt6WttGpFAf Yhrw== X-Received: by 10.194.174.225 with SMTP id bv1mr17957372wjc.101.1429394331294; Sat, 18 Apr 2015 14:58:51 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id g14sm17067253wjs.47.2015.04.18.14.58.49 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Apr 2015 14:58:50 -0700 (PDT) Message-ID: <5532D397.8090602@yandex.ru> Date: Sun, 19 Apr 2015 00:58:47 +0300 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 MIME-Version: 1.0 References: <83fv88ta5r.fsf@gnu.org> <5532ADA3.5000006@yandex.ru> <834mod6xnm.fsf@gnu.org> In-Reply-To: <834mod6xnm.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 04/18/2015 10:31 PM, Eli Zaretskii wrote: > It's best not to run "git add" in the first place in this case. How will we detect it? And why would the user expect this difference in behavior? They'd either have a file nicely resolved, or the conflict unresolved, *and* a part of changes in staging area? > Why not detect that the conflict was from stashed changes? This is > clearly stated at the last conflict marker. The find-file-hook could > detect that and record the information. It's more complicated, but sounds better if we prefer to detect unstashing specifically, as opposed to any conflicts that were created by a non-merge operation, I guess. >> But what's the justification for vc-git-resolve-when-done? > > So that "git commit" would "just work", I presume. A lot of problems start with someone wanting to make something "just work". > That would mean VC behaves wit Git differently than it does with other > VCSes (bzr, at least). You mean smerge-mode, not VC, right? How come? I don't even see > Yes. What if the user called 'git stash apply' instead of 'git stash pop'? > Although IME, Git itself does that when you resolve the last > conflict. But I'm not going to claim that this is 100% accurate, just > that it happened to me when I needed to resolve conflicts from stash. I didn't when I tried it, a couple of times. From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 18 Apr 2015 22:07:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: esr@snark.thyrsus.com, 20292@debbugs.gnu.org Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.142939479720748 (code B ref 20292); Sat, 18 Apr 2015 22:07:01 +0000 Received: (at 20292) by debbugs.gnu.org; 18 Apr 2015 22:06:37 +0000 Received: from localhost ([127.0.0.1]:60258 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yjasm-0005OZ-Th for submit@debbugs.gnu.org; Sat, 18 Apr 2015 18:06:37 -0400 Received: from mail-wi0-f169.google.com ([209.85.212.169]:36050) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yjask-0005OE-H6 for 20292@debbugs.gnu.org; Sat, 18 Apr 2015 18:06:34 -0400 Received: by wizk4 with SMTP id k4so58570639wiz.1 for <20292@debbugs.gnu.org>; Sat, 18 Apr 2015 15:06:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=t6cJyuMPfKJf12ZM7pLs0wBYDbv8xDni4kQP61hIBXk=; b=u+D6RZdlXPGHZu+Jf/TCEKlkKbPJe8wADs9V6sAM98I7Vt6+MxLeHGHid+H0p6O4YC IOh0llz57IG5T3d1hIkEJx4pylX9ojoHG+5MRs5aZEhQ2niRCSIL2Mw1PNA8lL4hd73R 3qXM8ARPBmueCpPRVcQjUqu74wS1zZM87y7vR4M2G/gW1M/GIMbK7lfTw/26XWvQ+JM2 Z5A6dDC4b5Monz6bVo+U5LMnYhxSmfLPeKtOMl9Ol3tQPAoGNxjOijSbMSJy0fHVkoz2 6VNLoaQfBGpv3M+DBve8OYSlmWsIF/9/wwp1YcI+CWAt3oGnyVzQ8hEI2yCGZlHVvYFB otKw== X-Received: by 10.194.104.71 with SMTP id gc7mr17118162wjb.114.1429394789077; Sat, 18 Apr 2015 15:06:29 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id ju2sm8566935wid.12.2015.04.18.15.06.27 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Apr 2015 15:06:28 -0700 (PDT) Message-ID: <5532D561.6000903@yandex.ru> Date: Sun, 19 Apr 2015 01:06:25 +0300 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 MIME-Version: 1.0 References: <83fv88ta5r.fsf@gnu.org> <5532ADA3.5000006@yandex.ru> <834mod6xnm.fsf@gnu.org> <5532D397.8090602@yandex.ru> In-Reply-To: <5532D397.8090602@yandex.ru> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 04/19/2015 12:58 AM, Dmitry Gutov wrote: >> That would mean VC behaves wit Git differently than it does with other >> VCSes (bzr, at least). > > You mean smerge-mode, not VC, right? How come? I don't even see ^^^ Sorry, please disregard this part. I can see it all right. From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Apr 2015 14:31:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: esr@snark.thyrsus.com, 20292@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.142945385924162 (code B ref 20292); Sun, 19 Apr 2015 14:31:01 +0000 Received: (at 20292) by debbugs.gnu.org; 19 Apr 2015 14:30:59 +0000 Received: from localhost ([127.0.0.1]:60793 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YjqFO-0006Hd-H4 for submit@debbugs.gnu.org; Sun, 19 Apr 2015 10:30:59 -0400 Received: from mtaout27.012.net.il ([80.179.55.183]:55086) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YjqFL-0006HL-BE for 20292@debbugs.gnu.org; Sun, 19 Apr 2015 10:30:56 -0400 Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NN200F00570YC00@mtaout27.012.net.il> for 20292@debbugs.gnu.org; Sun, 19 Apr 2015 17:25:30 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NN200AYN5EIJS50@mtaout27.012.net.il>; Sun, 19 Apr 2015 17:25:30 +0300 (IDT) Date: Sun, 19 Apr 2015 17:30:21 +0300 From: Eli Zaretskii In-reply-to: <5532D397.8090602@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <83zj645gxu.fsf@gnu.org> References: <83fv88ta5r.fsf@gnu.org> <5532ADA3.5000006@yandex.ru> <834mod6xnm.fsf@gnu.org> <5532D397.8090602@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Sun, 19 Apr 2015 00:58:47 +0300 > From: Dmitry Gutov > CC: esr@snark.thyrsus.com, 20292@debbugs.gnu.org > > On 04/18/2015 10:31 PM, Eli Zaretskii wrote: > > > It's best not to run "git add" in the first place in this case. > > How will we detect it? I suggested one method below; perhaps there are others, I simply don't know enough about Git. > And why would the user expect this difference in behavior? They'd > either have a file nicely resolved, or the conflict unresolved, > *and* a part of changes in staging area? Stashed changes were uncommitted before, so they should stay uncommitted after, I think. Having them staged means the situation after "stash pop" is different than it was before "stash save", which I think is not what the user expects. > > Why not detect that the conflict was from stashed changes? This is > > clearly stated at the last conflict marker. The find-file-hook could > > detect that and record the information. > > It's more complicated, but sounds better if we prefer to detect > unstashing specifically, as opposed to any conflicts that were created > by a non-merge operation, I guess. If there is a better way of doing that, fine. > >> But what's the justification for vc-git-resolve-when-done? > > > > So that "git commit" would "just work", I presume. > > A lot of problems start with someone wanting to make something "just work". But sometimes "just works" is not a beginning of a problem. > What if the user called 'git stash apply' instead of 'git stash pop'? If you are questioning the wisdom of doing "stash drop", then this question is not for me: it wasn't my suggestion. If we are not sure dropping the stash automatically is what the user wants, let's not drop it, and leave management of stashes to the user. It's not a big deal to leave the stash behind, I think. From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Apr 2015 16:29:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: esr@snark.thyrsus.com, 20292@debbugs.gnu.org Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.14294609322483 (code B ref 20292); Sun, 19 Apr 2015 16:29:02 +0000 Received: (at 20292) by debbugs.gnu.org; 19 Apr 2015 16:28:52 +0000 Received: from localhost ([127.0.0.1]:60827 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yjs5T-0000dz-RT for submit@debbugs.gnu.org; Sun, 19 Apr 2015 12:28:52 -0400 Received: from mail-wi0-f178.google.com ([209.85.212.178]:35541) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yjs5R-0000dm-Jz for 20292@debbugs.gnu.org; Sun, 19 Apr 2015 12:28:50 -0400 Received: by widdi4 with SMTP id di4so72729333wid.0 for <20292@debbugs.gnu.org>; Sun, 19 Apr 2015 09:28:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=G7skn+JXZ5NUeUH176QHm1CEnBvdqwDD0w1WaS6dyfo=; b=S3XmrhBc4mpjR7ONA6mgboJlq1osu7GVYhtvRd4hMOmEN3mmMcYB/7vIxQPcOIMWzn lJC1Ie9WQvCvj4ndo5HngLRq90fcOMYvmdUvEzDgv49QsNF5qPkBzeUBsZ/n0lywcLso IqU24+Of8Vm17uaV8JmeYEQn/16SpIatbl/AgdAwLlmmz/i7nXk46cKDz2cOxuqKt+gc gm9AZjZcvpJkD06Q29UU7Iat/Udjzf4LGhDmpSSzBphQ4aef6kC9ThVylozlGN6Vig75 KqgqXrsIUZbwM36vNrFKyuwzsDsKMuoQJ+5UGD+I0I/1muA+8TBbjV5eQmucdJjo96I0 pkvA== X-Received: by 10.195.12.48 with SMTP id en16mr23788673wjd.21.1429460923686; Sun, 19 Apr 2015 09:28:43 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id n8sm11578167wiy.19.2015.04.19.09.28.42 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Apr 2015 09:28:42 -0700 (PDT) Message-ID: <5533D7B8.7060508@yandex.ru> Date: Sun, 19 Apr 2015 19:28:40 +0300 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 MIME-Version: 1.0 References: <83fv88ta5r.fsf@gnu.org> <5532ADA3.5000006@yandex.ru> <834mod6xnm.fsf@gnu.org> <5532D397.8090602@yandex.ru> <83zj645gxu.fsf@gnu.org> In-Reply-To: <83zj645gxu.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 04/19/2015 05:30 PM, Eli Zaretskii wrote: > I suggested one method below; perhaps there are others, I simply don't > know enough about Git. Apparently, we misunderstand each other. By "this case", do you mean when merging a stash in general? Because I've described a more specific case (popping a stash when one has staged changes in one of the involved files), and it looked like you were referring to it in >>best not to run "git add" in the first place<<. > Stashed changes were uncommitted before, so they should stay > uncommitted after, I think. Having them staged means the situation > after "stash pop" is different than it was before "stash save", which > I think is not what the user expects. Right. And I meant the difference between what we do depending on whether user has something staged originally. > If you are questioning the wisdom of doing "stash drop", then this > question is not for me: it wasn't my suggestion. You said "yes". I asked about this in the context of consistency; the question was about how far will we go to be consistent with Bzr, and whether it's feasible to do so, or we should stop at some point. > If we are not sure > dropping the stash automatically is what the user wants, let's not > drop it, and leave management of stashes to the user. It's not a big > deal to leave the stash behind, I think. It's not that big a deal to leave marking files as resolved to the user either. Am I right to understand that's what you're currently suggesting, at least when dealing with stashes? This is easy (so, done). From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Apr 2015 17:07:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: esr@snark.thyrsus.com, 20292@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.14294631946007 (code B ref 20292); Sun, 19 Apr 2015 17:07:01 +0000 Received: (at 20292) by debbugs.gnu.org; 19 Apr 2015 17:06:34 +0000 Received: from localhost ([127.0.0.1]:60858 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yjsfx-0001Yo-3P for submit@debbugs.gnu.org; Sun, 19 Apr 2015 13:06:33 -0400 Received: from mtaout28.012.net.il ([80.179.55.184]:37831) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yjsfu-0001Ya-3j for 20292@debbugs.gnu.org; Sun, 19 Apr 2015 13:06:31 -0400 Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NN200700CH47D00@mtaout28.012.net.il> for 20292@debbugs.gnu.org; Sun, 19 Apr 2015 20:05:09 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NN200A4RCSLETA0@mtaout28.012.net.il>; Sun, 19 Apr 2015 20:05:09 +0300 (IDT) Date: Sun, 19 Apr 2015 20:06:14 +0300 From: Eli Zaretskii In-reply-to: <5533D7B8.7060508@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <83sibw59q1.fsf@gnu.org> References: <83fv88ta5r.fsf@gnu.org> <5532ADA3.5000006@yandex.ru> <834mod6xnm.fsf@gnu.org> <5532D397.8090602@yandex.ru> <83zj645gxu.fsf@gnu.org> <5533D7B8.7060508@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Sun, 19 Apr 2015 19:28:40 +0300 > From: Dmitry Gutov > CC: esr@snark.thyrsus.com, 20292@debbugs.gnu.org > > On 04/19/2015 05:30 PM, Eli Zaretskii wrote: > > > I suggested one method below; perhaps there are others, I simply don't > > know enough about Git. > > Apparently, we misunderstand each other. By "this case", do you mean > when merging a stash in general? I meant when "git stash pop" reports conflicts, in particular after a "git pull" or "git merge". > Because I've described a more specific case (popping a stash when one > has staged changes in one of the involved files), and it looked like you > were referring to it in >>best not to run "git add" in the first place<<. I think we were talking about the same use case, but I cannot be sure, since "has staged changes" might me more general than what I had in mind. > > Stashed changes were uncommitted before, so they should stay > > uncommitted after, I think. Having them staged means the situation > > after "stash pop" is different than it was before "stash save", which > > I think is not what the user expects. > > Right. And I meant the difference between what we do depending on > whether user has something staged originally. Before "git stash save"? The case I had in mind didn't have anything staged before that. > > If you are questioning the wisdom of doing "stash drop", then this > > question is not for me: it wasn't my suggestion. > > You said "yes". Yes, because someone more knowledgeable than myself said it was a good idea. > I asked about this in the context of consistency; the question was > about how far will we go to be consistent with Bzr, and whether it's > feasible to do so, or we should stop at some point. I think it's okay to leave the stash and not drop it in this case. > > If we are not sure > > dropping the stash automatically is what the user wants, let's not > > drop it, and leave management of stashes to the user. It's not a big > > deal to leave the stash behind, I think. > > It's not that big a deal to leave marking files as resolved to the user > either. Am I right to understand that's what you're currently > suggesting, at least when dealing with stashes? What does it mean to "mark files as resolved" when the conflict comes from stashed changes that were uncommitted before "stash save"? From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Apr 2015 17:39:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: esr@snark.thyrsus.com, 20292@debbugs.gnu.org Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.14294651208963 (code B ref 20292); Sun, 19 Apr 2015 17:39:01 +0000 Received: (at 20292) by debbugs.gnu.org; 19 Apr 2015 17:38:40 +0000 Received: from localhost ([127.0.0.1]:60872 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YjtB1-0002KV-Nf for submit@debbugs.gnu.org; Sun, 19 Apr 2015 13:38:40 -0400 Received: from mail-wg0-f47.google.com ([74.125.82.47]:34749) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YjtAz-0002KI-SW for 20292@debbugs.gnu.org; Sun, 19 Apr 2015 13:38:38 -0400 Received: by wgso17 with SMTP id o17so157675835wgs.1 for <20292@debbugs.gnu.org>; Sun, 19 Apr 2015 10:38:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=XW535hWZ3QArRunvLvOaO623rTIrS/4YxMinNGEK0q4=; b=HqFiQz5y9YdADnKG5pUifEfyuDxxZrabazODlzDLQl1GOGh7SAFyBkH5aZeg+LHxrW WYs3l1UplLQSEa4EVf+zFOrmVtgr+Ns2LHzWrxr15Fk3zt9/qTcHMlS7z5xgo6HiWSfY 9vSwhfYmzsOwtQN3kKCpxLb2yJ/7584GktUVMTeCv/SqePClZRlyjNdk2nYxzSK44P8s BhfbUC/zsbez8RUwNmFLMXPeuaciUcuDyKLt/a/PTQiHOcobUNjDjZ5dB3qYiw9ZS92q zexbNIfr9Yc8b/UP09jkklsfwkVcTQf57i0JGU4ydFXOap5nJDLgkjpdsGAdiJ8v36qV fNcQ== X-Received: by 10.180.92.65 with SMTP id ck1mr18092607wib.78.1429465111977; Sun, 19 Apr 2015 10:38:31 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id dm6sm11787794wib.22.2015.04.19.10.38.30 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Apr 2015 10:38:31 -0700 (PDT) Message-ID: <5533E816.2090208@yandex.ru> Date: Sun, 19 Apr 2015 20:38:30 +0300 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 MIME-Version: 1.0 References: <83fv88ta5r.fsf@gnu.org> <5532ADA3.5000006@yandex.ru> <834mod6xnm.fsf@gnu.org> <5532D397.8090602@yandex.ru> <83zj645gxu.fsf@gnu.org> <5533D7B8.7060508@yandex.ru> <83sibw59q1.fsf@gnu.org> In-Reply-To: <83sibw59q1.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 04/19/2015 08:06 PM, Eli Zaretskii wrote: > I meant when "git stash pop" reports conflicts, in particular after a > "git pull" or "git merge". That's the general case. > I think we were talking about the same use case, but I cannot be sure, > since "has staged changes" might me more general than what I had in > mind. No: it's more specific. Before you do 'git stash pop', either there's nothing in the staging area (and the conflict is most likely due to some new commits), or there is something in the staging area. "one has staged changes in one of the involved files" means the latter. > Before "git stash save"? The case I had in mind didn't have anything > staged before that. No, after "git stash save", but before "git stash pop". > Yes, because someone more knowledgeable than myself said it was a good > idea. It was a question. :) > What does it mean to "mark files as resolved" when the conflict comes > from stashed changes that were uncommitted before "stash save"? Changes that were staged, but then put into stash is a whole new different wrinkle. Luckily, 'git stash pop' only concerns itself with that distinction when passed a '--index' argument. From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Apr 2015 18:07:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: esr@snark.thyrsus.com, 20292@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.142946677111418 (code B ref 20292); Sun, 19 Apr 2015 18:07:01 +0000 Received: (at 20292) by debbugs.gnu.org; 19 Apr 2015 18:06:11 +0000 Received: from localhost ([127.0.0.1]:60877 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yjtbf-0002y5-Dg for submit@debbugs.gnu.org; Sun, 19 Apr 2015 14:06:11 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:48425) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yjtbc-0002xr-VM for 20292@debbugs.gnu.org; Sun, 19 Apr 2015 14:06:10 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NN200300F5S8V00@a-mtaout20.012.net.il> for 20292@debbugs.gnu.org; Sun, 19 Apr 2015 21:05:14 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NN20022IFKQY460@a-mtaout20.012.net.il>; Sun, 19 Apr 2015 21:05:14 +0300 (IDT) Date: Sun, 19 Apr 2015 21:05:05 +0300 From: Eli Zaretskii In-reply-to: <5533E816.2090208@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <83r3rg56zy.fsf@gnu.org> References: <83fv88ta5r.fsf@gnu.org> <5532ADA3.5000006@yandex.ru> <834mod6xnm.fsf@gnu.org> <5532D397.8090602@yandex.ru> <83zj645gxu.fsf@gnu.org> <5533D7B8.7060508@yandex.ru> <83sibw59q1.fsf@gnu.org> <5533E816.2090208@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Sun, 19 Apr 2015 20:38:30 +0300 > From: Dmitry Gutov > CC: esr@snark.thyrsus.com, 20292@debbugs.gnu.org > > On 04/19/2015 08:06 PM, Eli Zaretskii wrote: > > > I meant when "git stash pop" reports conflicts, in particular after a > > "git pull" or "git merge". > > That's the general case. > > > I think we were talking about the same use case, but I cannot be sure, > > since "has staged changes" might me more general than what I had in > > mind. > > No: it's more specific. Before you do 'git stash pop', either there's > nothing in the staging area (and the conflict is most likely due to some > new commits), or there is something in the staging area. > > "one has staged changes in one of the involved files" means the latter. > > > Before "git stash save"? The case I had in mind didn't have anything > > staged before that. > > No, after "git stash save", but before "git stash pop". I was talking about the following simple scenatio: git pull # get an error about uncommitted changes that prevent merge git stash save git pull git stash pop # get an error message about conflicts # resolve conflicts and save de-conflicted files From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Apr 2015 18:12:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: esr@snark.thyrsus.com, 20292@debbugs.gnu.org Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.142946712011932 (code B ref 20292); Sun, 19 Apr 2015 18:12:01 +0000 Received: (at 20292) by debbugs.gnu.org; 19 Apr 2015 18:12:00 +0000 Received: from localhost ([127.0.0.1]:60886 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YjthH-00036O-Mn for submit@debbugs.gnu.org; Sun, 19 Apr 2015 14:11:59 -0400 Received: from mail-wg0-f44.google.com ([74.125.82.44]:33646) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YjthF-00036A-Cv for 20292@debbugs.gnu.org; Sun, 19 Apr 2015 14:11:57 -0400 Received: by wgin8 with SMTP id n8so157600195wgi.0 for <20292@debbugs.gnu.org>; Sun, 19 Apr 2015 11:11:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=RdB7Mz2L2w0Ju7VvLv+sv2swcuzr3HwWE758VSXb2XA=; b=gybKWZ57OQCPxSy+QIuXd80U2Beqax4T3QIBPVYig+s0Nhacw4efQ8DJgVd4tF0FfK l8Gr9FYL+6Uw/d1wvUVRaC9/gar2ulkq5ur5Nl/fE0hh3RspElR1kipDZT/XxFO6ZcpF fZWB/BKZ88jV2dO3kPtpnNCpIhwXxX402xJ7cbhfTa8FF5k6kca7FMs64q+M9WLRa/2a fHyz6glCw7NHgXVF6rQzQG+jIblQ0ew5mdW9LZ0Z0ni9aL1eZkuIB7Gtv6duTtIpRrjz TlzT297QdAPeQLpxtzHNM5l8mvzBDR/R1A2OvBn5/7zn10rI0DF4z06Uvo2k5uZ1wT+T BvYA== X-Received: by 10.194.187.41 with SMTP id fp9mr24348382wjc.58.1429467111799; Sun, 19 Apr 2015 11:11:51 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id q4sm4168080wja.24.2015.04.19.11.11.50 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Apr 2015 11:11:51 -0700 (PDT) Message-ID: <5533EFE5.2050101@yandex.ru> Date: Sun, 19 Apr 2015 21:11:49 +0300 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 MIME-Version: 1.0 References: <83fv88ta5r.fsf@gnu.org> <5532ADA3.5000006@yandex.ru> <834mod6xnm.fsf@gnu.org> <5532D397.8090602@yandex.ru> <83zj645gxu.fsf@gnu.org> <5533D7B8.7060508@yandex.ru> <83sibw59q1.fsf@gnu.org> <5533E816.2090208@yandex.ru> <83r3rg56zy.fsf@gnu.org> In-Reply-To: <83r3rg56zy.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 04/19/2015 09:05 PM, Eli Zaretskii wrote: > I was talking about the following simple scenatio: > > git pull > # get an error about uncommitted changes that prevent merge > git stash save > git pull > git stash pop > # get an error message about conflicts > # resolve conflicts and save de-conflicted files And I, about a related but slightly different one, which we'd prefer not to make worse, right? # edit foo.bar git stash save # edit foo.bar again, differently, maybe in several places git add foo.bar git stash pop # get an error message about conflict in foo.bar # resolve conflicts and save foo.bar From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Apr 2015 18:27:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: esr@snark.thyrsus.com, 20292@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.142946798513232 (code B ref 20292); Sun, 19 Apr 2015 18:27:01 +0000 Received: (at 20292) by debbugs.gnu.org; 19 Apr 2015 18:26:25 +0000 Received: from localhost ([127.0.0.1]:60893 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YjtvF-0003RM-20 for submit@debbugs.gnu.org; Sun, 19 Apr 2015 14:26:25 -0400 Received: from mtaout27.012.net.il ([80.179.55.183]:35546) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YjtvD-0003R5-04 for 20292@debbugs.gnu.org; Sun, 19 Apr 2015 14:26:23 -0400 Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NN200K00FZCE000@mtaout27.012.net.il> for 20292@debbugs.gnu.org; Sun, 19 Apr 2015 21:20:47 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NN2009ZKGANPQA0@mtaout27.012.net.il>; Sun, 19 Apr 2015 21:20:47 +0300 (IDT) Date: Sun, 19 Apr 2015 21:25:38 +0300 From: Eli Zaretskii In-reply-to: <5533EFE5.2050101@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <83oamk561p.fsf@gnu.org> References: <83fv88ta5r.fsf@gnu.org> <5532ADA3.5000006@yandex.ru> <834mod6xnm.fsf@gnu.org> <5532D397.8090602@yandex.ru> <83zj645gxu.fsf@gnu.org> <5533D7B8.7060508@yandex.ru> <83sibw59q1.fsf@gnu.org> <5533E816.2090208@yandex.ru> <83r3rg56zy.fsf@gnu.org> <5533EFE5.2050101@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Sun, 19 Apr 2015 21:11:49 +0300 > From: Dmitry Gutov > CC: esr@snark.thyrsus.com, 20292@debbugs.gnu.org > > And I, about a related but slightly different one, which we'd prefer not > to make worse, right? > > # edit foo.bar > git stash save > # edit foo.bar again, differently, maybe in several places > git add foo.bar > git stash pop > # get an error message about conflict in foo.bar > # resolve conflicts and save foo.bar If we can, yes. If not, this is way out of scope of the bug report. From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Apr 2015 18:31:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: esr@snark.thyrsus.com, 20292@debbugs.gnu.org Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.142946824313699 (code B ref 20292); Sun, 19 Apr 2015 18:31:02 +0000 Received: (at 20292) by debbugs.gnu.org; 19 Apr 2015 18:30:43 +0000 Received: from localhost ([127.0.0.1]:60897 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YjtzO-0003Ys-Py for submit@debbugs.gnu.org; Sun, 19 Apr 2015 14:30:43 -0400 Received: from mail-wg0-f54.google.com ([74.125.82.54]:33049) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YjtzL-0003Yd-8w for 20292@debbugs.gnu.org; Sun, 19 Apr 2015 14:30:39 -0400 Received: by wgin8 with SMTP id n8so157851385wgi.0 for <20292@debbugs.gnu.org>; Sun, 19 Apr 2015 11:30:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=VNDqF8OxOOQo1WyMGzEUJgViJj5YuXK64xaEbgsHuBU=; b=Ase+kvuCy00EJSFoKKas48Ss0MqnTDP5mqrrnadwd3kS5KkHkCMELfbbjDuxHwYI0l wk6mI3YHDPaOee48jDckATTCb8XP46Or9rOqMGt7leL5okqhskF91E9noLVJlpNvc3sU xiXJhsjUcKsr8HTJeVaIpWKQ+ochnixwNi+k1vzs1Ze3fj+F3bPrvh7XybioZpM3+6E3 6Mab3PZ3dlFDpMfn479TGAvQng0zazXMS5mCRPE7xKh2m+ZEfz9H/aFbowCu//5s4Jb7 V3YlKBICeXU/EvL9wQ2skhLdvaBU7A1UdGLuV7nYYan3bEm0FiD2nlIs9UgOJX1UBdG7 Xp8Q== X-Received: by 10.180.73.230 with SMTP id o6mr19124393wiv.11.1429468233720; Sun, 19 Apr 2015 11:30:33 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id e10sm11968886wij.11.2015.04.19.11.30.32 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Apr 2015 11:30:33 -0700 (PDT) Message-ID: <5533F446.4020400@yandex.ru> Date: Sun, 19 Apr 2015 21:30:30 +0300 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 MIME-Version: 1.0 References: <83fv88ta5r.fsf@gnu.org> <5532ADA3.5000006@yandex.ru> <834mod6xnm.fsf@gnu.org> <5532D397.8090602@yandex.ru> <83zj645gxu.fsf@gnu.org> <5533D7B8.7060508@yandex.ru> <83sibw59q1.fsf@gnu.org> <5533E816.2090208@yandex.ru> <83r3rg56zy.fsf@gnu.org> <5533EFE5.2050101@yandex.ru> <83oamk561p.fsf@gnu.org> In-Reply-To: <83oamk561p.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 04/19/2015 09:25 PM, Eli Zaretskii wrote: > If we can, yes. If not, this is way out of scope of the bug report. Do you like the solution in d35f2f482273a822df695202f4a3bf1a5e473e63? From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Apr 2015 18:39:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: esr@snark.thyrsus.com, 20292@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.142946871014380 (code B ref 20292); Sun, 19 Apr 2015 18:39:01 +0000 Received: (at 20292) by debbugs.gnu.org; 19 Apr 2015 18:38:30 +0000 Received: from localhost ([127.0.0.1]:60901 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yju6w-0003js-2b for submit@debbugs.gnu.org; Sun, 19 Apr 2015 14:38:30 -0400 Received: from mtaout29.012.net.il ([80.179.55.185]:58274) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yju6u-0003jb-9g for 20292@debbugs.gnu.org; Sun, 19 Apr 2015 14:38:29 -0400 Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NN200900GQB9100@mtaout29.012.net.il> for 20292@debbugs.gnu.org; Sun, 19 Apr 2015 21:36:38 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NN200PQJH126290@mtaout29.012.net.il>; Sun, 19 Apr 2015 21:36:38 +0300 (IDT) Date: Sun, 19 Apr 2015 21:38:13 +0300 From: Eli Zaretskii In-reply-to: <5533F446.4020400@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <83mw2455gq.fsf@gnu.org> References: <83fv88ta5r.fsf@gnu.org> <5532ADA3.5000006@yandex.ru> <834mod6xnm.fsf@gnu.org> <5532D397.8090602@yandex.ru> <83zj645gxu.fsf@gnu.org> <5533D7B8.7060508@yandex.ru> <83sibw59q1.fsf@gnu.org> <5533E816.2090208@yandex.ru> <83r3rg56zy.fsf@gnu.org> <5533EFE5.2050101@yandex.ru> <83oamk561p.fsf@gnu.org> <5533F446.4020400@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Sun, 19 Apr 2015 21:30:30 +0300 > From: Dmitry Gutov > CC: esr@snark.thyrsus.com, 20292@debbugs.gnu.org > > On 04/19/2015 09:25 PM, Eli Zaretskii wrote: > > > If we can, yes. If not, this is way out of scope of the bug report. > > Do you like the solution in d35f2f482273a822df695202f4a3bf1a5e473e63? IMO, it's too radical: there's no need to avoid turning on smerge-mode, as it is useful for conflict resolution. "git add" is not run by smerge-mode, it is run by vc-git-resolve-when-done, so it should be enough to avoid adding that to after-save-hook, I think. Thanks. From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Apr 2015 19:29:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: esr@snark.thyrsus.com, 20292@debbugs.gnu.org Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.142947168918708 (code B ref 20292); Sun, 19 Apr 2015 19:29:02 +0000 Received: (at 20292) by debbugs.gnu.org; 19 Apr 2015 19:28:09 +0000 Received: from localhost ([127.0.0.1]:60919 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yjusz-0004rg-0R for submit@debbugs.gnu.org; Sun, 19 Apr 2015 15:28:09 -0400 Received: from mail-wi0-f174.google.com ([209.85.212.174]:32858) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yjusw-0004rB-QC for 20292@debbugs.gnu.org; Sun, 19 Apr 2015 15:28:07 -0400 Received: by wiax7 with SMTP id x7so68521468wia.0 for <20292@debbugs.gnu.org>; Sun, 19 Apr 2015 12:28:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=4WgVaBgI3muRXwK6ZLmkdS2U/dmQCQUw9QP3WSJams4=; b=QkS6Gs6OkDOL8y+nr6t+T71Kgkkq4FtYqh83Yf4HR+50WFR89Z/3sNIxAWkoXm1mJW P2iRDTE/ScV0xkBJGH5Ktd+vQ0Zrv5XGQ//8ovgp2NqVjQxwIEIii711hO8W79WrF8Dq 2S/5AGGwtfRWCA3ArhpddBiEUNvCgxJHd7ADAdSTROvSAZWtMihgTcJpYFlvqPWbgOmt WUdwoXxRYSUH0rHHHaRPyO0hJ6VfmxokZq4/ggvHM5l//PiJ6ZYh2KyRGU4DtkkkFld+ 2ZODU9Kl97/MQAtUNAE+wXCTeEfQyGGO7l9gC5uCU8ltSODWtTOjhUx334Ay+EQqHC1i rpog== X-Received: by 10.180.88.99 with SMTP id bf3mr9319296wib.75.1429471681075; Sun, 19 Apr 2015 12:28:01 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id ei4sm63437wib.22.2015.04.19.12.27.59 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Apr 2015 12:28:00 -0700 (PDT) Message-ID: <553401BE.90501@yandex.ru> Date: Sun, 19 Apr 2015 22:27:58 +0300 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 MIME-Version: 1.0 References: <83fv88ta5r.fsf@gnu.org> <5532ADA3.5000006@yandex.ru> <834mod6xnm.fsf@gnu.org> <5532D397.8090602@yandex.ru> <83zj645gxu.fsf@gnu.org> <5533D7B8.7060508@yandex.ru> <83sibw59q1.fsf@gnu.org> <5533E816.2090208@yandex.ru> <83r3rg56zy.fsf@gnu.org> <5533EFE5.2050101@yandex.ru> <83oamk561p.fsf@gnu.org> <5533F446.4020400@yandex.ru> <83mw2455gq.fsf@gnu.org> In-Reply-To: <83mw2455gq.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 04/19/2015 09:38 PM, Eli Zaretskii wrote: > IMO, it's too radical: there's no need to avoid turning on > smerge-mode, as it is useful for conflict resolution. "git add" is > not run by smerge-mode, it is run by vc-git-resolve-when-done, so it > should be enough to avoid adding that to after-save-hook, I think. Right. That should be resolved now. From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Apr 2015 19:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: esr@snark.thyrsus.com, 20292@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.142947203519421 (code B ref 20292); Sun, 19 Apr 2015 19:34:02 +0000 Received: (at 20292) by debbugs.gnu.org; 19 Apr 2015 19:33:55 +0000 Received: from localhost ([127.0.0.1]:60923 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YjuyZ-00053B-Df for submit@debbugs.gnu.org; Sun, 19 Apr 2015 15:33:55 -0400 Received: from mtaout28.012.net.il ([80.179.55.184]:46084) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YjuyU-00052s-RM for 20292@debbugs.gnu.org; Sun, 19 Apr 2015 15:33:51 -0400 Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NN200F00JI1DP00@mtaout28.012.net.il> for 20292@debbugs.gnu.org; Sun, 19 Apr 2015 22:32:30 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NN200BUAJM6FK30@mtaout28.012.net.il>; Sun, 19 Apr 2015 22:32:30 +0300 (IDT) Date: Sun, 19 Apr 2015 22:33:35 +0300 From: Eli Zaretskii In-reply-to: <553401BE.90501@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <83k2x76hgw.fsf@gnu.org> References: <83fv88ta5r.fsf@gnu.org> <5532ADA3.5000006@yandex.ru> <834mod6xnm.fsf@gnu.org> <5532D397.8090602@yandex.ru> <83zj645gxu.fsf@gnu.org> <5533D7B8.7060508@yandex.ru> <83sibw59q1.fsf@gnu.org> <5533E816.2090208@yandex.ru> <83r3rg56zy.fsf@gnu.org> <5533EFE5.2050101@yandex.ru> <83oamk561p.fsf@gnu.org> <5533F446.4020400@yandex.ru> <83mw2455gq.fsf@gnu.org> <553401BE.90501@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Sun, 19 Apr 2015 22:27:58 +0300 > From: Dmitry Gutov > CC: esr@snark.thyrsus.com, 20292@debbugs.gnu.org > > On 04/19/2015 09:38 PM, Eli Zaretskii wrote: > > > IMO, it's too radical: there's no need to avoid turning on > > smerge-mode, as it is useful for conflict resolution. "git add" is > > not run by smerge-mode, it is run by vc-git-resolve-when-done, so it > > should be enough to avoid adding that to after-save-hook, I think. > > Right. That should be resolved now. Thanks, looks good to me. From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 20 Apr 2015 02:42:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: esr@snark.thyrsus.com, Eli Zaretskii , 20292@debbugs.gnu.org Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.142949768331458 (code B ref 20292); Mon, 20 Apr 2015 02:42:01 +0000 Received: (at 20292) by debbugs.gnu.org; 20 Apr 2015 02:41:23 +0000 Received: from localhost ([127.0.0.1]:32838 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yk1eE-0008BK-W3 for submit@debbugs.gnu.org; Sun, 19 Apr 2015 22:41:23 -0400 Received: from pruche.dit.umontreal.ca ([132.204.246.22]:45009) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yk1eD-0008BB-5X for 20292@debbugs.gnu.org; Sun, 19 Apr 2015 22:41:21 -0400 Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id t3K2fIYf021622; Sun, 19 Apr 2015 22:41:18 -0400 Received: by pastel.home (Postfix, from userid 20848) id 20722282C; Sun, 19 Apr 2015 22:41:18 -0400 (EDT) From: Stefan Monnier Message-ID: References: <83fv88ta5r.fsf@gnu.org> <5532ADA3.5000006@yandex.ru> <834mod6xnm.fsf@gnu.org> <5532D397.8090602@yandex.ru> <83zj645gxu.fsf@gnu.org> <5533D7B8.7060508@yandex.ru> <83sibw59q1.fsf@gnu.org> <5533E816.2090208@yandex.ru> <83r3rg56zy.fsf@gnu.org> <5533EFE5.2050101@yandex.ru> <83oamk561p.fsf@gnu.org> <5533F446.4020400@yandex.ru> Date: Sun, 19 Apr 2015 22:41:18 -0400 In-Reply-To: <5533F446.4020400@yandex.ru> (Dmitry Gutov's message of "Sun, 19 Apr 2015 21:30:30 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV5281=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5281> : inlines <2753> : streams <1425378> : uri <1910937> X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) >> If we can, yes. If not, this is way out of scope of the bug report. > Do you like the solution in d35f2f482273a822df695202f4a3bf1a5e473e63? My main use case is "git stash pop; then repeatedly call M-x vc-find-conflicted-files and resolve the conflicts (mostly with smerge's help)". I get the impression that with this change vc-find-conflicted-files won't work correctly any more, because the files will keep appearing as "conflicted", even after I've resolved all the conflicts in them. Stefan From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 20 Apr 2015 14:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: esr@snark.thyrsus.com, 20292@debbugs.gnu.org, dgutov@yandex.ru Reply-To: Eli Zaretskii Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.142954113625184 (code B ref 20292); Mon, 20 Apr 2015 14:46:02 +0000 Received: (at 20292) by debbugs.gnu.org; 20 Apr 2015 14:45:36 +0000 Received: from localhost ([127.0.0.1]:33697 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YkCx5-0006Y7-Gl for submit@debbugs.gnu.org; Mon, 20 Apr 2015 10:45:35 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]:38269) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YkCx3-0006Xt-Ai for 20292@debbugs.gnu.org; Mon, 20 Apr 2015 10:45:34 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NN400K000LEV400@a-mtaout21.012.net.il> for 20292@debbugs.gnu.org; Mon, 20 Apr 2015 17:45:27 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NN400KBS0ZQRN90@a-mtaout21.012.net.il>; Mon, 20 Apr 2015 17:45:27 +0300 (IDT) Date: Mon, 20 Apr 2015 17:45:20 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83fv7u6epr.fsf@gnu.org> References: <83fv88ta5r.fsf@gnu.org> <5532ADA3.5000006@yandex.ru> <834mod6xnm.fsf@gnu.org> <5532D397.8090602@yandex.ru> <83zj645gxu.fsf@gnu.org> <5533D7B8.7060508@yandex.ru> <83sibw59q1.fsf@gnu.org> <5533E816.2090208@yandex.ru> <83r3rg56zy.fsf@gnu.org> <5533EFE5.2050101@yandex.ru> <83oamk561p.fsf@gnu.org> <5533F446.4020400@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Stefan Monnier > Cc: Eli Zaretskii , esr@snark.thyrsus.com, 20292@debbugs.gnu.org > Date: Sun, 19 Apr 2015 22:41:18 -0400 > > I get the impression that with this change vc-find-conflicted-files > won't work correctly any more, because the files will keep appearing > as "conflicted", even after I've resolved all the conflicts in them. You need to "unconflict" them by hand, yes, with "git reset HEAD FILE". If it is safe to issue this command automatically, we could do that in the case of "stash pop" conflict _instead_ of doing "git add" in the "normal" merge-conflict case. From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 20 Apr 2015 19:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: esr@snark.thyrsus.com, 20292@debbugs.gnu.org, dgutov@yandex.ru Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.142955765523646 (code B ref 20292); Mon, 20 Apr 2015 19:21:02 +0000 Received: (at 20292) by debbugs.gnu.org; 20 Apr 2015 19:20:55 +0000 Received: from localhost ([127.0.0.1]:33852 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YkHFW-00069J-QV for submit@debbugs.gnu.org; Mon, 20 Apr 2015 15:20:55 -0400 Received: from mercure.iro.umontreal.ca ([132.204.24.67]:35794) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YkHFU-00069A-GT for 20292@debbugs.gnu.org; Mon, 20 Apr 2015 15:20:52 -0400 Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 5565E85FA8; Mon, 20 Apr 2015 15:20:52 -0400 (EDT) Received: from lechon.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id 2D14C1E5B94; Mon, 20 Apr 2015 15:20:28 -0400 (EDT) Received: by lechon.iro.umontreal.ca (Postfix, from userid 20848) id 12B42B40DC; Mon, 20 Apr 2015 15:20:28 -0400 (EDT) From: Stefan Monnier Message-ID: References: <83fv88ta5r.fsf@gnu.org> <5532ADA3.5000006@yandex.ru> <834mod6xnm.fsf@gnu.org> <5532D397.8090602@yandex.ru> <83zj645gxu.fsf@gnu.org> <5533D7B8.7060508@yandex.ru> <83sibw59q1.fsf@gnu.org> <5533E816.2090208@yandex.ru> <83r3rg56zy.fsf@gnu.org> <5533EFE5.2050101@yandex.ru> <83oamk561p.fsf@gnu.org> <5533F446.4020400@yandex.ru> <83fv7u6epr.fsf@gnu.org> Date: Mon, 20 Apr 2015 15:20:28 -0400 In-Reply-To: <83fv7u6epr.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 20 Apr 2015 17:45:20 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-2.82, requis 5, autolearn=not spam, ALL_TRUSTED -2.82, MC_TSTLAST 0.00) X-DIRO-MailScanner-From: monnier@iro.umontreal.ca X-Spam-Status: No X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) >> I get the impression that with this change vc-find-conflicted-files >> won't work correctly any more, because the files will keep appearing >> as "conflicted", even after I've resolved all the conflicts in them. > You need to "unconflict" them by hand, yes, with "git reset HEAD FILE". I very much want Emacs to do that for me (or "git add", I really couldn't care less which is used, I just want the "conflicted" marker to be cleared). I went to the trouble to get this working for Bzr back in the day, then Svn (and managed to find someone else to do it for Git), because I find it much too inconvenient otherwise. > If it is safe to issue this command automatically, we could do > that in the case of "stash pop" conflict _instead_ of doing "git add" > in the "normal" merge-conflict case. I don't really know what is "safe" in this respect. For my own use, all of the options we've considered are safe. Stefan From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 20 Apr 2015 19:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: esr@snark.thyrsus.com, 20292@debbugs.gnu.org, dgutov@yandex.ru Reply-To: Eli Zaretskii Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.142955780523894 (code B ref 20292); Mon, 20 Apr 2015 19:24:02 +0000 Received: (at 20292) by debbugs.gnu.org; 20 Apr 2015 19:23:25 +0000 Received: from localhost ([127.0.0.1]:33856 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YkHHw-0006DK-Fb for submit@debbugs.gnu.org; Mon, 20 Apr 2015 15:23:24 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]:51344) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YkHHt-0006D5-D8 for 20292@debbugs.gnu.org; Mon, 20 Apr 2015 15:23:22 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NN400L00DPYIR00@a-mtaout21.012.net.il> for 20292@debbugs.gnu.org; Mon, 20 Apr 2015 22:23:15 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NN400L7GDUQFV70@a-mtaout21.012.net.il>; Mon, 20 Apr 2015 22:23:15 +0300 (IDT) Date: Mon, 20 Apr 2015 22:23:08 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <838udm61ur.fsf@gnu.org> References: <83fv88ta5r.fsf@gnu.org> <5532ADA3.5000006@yandex.ru> <834mod6xnm.fsf@gnu.org> <5532D397.8090602@yandex.ru> <83zj645gxu.fsf@gnu.org> <5533D7B8.7060508@yandex.ru> <83sibw59q1.fsf@gnu.org> <5533E816.2090208@yandex.ru> <83r3rg56zy.fsf@gnu.org> <5533EFE5.2050101@yandex.ru> <83oamk561p.fsf@gnu.org> <5533F446.4020400@yandex.ru> <83fv7u6epr.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Stefan Monnier > Cc: dgutov@yandex.ru, esr@snark.thyrsus.com, 20292@debbugs.gnu.org > Date: Mon, 20 Apr 2015 15:20:28 -0400 > > > If it is safe to issue this command automatically, we could do > > that in the case of "stash pop" conflict _instead_ of doing "git add" > > in the "normal" merge-conflict case. > > I don't really know what is "safe" in this respect. For my own use, all > of the options we've considered are safe. Then my vote is for using "git add FILE" with conflicts during a merge, and "git reset HEAD FILE" with conflicts during "stash pop". I think this is the simplest solution and is easy to implement with minimal changes. From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 21 Apr 2015 01:07:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: esr@snark.thyrsus.com, 20292@debbugs.gnu.org, dgutov@yandex.ru Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.14295783691905 (code B ref 20292); Tue, 21 Apr 2015 01:07:01 +0000 Received: (at 20292) by debbugs.gnu.org; 21 Apr 2015 01:06:09 +0000 Received: from localhost ([127.0.0.1]:34040 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YkMdd-0000Uf-Ht for submit@debbugs.gnu.org; Mon, 20 Apr 2015 21:06:09 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:46403) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YkMdb-0000UQ-KI for 20292@debbugs.gnu.org; Mon, 20 Apr 2015 21:06:08 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAGvvdVRMCqjW/2dsb2JhbAA3gVOhb4EIgXUBAQQBVh4FBQsLNAcLFBgNJC6HZaIRjGQJAQIBAoM+Aw4ECoNUBKNjhFg X-IPAS-Result: AgUFAGvvdVRMCqjW/2dsb2JhbAA3gVOhb4EIgXUBAQQBVh4FBQsLNAcLFBgNJC6HZaIRjGQJAQIBAoM+Aw4ECoNUBKNjhFg X-IronPort-AV: E=Sophos;i="5.11,557,1422939600"; d="scan'208";a="116937056" Received: from 76-10-168-214.dsl.teksavvy.com (HELO ceviche.home) ([76.10.168.214]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Apr 2015 21:06:01 -0400 Received: by ceviche.home (Postfix, from userid 20848) id ABFD86610A; Mon, 20 Apr 2015 21:06:01 -0400 (EDT) From: Stefan Monnier Message-ID: References: <83fv88ta5r.fsf@gnu.org> <5532ADA3.5000006@yandex.ru> <834mod6xnm.fsf@gnu.org> <5532D397.8090602@yandex.ru> <83zj645gxu.fsf@gnu.org> <5533D7B8.7060508@yandex.ru> <83sibw59q1.fsf@gnu.org> <5533E816.2090208@yandex.ru> <83r3rg56zy.fsf@gnu.org> <5533EFE5.2050101@yandex.ru> <83oamk561p.fsf@gnu.org> <5533F446.4020400@yandex.ru> <83fv7u6epr.fsf@gnu.org> <838udm61ur.fsf@gnu.org> Date: Mon, 20 Apr 2015 21:06:01 -0400 In-Reply-To: <838udm61ur.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 20 Apr 2015 22:23:08 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > Then my vote is for using "git add FILE" with conflicts during a > merge, and "git reset HEAD FILE" with conflicts during "stash pop". > I think this is the simplest solution and is easy to implement with > minimal changes. Fine by me, Stefan From unknown Mon Jun 23 23:55:28 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.503 (Entity 5.503) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Eli Zaretskii Subject: bug#20292: closed (Re: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file) Message-ID: References: <5536FE56.406@yandex.ru> <83fv88ta5r.fsf@gnu.org> X-Gnu-PR-Message: they-closed 20292 X-Gnu-PR-Package: emacs Reply-To: 20292@debbugs.gnu.org Date: Wed, 22 Apr 2015 01:51:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1429667462-9362-1" This is a multi-part message in MIME format... ------------=_1429667462-9362-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #20292: 24.5; Saving Git-controlled file with merge conflicts after "stash = pop" stages the file which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 20292@debbugs.gnu.org. --=20 20292: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D20292 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1429667462-9362-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 20292-done) by debbugs.gnu.org; 22 Apr 2015 01:50:25 +0000 Received: from localhost ([127.0.0.1]:35659 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ykjo0-0002Oo-4J for submit@debbugs.gnu.org; Tue, 21 Apr 2015 21:50:24 -0400 Received: from mail-wg0-f47.google.com ([74.125.82.47]:35145) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ykjnx-0002OR-Gg for 20292-done@debbugs.gnu.org; Tue, 21 Apr 2015 21:50:22 -0400 Received: by wgyo15 with SMTP id o15so231526660wgy.2 for <20292-done@debbugs.gnu.org>; Tue, 21 Apr 2015 18:50:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=hGGHsgtCDtCeTYB53L7B73PA+Tb8T29Ldbj0sr0XLtc=; b=nPLvWQ3J5ZxklceU1VmcbxoopX5J2UXbeGxvljyPUG5T6UUB8FSN1u/QtMmefmBME4 1YhWX2mNbUXqGtu/lr2GCCuOIbf5ebzZpUST+Y472mJbCcTRcWKx44NdxMdefQVCAh+M EDqEmpeMZ/l007ITgx1UUJqNxaVIWsGBl4EXaZ5PAk2RK5gHYRstNHSLf3GsPouYE0w4 4IcsSydFnPKw6tjTqcYnlOcyEh2CVi/esW5nXWFQ7vWPe+o11c7T9fyaLfik66ZFyLl0 xqI4+ssk8b1JLsJtNKoLvKewknZ5U9tlAxZ771KOfTw7vWSGGvVvkD0/lFArSVtFXvzz KuoA== X-Received: by 10.194.93.195 with SMTP id cw3mr46913536wjb.150.1429667415700; Tue, 21 Apr 2015 18:50:15 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id e18sm5005921wjz.27.2015.04.21.18.50.14 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Apr 2015 18:50:15 -0700 (PDT) Message-ID: <5536FE56.406@yandex.ru> Date: Wed, 22 Apr 2015 04:50:14 +0300 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 MIME-Version: 1.0 To: Stefan Monnier , Eli Zaretskii Subject: Re: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file References: <83fv88ta5r.fsf@gnu.org> <5532ADA3.5000006@yandex.ru> <834mod6xnm.fsf@gnu.org> <5532D397.8090602@yandex.ru> <83zj645gxu.fsf@gnu.org> <5533D7B8.7060508@yandex.ru> <83sibw59q1.fsf@gnu.org> <5533E816.2090208@yandex.ru> <83r3rg56zy.fsf@gnu.org> <5533EFE5.2050101@yandex.ru> <83oamk561p.fsf@gnu.org> <5533F446.4020400@yandex.ru> <83fv7u6epr.fsf@gnu.org> <838udm61ur.fsf@gnu.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 20292-done Cc: esr@snark.thyrsus.com, 20292-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 04/21/2015 04:06 AM, Stefan Monnier wrote: >> Then my vote is for using "git add FILE" with conflicts during a >> merge, and "git reset HEAD FILE" with conflicts during "stash pop". >> I think this is the simplest solution and is easy to implement with >> minimal changes. > > Fine by me, I've pushed this, together with the choosing logic suggested previously. Apparently it's the best we can do. ------------=_1429667462-9362-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 10 Apr 2015 12:56:03 +0000 Received: from localhost ([127.0.0.1]:51930 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgYTZ-0006BG-Hk for submit@debbugs.gnu.org; Fri, 10 Apr 2015 08:56:02 -0400 Received: from eggs.gnu.org ([208.118.235.92]:42586) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgYTW-0006Ax-HU for submit@debbugs.gnu.org; Fri, 10 Apr 2015 08:55:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YgYTQ-0001td-2R for submit@debbugs.gnu.org; Fri, 10 Apr 2015 08:55:53 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:60248) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YgYTQ-0001tZ-0J for submit@debbugs.gnu.org; Fri, 10 Apr 2015 08:55:52 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56066) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YgYTO-00075V-LK for bug-gnu-emacs@gnu.org; Fri, 10 Apr 2015 08:55:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YgYTJ-0001s6-T7 for bug-gnu-emacs@gnu.org; Fri, 10 Apr 2015 08:55:50 -0400 Received: from mtaout25.012.net.il ([80.179.55.181]:41950) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YgYTJ-0001rl-DV for bug-gnu-emacs@gnu.org; Fri, 10 Apr 2015 08:55:45 -0400 Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NML00100CTDIV00@mtaout25.012.net.il> for bug-gnu-emacs@gnu.org; Fri, 10 Apr 2015 15:51:10 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NML001R8D1AE200@mtaout25.012.net.il>; Fri, 10 Apr 2015 15:51:10 +0300 (IDT) Date: Fri, 10 Apr 2015 15:55:44 +0300 From: Eli Zaretskii Subject: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file X-012-Sender: halo1@inter.net.il To: bug-gnu-emacs@gnu.org Message-id: <83fv88ta5r.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: submit Cc: "Eric S. Raymond" X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) >From the shell prompt type "git stash save" to stash uncommitted changes. Then "git pull" or "git merge" from upstream, and finally type "git stash pop" to restore your original changes. If "git stash pop" encounters merge conflicts, then resolving these conflicts in Emacs and saving the buffer will run "git add" for the file whose conflicts were resolved. But that is not TRT in this case; the user likely does not expect to have her uncommitted changes staged for the next commit. Therefore, I think vc-git-resolve-when-done should not run "git add" if the merge conflict was due to "git stash pop". In GNU Emacs 24.5.1 (i686-pc-mingw32) of 2015-03-27 on HOME-C4E4A596F7 Windowing system distributor `Microsoft Corp.', version 5.1.2600 Configured using: `configure --prefix=/d/usr 'CFLAGS=-Og -gdwarf-4 -g3'' Important settings: value of $LANG: ENU locale-coding-system: cp1255 Major mode: RMAIL Minor modes in effect: diff-auto-refine-mode: t desktop-save-mode: t show-paren-mode: t display-time-mode: t tooltip-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t temp-buffer-resize-mode: t buffer-read-only: t line-number-mode: t Recent messages: Getting mail from d:/usr/eli/data/mail.new... Counting new messages...done (12) Saving file d:/usr/eli/rmail/INBOX... Wrote d:/usr/eli/rmail/INBOX [2 times] Computing summary lines...done 12 new messages read Mark set No following nondeleted message Saving file d:/usr/eli/rmail/INBOX... Wrote d:/usr/eli/rmail/INBOX [2 times] Load-path shadows: d:/usr/share/emacs/site-lisp/soap-inspect hides d:/usr/share/emacs/24.5/lisp/net/soap-inspect d:/usr/share/emacs/site-lisp/soap-client hides d:/usr/share/emacs/24.5/lisp/net/soap-client Features: (shadow emacsbug etags smerge-mode cc-awk bug-reference add-log misearch multi-isearch dabbrev shr-color color mule-util rmailout shr browse-url network-stream starttls tls mail-extr smtpmail auth-source eieio byte-opt bytecomp byte-compile cconv eieio-core password-cache mailalias sendmail help-mode cl-extra texinfo ld-script tcl conf-mode org-element org-rmail org-mhe org-irc org-info org-gnus gnus-util org-docview doc-view image-mode dired-x dired org-bibtex bibtex org-bbdb org-w3m org advice org-macro org-footnote org-pcomplete pcomplete org-list org-faces org-entities org-version ob-emacs-lisp ob ob-tangle ob-ref ob-lob ob-table ob-exp org-src ob-keys ob-comint comint ansi-color ring ob-core ob-eval org-compat org-macs org-loaddefs find-func cal-menu calendar cal-loaddefs arc-mode archive-mode parse-time diff-mode vc-bzr sh-script smie executable generic make-mode noutline outline easy-mmode vc-cvs jka-compr bat-mode vc-dispatcher vc-svn flyspell info vc-git cc-langs rmailsum qp rmailmm message format-spec rfc822 mml mml-sec mm-decode mm-bodies mm-encode mailabbrev gmm-utils mailheader mail-parse rfc2231 rmail rfc2047 rfc2045 ietf-drums mm-util help-fns mail-prsvr mail-utils desktop frameset server filecache mairix cus-edit cus-start cus-load wid-edit cl-loaddefs cl-lib saveplace midnight ispell generic-x cc-mode cc-fonts easymenu cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs paren battery time time-date tooltip electric uniquify ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp w32-common-fns disp-table w32-win w32-vars tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment lisp-mode prog-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote make-network-process w32notify w32 multi-tty emacs) Memory information: ((conses 8 1513834 148516) (symbols 32 42131 0) (miscs 32 5809 4393) (strings 16 105774 18210) (string-bytes 1 3133483) (vectors 8 37368) (vector-slots 4 1563878 83782) (floats 8 326 1158) (intervals 28 269674 1601) (buffers 508 358)) ------------=_1429667462-9362-1-- From unknown Mon Jun 23 23:55:28 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.503 (Entity 5.503) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: David Kastrup Subject: bug#20151: closed (Re: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file) Message-ID: References: <5536FE56.406@yandex.ru> <87iodwc9r0.fsf@fencepost.gnu.org> X-Gnu-PR-Message: they-closed 20151 X-Gnu-PR-Package: emacs Reply-To: 20151@debbugs.gnu.org Date: Wed, 22 Apr 2015 01:51:03 +0000 Content-Type: multipart/mixed; boundary="----------=_1429667463-9362-3" This is a multi-part message in MIME format... ------------=_1429667463-9362-3 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #20292: 25.0.50; Smerge does "git add" for every final conflict resolution which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 20151@debbugs.gnu.org. --=20 20292: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D20292 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1429667463-9362-3 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 20292-done) by debbugs.gnu.org; 22 Apr 2015 01:50:25 +0000 Received: from localhost ([127.0.0.1]:35659 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ykjo0-0002Oo-4J for submit@debbugs.gnu.org; Tue, 21 Apr 2015 21:50:24 -0400 Received: from mail-wg0-f47.google.com ([74.125.82.47]:35145) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ykjnx-0002OR-Gg for 20292-done@debbugs.gnu.org; Tue, 21 Apr 2015 21:50:22 -0400 Received: by wgyo15 with SMTP id o15so231526660wgy.2 for <20292-done@debbugs.gnu.org>; Tue, 21 Apr 2015 18:50:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=hGGHsgtCDtCeTYB53L7B73PA+Tb8T29Ldbj0sr0XLtc=; b=nPLvWQ3J5ZxklceU1VmcbxoopX5J2UXbeGxvljyPUG5T6UUB8FSN1u/QtMmefmBME4 1YhWX2mNbUXqGtu/lr2GCCuOIbf5ebzZpUST+Y472mJbCcTRcWKx44NdxMdefQVCAh+M EDqEmpeMZ/l007ITgx1UUJqNxaVIWsGBl4EXaZ5PAk2RK5gHYRstNHSLf3GsPouYE0w4 4IcsSydFnPKw6tjTqcYnlOcyEh2CVi/esW5nXWFQ7vWPe+o11c7T9fyaLfik66ZFyLl0 xqI4+ssk8b1JLsJtNKoLvKewknZ5U9tlAxZ771KOfTw7vWSGGvVvkD0/lFArSVtFXvzz KuoA== X-Received: by 10.194.93.195 with SMTP id cw3mr46913536wjb.150.1429667415700; Tue, 21 Apr 2015 18:50:15 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id e18sm5005921wjz.27.2015.04.21.18.50.14 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Apr 2015 18:50:15 -0700 (PDT) Message-ID: <5536FE56.406@yandex.ru> Date: Wed, 22 Apr 2015 04:50:14 +0300 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 MIME-Version: 1.0 To: Stefan Monnier , Eli Zaretskii Subject: Re: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file References: <83fv88ta5r.fsf@gnu.org> <5532ADA3.5000006@yandex.ru> <834mod6xnm.fsf@gnu.org> <5532D397.8090602@yandex.ru> <83zj645gxu.fsf@gnu.org> <5533D7B8.7060508@yandex.ru> <83sibw59q1.fsf@gnu.org> <5533E816.2090208@yandex.ru> <83r3rg56zy.fsf@gnu.org> <5533EFE5.2050101@yandex.ru> <83oamk561p.fsf@gnu.org> <5533F446.4020400@yandex.ru> <83fv7u6epr.fsf@gnu.org> <838udm61ur.fsf@gnu.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 20292-done Cc: esr@snark.thyrsus.com, 20292-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 04/21/2015 04:06 AM, Stefan Monnier wrote: >> Then my vote is for using "git add FILE" with conflicts during a >> merge, and "git reset HEAD FILE" with conflicts during "stash pop". >> I think this is the simplest solution and is easy to implement with >> minimal changes. > > Fine by me, I've pushed this, together with the choosing logic suggested previously. Apparently it's the best we can do. ------------=_1429667463-9362-3 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 20 Mar 2015 09:13:30 +0000 Received: from localhost ([127.0.0.1]:58824 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YYszh-0006sn-Cd for submit@debbugs.gnu.org; Fri, 20 Mar 2015 05:13:29 -0400 Received: from eggs.gnu.org ([208.118.235.92]:54490) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YYszf-0006sa-AM for submit@debbugs.gnu.org; Fri, 20 Mar 2015 05:13:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YYszY-0007td-AY for submit@debbugs.gnu.org; Fri, 20 Mar 2015 05:13:22 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:58691) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YYszY-0007tT-6z for submit@debbugs.gnu.org; Fri, 20 Mar 2015 05:13:20 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56189) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YYszW-0006ZH-Tn for bug-gnu-emacs@gnu.org; Fri, 20 Mar 2015 05:13:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YYszV-0007sr-J0 for bug-gnu-emacs@gnu.org; Fri, 20 Mar 2015 05:13:18 -0400 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:52606) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YYszV-0007sn-Fq for bug-gnu-emacs@gnu.org; Fri, 20 Mar 2015 05:13:17 -0400 Received: from localhost ([127.0.0.1]:59780 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YYszV-0008Ua-1V for bug-gnu-emacs@gnu.org; Fri, 20 Mar 2015 05:13:17 -0400 Received: by lola (Postfix, from userid 1000) id 1A913E0DD6; Fri, 20 Mar 2015 10:13:07 +0100 (CET) From: David Kastrup To: bug-gnu-emacs@gnu.org Subject: 25.0.50; Smerge does "git add" for every final conflict resolution Date: Fri, 20 Mar 2015 10:13:07 +0100 Message-ID: <87iodwc9r0.fsf@fencepost.gnu.org> MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) When Smerge-mode has fixed the final conflict in a Git conflict, it adds the file to the index. However, when the conflict occured as the result of "git stash pop" action in the work directory, the state of the index should not be touched: the whole point of using git stash is to store work directory and index separately and restore them separately. So probably Smerge-mode would have to check whether a conflict is recorded in the index before overwriting it. In GNU Emacs 25.0.50.1 (i686-pc-linux-gnu, GTK+ Version 3.12.2) of 2015-03-04 on lola Repository revision: ca2b0e220ee6b2cab538e84703559696ce477e71 Windowing system distributor `The X.Org Foundation', version 11.0.11600000 System Description: Ubuntu 14.10 Configured using: `configure --without-toolkit-scroll-bars' Configured features: XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS NOTIFY LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB Important settings: value of $LC_MONETARY: en_US.UTF-8 value of $LC_NUMERIC: en_US.UTF-8 value of $LC_TIME: en_US.UTF-8 value of $LANG: en_US.UTF-8 value of $XMODIFIERS: @im=ibus locale-coding-system: utf-8-unix Major mode: Emacs-Lisp Minor modes in effect: whitespace-mode: t shell-dirtrack-mode: t TeX-PDF-mode: t diff-auto-refine-mode: t desktop-save-mode: t minibuffer-electric-default-mode: t tooltip-mode: t global-eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t Recent messages: smerge-next is on , C-c ^ n Entering debugger... Continuing. smerge-ensure-match: No `base' Saving file /home/dak/lilymidi/lily-midi.el... Wrote /home/dak/lilymidi/lily-midi.el Whitespace mode enabled in current buffer You can run the command `whitespace-mode' with M-x whit-m RET Whitespace mode enabled in current buffer scroll-down-command: Beginning of buffer scroll-up-command: End of buffer Load-path shadows: None found. Features: (shadow emacsbug whitespace lily-midi midi-kbd pcmpl-unix pcmpl-gnu pp ccl shell pcomplete warnings misearch multi-isearch dabbrev gnus-dup apropos eieio-opt speedbar sb-image ezimage dframe find-func sendmail nnir debug gnus-kill shr-color color mule-util flow-fill sort smiley gnus-cite mm-archive mail-extr gnus-async gnus-bcklg qp gnus-ml disp-table pop3 nndir nndraft nnmh help-mode gnutls network-stream nsm starttls nnml nnfolder nnnil gnus-agent gnus-srvr gnus-score score-mode nnvirtual gnus-msg gnus-art mm-uu mml2015 mm-view mml-smime smime dig nntp gnus-cache gnus-sum gnus-group gnus-undo gnus-start gnus-cloud nnimap nnmail mail-source tls utf7 netrc nnoo parse-time gnus-spec gnus-int gnus-range message rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums mailabbrev gmm-utils mailheader gnus-win eww mm-url url-queue url url-proxy url-privacy url-expand url-methods url-history url-cookie url-domsuf url-util url-parse auth-source cl-macs eieio gv eieio-core cl-generic password-cache url-vars mailcap shr dom subr-x pcase browse-url format-spec sh-script smie executable make-mode smerge-mode nxml-uchnm rng-xsd xsd-regexp rng-cmpct rng-nxml rng-valid rng-loc rng-uri rng-parse nxml-parse rng-match rng-dt rng-util rng-pttrn nxml-ns nxml-mode nxml-outln nxml-rap nxml-util nxml-glyph nxml-enc xmltok dired-x dired python json autorevert filenotify bug-reference add-log latexenc tex-info texinfo preview prv-emacs reftex-dcr reftex-auc reftex reftex-vars tex-bar tex-buf toolbar-x noutline outline font-latex byte-opt bytecomp byte-compile cl-extra seq cconv latex edmacro kmacro tex-style tex dbus xml crm lilypond-mode compile comint ansi-color ring jka-compr scheme vc vc-dispatcher vc-git diff-mode easy-mmode cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs info easymenu package epg-config advice desktop frameset minibuf-eldef gnus gnus-ems nnheader gnus-util mail-utils mm-util help-fns mail-prsvr wid-edit cl-loaddefs cl-lib cus-start cus-load preview-latex tex-site auto-loads server time-date tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote make-network-process dbusbind gfilenotify dynamic-setting system-font-setting font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs) Memory information: ((conses 8 696689 124897) (symbols 24 55713 157) (miscs 20 1205 2247) (strings 16 119776 17186) (string-bytes 1 3828540) (vectors 8 48240) (vector-slots 4 1789635 56924) (floats 8 541 993) (intervals 28 35923 854) (buffers 520 295) (heap 1024 71211 19354)) -- David Kastrup ------------=_1429667463-9362-3-- From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 22 Apr 2015 07:36:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: esr@snark.thyrsus.com, monnier@iro.umontreal.ca, 20292@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.142968816025928 (code B ref 20292); Wed, 22 Apr 2015 07:36:02 +0000 Received: (at 20292) by debbugs.gnu.org; 22 Apr 2015 07:36:00 +0000 Received: from localhost ([127.0.0.1]:35721 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YkpCR-0006k7-Sh for submit@debbugs.gnu.org; Wed, 22 Apr 2015 03:36:00 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]:41927) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YkpCN-0006jr-9p for 20292@debbugs.gnu.org; Wed, 22 Apr 2015 03:35:56 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NN7004006685600@a-mtaout21.012.net.il> for 20292@debbugs.gnu.org; Wed, 22 Apr 2015 10:35:49 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NN7004UC6FO1N80@a-mtaout21.012.net.il>; Wed, 22 Apr 2015 10:35:48 +0300 (IDT) Date: Wed, 22 Apr 2015 10:35:46 +0300 From: Eli Zaretskii In-reply-to: <5536FE56.406@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <83egnc4nu5.fsf@gnu.org> References: <83fv88ta5r.fsf@gnu.org> <5532ADA3.5000006@yandex.ru> <834mod6xnm.fsf@gnu.org> <5532D397.8090602@yandex.ru> <83zj645gxu.fsf@gnu.org> <5533D7B8.7060508@yandex.ru> <83sibw59q1.fsf@gnu.org> <5533E816.2090208@yandex.ru> <83r3rg56zy.fsf@gnu.org> <5533EFE5.2050101@yandex.ru> <83oamk561p.fsf@gnu.org> <5533F446.4020400@yandex.ru> <83fv7u6epr.fsf@gnu.org> <838udm61ur.fsf@gnu.org> <5536FE56.406@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Wed, 22 Apr 2015 04:50:14 +0300 > From: Dmitry Gutov > CC: esr@snark.thyrsus.com, 20292-done@debbugs.gnu.org > > On 04/21/2015 04:06 AM, Stefan Monnier wrote: > >> Then my vote is for using "git add FILE" with conflicts during a > >> merge, and "git reset HEAD FILE" with conflicts during "stash pop". > >> I think this is the simplest solution and is easy to implement with > >> minimal changes. > > > > Fine by me, > > I've pushed this, together with the choosing logic suggested previously. > Apparently it's the best we can do. Thanks, this does TRT in my use cases. From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Richard Stallman Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 22 Apr 2015 08:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: eliz@gnu.org, 20292@debbugs.gnu.org, dgutov@yandex.ru Reply-To: rms@gnu.org Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.142969246832455 (code B ref 20292); Wed, 22 Apr 2015 08:48:02 +0000 Received: (at 20292) by debbugs.gnu.org; 22 Apr 2015 08:47:48 +0000 Received: from localhost ([127.0.0.1]:35740 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YkqJw-0008RO-09 for submit@debbugs.gnu.org; Wed, 22 Apr 2015 04:47:48 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:46054 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YkqJt-0008RG-PQ for 20292@debbugs.gnu.org; Wed, 22 Apr 2015 04:47:46 -0400 Received: from rms by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1YkqJs-0004M6-NQ; Wed, 22 Apr 2015 04:47:44 -0400 Date: Wed, 22 Apr 2015 04:47:44 -0400 Message-Id: Content-Type: text/plain; charset=Utf-8 From: Richard Stallman In-reply-to: <5536FE56.406@yandex.ru> (message from Dmitry Gutov on Wed, 22 Apr 2015 04:50:14 +0300) References: <83fv88ta5r.fsf@gnu.org> <5532ADA3.5000006@yandex.ru> <834mod6xnm.fsf@gnu.org> <5532D397.8090602@yandex.ru> <83zj645gxu.fsf@gnu.org> <5533D7B8.7060508@yandex.ru> <83sibw59q1.fsf@gnu.org> <5533E816.2090208@yandex.ru> <83r3rg56zy.fsf@gnu.org> <5533EFE5.2050101@yandex.ru> <83oamk561p.fsf@gnu.org> <5533F446.4020400@yandex.ru> <83fv7u6epr.fsf@gnu.org> <838udm61ur.fsf@gnu.org> <5536FE56.406@yandex.ru> X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > >> Then my vote is for using "git add FILE" with conflicts during a > >> merge, and "git reset HEAD FILE" with conflicts during "stash pop". > >> I think this is the simplest solution and is easy to implement with > >> minimal changes. > > > > Fine by me, > I've pushed this, together with the choosing logic suggested previously. > Apparently it's the best we can do. Could you describe the new behavior that you have implemented? -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! See stallman.org/skype.html. From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 22 Apr 2015 09:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: rms@gnu.org Cc: 20292@debbugs.gnu.org, dgutov@yandex.ru Reply-To: Eli Zaretskii Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.14296942022843 (code B ref 20292); Wed, 22 Apr 2015 09:17:01 +0000 Received: (at 20292) by debbugs.gnu.org; 22 Apr 2015 09:16:42 +0000 Received: from localhost ([127.0.0.1]:35749 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ykqlt-0000jm-Io for submit@debbugs.gnu.org; Wed, 22 Apr 2015 05:16:41 -0400 Received: from mtaout24.012.net.il ([80.179.55.180]:60929) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ykqlq-0000jX-3p for 20292@debbugs.gnu.org; Wed, 22 Apr 2015 05:16:39 -0400 Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NN700800AGGIP00@mtaout24.012.net.il> for 20292@debbugs.gnu.org; Wed, 22 Apr 2015 12:07:43 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NN7003GTAOV0Q60@mtaout24.012.net.il>; Wed, 22 Apr 2015 12:07:43 +0300 (IDT) Date: Wed, 22 Apr 2015 12:16:28 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83a8y04j6b.fsf@gnu.org> References: <83fv88ta5r.fsf@gnu.org> <5532ADA3.5000006@yandex.ru> <834mod6xnm.fsf@gnu.org> <5532D397.8090602@yandex.ru> <83zj645gxu.fsf@gnu.org> <5533D7B8.7060508@yandex.ru> <83sibw59q1.fsf@gnu.org> <5533E816.2090208@yandex.ru> <83r3rg56zy.fsf@gnu.org> <5533EFE5.2050101@yandex.ru> <83oamk561p.fsf@gnu.org> <5533F446.4020400@yandex.ru> <83fv7u6epr.fsf@gnu.org> <838udm61ur.fsf@gnu.org> <5536FE56.406@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Wed, 22 Apr 2015 04:47:44 -0400 > From: Richard Stallman > CC: 20292@debbugs.gnu.org, dgutov@yandex.ru, eliz@gnu.org > > > >> Then my vote is for using "git add FILE" with conflicts during a > > >> merge, and "git reset HEAD FILE" with conflicts during "stash pop". > > >> I think this is the simplest solution and is easy to implement with > > >> minimal changes. > > > > > > Fine by me, > > > I've pushed this, together with the choosing logic suggested previously. > > Apparently it's the best we can do. > > Could you describe the new behavior that you have implemented? The new behavior changes what Emacs does when you save a file which had conflicts that you resolved: . if the conflicts were due to a merge (which includes the automatic merge done by "git pull"), the behavior is as before: Emacs stages the file for commit by running "git add FILE" . if the conflicts were due to something else (which includes conflicts during "git stash pop"; not sure if there are other non-merge situations that create conflicts), then the new behavior is to run "git reset FILE", which leaves any changes in FILE uncommitted (and not staged), thus restoring the status of FILE before "git stash save" The one thing to remember is that after saving the file whose conflicts were resolved, you should type "C-x v v" to commit it in the first case, and do nothing in the second. From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Richard Stallman Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 22 Apr 2015 20:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 20292@debbugs.gnu.org, dgutov@yandex.ru Reply-To: rms@gnu.org Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.14297327907803 (code B ref 20292); Wed, 22 Apr 2015 20:00:02 +0000 Received: (at 20292) by debbugs.gnu.org; 22 Apr 2015 19:59:50 +0000 Received: from localhost ([127.0.0.1]:36804 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yl0oH-00021m-Tc for submit@debbugs.gnu.org; Wed, 22 Apr 2015 15:59:50 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:42347 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yl0oF-00021d-Kz for 20292@debbugs.gnu.org; Wed, 22 Apr 2015 15:59:47 -0400 Received: from rms by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1Yl0oE-0003UL-K6; Wed, 22 Apr 2015 15:59:46 -0400 Date: Wed, 22 Apr 2015 15:59:46 -0400 Message-Id: Content-Type: text/plain; charset=Utf-8 From: Richard Stallman In-reply-to: <83a8y04j6b.fsf@gnu.org> (message from Eli Zaretskii on Wed, 22 Apr 2015 12:16:28 +0300) References: <83fv88ta5r.fsf@gnu.org> <5532ADA3.5000006@yandex.ru> <834mod6xnm.fsf@gnu.org> <5532D397.8090602@yandex.ru> <83zj645gxu.fsf@gnu.org> <5533D7B8.7060508@yandex.ru> <83sibw59q1.fsf@gnu.org> <5533E816.2090208@yandex.ru> <83r3rg56zy.fsf@gnu.org> <5533EFE5.2050101@yandex.ru> <83oamk561p.fsf@gnu.org> <5533F446.4020400@yandex.ru> <83fv7u6epr.fsf@gnu.org> <838udm61ur.fsf@gnu.org> <5536FE56.406@yandex.ru> <83a8y04j6b.fsf@gnu.org> X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] It seems good. > The one thing to remember is that after saving the file whose > conflicts were resolved, you should type "C-x v v" to commit it in the > first case, and do nothing in the second. Does VC determine automatically whether the conflict was due to merge or due to git stash pop, or do you tell VC by doing C-x v v in the first case and nothing in the second case? -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! See stallman.org/skype.html. From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 22 Apr 2015 21:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: rms@gnu.org Cc: 20292@debbugs.gnu.org, dgutov@yandex.ru Reply-To: Eli Zaretskii Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.142973833716149 (code B ref 20292); Wed, 22 Apr 2015 21:33:02 +0000 Received: (at 20292) by debbugs.gnu.org; 22 Apr 2015 21:32:17 +0000 Received: from localhost ([127.0.0.1]:36839 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yl2Fl-0004CP-Fe for submit@debbugs.gnu.org; Wed, 22 Apr 2015 17:32:17 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:52624) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yl2Fi-0004CA-Sk for 20292@debbugs.gnu.org; Wed, 22 Apr 2015 17:32:16 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NN800A008U0J100@a-mtaout20.012.net.il> for 20292@debbugs.gnu.org; Thu, 23 Apr 2015 00:32:07 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NN800A4195IKC00@a-mtaout20.012.net.il>; Thu, 23 Apr 2015 00:32:07 +0300 (IDT) Date: Thu, 23 Apr 2015 00:32:06 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83fv7r3l49.fsf@gnu.org> References: <83fv88ta5r.fsf@gnu.org> <5532ADA3.5000006@yandex.ru> <834mod6xnm.fsf@gnu.org> <5532D397.8090602@yandex.ru> <83zj645gxu.fsf@gnu.org> <5533D7B8.7060508@yandex.ru> <83sibw59q1.fsf@gnu.org> <5533E816.2090208@yandex.ru> <83r3rg56zy.fsf@gnu.org> <5533EFE5.2050101@yandex.ru> <83oamk561p.fsf@gnu.org> <5533F446.4020400@yandex.ru> <83fv7u6epr.fsf@gnu.org> <838udm61ur.fsf@gnu.org> <5536FE56.406@yandex.ru> <83a8y04j6b.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Wed, 22 Apr 2015 15:59:46 -0400 > From: Richard Stallman > CC: dgutov@yandex.ru, 20292@debbugs.gnu.org, dgutov@yandex.ru > > > The one thing to remember is that after saving the file whose > > conflicts were resolved, you should type "C-x v v" to commit it in the > > first case, and do nothing in the second. > > Does VC determine automatically whether the conflict was due to merge > or due to git stash pop, > or do you tell VC by doing C-x v v in the first case and nothing > in the second case? It determines automatically. It has to, because what it does when you save the file already depends on that. When you type "C-x v v" after saving it, it's too late. From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 12 May 2015 23:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: esr@snark.thyrsus.com, monnier@iro.umontreal.ca, 20292@debbugs.gnu.org Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.14314724015515 (code B ref 20292); Tue, 12 May 2015 23:14:02 +0000 Received: (at 20292) by debbugs.gnu.org; 12 May 2015 23:13:21 +0000 Received: from localhost ([127.0.0.1]:42759 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YsJMX-0001Qt-8Q for submit@debbugs.gnu.org; Tue, 12 May 2015 19:13:21 -0400 Received: from mail-wg0-f49.google.com ([74.125.82.49]:35568) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YsJMV-0001Qc-0B for 20292@debbugs.gnu.org; Tue, 12 May 2015 19:13:19 -0400 Received: by wgnd10 with SMTP id d10so23592018wgn.2 for <20292@debbugs.gnu.org>; Tue, 12 May 2015 16:13:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=XMfW4/A075Gsvk2sssNds4o+uJns8dXYxqYxtLyzUcU=; b=P2VZyHHj6S4CqTo6/9axi4xG0ceSFmZHydCyD/gyGFbjRRZDs85SQQveGDCUF4b8jy rvtUairA/180DRnHXaIa4u+RlLJF0v4YlA0gOu/qHNNNL8LT+amQ/swA0UxraSfIXEth eNwM9pil4dCK4dV/BXf8rjciA5yIgrOpSV9xsd5cj435IeRdGDpWBl5mQPpEfoyi+kVF sWrt+dDzUPBnJvGIxNZgIzAnvubdF/cJ1subpxc1klcMXhIZxV2TiUIjFeHlK/4mHhqv lYFq35T8iQPBImjyoG5+mnP81K8X1kCHWpYRTcL82RvE5PtNjhjxmSlvTSLHNiLjdDAc oiCQ== X-Received: by 10.194.184.202 with SMTP id ew10mr34953755wjc.23.1431472393461; Tue, 12 May 2015 16:13:13 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id qs2sm2553031wjc.31.2015.05.12.16.13.12 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 May 2015 16:13:13 -0700 (PDT) References: <83fv88ta5r.fsf@gnu.org> <5532ADA3.5000006@yandex.ru> <834mod6xnm.fsf@gnu.org> <5532D397.8090602@yandex.ru> <83zj645gxu.fsf@gnu.org> <5533D7B8.7060508@yandex.ru> <83sibw59q1.fsf@gnu.org> <5533E816.2090208@yandex.ru> <83r3rg56zy.fsf@gnu.org> <5533EFE5.2050101@yandex.ru> <83oamk561p.fsf@gnu.org> <5533F446.4020400@yandex.ru> <83fv7u6epr.fsf@gnu.org> <838udm61ur.fsf@gnu.org> <5536FE56.406@yandex.ru> <83egnc4nu5.fsf@gnu.org> From: Dmitry Gutov Message-ID: <55528906.7060606@yandex.ru> Date: Wed, 13 May 2015 02:13:10 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 MIME-Version: 1.0 In-Reply-To: <83egnc4nu5.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Bad news, everyone! When a stash contains changes for several files, and "stash pop" encounters conflicts only in some of them, the rest of the files are stages automatically. At least, that happens with Git 2.1.0 on my machine, and some commenters here: http://stackoverflow.com/a/1237337/615245 So then when we unstage the files which had conflicts after resolving those, the result is mixed. Which doesn't look right. What shall we do? Unstage the automatically-staged files? Revert the changes from this bug? It seems Git really wants the changes staged after the conflict resolution. From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 13 May 2015 13:05:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: esr@snark.thyrsus.com, Eli Zaretskii , 20292@debbugs.gnu.org Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.143152226721808 (code B ref 20292); Wed, 13 May 2015 13:05:02 +0000 Received: (at 20292) by debbugs.gnu.org; 13 May 2015 13:04:27 +0000 Received: from localhost ([127.0.0.1]:43221 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YsWKo-0005ff-Dc for submit@debbugs.gnu.org; Wed, 13 May 2015 09:04:26 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:4372) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YsWKl-0005fR-8w for 20292@debbugs.gnu.org; Wed, 13 May 2015 09:04:24 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAGvvdVRFpYts/2dsb2JhbAA3gVOhb4EIgXUBAQQBVh4FBQsLDiYHCxQYDSQuh2WiEYxkCQECAQKDPgMOBAqDVASjY4RY X-IPAS-Result: AgYFAGvvdVRFpYts/2dsb2JhbAA3gVOhb4EIgXUBAQQBVh4FBQsLDiYHCxQYDSQuh2WiEYxkCQECAQKDPgMOBAqDVASjY4RY X-IronPort-AV: E=Sophos;i="5.11,557,1422939600"; d="scan'208";a="119541894" Received: from 69-165-139-108.dsl.teksavvy.com (HELO ceviche.home) ([69.165.139.108]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 May 2015 09:04:16 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 60BC766132; Wed, 13 May 2015 09:04:16 -0400 (EDT) From: Stefan Monnier Message-ID: References: <83fv88ta5r.fsf@gnu.org> <5532ADA3.5000006@yandex.ru> <834mod6xnm.fsf@gnu.org> <5532D397.8090602@yandex.ru> <83zj645gxu.fsf@gnu.org> <5533D7B8.7060508@yandex.ru> <83sibw59q1.fsf@gnu.org> <5533E816.2090208@yandex.ru> <83r3rg56zy.fsf@gnu.org> <5533EFE5.2050101@yandex.ru> <83oamk561p.fsf@gnu.org> <5533F446.4020400@yandex.ru> <83fv7u6epr.fsf@gnu.org> <838udm61ur.fsf@gnu.org> <5536FE56.406@yandex.ru> <83egnc4nu5.fsf@gnu.org> <55528906.7060606@yandex.ru> Date: Wed, 13 May 2015 09:04:16 -0400 In-Reply-To: <55528906.7060606@yandex.ru> (Dmitry Gutov's message of "Wed, 13 May 2015 02:13:10 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > What shall we do? Unstage the automatically-staged files? Revert the changes > from this bug? It seems Git really wants the changes staged after the > conflict resolution. IOW, the "resolve" step should always just use "git add", like we used to do. Yes, I think it's the right solution. Stefan From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 13 May 2015 16:20:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: esr@snark.thyrsus.com, monnier@iro.umontreal.ca, 20292@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.143153395917009 (code B ref 20292); Wed, 13 May 2015 16:20:05 +0000 Received: (at 20292) by debbugs.gnu.org; 13 May 2015 16:19:19 +0000 Received: from localhost ([127.0.0.1]:43973 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YsZNO-0004QF-6m for submit@debbugs.gnu.org; Wed, 13 May 2015 12:19:18 -0400 Received: from mtaout24.012.net.il ([80.179.55.180]:56506) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YsZNK-0004Pg-RB for 20292@debbugs.gnu.org; Wed, 13 May 2015 12:19:16 -0400 Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NOA00K00PZPI300@mtaout24.012.net.il> for 20292@debbugs.gnu.org; Wed, 13 May 2015 19:10:21 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NOA00IJTQ953G30@mtaout24.012.net.il>; Wed, 13 May 2015 19:10:21 +0300 (IDT) Date: Wed, 13 May 2015 19:18:57 +0300 From: Eli Zaretskii In-reply-to: <55528906.7060606@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <83zj58jvri.fsf@gnu.org> References: <83fv88ta5r.fsf@gnu.org> <5532ADA3.5000006@yandex.ru> <834mod6xnm.fsf@gnu.org> <5532D397.8090602@yandex.ru> <83zj645gxu.fsf@gnu.org> <5533D7B8.7060508@yandex.ru> <83sibw59q1.fsf@gnu.org> <5533E816.2090208@yandex.ru> <83r3rg56zy.fsf@gnu.org> <5533EFE5.2050101@yandex.ru> <83oamk561p.fsf@gnu.org> <5533F446.4020400@yandex.ru> <83fv7u6epr.fsf@gnu.org> <838udm61ur.fsf@gnu.org> <5536FE56.406@yandex.ru> <83egnc4nu5.fsf@gnu.org> <55528906.7060606@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Cc: monnier@iro.umontreal.ca, esr@snark.thyrsus.com, 20292@debbugs.gnu.org > From: Dmitry Gutov > Date: Wed, 13 May 2015 02:13:10 +0300 > > When a stash contains changes for several files, and "stash pop" encounters conflicts only in some of them, the rest of the files are stages automatically. > > At least, that happens with Git 2.1.0 on my machine I see this with 1.9.5 as well. > What shall we do? Report a bug in Git, I think. It doesn't make sense to have the outcome of "stash pop" wrt the index/staging depend on whether there were conflicts or not, which is what happening here: if I "stash pop" after pulling when none of my local stashed changes are in conflict with the pulled/merged content, I get back modified and unstaged files. Why would the existence of conflicts during "stash pop" produce any different effect for files _without_ conflicts, except by some obscure bug? > Unstage the automatically-staged files? If we can do that, yes. But how do we know which files to unstage? > Revert the changes from this bug? No! That'd be a step back. The current treatment of stashed changes is better than it was before the change. Also note that conflicts like this are quite rare, so the way vc-git worked previously was wrong in 99% of cases, why the one we have now is wrong in perhaps 0.1%. > It seems Git really wants the changes staged after the conflict resolution. It seems to me we've uncovered a bug in Git (gasp!). Git has no reasons to want the changes staged, certainly not depending on whether there were conflicts. From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 13 May 2015 16:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: esr@snark.thyrsus.com, 20292@debbugs.gnu.org, dgutov@yandex.ru Reply-To: Eli Zaretskii Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.143153405517358 (code B ref 20292); Wed, 13 May 2015 16:21:02 +0000 Received: (at 20292) by debbugs.gnu.org; 13 May 2015 16:20:55 +0000 Received: from localhost ([127.0.0.1]:43977 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YsZOv-0004Vr-Vl for submit@debbugs.gnu.org; Wed, 13 May 2015 12:20:54 -0400 Received: from mtaout25.012.net.il ([80.179.55.181]:39557) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YsZOt-0004VK-3K for 20292@debbugs.gnu.org; Wed, 13 May 2015 12:20:51 -0400 Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NOA00L00QD71E00@mtaout25.012.net.il> for 20292@debbugs.gnu.org; Wed, 13 May 2015 19:16:31 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NOA00KOYQJJDJ10@mtaout25.012.net.il>; Wed, 13 May 2015 19:16:31 +0300 (IDT) Date: Wed, 13 May 2015 19:20:39 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83y4ksjvoo.fsf@gnu.org> References: <83fv88ta5r.fsf@gnu.org> <5532ADA3.5000006@yandex.ru> <834mod6xnm.fsf@gnu.org> <5532D397.8090602@yandex.ru> <83zj645gxu.fsf@gnu.org> <5533D7B8.7060508@yandex.ru> <83sibw59q1.fsf@gnu.org> <5533E816.2090208@yandex.ru> <83r3rg56zy.fsf@gnu.org> <5533EFE5.2050101@yandex.ru> <83oamk561p.fsf@gnu.org> <5533F446.4020400@yandex.ru> <83fv7u6epr.fsf@gnu.org> <838udm61ur.fsf@gnu.org> <5536FE56.406@yandex.ru> <83egnc4nu5.fsf@gnu.org> <55528906.7060606@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Stefan Monnier > Cc: Eli Zaretskii , esr@snark.thyrsus.com, 20292@debbugs.gnu.org > Date: Wed, 13 May 2015 09:04:16 -0400 > > > What shall we do? Unstage the automatically-staged files? Revert the changes > > from this bug? It seems Git really wants the changes staged after the > > conflict resolution. > > IOW, the "resolve" step should always just use "git add", like we used > to do. How is that TRT when the original state was that there were uncommitted and unstaged changes? Running "git add" would confuse people who are not very knowledgeable about the index. If they _are_ knowledgeable, they'll "git reset" right away anyway. So please don't go back. From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 May 2015 01:25:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: esr@snark.thyrsus.com, monnier@iro.umontreal.ca, 20292@debbugs.gnu.org Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.14315666646479 (code B ref 20292); Thu, 14 May 2015 01:25:03 +0000 Received: (at 20292) by debbugs.gnu.org; 14 May 2015 01:24:24 +0000 Received: from localhost ([127.0.0.1]:44211 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yshst-0001gQ-TY for submit@debbugs.gnu.org; Wed, 13 May 2015 21:24:24 -0400 Received: from mail-wi0-f170.google.com ([209.85.212.170]:34705) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yshsq-0001fw-M8 for 20292@debbugs.gnu.org; Wed, 13 May 2015 21:24:21 -0400 Received: by wicmc15 with SMTP id mc15so4043251wic.1 for <20292@debbugs.gnu.org>; Wed, 13 May 2015 18:24:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=slcXO5kM5JGLXtp7f8Jp5vczP5YEbPzNQabOMEuxYZg=; b=NCfTQ4hLbSQw9UsPsA6N/N7mmoOz1V2MNUpr7XzdluHXSFnw+ro6sloMusrRECvKjs avsteY/1dImvmD15zJZ9fkN+wGYee1dakX8v+b4yW19ymJi1HKf76MmPZv9yXdAG8b00 jswXaAK1lQtLMtcFBGak7bERAqwRFxIMhvIEALGYiYoOM1F0BrJbfH4xNlnnxp7cGtr8 GiOVxkLd+ggioqJWYzBP+7/DrLdvSZCYRMt2IJRGVk1vBdeg316fM0bAJDVT6B0KDNrs eI8831A7+nbzXIH/Qsn1CgLFG5jbNeOGzzTdHMblCC0dB/FXZH/HUAaUkjYLfrAF71Qd u+yg== X-Received: by 10.180.93.36 with SMTP id cr4mr18781675wib.61.1431566654841; Wed, 13 May 2015 18:24:14 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id nb9sm10699874wic.10.2015.05.13.18.24.14 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 May 2015 18:24:14 -0700 (PDT) References: <83fv88ta5r.fsf@gnu.org> <5532ADA3.5000006@yandex.ru> <834mod6xnm.fsf@gnu.org> <5532D397.8090602@yandex.ru> <83zj645gxu.fsf@gnu.org> <5533D7B8.7060508@yandex.ru> <83sibw59q1.fsf@gnu.org> <5533E816.2090208@yandex.ru> <83r3rg56zy.fsf@gnu.org> <5533EFE5.2050101@yandex.ru> <83oamk561p.fsf@gnu.org> <5533F446.4020400@yandex.ru> <83fv7u6epr.fsf@gnu.org> <838udm61ur.fsf@gnu.org> <5536FE56.406@yandex.ru> <83egnc4nu5.fsf@gnu.org> <55528906.7060606@yandex.ru> <83zj58jvri.fsf@gnu.org> From: Dmitry Gutov Message-ID: <5553F93C.9010205@yandex.ru> Date: Thu, 14 May 2015 04:24:12 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 MIME-Version: 1.0 In-Reply-To: <83zj58jvri.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 05/13/2015 07:18 PM, Eli Zaretskii wrote: > Report a bug in Git, I think. I believe it's your turn to report a Git bug now. ;) Still, even if it's fixed, we'll have a lot of users, for years to come, that use Git without that fix. Note how you and I are using quite different versions, and the latest release is 2.4.1. > It doesn't make sense to have the > outcome of "stash pop" wrt the index/staging depend on whether there > were conflicts or not, which is what happening here: if I "stash pop" > after pulling when none of my local stashed changes are in conflict > with the pulled/merged content, I get back modified and unstaged > files. Why would the existence of conflicts during "stash pop" > produce any different effect for files _without_ conflicts, except by > some obscure bug? As a wild guess, maybe the files that get staged automatically are the result of automatic conflict resolution (there was some divergence, but it was resolved automatically; maybe the "no divergence" case is also treated like this, for simplicity). IOW, the "worse is better" kind of reasons. >> Unstage the automatically-staged files? > > If we can do that, yes. But how do we know which files to unstage? That the the difficulty: right after applying the stash we could know (all of them!), but Emacs can't know whether the user staged anything else between then and now (when all conflicts have been resolved). IOW, the user is better positioned to call 'git reset'. > No! That'd be a step back. The current treatment of stashed changes > is better than it was before the change. Also note that conflicts > like this are quite rare, so the way vc-git worked previously was > wrong in 99% of cases, why the one we have now is wrong in perhaps > 0.1%. I don't know where you got the percentages. My stashes routinely touch multiple files, and it's easy to imagine how not all of them could have conflicts after applying. The odds are hard to calculate, but the probability really must be in tens of percents, not below one. The current behavior is bad because it looks random. It would look especially random to someone who's used to interact with Git via command-line. > It seems to me we've uncovered a bug in Git (gasp!). Git has no > reasons to want the changes staged, certainly not depending on whether > there were conflicts. Staging changes is the Git way to mark conflict as resolved. Ergo, it expects the conflicting files to be staged after the user resolves the conflicts. Then it won't make a lot of sense to leave the rest of the files unstaged, would it? Maybe that's the reasoning. It's hard for me to tell without knowing exactly why Git conflates conflict resolution and staging. From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 May 2015 03:50:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: esr@snark.thyrsus.com, 20292@debbugs.gnu.org, Dmitry Gutov Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.14315753748595 (code B ref 20292); Thu, 14 May 2015 03:50:04 +0000 Received: (at 20292) by debbugs.gnu.org; 14 May 2015 03:49:34 +0000 Received: from localhost ([127.0.0.1]:44235 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ysk9N-0002EZ-KW for submit@debbugs.gnu.org; Wed, 13 May 2015 23:49:33 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:48560) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ysk9L-0002EA-NV for 20292@debbugs.gnu.org; Wed, 13 May 2015 23:49:32 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAGvvdVRFpYts/2dsb2JhbAA3gVOhb4EIgXUBAQQBVh4FBQsLNAcLFBgNJIgTohGLe2kJAQIBAoM+Aw4ECoNUBKNjhFg X-IPAS-Result: AgUFAGvvdVRFpYts/2dsb2JhbAA3gVOhb4EIgXUBAQQBVh4FBQsLNAcLFBgNJIgTohGLe2kJAQIBAoM+Aw4ECoNUBKNjhFg X-IronPort-AV: E=Sophos;i="5.11,557,1422939600"; d="scan'208";a="119695862" Received: from 69-165-139-108.dsl.teksavvy.com (HELO ceviche.home) ([69.165.139.108]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 May 2015 23:49:26 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 8CC0966092; Wed, 13 May 2015 23:49:25 -0400 (EDT) From: Stefan Monnier Message-ID: References: <83fv88ta5r.fsf@gnu.org> <5532ADA3.5000006@yandex.ru> <834mod6xnm.fsf@gnu.org> <5532D397.8090602@yandex.ru> <83zj645gxu.fsf@gnu.org> <5533D7B8.7060508@yandex.ru> <83sibw59q1.fsf@gnu.org> <5533E816.2090208@yandex.ru> <83r3rg56zy.fsf@gnu.org> <5533EFE5.2050101@yandex.ru> <83oamk561p.fsf@gnu.org> <5533F446.4020400@yandex.ru> <83fv7u6epr.fsf@gnu.org> <838udm61ur.fsf@gnu.org> <5536FE56.406@yandex.ru> <83egnc4nu5.fsf@gnu.org> <55528906.7060606@yandex.ru> <83zj58jvri.fsf@gnu.org> Date: Wed, 13 May 2015 23:49:25 -0400 In-Reply-To: <83zj58jvri.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 13 May 2015 19:18:57 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > is better than it was before the change. Also note that conflicts > like this are quite rare, It's about 99.9% of my "unstash-caused conflicts", so "rare" obviously depends on how you use Git. Stefan From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 May 2015 14:54:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: esr@snark.thyrsus.com, monnier@iro.umontreal.ca, 20292@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.143161520725410 (code B ref 20292); Thu, 14 May 2015 14:54:01 +0000 Received: (at 20292) by debbugs.gnu.org; 14 May 2015 14:53:27 +0000 Received: from localhost ([127.0.0.1]:45139 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YsuVp-0006be-Sm for submit@debbugs.gnu.org; Thu, 14 May 2015 10:53:27 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:36581) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YsuVm-0006bF-BG for 20292@debbugs.gnu.org; Thu, 14 May 2015 10:53:23 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NOC00L00H5X6S00@a-mtaout20.012.net.il> for 20292@debbugs.gnu.org; Thu, 14 May 2015 17:53:15 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NOC00LLYHCQ6O10@a-mtaout20.012.net.il>; Thu, 14 May 2015 17:53:15 +0300 (IDT) Date: Thu, 14 May 2015 17:53:12 +0300 From: Eli Zaretskii In-reply-to: <5553F93C.9010205@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <83617vjjmv.fsf@gnu.org> References: <83fv88ta5r.fsf@gnu.org> <5532ADA3.5000006@yandex.ru> <834mod6xnm.fsf@gnu.org> <5532D397.8090602@yandex.ru> <83zj645gxu.fsf@gnu.org> <5533D7B8.7060508@yandex.ru> <83sibw59q1.fsf@gnu.org> <5533E816.2090208@yandex.ru> <83r3rg56zy.fsf@gnu.org> <5533EFE5.2050101@yandex.ru> <83oamk561p.fsf@gnu.org> <5533F446.4020400@yandex.ru> <83fv7u6epr.fsf@gnu.org> <838udm61ur.fsf@gnu.org> <5536FE56.406@yandex.ru> <83egnc4nu5.fsf@gnu.org> <55528906.7060606@yandex.ru> <83zj58jvri.fsf@gnu.org> <5553F93C.9010205@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Cc: monnier@iro.umontreal.ca, esr@snark.thyrsus.com, 20292@debbugs.gnu.org > From: Dmitry Gutov > Date: Thu, 14 May 2015 04:24:12 +0300 > > Report a bug in Git, I think. > > I believe it's your turn to report a Git bug now. ;) So we do turns on this? > Still, even if it's fixed, we'll have a lot of users, for years to come, that use Git without that fix. Note how you and I are using quite different versions, and the latest release is 2.4.1. I only have an old version because there's no newer one for Windows, and I can't be bothered enough to build my own. Anyway, the fact that it takes a long time for a fix to percolate shouldn't preclude us from reporting it. > > It doesn't make sense to have the > > outcome of "stash pop" wrt the index/staging depend on whether there > > were conflicts or not, which is what happening here: if I "stash pop" > > after pulling when none of my local stashed changes are in conflict > > with the pulled/merged content, I get back modified and unstaged > > files. Why would the existence of conflicts during "stash pop" > > produce any different effect for files _without_ conflicts, except by > > some obscure bug? > > As a wild guess, maybe the files that get staged automatically are the result of automatic conflict resolution (there was some divergence, but it was resolved automatically; maybe the "no divergence" case is also treated like this, for simplicity). IOW, the "worse is better" kind of reasons. No, I reproduced this when some of the stashed files were not changed at all upstream, i.e. there shouldn't have been a need for any conflict resolution, automatic or otherwise, in those files. _My_ wild guess is that Git simply invokes the same code as is used in a "normal" merge, and that one stages files that are without conflicts. > Unstage the automatically-staged files? > > If we can do that, yes. But how do we know which files to unstage? > > That the the difficulty: right after applying the stash we could know (all of them!), but Emacs can't know whether the user staged anything else between then and now (when all conflicts have been resolved). IOW, the user is better positioned to call 'git reset'. The user is always better positioned, but we'd like VC to DTRT in the more popular situations where the user could be saved from the nuisance of figuring things out and typing shell commands. That's the main goal of VC, isn't it? If we know all the stashed files, how about invoking "git reset" for all of them? It cannot hurt, can it? > No! That'd be a step back. The current treatment of stashed changes > is better than it was before the change. Also note that conflicts > like this are quite rare, so the way vc-git worked previously was > wrong in 99% of cases, why the one we have now is wrong in perhaps > 0.1%. > > I don't know where you got the percentages. My stashes routinely touch multiple files, and it's easy to imagine how not all of them could have conflicts after applying. I'm talking about conflicts, not about the number of files. How many times did you have conflicts in "stash pop"? I almost never have them. > The odds are hard to calculate, but the probability really must be in tens of percents, not below one. Now I wonder where did _you_ get your percentages. > The current behavior is bad because it looks random. I agree it's bad, but only if (a) there are multiple changed files, and (b) some, but not all, of them have conflicts. Otherwise, the behavior is correct. By contrast, the previous behavior was always wrong. > It seems to me we've uncovered a bug in Git (gasp!). Git has no > reasons to want the changes staged, certainly not depending on whether > there were conflicts. > > Staging changes is the Git way to mark conflict as resolved. Not for uncommitted changes that were stashed, it ain't. For "normal" merge conflicts, yes, because a conflict-free merge would have committed the changes, so staging is a step in the right direction. But for conflicts in stashed uncommitted changes, it's a step in the wrong direction, especially in files that didn't have conflicts at all. > Ergo, it expects the conflicting files to be staged after the user resolves the conflicts. Then it won't make a lot of sense to leave the rest of the files unstaged, would it? Maybe that's the reasoning. It's a flawed reasoning, IMO. I stashed the changes because they are not yet ready to be committed, and I wanted them out of my way for a while. When I pop the stash, I want them uncommitted as they were before. Having them staged means that I might inadvertently commit them with my next "git commit", something that wasn't supposed to happen before the stash. > It's hard for me to tell without knowing exactly why Git conflates conflict resolution and staging. It's a bug. From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 May 2015 14:55:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: esr@snark.thyrsus.com, 20292@debbugs.gnu.org, dgutov@yandex.ru Reply-To: Eli Zaretskii Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.143161525825559 (code B ref 20292); Thu, 14 May 2015 14:55:01 +0000 Received: (at 20292) by debbugs.gnu.org; 14 May 2015 14:54:18 +0000 Received: from localhost ([127.0.0.1]:45143 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YsuWf-0006eA-OV for submit@debbugs.gnu.org; Thu, 14 May 2015 10:54:18 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:44518) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YsuWd-0006dp-Rm for 20292@debbugs.gnu.org; Thu, 14 May 2015 10:54:16 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NOC00000H6Q8H00@a-mtaout22.012.net.il> for 20292@debbugs.gnu.org; Thu, 14 May 2015 17:53:47 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NOC00NRNHDN5370@a-mtaout22.012.net.il>; Thu, 14 May 2015 17:53:47 +0300 (IDT) Date: Thu, 14 May 2015 17:53:44 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <834mnfjjlz.fsf@gnu.org> References: <83fv88ta5r.fsf@gnu.org> <5532ADA3.5000006@yandex.ru> <834mod6xnm.fsf@gnu.org> <5532D397.8090602@yandex.ru> <83zj645gxu.fsf@gnu.org> <5533D7B8.7060508@yandex.ru> <83sibw59q1.fsf@gnu.org> <5533E816.2090208@yandex.ru> <83r3rg56zy.fsf@gnu.org> <5533EFE5.2050101@yandex.ru> <83oamk561p.fsf@gnu.org> <5533F446.4020400@yandex.ru> <83fv7u6epr.fsf@gnu.org> <838udm61ur.fsf@gnu.org> <5536FE56.406@yandex.ru> <83egnc4nu5.fsf@gnu.org> <55528906.7060606@yandex.ru> <83zj58jvri.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Stefan Monnier > Cc: Dmitry Gutov , esr@snark.thyrsus.com, 20292@debbugs.gnu.org > Date: Wed, 13 May 2015 23:49:25 -0400 > > > is better than it was before the change. Also note that conflicts > > like this are quite rare, > > It's about 99.9% of my "unstash-caused conflicts", so "rare" obviously > depends on how you use Git. Indeed. May I ask why you have uncommitted changes when you pull (or do whatever else requires to stash them)? Why don't you commit them or move them to a branch, or work on a branch to begin with? From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 May 2015 15:52:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: esr@snark.thyrsus.com, 20292@debbugs.gnu.org, dgutov@yandex.ru Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.14316187138269 (code B ref 20292); Thu, 14 May 2015 15:52:01 +0000 Received: (at 20292) by debbugs.gnu.org; 14 May 2015 15:51:53 +0000 Received: from localhost ([127.0.0.1]:45240 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YsvQN-00029H-Vb for submit@debbugs.gnu.org; Thu, 14 May 2015 11:51:52 -0400 Received: from mercure.iro.umontreal.ca ([132.204.24.67]:56550) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YsvQM-000296-31 for 20292@debbugs.gnu.org; Thu, 14 May 2015 11:51:50 -0400 Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id C584585E8D; Thu, 14 May 2015 11:51:48 -0400 (EDT) Received: from lechon.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id 377A71E5B8D; Thu, 14 May 2015 11:51:24 -0400 (EDT) Received: by lechon.iro.umontreal.ca (Postfix, from userid 20848) id 17AD2B41A0; Thu, 14 May 2015 11:51:24 -0400 (EDT) From: Stefan Monnier Message-ID: References: <83fv88ta5r.fsf@gnu.org> <5532D397.8090602@yandex.ru> <83zj645gxu.fsf@gnu.org> <5533D7B8.7060508@yandex.ru> <83sibw59q1.fsf@gnu.org> <5533E816.2090208@yandex.ru> <83r3rg56zy.fsf@gnu.org> <5533EFE5.2050101@yandex.ru> <83oamk561p.fsf@gnu.org> <5533F446.4020400@yandex.ru> <83fv7u6epr.fsf@gnu.org> <838udm61ur.fsf@gnu.org> <5536FE56.406@yandex.ru> <83egnc4nu5.fsf@gnu.org> <55528906.7060606@yandex.ru> <83zj58jvri.fsf@gnu.org> <834mnfjjlz.fsf@gnu.org> Date: Thu, 14 May 2015 11:51:24 -0400 In-Reply-To: <834mnfjjlz.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 14 May 2015 17:53:44 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-2.82, requis 5, autolearn=not spam, ALL_TRUSTED -2.82, MC_TSTLAST 0.00) X-DIRO-MailScanner-From: monnier@iro.umontreal.ca X-Spam-Status: No X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > May I ask why you have uncommitted changes when you pull (or do > whatever else requires to stash them)? Typical case: - before committing, I do a final "pull". - the "pull" fails, so I have to stash/pull/unstash - the commit touches several files and has a conflict somewhere. > Why don't you commit them or move them to a branch, or work on > a branch to begin with? Old habits die hard, Stefan From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 May 2015 17:31:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier , Eli Zaretskii Cc: esr@snark.thyrsus.com, 20292@debbugs.gnu.org Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.143162463926842 (code B ref 20292); Thu, 14 May 2015 17:31:03 +0000 Received: (at 20292) by debbugs.gnu.org; 14 May 2015 17:30:39 +0000 Received: from localhost ([127.0.0.1]:45315 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yswxy-0006yr-Fx for submit@debbugs.gnu.org; Thu, 14 May 2015 13:30:39 -0400 Received: from mail-wg0-f51.google.com ([74.125.82.51]:33876) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yswxu-0006yY-NE for 20292@debbugs.gnu.org; Thu, 14 May 2015 13:30:35 -0400 Received: by wguv19 with SMTP id v19so20832462wgu.1 for <20292@debbugs.gnu.org>; Thu, 14 May 2015 10:30:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=dxzdvlzAiYOttNrPs2o/s6Tqfv7HYFf4hYu7hclg1L0=; b=aYn9GAZZnvDHzApIrNCEtHhTc3UwnvlOBgXL8zBExfej40cvjU0xoAfS9OgKg/41TY 9rALjCib2LuF7OkcFDDTncMZ6HYgZAWIvfbdfOYz8Xe4SBMUP2O+5eDmRY6o1wj+ATw1 hJmZAiPHp4dvpxJ1Al1X4G/Vw70j7T7Peoq8FktWak8yb8uZ06A1YzxTLwJmdbqr/rZu XP4+tX1whpGk9oMG3eCRLweWa0LS0TAUKGz9bgpGUCjNCskkheGgZRZcWgUQQL+Zp+So revIhuOgIeAEXn6+LvULGTPH78k+k7NC2Od1HrWLduR3vHtnCFqUqDTIndTRiIRK4sXW aDBw== X-Received: by 10.194.109.229 with SMTP id hv5mr10484470wjb.119.1431624628845; Thu, 14 May 2015 10:30:28 -0700 (PDT) Received: from [192.168.0.185] (static-nbl2-118.cytanet.com.cy. [212.31.107.118]) by mx.google.com with ESMTPSA id gt10sm10722826wib.20.2015.05.14.10.30.27 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 May 2015 10:30:28 -0700 (PDT) References: <83fv88ta5r.fsf@gnu.org> <5532D397.8090602@yandex.ru> <83zj645gxu.fsf@gnu.org> <5533D7B8.7060508@yandex.ru> <83sibw59q1.fsf@gnu.org> <5533E816.2090208@yandex.ru> <83r3rg56zy.fsf@gnu.org> <5533EFE5.2050101@yandex.ru> <83oamk561p.fsf@gnu.org> <5533F446.4020400@yandex.ru> <83fv7u6epr.fsf@gnu.org> <838udm61ur.fsf@gnu.org> <5536FE56.406@yandex.ru> <83egnc4nu5.fsf@gnu.org> <55528906.7060606@yandex.ru> <83zj58jvri.fsf@gnu.org> <834mnfjjlz.fsf@gnu.org> From: Dmitry Gutov Message-ID: <5554DBB2.3070005@yandex.ru> Date: Thu, 14 May 2015 20:30:26 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 05/14/2015 06:51 PM, Stefan Monnier wrote: >> May I ask why you have uncommitted changes when you pull (or do >> whatever else requires to stash them)? My main use case: there are local changes in several configuration files, which I don't ever intend to commit. > Typical case: > - before committing, I do a final "pull". > - the "pull" fails, so I have to stash/pull/unstash > - the commit touches several files and has a conflict somewhere. To avoid this scenario, I usually commit, and then 'git pull --rebase', which we don't, and shouldn't, recommend. >> Why don't you commit them or move them to a branch, or work on >> a branch to begin with? I think it would be annoying to create a branch for every tiny change. From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 May 2015 18:01:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: esr@snark.thyrsus.com, 20292@debbugs.gnu.org Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.143162645030407 (code B ref 20292); Thu, 14 May 2015 18:01:03 +0000 Received: (at 20292) by debbugs.gnu.org; 14 May 2015 18:00:50 +0000 Received: from localhost ([127.0.0.1]:45329 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YsxRA-0007tm-61 for submit@debbugs.gnu.org; Thu, 14 May 2015 14:00:49 -0400 Received: from mail-wi0-f178.google.com ([209.85.212.178]:37893) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YsxR6-0007pw-3Z for 20292@debbugs.gnu.org; Thu, 14 May 2015 14:00:46 -0400 Received: by wicnf17 with SMTP id nf17so103806187wic.1 for <20292@debbugs.gnu.org>; Thu, 14 May 2015 11:00:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=Pv968FVmAOtkufQ5u98iMD37liqrI25qNC1l8A6BjB0=; b=t3C5EFNcnODobOZIBKzx7dY0a2SaSKeY9pPlZCIiYVlGBxn0ncULjIOaGgn+Ik3aho r/gQjer31huMy+2FFIq4tJpUdjjUhlCd+iQnVUEdQttZvKO2mvPxFxpsOjy4E5mjm4sF Zl15bgAI6UEymQ4xwQROrBasCg1q7Xyur0YNRZp08WO/d1DiLeusPCAM1Wa+Ol3GGPMX AkFQBQpcWfEmLwct+XatPRYgJGOHuLIuM2nM8ZH5o6aQMSq6zOhoCXxanalGcss/R2CK LlqgmyHSBRm0/M9xmKUgzU+Rm5HvRqjQgrXSlJJr9w56O7KJ1/5uxIpZvOdqf5zsNtZZ lW4w== X-Received: by 10.195.11.202 with SMTP id ek10mr10378563wjd.12.1431626438155; Thu, 14 May 2015 11:00:38 -0700 (PDT) Received: from [192.168.0.185] (static-nbl2-118.cytanet.com.cy. [212.31.107.118]) by mx.google.com with ESMTPSA id um5sm39273833wjc.1.2015.05.14.11.00.37 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 May 2015 11:00:38 -0700 (PDT) References: <83fv88ta5r.fsf@gnu.org> <5532ADA3.5000006@yandex.ru> <834mod6xnm.fsf@gnu.org> <5532D397.8090602@yandex.ru> <83zj645gxu.fsf@gnu.org> <5533D7B8.7060508@yandex.ru> <83sibw59q1.fsf@gnu.org> <5533E816.2090208@yandex.ru> <83r3rg56zy.fsf@gnu.org> <5533EFE5.2050101@yandex.ru> <83oamk561p.fsf@gnu.org> <5533F446.4020400@yandex.ru> <83fv7u6epr.fsf@gnu.org> <838udm61ur.fsf@gnu.org> <5536FE56.406@yandex.ru> <83egnc4nu5.fsf@gnu.org> <55528906.7060606@yandex.ru> <83zj58jvri.fsf@gnu.org> <5553F93C.9010205@yandex.ru> <83617vjjmv.fsf@gnu.org> From: Dmitry Gutov Message-ID: <5554E2C4.7040209@yandex.ru> Date: Thu, 14 May 2015 21:00:36 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 MIME-Version: 1.0 In-Reply-To: <83617vjjmv.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 05/14/2015 05:53 PM, Eli Zaretskii wrote: > So we do turns on this? Why not? You seem to have a better idea why this behavior is necessarily a bug. > I only have an old version because there's no newer one for Windows, > and I can't be bothered enough to build my own. Then it'll even more likely that a lot of users will be on the "old version". > Anyway, the fact that it takes a long time for a fix to percolate > shouldn't preclude us from reporting it. Hopefully, if and when there's a fix, Emacs's behavior won't have to change much. But if Git grows a different "resolve a conflict" workflow, we'll try to honor it. > No, I reproduced this when some of the stashed files were not changed > at all upstream, i.e. there shouldn't have been a need for any > conflict resolution, automatic or otherwise, in those files. Then the guess from the end of the message you're replying to, might be closer to the truth. > _My_ wild guess is that Git simply invokes the same code as is used in > a "normal" merge, and that one stages files that are without conflicts. Right, or that. > The user is always better positioned, but we'd like VC to DTRT in the > more popular situations where the user could be saved from the > nuisance of figuring things out and typing shell commands. That's the > main goal of VC, isn't it? If we can do that without introducing inconsistencies, losing information, or surprising a lot of users. > If we know all the stashed files, how about invoking "git reset" for > all of them? It cannot hurt, can it? How will we know it? Emacs could try to list all staged files, but there's no good way to know that they all belong to the applied stash (looking at the top stash isn't reliable either: the user might have specified a different one explicitly). > I'm talking about conflicts, not about the number of files. How many > times did you have conflicts in "stash pop"? Often. But that's irrelevant: in all cases when we don't have a conflict when applying a stash, this bug does not apply. So we should be discussing the percentage of "conflict in only some of the files" out of "conflict when applying the stash" situations. >> The odds are hard to calculate, but the probability really must be in tens of percents, not below one. > > Now I wonder where did _you_ get your percentages. I'm simply basing it on the assumption that a stash likely touches multiple files (and that depends on the project/language/environment, so it could be frequently false in certain old-school "a few files, each of them huge" C projects). If the stash does touch several files, and there's a conflict, it's easy to imagine that the conflict would be only in some of them. > I agree it's bad, but only if (a) there are multiple changed files, > and (b) some, but not all, of them have conflicts. Which is a fairly common situation, like described above. > By contrast, the previous behavior was always > wrong. It was non-ideal, but apparently it was consistent with how a person usually works with Git. >> Staging changes is the Git way to mark conflict as resolved. > > Not for uncommitted changes that were stashed, it ain't. It is. Everywhere the documentation talks about resolving a conflict, the documented next step is 'git add'. Nowhere it talks about doing something else after resolving a stash conflict. I'd love to be proved wrong, though. > For "normal" > merge conflicts, yes, because a conflict-free merge would have > committed the changes, so staging is a step in the right direction. > But for conflicts in stashed uncommitted changes, it's a step in the > wrong direction, especially in files that didn't have conflicts at > all. Here you're talking about your own intention, not about the usual Git workflow. Yes, it might be suboptimal, but we might have to live with it anyway. > It's a flawed reasoning, IMO. I stashed the changes because they are > not yet ready to be committed, and I wanted them out of my way for a > while. When I pop the stash, I want them uncommitted as they were > before. Sure, that's why it's suboptimal. But apparently at some point a decision was made to handle "normal" merge conflicts and the stash conflicts in the same way. I may be wrong about this: the Git mailing list is a better place to ask. From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 May 2015 18:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: esr@snark.thyrsus.com, monnier@iro.umontreal.ca, 20292@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.14316285866008 (code B ref 20292); Thu, 14 May 2015 18:37:02 +0000 Received: (at 20292) by debbugs.gnu.org; 14 May 2015 18:36:26 +0000 Received: from localhost ([127.0.0.1]:45337 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ysxzd-0001Yp-BE for submit@debbugs.gnu.org; Thu, 14 May 2015 14:36:25 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:54756) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ysxza-0001Ya-1P for 20292@debbugs.gnu.org; Thu, 14 May 2015 14:36:23 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NOC00100RIYWJ00@a-mtaout22.012.net.il> for 20292@debbugs.gnu.org; Thu, 14 May 2015 21:36:15 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NOC001MCROEK290@a-mtaout22.012.net.il>; Thu, 14 May 2015 21:36:15 +0300 (IDT) Date: Thu, 14 May 2015 21:36:12 +0300 From: Eli Zaretskii In-reply-to: <5554DBB2.3070005@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <83mw17huqr.fsf@gnu.org> References: <83fv88ta5r.fsf@gnu.org> <5532D397.8090602@yandex.ru> <83zj645gxu.fsf@gnu.org> <5533D7B8.7060508@yandex.ru> <83sibw59q1.fsf@gnu.org> <5533E816.2090208@yandex.ru> <83r3rg56zy.fsf@gnu.org> <5533EFE5.2050101@yandex.ru> <83oamk561p.fsf@gnu.org> <5533F446.4020400@yandex.ru> <83fv7u6epr.fsf@gnu.org> <838udm61ur.fsf@gnu.org> <5536FE56.406@yandex.ru> <83egnc4nu5.fsf@gnu.org> <55528906.7060606@yandex.ru> <83zj58jvri.fsf@gnu.org> <834mnfjjlz.fsf@gnu.org> <5554DBB2.3070005@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Cc: esr@snark.thyrsus.com, 20292@debbugs.gnu.org > From: Dmitry Gutov > Date: Thu, 14 May 2015 20:30:26 +0300 > > On 05/14/2015 06:51 PM, Stefan Monnier wrote: > >> May I ask why you have uncommitted changes when you pull (or do > >> whatever else requires to stash them)? > > My main use case: there are local changes in several configuration > files, which I don't ever intend to commit. > > > Typical case: > > - before committing, I do a final "pull". > > - the "pull" fails, so I have to stash/pull/unstash > > - the commit touches several files and has a conflict somewhere. > > To avoid this scenario, I usually commit, and then 'git pull --rebase', > which we don't, and shouldn't, recommend. > > >> Why don't you commit them or move them to a branch, or work on > >> a branch to begin with? > > I think it would be annoying to create a branch for every tiny change. So: do we have a way of knowing which files had their changes stashed? Then we could call "git reset" on each one of them, after "stash pop". From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 May 2015 18:49:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: esr@snark.thyrsus.com, 20292@debbugs.gnu.org Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.14316293167176 (code B ref 20292); Thu, 14 May 2015 18:49:01 +0000 Received: (at 20292) by debbugs.gnu.org; 14 May 2015 18:48:36 +0000 Received: from localhost ([127.0.0.1]:45360 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YsyBP-0001rf-WE for submit@debbugs.gnu.org; Thu, 14 May 2015 14:48:36 -0400 Received: from mail-wi0-f173.google.com ([209.85.212.173]:35785) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YsyBN-0001rR-Gc for 20292@debbugs.gnu.org; Thu, 14 May 2015 14:48:34 -0400 Received: by wicmx19 with SMTP id mx19so28410120wic.0 for <20292@debbugs.gnu.org>; Thu, 14 May 2015 11:48:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=Yvq9LXICg2DD8TQ0klu8Q9qPqPOm7IMWKrKRDuz/JG0=; b=hKqWopLV43kg9Pz8TuNHP3LuzjZD00Z4SBgSoX/By+xJib3yAsLDchmMn7sarvz9iu coGCQshjs2dC2tVsHEx6F4gsebYX3rTuXbguDJK59Y5ggLiRYZLh7VXcOp2M6dLQLHzF 64t/i0v6wLIjemNtzjY2VWhAsTEpC91xvratpwvTH/vGG81tX0zWnwRnAGqHJ30wq8Gv aq4/yWieb2fAKvxcJk8fCe9+oylsalPQ0OI6dfcH+WPNoIKYijMo8DekDvhlZSUpg5xO n/rGeSmSf1LY8r8cAd+9A/zPyskopJsdjLTL6LrtIbZZiHinyzU9dCjfEWb4GThDNfDp 9rvw== X-Received: by 10.194.236.33 with SMTP id ur1mr9499321wjc.77.1431629307722; Thu, 14 May 2015 11:48:27 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id fa8sm14563182wib.14.2015.05.14.11.48.23 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 May 2015 11:48:23 -0700 (PDT) References: <83fv88ta5r.fsf@gnu.org> <5532D397.8090602@yandex.ru> <83zj645gxu.fsf@gnu.org> <5533D7B8.7060508@yandex.ru> <83sibw59q1.fsf@gnu.org> <5533E816.2090208@yandex.ru> <83r3rg56zy.fsf@gnu.org> <5533EFE5.2050101@yandex.ru> <83oamk561p.fsf@gnu.org> <5533F446.4020400@yandex.ru> <83fv7u6epr.fsf@gnu.org> <838udm61ur.fsf@gnu.org> <5536FE56.406@yandex.ru> <83egnc4nu5.fsf@gnu.org> <55528906.7060606@yandex.ru> <83zj58jvri.fsf@gnu.org> <834mnfjjlz.fsf@gnu.org> <5554DBB2.3070005@yandex.ru> <83mw17huqr.fsf@gnu.org> From: Dmitry Gutov Message-ID: <5554EDF5.5050606@yandex.ru> Date: Thu, 14 May 2015 21:48:21 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 MIME-Version: 1.0 In-Reply-To: <83mw17huqr.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 05/14/2015 09:36 PM, Eli Zaretskii wrote: > So: do we have a way of knowing which files had their changes stashed? I don't think so. Further, like I mentioned before, the user might have staged some further changes to those other, non-conflicting files. Do you apply stashes via the vc-dir interface? We could do something in that implementation. From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 May 2015 18:50:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: esr@snark.thyrsus.com, 20292@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.14316294037316 (code B ref 20292); Thu, 14 May 2015 18:50:05 +0000 Received: (at 20292) by debbugs.gnu.org; 14 May 2015 18:50:03 +0000 Received: from localhost ([127.0.0.1]:45364 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YsyCn-0001to-EN for submit@debbugs.gnu.org; Thu, 14 May 2015 14:50:02 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]:54772) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YsyCk-0001tX-FB for 20292@debbugs.gnu.org; Thu, 14 May 2015 14:49:59 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NOC00D00S3GEO00@a-mtaout21.012.net.il> for 20292@debbugs.gnu.org; Thu, 14 May 2015 21:49:52 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NOC00DGFSB3DB50@a-mtaout21.012.net.il>; Thu, 14 May 2015 21:49:51 +0300 (IDT) Date: Thu, 14 May 2015 21:49:49 +0300 From: Eli Zaretskii In-reply-to: <5554E2C4.7040209@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <83k2wbhu42.fsf@gnu.org> References: <83fv88ta5r.fsf@gnu.org> <5532ADA3.5000006@yandex.ru> <834mod6xnm.fsf@gnu.org> <5532D397.8090602@yandex.ru> <83zj645gxu.fsf@gnu.org> <5533D7B8.7060508@yandex.ru> <83sibw59q1.fsf@gnu.org> <5533E816.2090208@yandex.ru> <83r3rg56zy.fsf@gnu.org> <5533EFE5.2050101@yandex.ru> <83oamk561p.fsf@gnu.org> <5533F446.4020400@yandex.ru> <83fv7u6epr.fsf@gnu.org> <838udm61ur.fsf@gnu.org> <5536FE56.406@yandex.ru> <83egnc4nu5.fsf@gnu.org> <55528906.7060606@yandex.ru> <83zj58jvri.fsf@gnu.org> <5553F93C.9010205@yandex.ru> <83617vjjmv.fsf@gnu.org> <5554E2C4.7040209@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Cc: esr@snark.thyrsus.com, 20292@debbugs.gnu.org > From: Dmitry Gutov > Date: Thu, 14 May 2015 21:00:36 +0300 > > > If we know all the stashed files, how about invoking "git reset" for > > all of them? It cannot hurt, can it? > > How will we know it? Emacs could try to list all staged files, but > there's no good way to know that they all belong to the applied > stash (looking at the top stash isn't reliable either: the user > might have specified a different one explicitly). We could assume that any staged file during resolution of conflict due to "stash pop" is from the stash. If that's too dangerous (is it?), we could ask for confirmation. From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 May 2015 18:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: esr@snark.thyrsus.com, 20292@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.14316295507549 (code B ref 20292); Thu, 14 May 2015 18:53:02 +0000 Received: (at 20292) by debbugs.gnu.org; 14 May 2015 18:52:30 +0000 Received: from localhost ([127.0.0.1]:45368 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YsyFC-0001xg-55 for submit@debbugs.gnu.org; Thu, 14 May 2015 14:52:30 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:47298) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YsyF9-0001xS-VX for 20292@debbugs.gnu.org; Thu, 14 May 2015 14:52:28 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NOC00M00S6PS400@a-mtaout20.012.net.il> for 20292@debbugs.gnu.org; Thu, 14 May 2015 21:52:21 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NOC00MDTSF9IHA0@a-mtaout20.012.net.il>; Thu, 14 May 2015 21:52:21 +0300 (IDT) Date: Thu, 14 May 2015 21:52:19 +0300 From: Eli Zaretskii In-reply-to: <5554EDF5.5050606@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <83iobvhtzw.fsf@gnu.org> References: <83fv88ta5r.fsf@gnu.org> <5532D397.8090602@yandex.ru> <83zj645gxu.fsf@gnu.org> <5533D7B8.7060508@yandex.ru> <83sibw59q1.fsf@gnu.org> <5533E816.2090208@yandex.ru> <83r3rg56zy.fsf@gnu.org> <5533EFE5.2050101@yandex.ru> <83oamk561p.fsf@gnu.org> <5533F446.4020400@yandex.ru> <83fv7u6epr.fsf@gnu.org> <838udm61ur.fsf@gnu.org> <5536FE56.406@yandex.ru> <83egnc4nu5.fsf@gnu.org> <55528906.7060606@yandex.ru> <83zj58jvri.fsf@gnu.org> <834mnfjjlz.fsf@gnu.org> <5554DBB2.3070005@yandex.ru> <83mw17huqr.fsf@gnu.org> <5554EDF5.5050606@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Cc: esr@snark.thyrsus.com, 20292@debbugs.gnu.org > From: Dmitry Gutov > Date: Thu, 14 May 2015 21:48:21 +0300 > > Do you apply stashes via the vc-dir interface? No. > We could do something in that implementation. I think its a good idea. From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 May 2015 19:10:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: esr@snark.thyrsus.com, 20292@debbugs.gnu.org Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.14316305939338 (code B ref 20292); Thu, 14 May 2015 19:10:03 +0000 Received: (at 20292) by debbugs.gnu.org; 14 May 2015 19:09:53 +0000 Received: from localhost ([127.0.0.1]:45391 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YsyW0-0002QX-Qj for submit@debbugs.gnu.org; Thu, 14 May 2015 15:09:53 -0400 Received: from mail-wg0-f52.google.com ([74.125.82.52]:32946) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YsyVz-0002QI-BS for 20292@debbugs.gnu.org; Thu, 14 May 2015 15:09:52 -0400 Received: by wgin8 with SMTP id n8so85978255wgi.0 for <20292@debbugs.gnu.org>; Thu, 14 May 2015 12:09:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=NnLxa57rBsh/Ni4Puj60dgSGLBYZr4TTX2yjyc+ENPI=; b=0HfjyR1rDSnvm2AxeI+2nxYM9mJz+Wq223okwdMnQkXYNIdkaDdbibNFVF0rciRCWB NMdS8DDjMYIZCKygmDdGi3Syal7abqyNUnsY+JNcS4GTEYfU7LVCHV7LHro+IxOFu2Es MBtFBAo0E64nSiKAlFMWyS4Udbue/jYVsIF8QaIUrzBcdxcSCR5OchjzaY8bxVvGfhQe sfQC4GIFTgEKajBBqVtH9WScMxdvZJr//3Cp+j7BIajoeicPhkw6NEkx1Em93fNUBoBE NkW0eajRCIb+ZGTJPrbwlgjMdOTKOx4mFCdzT176j8dlpJjsQfFvZalIhidaguu/2U4s lbqQ== X-Received: by 10.180.74.208 with SMTP id w16mr26820043wiv.31.1431630585591; Thu, 14 May 2015 12:09:45 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id g11sm39529630wjr.25.2015.05.14.12.09.43 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 May 2015 12:09:45 -0700 (PDT) References: <83fv88ta5r.fsf@gnu.org> <5532D397.8090602@yandex.ru> <83zj645gxu.fsf@gnu.org> <5533D7B8.7060508@yandex.ru> <83sibw59q1.fsf@gnu.org> <5533E816.2090208@yandex.ru> <83r3rg56zy.fsf@gnu.org> <5533EFE5.2050101@yandex.ru> <83oamk561p.fsf@gnu.org> <5533F446.4020400@yandex.ru> <83fv7u6epr.fsf@gnu.org> <838udm61ur.fsf@gnu.org> <5536FE56.406@yandex.ru> <83egnc4nu5.fsf@gnu.org> <55528906.7060606@yandex.ru> <83zj58jvri.fsf@gnu.org> <834mnfjjlz.fsf@gnu.org> <5554DBB2.3070005@yandex.ru> <83mw17huqr.fsf@gnu.org> <5554EDF5.5050606@yandex.ru> <83iobvhtzw.fsf@gnu.org> From: Dmitry Gutov Message-ID: <5554F2F3.6010109@yandex.ru> Date: Thu, 14 May 2015 22:09:39 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 MIME-Version: 1.0 In-Reply-To: <83iobvhtzw.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 05/14/2015 09:52 PM, Eli Zaretskii wrote: > I think its a good idea. It might be. But I don't actually know how to approach it. Doing 'git reset' right after a stash is popped would break vc-git-conflicted-files. If we don't do that, then what else *do* we do in vc-git-stash-apply and vc-git-stash-pop? Note that vc-git-resolve-when-done has to work satisfactorily both after vc-git-stash-apply, and after 'git stash apply' performed in console. From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 May 2015 19:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: esr@snark.thyrsus.com, 20292@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.143163201411708 (code B ref 20292); Thu, 14 May 2015 19:34:02 +0000 Received: (at 20292) by debbugs.gnu.org; 14 May 2015 19:33:34 +0000 Received: from localhost ([127.0.0.1]:45399 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ysysv-00032l-QV for submit@debbugs.gnu.org; Thu, 14 May 2015 15:33:34 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:54719) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ysyst-00032X-7A for 20292@debbugs.gnu.org; Thu, 14 May 2015 15:33:32 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NOC00M00U52ZU00@a-mtaout20.012.net.il> for 20292@debbugs.gnu.org; Thu, 14 May 2015 22:33:23 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NOC00M9HUBMXZ30@a-mtaout20.012.net.il>; Thu, 14 May 2015 22:33:23 +0300 (IDT) Date: Thu, 14 May 2015 22:33:20 +0300 From: Eli Zaretskii In-reply-to: <5554F2F3.6010109@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <83fv6zhs3j.fsf@gnu.org> References: <83fv88ta5r.fsf@gnu.org> <5532D397.8090602@yandex.ru> <83zj645gxu.fsf@gnu.org> <5533D7B8.7060508@yandex.ru> <83sibw59q1.fsf@gnu.org> <5533E816.2090208@yandex.ru> <83r3rg56zy.fsf@gnu.org> <5533EFE5.2050101@yandex.ru> <83oamk561p.fsf@gnu.org> <5533F446.4020400@yandex.ru> <83fv7u6epr.fsf@gnu.org> <838udm61ur.fsf@gnu.org> <5536FE56.406@yandex.ru> <83egnc4nu5.fsf@gnu.org> <55528906.7060606@yandex.ru> <83zj58jvri.fsf@gnu.org> <834mnfjjlz.fsf@gnu.org> <5554DBB2.3070005@yandex.ru> <83mw17huqr.fsf@gnu.org> <5554EDF5.5050606@yandex.ru> <83iobvhtzw.fsf@gnu.org> <5554F2F3.6010109@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Cc: esr@snark.thyrsus.com, 20292@debbugs.gnu.org > From: Dmitry Gutov > Date: Thu, 14 May 2015 22:09:39 +0300 > > On 05/14/2015 09:52 PM, Eli Zaretskii wrote: > > > I think its a good idea. > > It might be. But I don't actually know how to approach it. > > Doing 'git reset' right after a stash is popped would break > vc-git-conflicted-files. > > If we don't do that, then what else *do* we do in vc-git-stash-apply and > vc-git-stash-pop? Ask the user whether to reset each file in the index (other than the one in which the conflicts were resolved), perhaps? From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 May 2015 20:25:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: esr@snark.thyrsus.com, 20292@debbugs.gnu.org Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.143163508616580 (code B ref 20292); Thu, 14 May 2015 20:25:03 +0000 Received: (at 20292) by debbugs.gnu.org; 14 May 2015 20:24:46 +0000 Received: from localhost ([127.0.0.1]:45425 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YszgU-0004JM-5Q for submit@debbugs.gnu.org; Thu, 14 May 2015 16:24:46 -0400 Received: from mail-wi0-f180.google.com ([209.85.212.180]:34166) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YszgR-0004J6-O8 for 20292@debbugs.gnu.org; Thu, 14 May 2015 16:24:44 -0400 Received: by wicmc15 with SMTP id mc15so23296585wic.1 for <20292@debbugs.gnu.org>; Thu, 14 May 2015 13:24:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=cb3b9fNPGMHDIBScld2MtDTUUMEavKBO9qFQpKNSwjY=; b=FD98raVzt5l+c1U0ShBavDSZU0pK5Yk8I2IQsqFIfu0LVF2kG9z1aXRGyQSnm0wewJ 8yOw50n9TQVgo46enQfKHUETrMX/KigF6Rcw+K2L1MzxpHPBUap1VA2ILQ/idlYvWCrO fBrf2NCaq+JFkuYFR7Zhc702NIII7bzlfQGn9UWoxtrGQoVtLSXHvUKK9GcbMUqgla6Y dJYnowhOr6QHZgrSGqIW/WFcdVTGB6JuOXGwqJY8tHu66uBSM9vYIoybipmSbQGp5TgS GQAl6PXgyW0ypiyWXAmctCSGeV+klPOkJpNC+xzE8R6s5kzvsJJnRYfUrjzZGE47E9Da iN3w== X-Received: by 10.180.103.231 with SMTP id fz7mr27184545wib.35.1431635078176; Thu, 14 May 2015 13:24:38 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id cf9sm138512wjc.27.2015.05.14.13.24.36 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 May 2015 13:24:37 -0700 (PDT) References: <83fv88ta5r.fsf@gnu.org> <5532D397.8090602@yandex.ru> <83zj645gxu.fsf@gnu.org> <5533D7B8.7060508@yandex.ru> <83sibw59q1.fsf@gnu.org> <5533E816.2090208@yandex.ru> <83r3rg56zy.fsf@gnu.org> <5533EFE5.2050101@yandex.ru> <83oamk561p.fsf@gnu.org> <5533F446.4020400@yandex.ru> <83fv7u6epr.fsf@gnu.org> <838udm61ur.fsf@gnu.org> <5536FE56.406@yandex.ru> <83egnc4nu5.fsf@gnu.org> <55528906.7060606@yandex.ru> <83zj58jvri.fsf@gnu.org> <834mnfjjlz.fsf@gnu.org> <5554DBB2.3070005@yandex.ru> <83mw17huqr.fsf@gnu.org> <5554EDF5.5050606@yandex.ru> <83iobvhtzw.fsf@gnu.org> <5554F2F3.6010109@yandex.ru> <83fv6zhs3j.fsf@gnu.org> From: Dmitry Gutov Message-ID: <55550482.1020404@yandex.ru> Date: Thu, 14 May 2015 23:24:34 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 MIME-Version: 1.0 In-Reply-To: <83fv6zhs3j.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 05/14/2015 10:33 PM, Eli Zaretskii wrote: > Ask the user whether to reset each file in the index (other than the > one in which the conflicts were resolved), perhaps? That doesn't sound to me like something an after-save-hook should do. And we can't reset each other file, we'd first have to check whether some of them still conflicts. From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 May 2015 20:56:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: esr@snark.thyrsus.com, Eli Zaretskii , 20292@debbugs.gnu.org Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.143163696019417 (code B ref 20292); Thu, 14 May 2015 20:56:03 +0000 Received: (at 20292) by debbugs.gnu.org; 14 May 2015 20:56:00 +0000 Received: from localhost ([127.0.0.1]:45438 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yt0Ah-000536-Al for submit@debbugs.gnu.org; Thu, 14 May 2015 16:55:59 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:6706) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yt0Ae-00052t-MQ for 20292@debbugs.gnu.org; Thu, 14 May 2015 16:55:57 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAGvvdVRFpYts/2dsb2JhbAA3gVOhb4EIgXYBBVYeBRALDiYHCxQYDSSqJIt7cgMBAoM+AwMLBAqDVASjY4RY X-IPAS-Result: AgUFAGvvdVRFpYts/2dsb2JhbAA3gVOhb4EIgXYBBVYeBRALDiYHCxQYDSSqJIt7cgMBAoM+AwMLBAqDVASjY4RY X-IronPort-AV: E=Sophos;i="5.11,557,1422939600"; d="scan'208";a="119859784" Received: from 69-165-139-108.dsl.teksavvy.com (HELO fmsmemgm.homelinux.net) ([69.165.139.108]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 May 2015 16:55:51 -0400 Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id A1488AE129; Thu, 14 May 2015 16:55:50 -0400 (EDT) From: Stefan Monnier Message-ID: References: <83fv88ta5r.fsf@gnu.org> <5533F446.4020400@yandex.ru> <83fv7u6epr.fsf@gnu.org> <838udm61ur.fsf@gnu.org> <5536FE56.406@yandex.ru> <83egnc4nu5.fsf@gnu.org> <55528906.7060606@yandex.ru> <83zj58jvri.fsf@gnu.org> <834mnfjjlz.fsf@gnu.org> <5554DBB2.3070005@yandex.ru> <83mw17huqr.fsf@gnu.org> <5554EDF5.5050606@yandex.ru> <83iobvhtzw.fsf@gnu.org> <5554F2F3.6010109@yandex.ru> <83fv6zhs3j.fsf@gnu.org> <55550482.1020404@yandex.ru> Date: Thu, 14 May 2015 16:55:50 -0400 In-Reply-To: <55550482.1020404@yandex.ru> (Dmitry Gutov's message of "Thu, 14 May 2015 23:24:34 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) I think the only sane way to handle this is to always use "git add" and to add a config var so users who don't like it can disable it. After all, when unstashing changes in a file that already has a modification staged, Git is pretty happy to silently/automatically "git add" the resulting merge (hence throwing away the info about the particular changes that were staged before the unstash) if it doesn't have conflicts (at least it does so if the unstash finds conflicts in other files). So I don't see why Emacs shouldn't feel free to "git add" the file once conflicts are resolved. IOW, I think bug#20292 is simply not a bug. Stefan From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 15 May 2015 07:12:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: esr@snark.thyrsus.com, 20292@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.143167386511440 (code B ref 20292); Fri, 15 May 2015 07:12:01 +0000 Received: (at 20292) by debbugs.gnu.org; 15 May 2015 07:11:05 +0000 Received: from localhost ([127.0.0.1]:45692 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yt9lv-0002yR-E1 for submit@debbugs.gnu.org; Fri, 15 May 2015 03:11:04 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:61906) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yt9lr-0002xs-Hr for 20292@debbugs.gnu.org; Fri, 15 May 2015 03:11:01 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NOD00400QEK2000@a-mtaout20.012.net.il> for 20292@debbugs.gnu.org; Fri, 15 May 2015 10:10:53 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NOD0039IQM4VG80@a-mtaout20.012.net.il>; Fri, 15 May 2015 10:10:53 +0300 (IDT) Date: Fri, 15 May 2015 10:10:51 +0300 From: Eli Zaretskii In-reply-to: <55550482.1020404@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <83d222iadg.fsf@gnu.org> References: <83fv88ta5r.fsf@gnu.org> <5532D397.8090602@yandex.ru> <83zj645gxu.fsf@gnu.org> <5533D7B8.7060508@yandex.ru> <83sibw59q1.fsf@gnu.org> <5533E816.2090208@yandex.ru> <83r3rg56zy.fsf@gnu.org> <5533EFE5.2050101@yandex.ru> <83oamk561p.fsf@gnu.org> <5533F446.4020400@yandex.ru> <83fv7u6epr.fsf@gnu.org> <838udm61ur.fsf@gnu.org> <5536FE56.406@yandex.ru> <83egnc4nu5.fsf@gnu.org> <55528906.7060606@yandex.ru> <83zj58jvri.fsf@gnu.org> <834mnfjjlz.fsf@gnu.org> <5554DBB2.3070005@yandex.ru> <83mw17huqr.fsf@gnu.org> <5554EDF5.5050606@yandex.ru> <83iobvhtzw.fsf@gnu.org> <5554F2F3.6010109@yandex.ru> <83fv6zhs3j.fsf@gnu.org> <55550482.1020404@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Cc: esr@snark.thyrsus.com, 20292@debbugs.gnu.org > From: Dmitry Gutov > Date: Thu, 14 May 2015 23:24:34 +0300 > > On 05/14/2015 10:33 PM, Eli Zaretskii wrote: > > > Ask the user whether to reset each file in the index (other than the > > one in which the conflicts were resolved), perhaps? > > That doesn't sound to me like something an after-save-hook should do. Why not? > And we can't reset each other file, we'd first have to check whether > some of them still conflicts. Can we know that conflicts still exist? From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 15 May 2015 07:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: esr@snark.thyrsus.com, 20292@debbugs.gnu.org, dgutov@yandex.ru Reply-To: Eli Zaretskii Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.143167408911764 (code B ref 20292); Fri, 15 May 2015 07:15:02 +0000 Received: (at 20292) by debbugs.gnu.org; 15 May 2015 07:14:49 +0000 Received: from localhost ([127.0.0.1]:45696 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yt9pY-00033f-AU for submit@debbugs.gnu.org; Fri, 15 May 2015 03:14:48 -0400 Received: from mtaout25.012.net.il ([80.179.55.181]:55833) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yt9pV-00033O-IA for 20292@debbugs.gnu.org; Fri, 15 May 2015 03:14:46 -0400 Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NOD00000QKGTN00@mtaout25.012.net.il> for 20292@debbugs.gnu.org; Fri, 15 May 2015 10:10:26 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NOD00F9PQLEKIB0@mtaout25.012.net.il>; Fri, 15 May 2015 10:10:26 +0300 (IDT) Date: Fri, 15 May 2015 10:14:38 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83bnhmia75.fsf@gnu.org> References: <83fv88ta5r.fsf@gnu.org> <5533F446.4020400@yandex.ru> <83fv7u6epr.fsf@gnu.org> <838udm61ur.fsf@gnu.org> <5536FE56.406@yandex.ru> <83egnc4nu5.fsf@gnu.org> <55528906.7060606@yandex.ru> <83zj58jvri.fsf@gnu.org> <834mnfjjlz.fsf@gnu.org> <5554DBB2.3070005@yandex.ru> <83mw17huqr.fsf@gnu.org> <5554EDF5.5050606@yandex.ru> <83iobvhtzw.fsf@gnu.org> <5554F2F3.6010109@yandex.ru> <83fv6zhs3j.fsf@gnu.org> <55550482.1020404@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Stefan Monnier > Cc: Eli Zaretskii , esr@snark.thyrsus.com, 20292@debbugs.gnu.org > Date: Thu, 14 May 2015 16:55:50 -0400 > > > I think the only sane way to handle this is to always use "git add" and > to add a config var so users who don't like it can disable it. Who'd like it? It will do something utterly inappropriate. > After all, when unstashing changes in a file that already has > a modification staged That's not the use case we were discussing, though. We were discussing a use case where the user merged from another repository, and then wants her uncommitted changes restored. Leaving them staged will trip the naive users. > IOW, I think bug#20292 is simply not a bug. I respectfully disagree. From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 15 May 2015 07:18:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: esr@snark.thyrsus.com, 20292@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.143167426512065 (code B ref 20292); Fri, 15 May 2015 07:18:01 +0000 Received: (at 20292) by debbugs.gnu.org; 15 May 2015 07:17:45 +0000 Received: from localhost ([127.0.0.1]:45701 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yt9sO-00038W-EP for submit@debbugs.gnu.org; Fri, 15 May 2015 03:17:45 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]:45441) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yt9sM-00038H-0N for 20292@debbugs.gnu.org; Fri, 15 May 2015 03:17:42 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NOD00F00QNS2P00@a-mtaout21.012.net.il> for 20292@debbugs.gnu.org; Fri, 15 May 2015 10:17:35 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NOD00FA6QXB2O10@a-mtaout21.012.net.il>; Fri, 15 May 2015 10:17:35 +0300 (IDT) Date: Fri, 15 May 2015 10:17:34 +0300 From: Eli Zaretskii In-reply-to: <55550482.1020404@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <83a8x6ia29.fsf@gnu.org> References: <83fv88ta5r.fsf@gnu.org> <5532D397.8090602@yandex.ru> <83zj645gxu.fsf@gnu.org> <5533D7B8.7060508@yandex.ru> <83sibw59q1.fsf@gnu.org> <5533E816.2090208@yandex.ru> <83r3rg56zy.fsf@gnu.org> <5533EFE5.2050101@yandex.ru> <83oamk561p.fsf@gnu.org> <5533F446.4020400@yandex.ru> <83fv7u6epr.fsf@gnu.org> <838udm61ur.fsf@gnu.org> <5536FE56.406@yandex.ru> <83egnc4nu5.fsf@gnu.org> <55528906.7060606@yandex.ru> <83zj58jvri.fsf@gnu.org> <834mnfjjlz.fsf@gnu.org> <5554DBB2.3070005@yandex.ru> <83mw17huqr.fsf@gnu.org> <5554EDF5.5050606@yandex.ru> <83iobvhtzw.fsf@gnu.org> <5554F2F3.6010109@yandex.ru> <83fv6zhs3j.fsf@gnu.org> <55550482.1020404@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Cc: esr@snark.thyrsus.com, 20292@debbugs.gnu.org > From: Dmitry Gutov > Date: Thu, 14 May 2015 23:24:34 +0300 > > And we can't reset each other file, we'd first have to check whether > some of them still conflicts. Btw, if we are seriously considering Stefan's suggestion to "git add" after conflicts are resolved, I see no reason not to "git reset" everything instead, since all that would do is make the staged files unstaged -- hardly a disaster, as all the user needs to do is add them back, and a user who knows Git enough to have staged changes before un-stashing will have no problems with that (if they at all use VC). From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 15 May 2015 18:15:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: esr@snark.thyrsus.com, 20292@debbugs.gnu.org, dgutov@yandex.ru Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.143171365819474 (code B ref 20292); Fri, 15 May 2015 18:15:01 +0000 Received: (at 20292) by debbugs.gnu.org; 15 May 2015 18:14:18 +0000 Received: from localhost ([127.0.0.1]:46456 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YtK7k-000541-VB for submit@debbugs.gnu.org; Fri, 15 May 2015 14:14:17 -0400 Received: from mercure.iro.umontreal.ca ([132.204.24.67]:34732) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YtK7i-00053t-NM for 20292@debbugs.gnu.org; Fri, 15 May 2015 14:14:15 -0400 Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 967EB85FF1; Fri, 15 May 2015 14:14:13 -0400 (EDT) Received: from lechon.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id AC2C31E5B8D; Fri, 15 May 2015 14:13:50 -0400 (EDT) Received: by lechon.iro.umontreal.ca (Postfix, from userid 20848) id 898FAB409F; Fri, 15 May 2015 14:13:50 -0400 (EDT) From: Stefan Monnier Message-ID: References: <83fv88ta5r.fsf@gnu.org> <83fv7u6epr.fsf@gnu.org> <838udm61ur.fsf@gnu.org> <5536FE56.406@yandex.ru> <83egnc4nu5.fsf@gnu.org> <55528906.7060606@yandex.ru> <83zj58jvri.fsf@gnu.org> <834mnfjjlz.fsf@gnu.org> <5554DBB2.3070005@yandex.ru> <83mw17huqr.fsf@gnu.org> <5554EDF5.5050606@yandex.ru> <83iobvhtzw.fsf@gnu.org> <5554F2F3.6010109@yandex.ru> <83fv6zhs3j.fsf@gnu.org> <55550482.1020404@yandex.ru> <83bnhmia75.fsf@gnu.org> Date: Fri, 15 May 2015 14:13:50 -0400 In-Reply-To: <83bnhmia75.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 15 May 2015 10:14:38 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-2.82, requis 5, autolearn=not spam, ALL_TRUSTED -2.82, MC_TSTLAST 0.00) X-DIRO-MailScanner-From: monnier@iro.umontreal.ca X-Spam-Status: No X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > That's not the use case we were discussing, though. We were > discussing a use case where the user merged from another repository, > and then wants her uncommitted changes restored. Leaving them staged > will trip the naive users. But Emacs is not the main culprit: Git itself will stage all the non-conflicting changes, so why should this not trip the user similarly? IOW if the user gets tripped by Emacs doing "git add" after resolving a unstash conflict, why would that same user not already be tripped identically by Git doing this "git add" on the non-conflicted files? Stefan From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 15 May 2015 18:56:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: esr@snark.thyrsus.com, 20292@debbugs.gnu.org, dgutov@yandex.ru Reply-To: Eli Zaretskii Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.143171615423266 (code B ref 20292); Fri, 15 May 2015 18:56:02 +0000 Received: (at 20292) by debbugs.gnu.org; 15 May 2015 18:55:54 +0000 Received: from localhost ([127.0.0.1]:46469 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YtKm1-00063C-Vy for submit@debbugs.gnu.org; Fri, 15 May 2015 14:55:54 -0400 Received: from mtaout24.012.net.il ([80.179.55.180]:53790) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YtKlz-00062x-47 for 20292@debbugs.gnu.org; Fri, 15 May 2015 14:55:52 -0400 Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NOE00I00MOOYM00@mtaout24.012.net.il> for 20292@debbugs.gnu.org; Fri, 15 May 2015 21:47:02 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NOE0094OMUDQTA0@mtaout24.012.net.il>; Fri, 15 May 2015 21:47:02 +0300 (IDT) Date: Fri, 15 May 2015 21:55:44 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83mw15hdqn.fsf@gnu.org> References: <83fv88ta5r.fsf@gnu.org> <83fv7u6epr.fsf@gnu.org> <838udm61ur.fsf@gnu.org> <5536FE56.406@yandex.ru> <83egnc4nu5.fsf@gnu.org> <55528906.7060606@yandex.ru> <83zj58jvri.fsf@gnu.org> <834mnfjjlz.fsf@gnu.org> <5554DBB2.3070005@yandex.ru> <83mw17huqr.fsf@gnu.org> <5554EDF5.5050606@yandex.ru> <83iobvhtzw.fsf@gnu.org> <5554F2F3.6010109@yandex.ru> <83fv6zhs3j.fsf@gnu.org> <55550482.1020404@yandex.ru> <83bnhmia75.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Stefan Monnier > Cc: dgutov@yandex.ru, esr@snark.thyrsus.com, 20292@debbugs.gnu.org > Date: Fri, 15 May 2015 14:13:50 -0400 > > > That's not the use case we were discussing, though. We were > > discussing a use case where the user merged from another repository, > > and then wants her uncommitted changes restored. Leaving them staged > > will trip the naive users. > > But Emacs is not the main culprit: Git itself will stage all the > non-conflicting changes, so why should this not trip the user similarly? The users I have in mind expect Emacs to save them from Git idiosyncrasies. > IOW if the user gets tripped by Emacs doing "git add" after resolving > a unstash conflict, why would that same user not already be tripped > identically by Git doing this "git add" on the non-conflicted files? Because they don't use Git from the shell, or at least try not to. From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 15 May 2015 20:03:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: esr@snark.thyrsus.com, 20292@debbugs.gnu.org, dgutov@yandex.ru Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.143172015029683 (code B ref 20292); Fri, 15 May 2015 20:03:01 +0000 Received: (at 20292) by debbugs.gnu.org; 15 May 2015 20:02:30 +0000 Received: from localhost ([127.0.0.1]:46478 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YtLoT-0007ih-TD for submit@debbugs.gnu.org; Fri, 15 May 2015 16:02:30 -0400 Received: from mercure.iro.umontreal.ca ([132.204.24.67]:37854) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YtLoR-0007iY-I0 for 20292@debbugs.gnu.org; Fri, 15 May 2015 16:02:28 -0400 Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 8A4269C14E; Fri, 15 May 2015 16:02:26 -0400 (EDT) Received: from lechon.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id EE7291E5B96; Fri, 15 May 2015 16:02:03 -0400 (EDT) Received: by lechon.iro.umontreal.ca (Postfix, from userid 20848) id CB754B409F; Fri, 15 May 2015 16:02:03 -0400 (EDT) From: Stefan Monnier Message-ID: References: <83fv88ta5r.fsf@gnu.org> <838udm61ur.fsf@gnu.org> <5536FE56.406@yandex.ru> <83egnc4nu5.fsf@gnu.org> <55528906.7060606@yandex.ru> <83zj58jvri.fsf@gnu.org> <834mnfjjlz.fsf@gnu.org> <5554DBB2.3070005@yandex.ru> <83mw17huqr.fsf@gnu.org> <5554EDF5.5050606@yandex.ru> <83iobvhtzw.fsf@gnu.org> <5554F2F3.6010109@yandex.ru> <83fv6zhs3j.fsf@gnu.org> <55550482.1020404@yandex.ru> <83bnhmia75.fsf@gnu.org> <83mw15hdqn.fsf@gnu.org> Date: Fri, 15 May 2015 16:02:03 -0400 In-Reply-To: <83mw15hdqn.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 15 May 2015 21:55:44 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-2.82, requis 5, autolearn=not spam, ALL_TRUSTED -2.82, MC_TSTLAST 0.00) X-DIRO-MailScanner-From: monnier@iro.umontreal.ca X-Spam-Status: No X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) >> > That's not the use case we were discussing, though. We were >> > discussing a use case where the user merged from another repository, >> > and then wants her uncommitted changes restored. Leaving them staged >> > will trip the naive users. >> But Emacs is not the main culprit: Git itself will stage all the >> non-conflicting changes, so why should this not trip the user similarly? > The users I have in mind expect Emacs to save them from Git > idiosyncrasies. I don't see how that's relevant. By behaving differently from the rest of Git, I'm afraid we'll just introduce more problems. >> IOW if the user gets tripped by Emacs doing "git add" after resolving >> a unstash conflict, why would that same user not already be tripped >> identically by Git doing this "git add" on the non-conflicted files? > Because they don't use Git from the shell, or at least try not to. Feel free to change the behavior of vc-git-resolve-when-done for the case where the unstash was done from within Emacs after you've changed this unstash to behave the way you want it, rather than the way Git does it. In my case, the unstash is done by Git with no Emacs involvement, and in that case it seems that "git add" is just the only sane thing to do. Stefan From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 15 May 2015 20:20:08 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: esr@snark.thyrsus.com, 20292@debbugs.gnu.org, dgutov@yandex.ru Reply-To: Eli Zaretskii Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.143172119131247 (code B ref 20292); Fri, 15 May 2015 20:20:08 +0000 Received: (at 20292) by debbugs.gnu.org; 15 May 2015 20:19:51 +0000 Received: from localhost ([127.0.0.1]:46505 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YtM5G-00087u-Q8 for submit@debbugs.gnu.org; Fri, 15 May 2015 16:19:51 -0400 Received: from mtaout25.012.net.il ([80.179.55.181]:48832) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YtM5D-00087f-G3 for 20292@debbugs.gnu.org; Fri, 15 May 2015 16:19:49 -0400 Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NOE00A00QHP8400@mtaout25.012.net.il> for 20292@debbugs.gnu.org; Fri, 15 May 2015 23:15:28 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NOE005UKQXNOK60@mtaout25.012.net.il>; Fri, 15 May 2015 23:15:28 +0300 (IDT) Date: Fri, 15 May 2015 23:19:35 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83iobth9uw.fsf@gnu.org> References: <83fv88ta5r.fsf@gnu.org> <838udm61ur.fsf@gnu.org> <5536FE56.406@yandex.ru> <83egnc4nu5.fsf@gnu.org> <55528906.7060606@yandex.ru> <83zj58jvri.fsf@gnu.org> <834mnfjjlz.fsf@gnu.org> <5554DBB2.3070005@yandex.ru> <83mw17huqr.fsf@gnu.org> <5554EDF5.5050606@yandex.ru> <83iobvhtzw.fsf@gnu.org> <5554F2F3.6010109@yandex.ru> <83fv6zhs3j.fsf@gnu.org> <55550482.1020404@yandex.ru> <83bnhmia75.fsf@gnu.org> <83mw15hdqn.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Stefan Monnier > Cc: dgutov@yandex.ru, esr@snark.thyrsus.com, 20292@debbugs.gnu.org > Date: Fri, 15 May 2015 16:02:03 -0400 > > >> > That's not the use case we were discussing, though. We were > >> > discussing a use case where the user merged from another repository, > >> > and then wants her uncommitted changes restored. Leaving them staged > >> > will trip the naive users. > >> But Emacs is not the main culprit: Git itself will stage all the > >> non-conflicting changes, so why should this not trip the user similarly? > > The users I have in mind expect Emacs to save them from Git > > idiosyncrasies. > > I don't see how that's relevant. Strange. > By behaving differently from the rest of Git, I'm afraid we'll just > introduce more problems. I'm not afraid of that. > >> IOW if the user gets tripped by Emacs doing "git add" after resolving > >> a unstash conflict, why would that same user not already be tripped > >> identically by Git doing this "git add" on the non-conflicted files? > > Because they don't use Git from the shell, or at least try not to. > > Feel free to change the behavior of vc-git-resolve-when-done for the > case where the unstash was done from within Emacs after you've changed > this unstash to behave the way you want it, rather than the way Git > does it. > > In my case, the unstash is done by Git with no Emacs involvement, and in > that case it seems that "git add" is just the only sane thing to do. Then I guess the only way to stop this endless and futile argument is to have an option that will control whether we "add" or "reset". From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 15 May 2015 23:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: esr@snark.thyrsus.com, Eli Zaretskii , 20292@debbugs.gnu.org Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.143173387019613 (code B ref 20292); Fri, 15 May 2015 23:52:02 +0000 Received: (at 20292) by debbugs.gnu.org; 15 May 2015 23:51:10 +0000 Received: from localhost ([127.0.0.1]:46573 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YtPNl-00056G-9n for submit@debbugs.gnu.org; Fri, 15 May 2015 19:51:10 -0400 Received: from mail-wi0-f174.google.com ([209.85.212.174]:32800) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YtPNi-00055k-Eg for 20292@debbugs.gnu.org; Fri, 15 May 2015 19:51:07 -0400 Received: by wicmx19 with SMTP id mx19so49439475wic.0 for <20292@debbugs.gnu.org>; Fri, 15 May 2015 16:51:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=HbUtOHQAKv5TiPqPDCtvYZIxMOD9bNZkv0ggvIzZIVo=; b=kabR0Z0WII0DpNGySdIvo7PAF5zEj8DPvJosVMWqQEh8sEhQtmB/k6WYC2VL7nYziB Iju3gA0qd6EpfPJv/aIKaYW879veRY+DheRTu0z0G+D3LH6tAcQdALYlg+l2KDJbbFHj 3bKJvBPnzOD/obt1q8hNAqry+cJmluU+1/KiICxvnbLmbIZt6bCFLgWAlWFlf1Gq7pip Ho/FZbNC8oNTACL0fI8e38kPcVz4ERggN2MPTAWdguJzK9pTk8x5UGDpPINrilzBZP0V fhVQjjauJq/+1vvoNNtBDd9NzC/CGUeVDq97UhaTPmJPVyzi4zeGLyZOyv3X5xTgaY8z aGgg== X-Received: by 10.180.104.197 with SMTP id gg5mr1716449wib.27.1431733860792; Fri, 15 May 2015 16:51:00 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id ek10sm372081wid.1.2015.05.15.16.50.59 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 May 2015 16:51:00 -0700 (PDT) References: <83fv88ta5r.fsf@gnu.org> <5533F446.4020400@yandex.ru> <83fv7u6epr.fsf@gnu.org> <838udm61ur.fsf@gnu.org> <5536FE56.406@yandex.ru> <83egnc4nu5.fsf@gnu.org> <55528906.7060606@yandex.ru> <83zj58jvri.fsf@gnu.org> <834mnfjjlz.fsf@gnu.org> <5554DBB2.3070005@yandex.ru> <83mw17huqr.fsf@gnu.org> <5554EDF5.5050606@yandex.ru> <83iobvhtzw.fsf@gnu.org> <5554F2F3.6010109@yandex.ru> <83fv6zhs3j.fsf@gnu.org> <55550482.1020404@yandex.ru> From: Dmitry Gutov Message-ID: <55568661.90506@yandex.ru> Date: Sat, 16 May 2015 02:50:57 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 05/14/2015 11:55 PM, Stefan Monnier wrote: > > I think the only sane way to handle this is to always use "git add" and > to add a config var so users who don't like it can disable it. If we're fine with a config var, we might as well try to support the alternative behavior. This should do it: diff --git a/lisp/vc/vc-git.el b/lisp/vc/vc-git.el index 20f2101..2fbb71b 100644 --- a/lisp/vc/vc-git.el +++ b/lisp/vc/vc-git.el @@ -130,6 +130,17 @@ If nil, use the value of `vc-annotate-switches'. If t, use no switches." :version "25.1" :group 'vc-git) +(defcustom vc-git-resolve-conflicts t + "When non-nil, mark conflicted file as resolved upon saving. +That happens after all conflict markers in it have been removed. +If the value is `unstage', then after the last conflict is +resolved, the staging area is cleared if no merge is in progress." + :type '(choice (const :tag "Don't resolve" nil) + (const :tag "Resolve" t) + (const :tag "Unstage all after resolving" unstage)) + :version "25.1" + :group 'vc-git) + (defcustom vc-git-program "git" "Name of the Git executable (excluding any arguments)." :version "24.1" @@ -801,12 +812,16 @@ This prompts for a branch to merge from." (save-excursion (goto-char (point-min)) (unless (re-search-forward "^<<<<<<< " nil t) - (if (file-exists-p (expand-file-name ".git/MERGE_HEAD" - (vc-git-root buffer-file-name))) - ;; Doing a merge. - (vc-git-command nil 0 buffer-file-name "add") - ;; Doing something else. Likely applying a stash (bug#20292). - (vc-git-command nil 0 buffer-file-name "reset")) + (vc-git-command nil 0 buffer-file-name "add") + (when (and + (eq vc-git-resolve-conflicts 'unstage) + ;; Doing something other than a merge. Likely applying a + ;; stash (bug#20292). + (not + (file-exists-p (expand-file-name ".git/MERGE_HEAD" + (vc-git-root buffer-file-name)))) + (not (vc-git-conflicted-files (vc-git-root buffer-file-name)))) + (vc-git-command nil 0 nil "reset")) ;; Remove the hook so that it is not called multiple times. (remove-hook 'after-save-hook 'vc-git-resolve-when-done t)))) @@ -823,7 +838,8 @@ This prompts for a branch to merge from." (re-search-forward "^<<<<<<< " nil 'noerror))) (vc-file-setprop buffer-file-name 'vc-state 'conflict) (smerge-start-session) - (add-hook 'after-save-hook 'vc-git-resolve-when-done nil 'local) + (when vc-git-resolve-conflicts + (add-hook 'after-save-hook 'vc-git-resolve-when-done nil 'local)) (message "There are unresolved conflicts in this file"))) ;;; HISTORY FUNCTIONS From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 15 May 2015 23:53:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: esr@snark.thyrsus.com, 20292@debbugs.gnu.org, dgutov@yandex.ru Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.143173393719743 (code B ref 20292); Fri, 15 May 2015 23:53:01 +0000 Received: (at 20292) by debbugs.gnu.org; 15 May 2015 23:52:17 +0000 Received: from localhost ([127.0.0.1]:46577 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YtPOq-00058N-F1 for submit@debbugs.gnu.org; Fri, 15 May 2015 19:52:16 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:59897) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YtPOo-00058A-Bi for 20292@debbugs.gnu.org; Fri, 15 May 2015 19:52:14 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAGvvdVRFpYts/2dsb2JhbAA3gVOhb4EIgXUBAQQBVh4FBQsLNAcLFBgNJIgTohGLeywDOgkDA4M+Aw4ECoNUBKNjhFg X-IPAS-Result: AgUFAGvvdVRFpYts/2dsb2JhbAA3gVOhb4EIgXUBAQQBVh4FBQsLNAcLFBgNJIgTohGLeywDOgkDA4M+Aw4ECoNUBKNjhFg X-IronPort-AV: E=Sophos;i="5.11,557,1422939600"; d="scan'208";a="120085974" Received: from 69-165-139-108.dsl.teksavvy.com (HELO pastel.home) ([69.165.139.108]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 May 2015 19:52:09 -0400 Received: by pastel.home (Postfix, from userid 20848) id 5F57D2602; Fri, 15 May 2015 19:52:08 -0400 (EDT) From: Stefan Monnier Message-ID: References: <83fv88ta5r.fsf@gnu.org> <5536FE56.406@yandex.ru> <83egnc4nu5.fsf@gnu.org> <55528906.7060606@yandex.ru> <83zj58jvri.fsf@gnu.org> <834mnfjjlz.fsf@gnu.org> <5554DBB2.3070005@yandex.ru> <83mw17huqr.fsf@gnu.org> <5554EDF5.5050606@yandex.ru> <83iobvhtzw.fsf@gnu.org> <5554F2F3.6010109@yandex.ru> <83fv6zhs3j.fsf@gnu.org> <55550482.1020404@yandex.ru> <83bnhmia75.fsf@gnu.org> <83mw15hdqn.fsf@gnu.org> <83iobth9uw.fsf@gnu.org> Date: Fri, 15 May 2015 19:52:08 -0400 In-Reply-To: <83iobth9uw.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 15 May 2015 23:19:35 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > Then I guess the only way to stop this endless and futile argument is > to have an option that will control whether we "add" or "reset". That sounds right (and is basically what I suggested, tho what I suggested was a boolean to prevent "git add", but indeed we could make it into a 3-way choice between "git add", "git reset", and "do nothing"). If we want something more refined, I think we'd need to more precisely characterize the cases where we want "git add" and those where we want "git reset" (it seems many details are important such as whether the conflict comes from "git merge" or from "git stash", whether there were staged changes before the command was run, maybe more) and AFAIK those cases can't be distinguished solely based on the state of the current file but also depend on the other files in the project. Stefan From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 15 May 2015 23:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier , Eli Zaretskii Cc: esr@snark.thyrsus.com, 20292@debbugs.gnu.org Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.143173425620260 (code B ref 20292); Fri, 15 May 2015 23:58:02 +0000 Received: (at 20292) by debbugs.gnu.org; 15 May 2015 23:57:36 +0000 Received: from localhost ([127.0.0.1]:46585 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YtPTz-0005Gh-Ca for submit@debbugs.gnu.org; Fri, 15 May 2015 19:57:35 -0400 Received: from mail-wi0-f171.google.com ([209.85.212.171]:34657) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YtPTx-0005GV-OT for 20292@debbugs.gnu.org; Fri, 15 May 2015 19:57:34 -0400 Received: by wicmc15 with SMTP id mc15so49495489wic.1 for <20292@debbugs.gnu.org>; Fri, 15 May 2015 16:57:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=vpFZdJJEsnetFPew5nSFJiGfQlxIuhOsw/I731un7Qo=; b=y99PG2UKl7fKEG4kV0Uou/AHH0odJv/pqTJxUmCzKKkebV5XjpvBO5cBK5edCz1hGA ajnDL+LF8jlsz+CBQO6LUNr3XUjazslL8/dU5YUDFQqBSDkVA+C1qsAUICwyonTEiPQ5 d9cH6G86W98MtvX2Bo+G2PbXOKnx+R2ZHtpqkIZMlpv74D9vbSYYTeXwJibIaamiElaC /wb5KbWAcdRX1VnjvLpTMcdUF17X9uZp31zyTp0UE6hAt6I/qXjTU+puLJJoQyXyCmWq 9MLPTgTXwRnWi46MM2FLT2tcaRd3EEyUHpa5E3Mn8XMfEc6IwOYDIQwuLFPC6I7UnaGW xk0g== X-Received: by 10.194.77.44 with SMTP id p12mr23193475wjw.1.1431734248141; Fri, 15 May 2015 16:57:28 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id 16sm4764155wjs.41.2015.05.15.16.57.27 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 May 2015 16:57:28 -0700 (PDT) References: <83fv88ta5r.fsf@gnu.org> <5536FE56.406@yandex.ru> <83egnc4nu5.fsf@gnu.org> <55528906.7060606@yandex.ru> <83zj58jvri.fsf@gnu.org> <834mnfjjlz.fsf@gnu.org> <5554DBB2.3070005@yandex.ru> <83mw17huqr.fsf@gnu.org> <5554EDF5.5050606@yandex.ru> <83iobvhtzw.fsf@gnu.org> <5554F2F3.6010109@yandex.ru> <83fv6zhs3j.fsf@gnu.org> <55550482.1020404@yandex.ru> <83bnhmia75.fsf@gnu.org> <83mw15hdqn.fsf@gnu.org> <83iobth9uw.fsf@gnu.org> From: Dmitry Gutov Message-ID: <555687E4.8070605@yandex.ru> Date: Sat, 16 May 2015 02:57:24 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 05/16/2015 02:52 AM, Stefan Monnier wrote: > but indeed we > could make it into a 3-way choice between "git add", "git reset", > and "do nothing"). You've read my mind. :) > whether there were > staged changes before the command was run We'll just ignore this. > and AFAIK those > cases can't be distinguished solely based on the state of the current > file but also depend on the other files in the project. That's not a problem, we have vc-git-root. From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 16 May 2015 07:16:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: esr@snark.thyrsus.com, monnier@iro.umontreal.ca, 20292@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.14317605283916 (code B ref 20292); Sat, 16 May 2015 07:16:02 +0000 Received: (at 20292) by debbugs.gnu.org; 16 May 2015 07:15:28 +0000 Received: from localhost ([127.0.0.1]:46747 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YtWJj-000112-HE for submit@debbugs.gnu.org; Sat, 16 May 2015 03:15:28 -0400 Received: from mtaout23.012.net.il ([80.179.55.175]:47421) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YtWJh-00010p-55 for 20292@debbugs.gnu.org; Sat, 16 May 2015 03:15:26 -0400 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0NOF00500LF6HD00@a-mtaout23.012.net.il> for 20292@debbugs.gnu.org; Sat, 16 May 2015 10:15:18 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NOF0057TLHIAUB0@a-mtaout23.012.net.il>; Sat, 16 May 2015 10:15:18 +0300 (IDT) Date: Sat, 16 May 2015 10:15:19 +0300 From: Eli Zaretskii In-reply-to: <55568661.90506@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <83bnhlgfi0.fsf@gnu.org> References: <83fv88ta5r.fsf@gnu.org> <5533F446.4020400@yandex.ru> <83fv7u6epr.fsf@gnu.org> <838udm61ur.fsf@gnu.org> <5536FE56.406@yandex.ru> <83egnc4nu5.fsf@gnu.org> <55528906.7060606@yandex.ru> <83zj58jvri.fsf@gnu.org> <834mnfjjlz.fsf@gnu.org> <5554DBB2.3070005@yandex.ru> <83mw17huqr.fsf@gnu.org> <5554EDF5.5050606@yandex.ru> <83iobvhtzw.fsf@gnu.org> <5554F2F3.6010109@yandex.ru> <83fv6zhs3j.fsf@gnu.org> <55550482.1020404@yandex.ru> <55568661.90506@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Cc: Eli Zaretskii , esr@snark.thyrsus.com, 20292@debbugs.gnu.org > From: Dmitry Gutov > Date: Sat, 16 May 2015 02:50:57 +0300 > > On 05/14/2015 11:55 PM, Stefan Monnier wrote: > > > > I think the only sane way to handle this is to always use "git add" and > > to add a config var so users who don't like it can disable it. > > If we're fine with a config var, we might as well try to support the > alternative behavior. This should do it: Thanks. Just so I'm sure my reading of the patch is correct: this option will never modify the behavior for conflicts that arise during a "normal" merge (as opposed to "stash pop", for example), right? From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 16 May 2015 08:04:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: esr@snark.thyrsus.com, monnier@iro.umontreal.ca, 20292@debbugs.gnu.org Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.14317634288959 (code B ref 20292); Sat, 16 May 2015 08:04:02 +0000 Received: (at 20292) by debbugs.gnu.org; 16 May 2015 08:03:48 +0000 Received: from localhost ([127.0.0.1]:46767 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YtX4V-0002KR-Tt for submit@debbugs.gnu.org; Sat, 16 May 2015 04:03:48 -0400 Received: from mail-wi0-f170.google.com ([209.85.212.170]:36108) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YtX4U-0002KC-QY for 20292@debbugs.gnu.org; Sat, 16 May 2015 04:03:47 -0400 Received: by wizk4 with SMTP id k4so17416292wiz.1 for <20292@debbugs.gnu.org>; Sat, 16 May 2015 01:03:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=iUqhOo910g5OJZYfyjZ86OvvgbYG4B3SC27Li2KyaYY=; b=VrgSj+ojEG2TcII/NA8mAcjdmoTbRi+H7Y4syBPBvlj53uzg6nEezMH3s3etoae7I5 iywMuS7A8hZrbadcYF8DtEZznHEdywNAFt+i3zLVvF/yfk3LwPThaMhZLxgHnRrbTuu0 vyx9zvF1TiSdBLpxkySGLx4Z7px7V8hwc8x2XEsI+4W9z4z8zd+s7eYaC5N0XiJ6b0tC DSlUBzZajy2SOEktRUxZonqNrTIdlyPJ8Hqp+ByBG5jDb9d1XURdtIFDDd1Eybrl4aXK 3N30434+zXXhWbmQ919W4NHZN4g+3gOQrpLUXGGWaOdzZgpcrh+LDwgmmt+O1CIMgK3G mdEw== X-Received: by 10.194.71.51 with SMTP id r19mr12932011wju.74.1431763421236; Sat, 16 May 2015 01:03:41 -0700 (PDT) Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id o5sm2450398wia.0.2015.05.16.01.03.39 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 16 May 2015 01:03:40 -0700 (PDT) References: <83fv88ta5r.fsf@gnu.org> <5533F446.4020400@yandex.ru> <83fv7u6epr.fsf@gnu.org> <838udm61ur.fsf@gnu.org> <5536FE56.406@yandex.ru> <83egnc4nu5.fsf@gnu.org> <55528906.7060606@yandex.ru> <83zj58jvri.fsf@gnu.org> <834mnfjjlz.fsf@gnu.org> <5554DBB2.3070005@yandex.ru> <83mw17huqr.fsf@gnu.org> <5554EDF5.5050606@yandex.ru> <83iobvhtzw.fsf@gnu.org> <5554F2F3.6010109@yandex.ru> <83fv6zhs3j.fsf@gnu.org> <55550482.1020404@yandex.ru> <55568661.90506@yandex.ru> <83bnhlgfi0.fsf@gnu.org> From: Dmitry Gutov Message-ID: <5556F9D8.4070503@yandex.ru> Date: Sat, 16 May 2015 11:03:36 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 MIME-Version: 1.0 In-Reply-To: <83bnhlgfi0.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 05/16/2015 10:15 AM, Eli Zaretskii wrote: > Thanks. Just so I'm sure my reading of the patch is correct: this > option will never modify the behavior for conflicts that arise during > a "normal" merge (as opposed to "stash pop", for example), right? That's the intention, yes. From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 16 May 2015 08:56:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: esr@snark.thyrsus.com, monnier@iro.umontreal.ca, 20292@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.143176653314184 (code B ref 20292); Sat, 16 May 2015 08:56:01 +0000 Received: (at 20292) by debbugs.gnu.org; 16 May 2015 08:55:33 +0000 Received: from localhost ([127.0.0.1]:46777 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YtXsa-0003gi-Iy for submit@debbugs.gnu.org; Sat, 16 May 2015 04:55:32 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:37226) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YtXsX-0003gQ-Km for 20292@debbugs.gnu.org; Sat, 16 May 2015 04:55:30 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NOF00D00PWNFZ00@a-mtaout20.012.net.il> for 20292@debbugs.gnu.org; Sat, 16 May 2015 11:55:22 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NOF00DHJQ4AG800@a-mtaout20.012.net.il>; Sat, 16 May 2015 11:55:22 +0300 (IDT) Date: Sat, 16 May 2015 11:55:23 +0300 From: Eli Zaretskii In-reply-to: <5556F9D8.4070503@yandex.ru> X-012-Sender: halo1@inter.net.il Message-id: <83617shpfo.fsf@gnu.org> References: <83fv88ta5r.fsf@gnu.org> <5533F446.4020400@yandex.ru> <83fv7u6epr.fsf@gnu.org> <838udm61ur.fsf@gnu.org> <5536FE56.406@yandex.ru> <83egnc4nu5.fsf@gnu.org> <55528906.7060606@yandex.ru> <83zj58jvri.fsf@gnu.org> <834mnfjjlz.fsf@gnu.org> <5554DBB2.3070005@yandex.ru> <83mw17huqr.fsf@gnu.org> <5554EDF5.5050606@yandex.ru> <83iobvhtzw.fsf@gnu.org> <5554F2F3.6010109@yandex.ru> <83fv6zhs3j.fsf@gnu.org> <55550482.1020404@yandex.ru> <55568661.90506@yandex.ru> <83bnhlgfi0.fsf@gnu.org> <5556F9D8.4070503@yandex.ru> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Cc: monnier@iro.umontreal.ca, esr@snark.thyrsus.com, 20292@debbugs.gnu.org > From: Dmitry Gutov > Date: Sat, 16 May 2015 11:03:36 +0300 > > On 05/16/2015 10:15 AM, Eli Zaretskii wrote: > > > Thanks. Just so I'm sure my reading of the patch is correct: this > > option will never modify the behavior for conflicts that arise during > > a "normal" merge (as opposed to "stash pop", for example), right? > > That's the intention, yes. Great, thanks. From unknown Mon Jun 23 23:55:28 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.503 (Entity 5.503) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Eli Zaretskii Subject: bug#20292: closed (Re: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file) Message-ID: References: <555742E0.40909@yandex.ru> <83fv88ta5r.fsf@gnu.org> X-Gnu-PR-Message: they-closed 20292 X-Gnu-PR-Package: emacs Reply-To: 20292@debbugs.gnu.org Date: Sat, 16 May 2015 13:16:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1431782162-12422-1" This is a multi-part message in MIME format... ------------=_1431782162-12422-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #20292: 24.5; Saving Git-controlled file with merge conflicts after "stash = pop" stages the file which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 20292@debbugs.gnu.org. --=20 20292: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D20292 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1431782162-12422-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 20292-done) by debbugs.gnu.org; 16 May 2015 13:15:25 +0000 Received: from localhost ([127.0.0.1]:46852 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ytbw4-0003DU-AV for submit@debbugs.gnu.org; Sat, 16 May 2015 09:15:24 -0400 Received: from mail-wi0-f181.google.com ([209.85.212.181]:37854) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ytbw1-0003DF-OP for 20292-done@debbugs.gnu.org; Sat, 16 May 2015 09:15:22 -0400 Received: by wibt6 with SMTP id t6so21568876wib.0 for <20292-done@debbugs.gnu.org>; Sat, 16 May 2015 06:15:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=9Wq4oCX1hFeIsDCbEZPB9ortdIZivc+n84uM0uIWG/E=; b=zHrC0WeuzMerxgkaZzD+zU3x2X5Mp/wi+Zs2OCtLNdxY3ZhE4ghitHimq7/KAi6JRz djSvyIyRpzveq9RkEh2X4uJYyX1JKepwG+FU7y0JoEX6w0Kxx7jPwnXDj5wwR6r0DE3Q 6kZSE0+SxMMMEO1euvOlLw8OaFBt78KMl+ANLqMgpH/akGysbdplJKMWMEk8J7qCmt78 OQL0Qc0vNu53FlET8kF6sJ4IvlQV+GWxO1ZDEw1NauIVKLew3xCwTFqFjdEKvZsfiOk4 WyEVtpyCxjaebAlMz1FtPSENTCRVdkXG4CXaMKbOGFYQDYwdicTR/EMOFXDzfw3g9Fxb VHhA== X-Received: by 10.194.121.135 with SMTP id lk7mr5665917wjb.109.1431782116119; Sat, 16 May 2015 06:15:16 -0700 (PDT) Received: from [192.168.0.185] (static-nbl2-118.cytanet.com.cy. [212.31.107.118]) by mx.google.com with ESMTPSA id r9sm7291860wjo.26.2015.05.16.06.15.13 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 16 May 2015 06:15:14 -0700 (PDT) Subject: Re: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file To: Eli Zaretskii References: <83fv88ta5r.fsf@gnu.org> <5533F446.4020400@yandex.ru> <83fv7u6epr.fsf@gnu.org> <838udm61ur.fsf@gnu.org> <5536FE56.406@yandex.ru> <83egnc4nu5.fsf@gnu.org> <55528906.7060606@yandex.ru> <83zj58jvri.fsf@gnu.org> <834mnfjjlz.fsf@gnu.org> <5554DBB2.3070005@yandex.ru> <83mw17huqr.fsf@gnu.org> <5554EDF5.5050606@yandex.ru> <83iobvhtzw.fsf@gnu.org> <5554F2F3.6010109@yandex.ru> <83fv6zhs3j.fsf@gnu.org> <55550482.1020404@yandex.ru> <55568661.90506@yandex.ru> <83bnhlgfi0.fsf@gnu.org> <5556F9D8.4070503@yandex.ru> <83617shpfo.fsf@gnu.org> From: Dmitry Gutov Message-ID: <555742E0.40909@yandex.ru> Date: Sat, 16 May 2015 16:15:12 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 MIME-Version: 1.0 In-Reply-To: <83617shpfo.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 20292-done Cc: esr@snark.thyrsus.com, monnier@iro.umontreal.ca, 20292-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 05/16/2015 11:55 AM, Eli Zaretskii wrote: > Great, thanks. Pushed, with some tweaks. ------------=_1431782162-12422-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 10 Apr 2015 12:56:03 +0000 Received: from localhost ([127.0.0.1]:51930 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgYTZ-0006BG-Hk for submit@debbugs.gnu.org; Fri, 10 Apr 2015 08:56:02 -0400 Received: from eggs.gnu.org ([208.118.235.92]:42586) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgYTW-0006Ax-HU for submit@debbugs.gnu.org; Fri, 10 Apr 2015 08:55:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YgYTQ-0001td-2R for submit@debbugs.gnu.org; Fri, 10 Apr 2015 08:55:53 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:60248) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YgYTQ-0001tZ-0J for submit@debbugs.gnu.org; Fri, 10 Apr 2015 08:55:52 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56066) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YgYTO-00075V-LK for bug-gnu-emacs@gnu.org; Fri, 10 Apr 2015 08:55:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YgYTJ-0001s6-T7 for bug-gnu-emacs@gnu.org; Fri, 10 Apr 2015 08:55:50 -0400 Received: from mtaout25.012.net.il ([80.179.55.181]:41950) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YgYTJ-0001rl-DV for bug-gnu-emacs@gnu.org; Fri, 10 Apr 2015 08:55:45 -0400 Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NML00100CTDIV00@mtaout25.012.net.il> for bug-gnu-emacs@gnu.org; Fri, 10 Apr 2015 15:51:10 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NML001R8D1AE200@mtaout25.012.net.il>; Fri, 10 Apr 2015 15:51:10 +0300 (IDT) Date: Fri, 10 Apr 2015 15:55:44 +0300 From: Eli Zaretskii Subject: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file X-012-Sender: halo1@inter.net.il To: bug-gnu-emacs@gnu.org Message-id: <83fv88ta5r.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: submit Cc: "Eric S. Raymond" X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) >From the shell prompt type "git stash save" to stash uncommitted changes. Then "git pull" or "git merge" from upstream, and finally type "git stash pop" to restore your original changes. If "git stash pop" encounters merge conflicts, then resolving these conflicts in Emacs and saving the buffer will run "git add" for the file whose conflicts were resolved. But that is not TRT in this case; the user likely does not expect to have her uncommitted changes staged for the next commit. Therefore, I think vc-git-resolve-when-done should not run "git add" if the merge conflict was due to "git stash pop". In GNU Emacs 24.5.1 (i686-pc-mingw32) of 2015-03-27 on HOME-C4E4A596F7 Windowing system distributor `Microsoft Corp.', version 5.1.2600 Configured using: `configure --prefix=/d/usr 'CFLAGS=-Og -gdwarf-4 -g3'' Important settings: value of $LANG: ENU locale-coding-system: cp1255 Major mode: RMAIL Minor modes in effect: diff-auto-refine-mode: t desktop-save-mode: t show-paren-mode: t display-time-mode: t tooltip-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t temp-buffer-resize-mode: t buffer-read-only: t line-number-mode: t Recent messages: Getting mail from d:/usr/eli/data/mail.new... Counting new messages...done (12) Saving file d:/usr/eli/rmail/INBOX... Wrote d:/usr/eli/rmail/INBOX [2 times] Computing summary lines...done 12 new messages read Mark set No following nondeleted message Saving file d:/usr/eli/rmail/INBOX... Wrote d:/usr/eli/rmail/INBOX [2 times] Load-path shadows: d:/usr/share/emacs/site-lisp/soap-inspect hides d:/usr/share/emacs/24.5/lisp/net/soap-inspect d:/usr/share/emacs/site-lisp/soap-client hides d:/usr/share/emacs/24.5/lisp/net/soap-client Features: (shadow emacsbug etags smerge-mode cc-awk bug-reference add-log misearch multi-isearch dabbrev shr-color color mule-util rmailout shr browse-url network-stream starttls tls mail-extr smtpmail auth-source eieio byte-opt bytecomp byte-compile cconv eieio-core password-cache mailalias sendmail help-mode cl-extra texinfo ld-script tcl conf-mode org-element org-rmail org-mhe org-irc org-info org-gnus gnus-util org-docview doc-view image-mode dired-x dired org-bibtex bibtex org-bbdb org-w3m org advice org-macro org-footnote org-pcomplete pcomplete org-list org-faces org-entities org-version ob-emacs-lisp ob ob-tangle ob-ref ob-lob ob-table ob-exp org-src ob-keys ob-comint comint ansi-color ring ob-core ob-eval org-compat org-macs org-loaddefs find-func cal-menu calendar cal-loaddefs arc-mode archive-mode parse-time diff-mode vc-bzr sh-script smie executable generic make-mode noutline outline easy-mmode vc-cvs jka-compr bat-mode vc-dispatcher vc-svn flyspell info vc-git cc-langs rmailsum qp rmailmm message format-spec rfc822 mml mml-sec mm-decode mm-bodies mm-encode mailabbrev gmm-utils mailheader mail-parse rfc2231 rmail rfc2047 rfc2045 ietf-drums mm-util help-fns mail-prsvr mail-utils desktop frameset server filecache mairix cus-edit cus-start cus-load wid-edit cl-loaddefs cl-lib saveplace midnight ispell generic-x cc-mode cc-fonts easymenu cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs paren battery time time-date tooltip electric uniquify ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp w32-common-fns disp-table w32-win w32-vars tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment lisp-mode prog-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote make-network-process w32notify w32 multi-tty emacs) Memory information: ((conses 8 1513834 148516) (symbols 32 42131 0) (miscs 32 5809 4393) (strings 16 105774 18210) (string-bytes 1 3133483) (vectors 8 37368) (vector-slots 4 1563878 83782) (floats 8 326 1158) (intervals 28 269674 1601) (buffers 508 358)) ------------=_1431782162-12422-1-- From unknown Mon Jun 23 23:55:28 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.503 (Entity 5.503) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: David Kastrup Subject: bug#20151: closed (Re: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file) Message-ID: References: <555742E0.40909@yandex.ru> <87iodwc9r0.fsf@fencepost.gnu.org> X-Gnu-PR-Message: they-closed 20151 X-Gnu-PR-Package: emacs Reply-To: 20151@debbugs.gnu.org Date: Sat, 16 May 2015 13:16:03 +0000 Content-Type: multipart/mixed; boundary="----------=_1431782163-12422-3" This is a multi-part message in MIME format... ------------=_1431782163-12422-3 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #20292: 25.0.50; Smerge does "git add" for every final conflict resolution which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 20151@debbugs.gnu.org. --=20 20292: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D20292 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1431782163-12422-3 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 20292-done) by debbugs.gnu.org; 16 May 2015 13:15:25 +0000 Received: from localhost ([127.0.0.1]:46852 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ytbw4-0003DU-AV for submit@debbugs.gnu.org; Sat, 16 May 2015 09:15:24 -0400 Received: from mail-wi0-f181.google.com ([209.85.212.181]:37854) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ytbw1-0003DF-OP for 20292-done@debbugs.gnu.org; Sat, 16 May 2015 09:15:22 -0400 Received: by wibt6 with SMTP id t6so21568876wib.0 for <20292-done@debbugs.gnu.org>; Sat, 16 May 2015 06:15:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=9Wq4oCX1hFeIsDCbEZPB9ortdIZivc+n84uM0uIWG/E=; b=zHrC0WeuzMerxgkaZzD+zU3x2X5Mp/wi+Zs2OCtLNdxY3ZhE4ghitHimq7/KAi6JRz djSvyIyRpzveq9RkEh2X4uJYyX1JKepwG+FU7y0JoEX6w0Kxx7jPwnXDj5wwR6r0DE3Q 6kZSE0+SxMMMEO1euvOlLw8OaFBt78KMl+ANLqMgpH/akGysbdplJKMWMEk8J7qCmt78 OQL0Qc0vNu53FlET8kF6sJ4IvlQV+GWxO1ZDEw1NauIVKLew3xCwTFqFjdEKvZsfiOk4 WyEVtpyCxjaebAlMz1FtPSENTCRVdkXG4CXaMKbOGFYQDYwdicTR/EMOFXDzfw3g9Fxb VHhA== X-Received: by 10.194.121.135 with SMTP id lk7mr5665917wjb.109.1431782116119; Sat, 16 May 2015 06:15:16 -0700 (PDT) Received: from [192.168.0.185] (static-nbl2-118.cytanet.com.cy. [212.31.107.118]) by mx.google.com with ESMTPSA id r9sm7291860wjo.26.2015.05.16.06.15.13 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 16 May 2015 06:15:14 -0700 (PDT) Subject: Re: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file To: Eli Zaretskii References: <83fv88ta5r.fsf@gnu.org> <5533F446.4020400@yandex.ru> <83fv7u6epr.fsf@gnu.org> <838udm61ur.fsf@gnu.org> <5536FE56.406@yandex.ru> <83egnc4nu5.fsf@gnu.org> <55528906.7060606@yandex.ru> <83zj58jvri.fsf@gnu.org> <834mnfjjlz.fsf@gnu.org> <5554DBB2.3070005@yandex.ru> <83mw17huqr.fsf@gnu.org> <5554EDF5.5050606@yandex.ru> <83iobvhtzw.fsf@gnu.org> <5554F2F3.6010109@yandex.ru> <83fv6zhs3j.fsf@gnu.org> <55550482.1020404@yandex.ru> <55568661.90506@yandex.ru> <83bnhlgfi0.fsf@gnu.org> <5556F9D8.4070503@yandex.ru> <83617shpfo.fsf@gnu.org> From: Dmitry Gutov Message-ID: <555742E0.40909@yandex.ru> Date: Sat, 16 May 2015 16:15:12 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 MIME-Version: 1.0 In-Reply-To: <83617shpfo.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 20292-done Cc: esr@snark.thyrsus.com, monnier@iro.umontreal.ca, 20292-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 05/16/2015 11:55 AM, Eli Zaretskii wrote: > Great, thanks. Pushed, with some tweaks. ------------=_1431782163-12422-3 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 20 Mar 2015 09:13:30 +0000 Received: from localhost ([127.0.0.1]:58824 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YYszh-0006sn-Cd for submit@debbugs.gnu.org; Fri, 20 Mar 2015 05:13:29 -0400 Received: from eggs.gnu.org ([208.118.235.92]:54490) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YYszf-0006sa-AM for submit@debbugs.gnu.org; Fri, 20 Mar 2015 05:13:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YYszY-0007td-AY for submit@debbugs.gnu.org; Fri, 20 Mar 2015 05:13:22 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:58691) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YYszY-0007tT-6z for submit@debbugs.gnu.org; Fri, 20 Mar 2015 05:13:20 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56189) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YYszW-0006ZH-Tn for bug-gnu-emacs@gnu.org; Fri, 20 Mar 2015 05:13:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YYszV-0007sr-J0 for bug-gnu-emacs@gnu.org; Fri, 20 Mar 2015 05:13:18 -0400 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:52606) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YYszV-0007sn-Fq for bug-gnu-emacs@gnu.org; Fri, 20 Mar 2015 05:13:17 -0400 Received: from localhost ([127.0.0.1]:59780 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YYszV-0008Ua-1V for bug-gnu-emacs@gnu.org; Fri, 20 Mar 2015 05:13:17 -0400 Received: by lola (Postfix, from userid 1000) id 1A913E0DD6; Fri, 20 Mar 2015 10:13:07 +0100 (CET) From: David Kastrup To: bug-gnu-emacs@gnu.org Subject: 25.0.50; Smerge does "git add" for every final conflict resolution Date: Fri, 20 Mar 2015 10:13:07 +0100 Message-ID: <87iodwc9r0.fsf@fencepost.gnu.org> MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) When Smerge-mode has fixed the final conflict in a Git conflict, it adds the file to the index. However, when the conflict occured as the result of "git stash pop" action in the work directory, the state of the index should not be touched: the whole point of using git stash is to store work directory and index separately and restore them separately. So probably Smerge-mode would have to check whether a conflict is recorded in the index before overwriting it. In GNU Emacs 25.0.50.1 (i686-pc-linux-gnu, GTK+ Version 3.12.2) of 2015-03-04 on lola Repository revision: ca2b0e220ee6b2cab538e84703559696ce477e71 Windowing system distributor `The X.Org Foundation', version 11.0.11600000 System Description: Ubuntu 14.10 Configured using: `configure --without-toolkit-scroll-bars' Configured features: XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS NOTIFY LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB Important settings: value of $LC_MONETARY: en_US.UTF-8 value of $LC_NUMERIC: en_US.UTF-8 value of $LC_TIME: en_US.UTF-8 value of $LANG: en_US.UTF-8 value of $XMODIFIERS: @im=ibus locale-coding-system: utf-8-unix Major mode: Emacs-Lisp Minor modes in effect: whitespace-mode: t shell-dirtrack-mode: t TeX-PDF-mode: t diff-auto-refine-mode: t desktop-save-mode: t minibuffer-electric-default-mode: t tooltip-mode: t global-eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t Recent messages: smerge-next is on , C-c ^ n Entering debugger... Continuing. smerge-ensure-match: No `base' Saving file /home/dak/lilymidi/lily-midi.el... Wrote /home/dak/lilymidi/lily-midi.el Whitespace mode enabled in current buffer You can run the command `whitespace-mode' with M-x whit-m RET Whitespace mode enabled in current buffer scroll-down-command: Beginning of buffer scroll-up-command: End of buffer Load-path shadows: None found. Features: (shadow emacsbug whitespace lily-midi midi-kbd pcmpl-unix pcmpl-gnu pp ccl shell pcomplete warnings misearch multi-isearch dabbrev gnus-dup apropos eieio-opt speedbar sb-image ezimage dframe find-func sendmail nnir debug gnus-kill shr-color color mule-util flow-fill sort smiley gnus-cite mm-archive mail-extr gnus-async gnus-bcklg qp gnus-ml disp-table pop3 nndir nndraft nnmh help-mode gnutls network-stream nsm starttls nnml nnfolder nnnil gnus-agent gnus-srvr gnus-score score-mode nnvirtual gnus-msg gnus-art mm-uu mml2015 mm-view mml-smime smime dig nntp gnus-cache gnus-sum gnus-group gnus-undo gnus-start gnus-cloud nnimap nnmail mail-source tls utf7 netrc nnoo parse-time gnus-spec gnus-int gnus-range message rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums mailabbrev gmm-utils mailheader gnus-win eww mm-url url-queue url url-proxy url-privacy url-expand url-methods url-history url-cookie url-domsuf url-util url-parse auth-source cl-macs eieio gv eieio-core cl-generic password-cache url-vars mailcap shr dom subr-x pcase browse-url format-spec sh-script smie executable make-mode smerge-mode nxml-uchnm rng-xsd xsd-regexp rng-cmpct rng-nxml rng-valid rng-loc rng-uri rng-parse nxml-parse rng-match rng-dt rng-util rng-pttrn nxml-ns nxml-mode nxml-outln nxml-rap nxml-util nxml-glyph nxml-enc xmltok dired-x dired python json autorevert filenotify bug-reference add-log latexenc tex-info texinfo preview prv-emacs reftex-dcr reftex-auc reftex reftex-vars tex-bar tex-buf toolbar-x noutline outline font-latex byte-opt bytecomp byte-compile cl-extra seq cconv latex edmacro kmacro tex-style tex dbus xml crm lilypond-mode compile comint ansi-color ring jka-compr scheme vc vc-dispatcher vc-git diff-mode easy-mmode cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs info easymenu package epg-config advice desktop frameset minibuf-eldef gnus gnus-ems nnheader gnus-util mail-utils mm-util help-fns mail-prsvr wid-edit cl-loaddefs cl-lib cus-start cus-load preview-latex tex-site auto-loads server time-date tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote make-network-process dbusbind gfilenotify dynamic-setting system-font-setting font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs) Memory information: ((conses 8 696689 124897) (symbols 24 55713 157) (miscs 20 1205 2247) (strings 16 119776 17186) (string-bytes 1 3828540) (vectors 8 48240) (vector-slots 4 1789635 56924) (floats 8 541 993) (intervals 28 35923 854) (buffers 520 295) (heap 1024 71211 19354)) -- David Kastrup ------------=_1431782163-12422-3-- From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 16 May 2015 13:50:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: esr@snark.thyrsus.com, Eli Zaretskii , 20292@debbugs.gnu.org Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.143178415015680 (code B ref 20292); Sat, 16 May 2015 13:50:03 +0000 Received: (at 20292) by debbugs.gnu.org; 16 May 2015 13:49:10 +0000 Received: from localhost ([127.0.0.1]:46867 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YtcSi-00044o-LN for submit@debbugs.gnu.org; Sat, 16 May 2015 09:49:09 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:45363) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YtcSe-00044J-Of for 20292@debbugs.gnu.org; Sat, 16 May 2015 09:49:05 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAGvvdVRFpYts/2dsb2JhbAA3gVOhb4EIgXUBAQQBVh4FEAsOJgcLFBgNJIgTohGMJz0JAQIBAoM+Aw4ECoNUBKNjhFg X-IPAS-Result: AgUFAGvvdVRFpYts/2dsb2JhbAA3gVOhb4EIgXUBAQQBVh4FEAsOJgcLFBgNJIgTohGMJz0JAQIBAoM+Aw4ECoNUBKNjhFg X-IronPort-AV: E=Sophos;i="5.11,557,1422939600"; d="scan'208";a="120189894" Received: from 69-165-139-108.dsl.teksavvy.com (HELO pastel.home) ([69.165.139.108]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 May 2015 09:49:00 -0400 Received: by pastel.home (Postfix, from userid 20848) id D45F52608; Sat, 16 May 2015 09:48:58 -0400 (EDT) From: Stefan Monnier Message-ID: References: <83fv88ta5r.fsf@gnu.org> <55528906.7060606@yandex.ru> <83zj58jvri.fsf@gnu.org> <834mnfjjlz.fsf@gnu.org> <5554DBB2.3070005@yandex.ru> <83mw17huqr.fsf@gnu.org> <5554EDF5.5050606@yandex.ru> <83iobvhtzw.fsf@gnu.org> <5554F2F3.6010109@yandex.ru> <83fv6zhs3j.fsf@gnu.org> <55550482.1020404@yandex.ru> <83bnhmia75.fsf@gnu.org> <83mw15hdqn.fsf@gnu.org> <83iobth9uw.fsf@gnu.org> <555687E4.8070605@yandex.ru> Date: Sat, 16 May 2015 09:48:58 -0400 In-Reply-To: <555687E4.8070605@yandex.ru> (Dmitry Gutov's message of "Sat, 16 May 2015 02:57:24 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) >> and AFAIK those cases can't be distinguished solely based on the >> state of the current file but also depend on the other files in >> the project. > That's not a problem, we have vc-git-root. It's not a theoretical problem, no, but it's a practical/programming problem in that someone has to write the code, and the resulting code will be that much more brittle and inefficient. Stefan From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 16 May 2015 13:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: esr@snark.thyrsus.com, Eli Zaretskii , 20292@debbugs.gnu.org Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.143178440116072 (code B ref 20292); Sat, 16 May 2015 13:54:02 +0000 Received: (at 20292) by debbugs.gnu.org; 16 May 2015 13:53:21 +0000 Received: from localhost ([127.0.0.1]:46874 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YtcWm-0004BA-Jt for submit@debbugs.gnu.org; Sat, 16 May 2015 09:53:20 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:32195) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YtcWk-0004Au-K7 for 20292@debbugs.gnu.org; Sat, 16 May 2015 09:53:18 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAGvvdVRFpYts/2dsb2JhbAA3gVOhb4EIgXUBAQQBVh4FBQsLDiYHCxQYDSSIE6IRjGQJAwECgz4DDgQKg1QEo2OEWA X-IPAS-Result: AgUFAGvvdVRFpYts/2dsb2JhbAA3gVOhb4EIgXUBAQQBVh4FBQsLDiYHCxQYDSSIE6IRjGQJAwECgz4DDgQKg1QEo2OEWA X-IronPort-AV: E=Sophos;i="5.11,557,1422939600"; d="scan'208";a="120190259" Received: from 69-165-139-108.dsl.teksavvy.com (HELO pastel.home) ([69.165.139.108]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 May 2015 09:53:14 -0400 Received: by pastel.home (Postfix, from userid 20848) id D82112608; Sat, 16 May 2015 09:53:12 -0400 (EDT) From: Stefan Monnier Message-ID: References: <83fv88ta5r.fsf@gnu.org> <83fv7u6epr.fsf@gnu.org> <838udm61ur.fsf@gnu.org> <5536FE56.406@yandex.ru> <83egnc4nu5.fsf@gnu.org> <55528906.7060606@yandex.ru> <83zj58jvri.fsf@gnu.org> <834mnfjjlz.fsf@gnu.org> <5554DBB2.3070005@yandex.ru> <83mw17huqr.fsf@gnu.org> <5554EDF5.5050606@yandex.ru> <83iobvhtzw.fsf@gnu.org> <5554F2F3.6010109@yandex.ru> <83fv6zhs3j.fsf@gnu.org> <55550482.1020404@yandex.ru> <55568661.90506@yandex.ru> Date: Sat, 16 May 2015 09:53:12 -0400 In-Reply-To: <55568661.90506@yandex.ru> (Dmitry Gutov's message of "Sat, 16 May 2015 02:50:57 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > If we're fine with a config var, we might as well try to support the > alternative behavior. This should do it: Looks OK to me. > + :group 'vc-git) This is redundant. > + (when (and > + (eq vc-git-resolve-conflicts 'unstage) > + ;; Doing something other than a merge. Likely applying a > + ;; stash (bug#20292). > + (not > + (file-exists-p (expand-file-name ".git/MERGE_HEAD" > + (vc-git-root > buffer-file-name)))) > + (not (vc-git-conflicted-files (vc-git-root > buffer-file-name)))) If you switch to "(unless (or ..." you'll get rid of one "not". Stefan From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 16 May 2015 14:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: esr@snark.thyrsus.com, 20292@debbugs.gnu.org Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.143178560518512 (code B ref 20292); Sat, 16 May 2015 14:14:02 +0000 Received: (at 20292) by debbugs.gnu.org; 16 May 2015 14:13:25 +0000 Received: from localhost ([127.0.0.1]:47396 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YtcqC-0004oV-PP for submit@debbugs.gnu.org; Sat, 16 May 2015 10:13:25 -0400 Received: from mail-wi0-f177.google.com ([209.85.212.177]:38175) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YtcqA-0004oJ-Qb for 20292@debbugs.gnu.org; Sat, 16 May 2015 10:13:23 -0400 Received: by wicnf17 with SMTP id nf17so22625578wic.1 for <20292@debbugs.gnu.org>; Sat, 16 May 2015 07:13:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=4CUf4nBV7U46NzEQ7oanb+KU7RE/wPFVzlRBybDPLms=; b=WO63p872CNrnyWYO0JDH7R42+VCGzvXunRFFv4M4ByTTa1bEHb79ZDS+pqXbasW+05 br/OLxEjU5Is3VwoOEjcdnyohE4y2SReGML1kLjtfr86eWwHuDEC9clg4HKq6ana62mY nFEjR3YwPF7HF0Z8fLdWgHyUBtarmUkNWA3DVADfsE0He87lglGVVmK8PFh2FHu88ElK IzmTNg/DSuujY7h1hBwdRU9hhla5A6K+bfZ9IKaavtU08RmSvzoxsHPdY+Fo0F4A0NN+ zNDuaDxU9esoqQFVURS86DWixGzmG/HkGXduBp3n8dXnI7ntpPCiFi53ahByJ7xQnLbD Q6HQ== X-Received: by 10.180.11.236 with SMTP id t12mr6264242wib.19.1431785597223; Sat, 16 May 2015 07:13:17 -0700 (PDT) Received: from [192.168.0.185] (static-nbl2-118.cytanet.com.cy. [212.31.107.118]) by mx.google.com with ESMTPSA id l6sm3066871wib.18.2015.05.16.07.13.16 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 16 May 2015 07:13:17 -0700 (PDT) References: <83fv88ta5r.fsf@gnu.org> <83fv7u6epr.fsf@gnu.org> <838udm61ur.fsf@gnu.org> <5536FE56.406@yandex.ru> <83egnc4nu5.fsf@gnu.org> <55528906.7060606@yandex.ru> <83zj58jvri.fsf@gnu.org> <834mnfjjlz.fsf@gnu.org> <5554DBB2.3070005@yandex.ru> <83mw17huqr.fsf@gnu.org> <5554EDF5.5050606@yandex.ru> <83iobvhtzw.fsf@gnu.org> <5554F2F3.6010109@yandex.ru> <83fv6zhs3j.fsf@gnu.org> <55550482.1020404@yandex.ru> <55568661.90506@yandex.ru> From: Dmitry Gutov Message-ID: <5557507B.80901@yandex.ru> Date: Sat, 16 May 2015 17:13:15 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 05/16/2015 04:53 PM, Stefan Monnier wrote: > This is redundant. > If you switch to "(unless (or ..." you'll get rid of one "not". These should be addressed now. From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 27 13:44:29 2016 Received: (at control) by debbugs.gnu.org; 27 Oct 2016 17:44:29 +0000 Received: from localhost ([127.0.0.1]:32799 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bzoj7-0001ih-6S for submit@debbugs.gnu.org; Thu, 27 Oct 2016 13:44:29 -0400 Received: from mail-qk0-f179.google.com ([209.85.220.179]:32983) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bzoFg-0000yF-43 for control@debbugs.gnu.org; Thu, 27 Oct 2016 13:14:04 -0400 Received: by mail-qk0-f179.google.com with SMTP id v138so159556qka.0 for ; Thu, 27 Oct 2016 10:14:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=1O9CbS15ekFLXoKPRpaUxZWjncZ39NA1OM45VDFBFkQ=; b=ysS45ywikiTJ+YM5j8RhyXFEmG94FE4eAzPT34Dn0Lfh/nF0Cx1ocMywY0qaKucpSq egJZfOJ9ul8RISYm8zSZRnM1Da/WXC7g1R9G76YlBCVCrOgXKP1j1gLKvFcWcd6vpisA VLcR7yQdqYRhCFI2RSvGZJyRQxcH14fB1N/fkboMdAENBtwfNuuvaMaz5mz8mOnbg0qH OOL+9Y0OPkyzeawX2CtjkEek4chFOKTrg8plbnJWx/Gzd9kWPjChmjqHUlTWFm3RKg7O 0zV3slODZcAOFG1MX11a0TNh5ySuebj/MItys8mJec/OmxoPjTV+qKDkVtybjo0VMUed qZAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=1O9CbS15ekFLXoKPRpaUxZWjncZ39NA1OM45VDFBFkQ=; b=VRYghkqByKlND3QPhN+eTmHSwW/WImQFrsJp3yLOq6r/m+zFTPaZEfYDw7/dnWb/M/ W0rhL41xC5yng5gkOajbp5D+nKoBNXDZwkOdIljEohvQ2h+BO0ZBluiOqJvONgE/40e4 SbJQ84erLZnBwQNV8xlMXfjrmRF7y+JsvK1NPrb+RCGt/DxZjwcRfHWmpeWEFdiSzl/D obZ/M4+AVfEKghn1W5SdGM8u3d9BYBfCmRezTU+luPCeOd3wpt5vcTdW+v2BVIjkOgtI Fw34fBSVEdEYTWgiFPKMhLece0rGygI0+Fe2bmreeQd8s2eTn+tU3zAC6ohQN2JKdXSv jRQQ== X-Gm-Message-State: ABUngvcTpu3mG7UC4I7ZqhookQUdadRi4mTyO0DvHzLWnWlQfqglsszecy79AwFdvE8Q7pc0L0feeEXYvue9HA== X-Received: by 10.55.154.200 with SMTP id c191mr6950659qke.117.1477588438130; Thu, 27 Oct 2016 10:13:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.22.203 with HTTP; Thu, 27 Oct 2016 10:13:37 -0700 (PDT) From: Junio C Hamano Date: Thu, 27 Oct 2016 10:13:37 -0700 X-Google-Sender-Auth: XHZk-mvTVHDsdL5C_ve9VfoowtY Message-ID: Subject: unarchive 20292 To: control@debbugs.gnu.org Content-Type: text/plain; charset=UTF-8 X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: control X-Mailman-Approved-At: Thu, 27 Oct 2016 13:44:27 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.2 (/) unarchive 20292 From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Nov 2016 00:26:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Junio C Hamano , 20292@debbugs.gnu.org Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.147925594830658 (code B ref 20292); Wed, 16 Nov 2016 00:26:01 +0000 Received: (at 20292) by debbugs.gnu.org; 16 Nov 2016 00:25:48 +0000 Received: from localhost ([127.0.0.1]:58648 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c6o2t-0007yO-TB for submit@debbugs.gnu.org; Tue, 15 Nov 2016 19:25:48 -0500 Received: from mail-wm0-f66.google.com ([74.125.82.66]:35691) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c6o2s-0007yC-Hy for 20292@debbugs.gnu.org; Tue, 15 Nov 2016 19:25:46 -0500 Received: by mail-wm0-f66.google.com with SMTP id a20so5579336wme.2 for <20292@debbugs.gnu.org>; Tue, 15 Nov 2016 16:25:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=hnoGjWzCVZFVCPyjCb4XKf9CSWHWybFTGzgREM9j2EA=; b=SRSqq7NvX+OR2yLaGjqE0svgZD3v43YpnHRUO/Vthd7Lub63V7eBG9kEnv8pfgspnr alrFNP8INuiYl8Vixt33J8sS7GN6IizvwWau2ALNo6ZiZqA34KM8ZEqRn0ie64yW79Eh GIL2eKCj0ClVQBtCykwO3cBL4pdQULtBsivKtZVC+n52Okx+KEUZzlyuewucJTjAZQzJ gayLK6j5a4NDGFj+tyg1/IuHKQRKa45qFDtMg7hrvsvTZtUKzMkIgMLeLTrgZ3fUuMXa 8rpUDDC1O8S9aa6olDpwrhvyDEotMzJtmUXHcjaWEFBqQ38U9mTwC0KlS9epkAUXkdmo 1fIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=hnoGjWzCVZFVCPyjCb4XKf9CSWHWybFTGzgREM9j2EA=; b=iOwoJTroBUxCVCMOsTq/F5BMvGccEfxKmk9KpM2ih9QZ/CS7Lw3z0TrXXYq5Ck3yZH oulVV7VCFxJeQGBIsrt8pviRsLySNNN1N6rEbbG+Vq6eo99ICgyl9kk4j4B6Vrp7Jp4G ZyBz1+i7iqDlXzudzggLQe8xEUfm8wh1T2nkcVcEJOGwpHb459Nv0u8N9S3+1qaW42iq OjgfmwELEDIngjFcdVFaPGaerECxscqdRThbJWuFcvpZiU4fojH/5hi8JmqBqORALZPT XP2wyIXosELsP9YARHp/K72U0iVfauDEIeeNfmGeqCO/fumb7tEVSvULUDfcHcyrwlsG bUig== X-Gm-Message-State: ABUngvdrDbjWNL18dDRV9kavzndfvNswcoPRKid3BpBVtlFHm+JZf9SRW6eim4PV913FeQ== X-Received: by 10.194.107.97 with SMTP id hb1mr42646wjb.134.1479255940722; Tue, 15 Nov 2016 16:25:40 -0800 (PST) Received: from [192.168.1.3] ([185.105.173.41]) by smtp.googlemail.com with ESMTPSA id e188sm6917820wma.21.2016.11.15.16.25.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Nov 2016 16:25:39 -0800 (PST) References: From: Dmitry Gutov Message-ID: Date: Wed, 16 Nov 2016 02:25:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Thunderbird/50.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) Hi Junio, Sorry for the late reply. Too bad neither of your emails were recorded in the bug report thread (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20292). Maybe it would be better if you file a separate bug report. On 27.10.2016 20:20, Junio C Hamano wrote: > The way Git is designed to be used is for the user to edit the > latter to come up with a conflict resolution in the working tree, > then add that result to the index, after the user is satisfied with > it, before continuing (typically, but not necessarily, to record the > result with "git commit"). > > Now, what about the cleanly automerged paths? They are added to the > index and this is by design. You can see why this is necessary by > doing: Thank you for the explanation. It does make sense now, but that does not necessarily mean that we should change what Emacs does about the conflicts. You see, the change in question is in vc-git, which is part of our VC package, which does not support every nifty feature of each VCS it handles, and instead tries to provide a unified UI to the whole bunch of them. In a lot of cases that means that we exchange power for simplicity. And while we might be happier with a more full-featured solution for dealing with conflicts (a new, better visualization, more controls), we don't have that now, and vc-git-resolve-conflicts is the faster, simple alternative we have come up with for now. > - But before doing "git add" to tell Git that you are done with > these paths, run "git diff" (no other parameters). You may have > to (setq vc-git-resolve-conflicts nil) for that > > You will notice that this invocation of "git diff" show concisely > how the result of your conflict resolution differs from either of > the branch. This is used by Git users as one of the final step of > verification before telling Git "I now am done with the conflict in > this path and resolution is good" by issuing "git add" for the path. > > You will also notice that this invocation of "git diff" does not > clutter with changes that have been auto-merged cleanly. At this > step of the workflow to resolve conflicts, the user is concentrating > on the paths that had conflicts, and it is crucial that cleanly > auto-merged paths do not get in the way. The user can still view > the overall picture by asking "git diff HEAD" (to see both > automerged result and hand-resolved result, the latter of which may > or may not have been added to the index) and "git diff --cached" (to > see automerged result and hand-resolved and then "git add"'ed > result). > > So, there is no "Bad news, everybody!" in the behaviour you > observed. You have quoted a fairly early message in that bug discussion. Later on, we have reached a solution that seems to have satisfied all participants. Although it still does the automatic 'git add' call which you seems to consider the main problem. >> What shall we do? Unstage the automatically-staged files? Revert the >> changes from this bug? It seems Git really wants the changes staged >> after the conflict resolution. > > I do not know what you thought you can achieve by "unstage the > auto-merged paths?" here, but perhaps you were expecting "git diff" > (no arguments) would be the way to view all the changes that a mergy > operation with conflicted states brought in? Not really. We get the "unstage the automatically-staged files" effect by calling "git reset" when the user has made an explicit configuration to do that and there's no ".git/MERGE_HEAD" (see the definition of vc-git-resolve-when-done). To put it simply, we wanted to be able to easily resolve the merge conflict after e.g. 'git stash pop' without having to additionally interact with Git outside of Emacs. The current behavior is a compromise that allows us to achieve that. It also mirrors a similar feature in our Bazaar VC backend (which certain developers have grown accustomed to). > If that (i.e. "view > all the changes") was what you wanted to achieve, then neither > "unstage the auto-merged paths" nor "automatically 'git add' upon > saving the buffer" is a good solution. > > I was told by somebody that the message I am responding to > eventually resulted in vc-git-resolve-conflicts that defaults to > true in Emacs 25.1, which lead to "automatically 'git add' upon > saving the buffer". I think this variable and its default is a big > disservice to Git users' whose daily work involves lots of conflict > resolutions in mergy operations. The ability to 'git diff' which you have described seems fairly obscure to me and the majority of Emacs/Git users, so even if we make vc-git-resolve-conflicts default to nil, it's unlikely that the majority of users will really benefit from that. You, as a core Git developer, represent the informed minority, and as such, it's probably not too much to expect that you and the others can customize vc-git-resolve-conflicts to nil without much trouble. That said, I was not the one to add this variable, and though so far I have found it useful enough, I wouldn't miss it too much either. On the other hand, we haven't received any bug reports about it so far, so maybe most users either don't notice the new behavior, or have found it handy. Best regards, Dmitry. From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Nov 2016 17:31:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 20292@debbugs.gnu.org, gitster@pobox.com Reply-To: Eli Zaretskii Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.147931741414137 (code B ref 20292); Wed, 16 Nov 2016 17:31:01 +0000 Received: (at 20292) by debbugs.gnu.org; 16 Nov 2016 17:30:14 +0000 Received: from localhost ([127.0.0.1]:59824 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c742I-0003fx-Dp for submit@debbugs.gnu.org; Wed, 16 Nov 2016 12:30:14 -0500 Received: from eggs.gnu.org ([208.118.235.92]:54120) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c742G-0003fi-U2 for 20292@debbugs.gnu.org; Wed, 16 Nov 2016 12:30:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c7427-0004qV-N8 for 20292@debbugs.gnu.org; Wed, 16 Nov 2016 12:30:07 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:54917) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c7427-0004qR-KU; Wed, 16 Nov 2016 12:30:03 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4365 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1c7426-00037W-Pk; Wed, 16 Nov 2016 12:30:03 -0500 Date: Wed, 16 Nov 2016 19:30:02 +0200 Message-Id: <83h977fi3p.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Dmitry Gutov on Wed, 16 Nov 2016 02:25:32 +0200) References: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -7.9 (-------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -7.9 (-------) > From: Dmitry Gutov > Date: Wed, 16 Nov 2016 02:25:32 +0200 > > Sorry for the late reply. Too bad neither of your emails were recorded > in the bug report thread > (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20292). I don't even see the message you are responding to. Was it sent only to you, Dmitry? > The ability to 'git diff' which you have described seems fairly obscure > to me and the majority of Emacs/Git users, so even if we make > vc-git-resolve-conflicts default to nil, it's unlikely that the majority > of users will really benefit from that. > > You, as a core Git developer, represent the informed minority, and as > such, it's probably not too much to expect that you and the others can > customize vc-git-resolve-conflicts to nil without much trouble. Perhaps there could be a way to customize vc-git so that it caters to such advanced users? From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Nov 2016 22:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 20292@debbugs.gnu.org, gitster@pobox.com Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.147933635312562 (code B ref 20292); Wed, 16 Nov 2016 22:46:02 +0000 Received: (at 20292) by debbugs.gnu.org; 16 Nov 2016 22:45:53 +0000 Received: from localhost ([127.0.0.1]:59941 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c78xk-0003GY-KY for submit@debbugs.gnu.org; Wed, 16 Nov 2016 17:45:52 -0500 Received: from mail-wm0-f46.google.com ([74.125.82.46]:35135) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c78xj-0003GK-B3 for 20292@debbugs.gnu.org; Wed, 16 Nov 2016 17:45:51 -0500 Received: by mail-wm0-f46.google.com with SMTP id a197so272073198wmd.0 for <20292@debbugs.gnu.org>; Wed, 16 Nov 2016 14:45:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=dSpAxbo9NInH48q79zuY+iR91PT2RfUjP7hsPe2M4/s=; b=PnhY1ZMVQsZmhc01zYr+cYRSvZKnzCE8P+f2USArRBtGPvkJI9NXxBokacCyGenSf6 yI0Rqci8qCDrsNWrDTXEHZ1yLa/+8SB4VGfLtReQVo50pR+vX7SiySErCKSEhBjOBWv1 wfcGHYnJeVKHNzFNvEDNoKjUjRlJIQtgV5oyHYCkKvP9vF0XIbaZKHEGolqZ834HaQuK RjLlUFHg92K89JcCHnBjoyXnjRWZQW4k3AFAyz6tmBXsQ6L1bVeaeDJBxXiMZHm17DoJ XBECzP8AdH7FeT8vbHPpKnN/Qv4wvcWScyjH8f3K2neoUZq4BYj5Q6ltvVOcqpzovNTK v8cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-language; bh=dSpAxbo9NInH48q79zuY+iR91PT2RfUjP7hsPe2M4/s=; b=fDCBSp9FIZSa5guad80dRTiYh3MgiBIduw671LMEXwb+VjS2qTO0nolPKUOHmyweUM X2bC1BivMqBnemj+FK9zUi/Tt8bteZegCTbxeOlJdwPnXJYKAztP/rgziz5YGiXXVULa 9IRS47gqwBaP0Dyh+KSIFy9w3vipbP8OFt2L/YqNIrykgnrVNSY/une6BTBabyPE4ZiZ IIW6v5lzNuXRzdjDJHmydVL9DAyLhRkR2sbSWjbJ3cvGu4jfM3hjjDhRLbX4JNFhfXpE 2vpN3xHP6pvLQmwyIGPHEy1MamurXjchDhDUMqnb7pGHCVNggYMmzwu+rvB5AGfB8E4n 6dZw== X-Gm-Message-State: ABUngvfmWrKsUoGCUvieXZKPh9wqYDEwz2Hyx1hk6HvBLUTqb+1dhjOrdjqa2uiRoFSZZg== X-Received: by 10.28.232.16 with SMTP id f16mr510105wmh.103.1479336345687; Wed, 16 Nov 2016 14:45:45 -0800 (PST) Received: from [192.168.1.3] ([185.105.173.41]) by smtp.googlemail.com with ESMTPSA id 135sm528738wmh.14.2016.11.16.14.45.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Nov 2016 14:45:44 -0800 (PST) References: <83h977fi3p.fsf@gnu.org> From: Dmitry Gutov Message-ID: Date: Thu, 17 Nov 2016 00:45:43 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Thunderbird/50.0 MIME-Version: 1.0 In-Reply-To: <83h977fi3p.fsf@gnu.org> Content-Type: multipart/mixed; boundary="------------13F9296C272AE6A78E3428E9" Content-Language: en-US X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) This is a multi-part message in MIME format. --------------13F9296C272AE6A78E3428E9 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 16.11.2016 19:30, Eli Zaretskii wrote: > I don't even see the message you are responding to. Was it sent only > to you, Dmitry? It was addressed to both me and the bug email, but didn't arrive at the latter. I'm attaching the full message here. >> You, as a core Git developer, represent the informed minority, and as >> such, it's probably not too much to expect that you and the others can >> customize vc-git-resolve-conflicts to nil without much trouble. > > Perhaps there could be a way to customize vc-git so that it caters to > such advanced users? vc-git-resolve-conflicts is already a user option. Were you thinking of something else? --------------13F9296C272AE6A78E3428E9 Content-Type: message/rfc822; name="Re: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after \"stash pop\" stages the file.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="Re: bug#20292: 24.5; Saving Git-controlled file with merge c"; filename*1="onflicts after \"stash pop\" stages the file.eml" Received: from mxfront6h.mail.yandex.net ([127.0.0.1]) by mxfront6h.mail.yandex.net with LMTP id K4YRSjOQ for ; Thu, 27 Oct 2016 20:20:57 +0300 Received: from pb-smtp2.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) by mxfront6h.mail.yandex.net (nwsmtp/Yandex) with ESMTPS id 6yz1VxnAk1-Kuk0kXjZ; Thu, 27 Oct 2016 20:20:56 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) Return-Path: junio@pobox.com X-Yandex-Front: mxfront6h.mail.yandex.net X-Yandex-TimeMark: 1477588856 Authentication-Results: mxfront6h.mail.yandex.net; spf=pass (mxfront6h.mail.yandex.net: domain of pobox.com designates 64.147.108.71 as permitted sender) smtp.mail=junio@pobox.com; dkim=pass header.i=@pobox.com X-Yandex-Spam: 1 Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id D33A049621; Thu, 27 Oct 2016 13:20:54 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:in-reply-to:date:message-id:mime-version:content-type; s=sasl; bh=vrrDMZxxYh3jslwe0ZI2oy/JDtI=; b=TI9IEsAv1018R6NzLt1g boMtZadsz4h6vlXvwhB/Z0enwt6wT8ChlnkKjYDz2A2ieJ27Jf/QuLu3Rdav0Nsp 6OZlPh7OVcW5CsgEtqgV9qEylVXfVyS9g37KR7hsfc4TFsa0BZiyriwFgVENgj2K bjwIorT3mVKhiP/QHjniGtw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:in-reply-to:date:message-id:mime-version:content-type; q=dns; s=sasl; b=pdgpeYLZJio/VPkvlMOSuqB7rHtXIz6KmvSElScFFnTQ1g T2LyvB/gkX6nbXHohilSrZBLQefTcwsgDHZ1D3AJC6ywA2QdqOkOyrYWjKelbEFy G6MnCWiPdG0enxOVycmwORv8bQRf4EkRanGme/pgHgeiPb1rcn3khUgebvsk8= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id CB1E549620; Thu, 27 Oct 2016 13:20:54 -0400 (EDT) Received: from pobox.com (unknown [104.132.0.95]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 483C04961F; Thu, 27 Oct 2016 13:20:54 -0400 (EDT) From: Junio C Hamano To: 20292@debbugs.gnu.org Cc: Dmitry Gutov Subject: Re: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file In-reply-to: <55528906.7060606@yandex.ru> Date: Thu, 27 Oct 2016 10:20:52 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Pobox-Relay-ID: B75BE8B6-9C69-11E6-AB10-3AB77A1B28F4-77302942!pb-smtp2.pobox.com X-Yandex-Forward: d73b28f8c179ee3553784c2a7b141268 X-Yandex-Filter: 208239 Sorry for responding to an ancient message, but you said > When a stash contains changes for several files, and "stash pop" > encounters conflicts only in some of them, the rest of the files are > stages automatically. > > So then when we unstage the files which had conflicts after > resolving those, the result is mixed. Which doesn't look right. But this is a completely normal and designed way how conflicts are resolved during any "mergy" operations in Git. It is not limited to "stash pop" (or "stash apply"). "git merge", "git cherry-pick", "git revert", "git am -3" and even "git checkout -m another-branch" share this feature. When doing a mergy operation, some paths will merge cleanly and some paths will have conflicts. A conflicted path will - leave multiple stages in the index; the common ancestor version in stage#1, the version you originally had in stage#2, and the version the mergy operation wanted to bring the changes from into your state in stage#3. - have conflicted merge result in the working tree, with the conflict markers. The way Git is designed to be used is for the user to edit the latter to come up with a conflict resolution in the working tree, then add that result to the index, after the user is satisfied with it, before continuing (typically, but not necessarily, to record the result with "git commit"). Now, what about the cleanly automerged paths? They are added to the index and this is by design. You can see why this is necessary by doing: - Start a mergy operation (e.g. "stash pop", or "git merge") that conflicts; - Resolve the conflicts in the working tree, - But before doing "git add" to tell Git that you are done with these paths, run "git diff" (no other parameters). You may have to (setq vc-git-resolve-conflicts nil) for that You will notice that this invocation of "git diff" show concisely how the result of your conflict resolution differs from either of the branch. This is used by Git users as one of the final step of verification before telling Git "I now am done with the conflict in this path and resolution is good" by issuing "git add" for the path. You will also notice that this invocation of "git diff" does not clutter with changes that have been auto-merged cleanly. At this step of the workflow to resolve conflicts, the user is concentrating on the paths that had conflicts, and it is crucial that cleanly auto-merged paths do not get in the way. The user can still view the overall picture by asking "git diff HEAD" (to see both automerged result and hand-resolved result, the latter of which may or may not have been added to the index) and "git diff --cached" (to see automerged result and hand-resolved and then "git add"'ed result). So, there is no "Bad news, everybody!" in the behaviour you observed. > What shall we do? Unstage the automatically-staged files? Revert the > changes from this bug? It seems Git really wants the changes staged > after the conflict resolution. I do not know what you thought you can achieve by "unstage the auto-merged paths?" here, but perhaps you were expecting "git diff" (no arguments) would be the way to view all the changes that a mergy operation with conflicted states brought in? If that (i.e. "view all the changes") was what you wanted to achieve, then neither "unstage the auto-merged paths" nor "automatically 'git add' upon saving the buffer" is a good solution. I was told by somebody that the message I am responding to eventually resulted in vc-git-resolve-conflicts that defaults to true in Emacs 25.1, which lead to "automatically 'git add' upon saving the buffer". I think this variable and its default is a big disservice to Git users' whose daily work involves lots of conflict resolutions in mergy operations. Running "git diff HEAD" instead of "git diff" may be the solution, if the problem were "I want to view all the changes, both already added to the index and the ones that have not been yet", though I am not sure from the "Bad news, everybody!" message if that is the problem you were trying to solve. --------------13F9296C272AE6A78E3428E9-- From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 17 Nov 2016 15:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 20292@debbugs.gnu.org, gitster@pobox.com Reply-To: Eli Zaretskii Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.147939825620890 (code B ref 20292); Thu, 17 Nov 2016 15:58:02 +0000 Received: (at 20292) by debbugs.gnu.org; 17 Nov 2016 15:57:36 +0000 Received: from localhost ([127.0.0.1]:60845 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c7P4B-0005Qr-Ul for submit@debbugs.gnu.org; Thu, 17 Nov 2016 10:57:36 -0500 Received: from eggs.gnu.org ([208.118.235.92]:38316) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c7P4A-0005Qc-5W for 20292@debbugs.gnu.org; Thu, 17 Nov 2016 10:57:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c7P41-0005x5-0a for 20292@debbugs.gnu.org; Thu, 17 Nov 2016 10:57:29 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:44997) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c7P40-0005x0-Sz; Thu, 17 Nov 2016 10:57:24 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1496 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1c7P40-0003PC-4x; Thu, 17 Nov 2016 10:57:24 -0500 Date: Thu, 17 Nov 2016 17:57:25 +0200 Message-Id: <834m36f6ai.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Dmitry Gutov on Thu, 17 Nov 2016 00:45:43 +0200) References: <83h977fi3p.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -7.9 (-------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -7.9 (-------) > Cc: gitster@pobox.com, 20292@debbugs.gnu.org > From: Dmitry Gutov > Date: Thu, 17 Nov 2016 00:45:43 +0200 > > > I don't even see the message you are responding to. Was it sent only > > to you, Dmitry? > > It was addressed to both me and the bug email, but didn't arrive at the > latter. I'm attaching the full message here. Thanks. I don't understand why it is not on the tracker, I guess it wasn't actually sent there, for some reason. > >> You, as a core Git developer, represent the informed minority, and as > >> such, it's probably not too much to expect that you and the others can > >> customize vc-git-resolve-conflicts to nil without much trouble. > > > > Perhaps there could be a way to customize vc-git so that it caters to > > such advanced users? > > vc-git-resolve-conflicts is already a user option. My impression was that Juno, for some reason, finds that insufficient. But if I misunderstood, and the issue is only with its default value, then indeed I see no problem. From unknown Mon Jun 23 23:55:28 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 17 Nov 2016 18:05:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20292 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 20292@debbugs.gnu.org, gitster@pobox.com Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.14794058771223 (code B ref 20292); Thu, 17 Nov 2016 18:05:01 +0000 Received: (at 20292) by debbugs.gnu.org; 17 Nov 2016 18:04:37 +0000 Received: from localhost ([127.0.0.1]:60928 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c7R36-0000Jf-Qs for submit@debbugs.gnu.org; Thu, 17 Nov 2016 13:04:36 -0500 Received: from mail-wm0-f48.google.com ([74.125.82.48]:36179) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c7R35-0000JT-Jq for 20292@debbugs.gnu.org; Thu, 17 Nov 2016 13:04:35 -0500 Received: by mail-wm0-f48.google.com with SMTP id g23so327038571wme.1 for <20292@debbugs.gnu.org>; Thu, 17 Nov 2016 10:04:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=yOPvxNKM7yvwdq2kph3F92CqibYMBB6v0PHU7dzlElw=; b=fi9RXWqNzVffFI8W8/qTeyena7zJg4WJ/yWgJUCDqiewR6dgUR5B9fpJez/rpYIAEJ j7vHJgngdk0tNCRAT2TV1WAZDt4o+3Xqq307RYoTnCeykH9pJCT/JEDHY/eX+u4tiCEG XbKDm9O9cUp8EF9v0V4yyylBLwAGDXuv/tMnJAhnv0ykOVAbxbUTgG2omfo6YFOU63Y9 K2++YXDWakyx01U2v9ddziklDypNXO9qkRh+uPcOwnhVuN5N6okltPjbDhD3mKDWYfQo CRSoKNWHQQN8SW03SeUAPHJdg+YQVPZGpm+e1CiWMwmBQuXDmYipHEBkYB5cYEoeG+4f jSUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=yOPvxNKM7yvwdq2kph3F92CqibYMBB6v0PHU7dzlElw=; b=B3YXzw0v2nXSX14WCYq2YrZTHyLyPb0nAEKu1tErFaIUD9aHSwO9b8GPa4BCQMOYOp xICllyCR4pS3j/++/PeCemCsIEd4EzU1LvVSFpiHz3B5jfm3vSyGgAneuFYT3qg7f4DM 7EigxUEbdExzZzQvl3/68UaHM5S9MowafHC0la2FPyqnueAwzyPjsBhqVA9y9PhOPlQ3 dbAlTL6b1aCzdsypr2xZ4QE8RsRr1EKeGM24vEhfz45h/hgC05Qe6bM1ImdlksaVkQqR J2aiZEpKn8msFPJmZkFFGnfc6z5mAbIEzCk+4VPXaLzp+LzaD80yK0o9u8lE2QUga8VQ /94w== X-Gm-Message-State: AKaTC033nEyQU2hrX5bKJhz1BDZoHOddCbK63f+KcFv4ZLrGR2tZARvXzTKAEFhDotLlTQ== X-Received: by 10.28.63.3 with SMTP id m3mr5834611wma.113.1479405869858; Thu, 17 Nov 2016 10:04:29 -0800 (PST) Received: from [192.168.1.3] ([185.105.173.41]) by smtp.googlemail.com with ESMTPSA id d17sm4509581wjr.14.2016.11.17.10.04.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Nov 2016 10:04:29 -0800 (PST) References: <83h977fi3p.fsf@gnu.org> <834m36f6ai.fsf@gnu.org> From: Dmitry Gutov Message-ID: <25fddd5b-9a1f-230a-eae5-10ba287db626@yandex.ru> Date: Thu, 17 Nov 2016 20:04:27 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Thunderbird/50.0 MIME-Version: 1.0 In-Reply-To: <834m36f6ai.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) On 17.11.2016 17:57, Eli Zaretskii wrote: > Thanks. I don't understand why it is not on the tracker, I guess it > wasn't actually sent there, for some reason. The bug had been archived up to the same day. Although the request to unarchive it was sent before the email in question. Or maybe the time zones conspired to make that false. >> vc-git-resolve-conflicts is already a user option. > > My impression was that Juno, for some reason, finds that > insufficient. But if I misunderstood, and the issue is only with its > default value, then indeed I see no problem. He indeed complained about the default value.