From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov 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 19:28:40 +0300 Message-ID: <5533D7B8.7060508@yandex.ru> References: <83fv88ta5r.fsf@gnu.org> <5532ADA3.5000006@yandex.ru> <834mod6xnm.fsf@gnu.org> <5532D397.8090602@yandex.ru> <83zj645gxu.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1429460965 32289 80.91.229.3 (19 Apr 2015 16:29:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 19 Apr 2015 16:29:25 +0000 (UTC) Cc: esr@snark.thyrsus.com, 20292@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Apr 19 18:29:13 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 1Yjs5m-0008Io-W2 for geb-bug-gnu-emacs@m.gmane.org; Sun, 19 Apr 2015 18:29:11 +0200 Original-Received: from localhost ([::1]:49085 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yjs5m-0003jf-7L for geb-bug-gnu-emacs@m.gmane.org; Sun, 19 Apr 2015 12:29:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59769) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yjs5i-0003jX-BG for bug-gnu-emacs@gnu.org; Sun, 19 Apr 2015 12:29:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yjs5f-0002Fz-1R for bug-gnu-emacs@gnu.org; Sun, 19 Apr 2015 12:29:06 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:42818) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yjs5e-0002Fv-Uk for bug-gnu-emacs@gnu.org; Sun, 19 Apr 2015 12:29:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Yjs5e-0000eP-Ft for bug-gnu-emacs@gnu.org; Sun, 19 Apr 2015 12:29:02 -0400 X-Loop: help-debbugs@gnu.org 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: Original-Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.14294609322483 (code B ref 20292); Sun, 19 Apr 2015 16:29:02 +0000 Original-Received: (at 20292) by debbugs.gnu.org; 19 Apr 2015 16:28:52 +0000 Original-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 Original-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 Original-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) Original-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) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 In-Reply-To: <83zj645gxu.fsf@gnu.org> 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:101722 Archived-At: 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).