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 20:06:14 +0300 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1429463246 1292 80.91.229.3 (19 Apr 2015 17:07:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 19 Apr 2015 17:07:26 +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 19:07: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 1Yjsgb-0005Ft-EM for geb-bug-gnu-emacs@m.gmane.org; Sun, 19 Apr 2015 19:07:13 +0200 Original-Received: from localhost ([::1]:49153 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yjsga-0001p4-6Q for geb-bug-gnu-emacs@m.gmane.org; Sun, 19 Apr 2015 13:07:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35949) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YjsgW-0001oo-6d for bug-gnu-emacs@gnu.org; Sun, 19 Apr 2015 13:07:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YjsgQ-0003PU-Ei for bug-gnu-emacs@gnu.org; Sun, 19 Apr 2015 13:07:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:42849) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YjsgQ-0003PN-BF for bug-gnu-emacs@gnu.org; Sun, 19 Apr 2015 13:07:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YjsgP-0001Zc-QL for bug-gnu-emacs@gnu.org; Sun, 19 Apr 2015 13:07: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 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: Original-Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.14294631946007 (code B ref 20292); Sun, 19 Apr 2015 17:07:01 +0000 Original-Received: (at 20292) by debbugs.gnu.org; 19 Apr 2015 17:06:34 +0000 Original-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 Original-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 Original-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) Original-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) In-reply-to: <5533D7B8.7060508@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:101728 Archived-At: > 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"?