From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file Date: Sun, 19 Apr 2015 17:30:21 +0300 Message-ID: <83zj645gxu.fsf@gnu.org> References: <83fv88ta5r.fsf@gnu.org> <5532ADA3.5000006@yandex.ru> <834mod6xnm.fsf@gnu.org> <5532D397.8090602@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1429453881 24578 80.91.229.3 (19 Apr 2015 14:31:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 19 Apr 2015 14:31:21 +0000 (UTC) Cc: esr@snark.thyrsus.com, 20292@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Apr 19 16:31:10 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YjqFZ-0005O5-S6 for geb-bug-gnu-emacs@m.gmane.org; Sun, 19 Apr 2015 16:31:10 +0200 Original-Received: from localhost ([::1]:48722 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YjqFZ-0001uV-4h for geb-bug-gnu-emacs@m.gmane.org; Sun, 19 Apr 2015 10:31:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39493) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YjqFV-0001uO-Mv for bug-gnu-emacs@gnu.org; Sun, 19 Apr 2015 10:31:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YjqFS-0002Ry-Go for bug-gnu-emacs@gnu.org; Sun, 19 Apr 2015 10:31:05 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:42784) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YjqFS-0002Rs-DJ for bug-gnu-emacs@gnu.org; Sun, 19 Apr 2015 10:31:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YjqFR-0006Hu-R9 for bug-gnu-emacs@gnu.org; Sun, 19 Apr 2015 10:31:02 -0400 X-Loop: help-debbugs@gnu.org 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: Original-Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.142945385924162 (code B ref 20292); Sun, 19 Apr 2015 14:31:01 +0000 Original-Received: (at 20292) by debbugs.gnu.org; 19 Apr 2015 14:30:59 +0000 Original-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 Original-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 Original-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) Original-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) In-reply-to: <5532D397.8090602@yandex.ru> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:101717 Archived-At: > 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.