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: Thu, 14 May 2015 21:00:36 +0300 Message-ID: <5554E2C4.7040209@yandex.ru> 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> 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 1431626489 17077 80.91.229.3 (14 May 2015 18:01:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 14 May 2015 18:01:29 +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 Thu May 14 20:01: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 1YsxRY-0008CI-NM for geb-bug-gnu-emacs@m.gmane.org; Thu, 14 May 2015 20:01:12 +0200 Original-Received: from localhost ([::1]:56200 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YsxRX-0004aY-WE for geb-bug-gnu-emacs@m.gmane.org; Thu, 14 May 2015 14:01:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44236) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YsxRU-0004aE-88 for bug-gnu-emacs@gnu.org; Thu, 14 May 2015 14:01:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YsxRR-000149-08 for bug-gnu-emacs@gnu.org; Thu, 14 May 2015 14:01:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:35354) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YsxRQ-000145-Tu for bug-gnu-emacs@gnu.org; Thu, 14 May 2015 14:01:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YsxRQ-00080k-7V for bug-gnu-emacs@gnu.org; Thu, 14 May 2015 14:01:04 -0400 X-Loop: help-debbugs@gnu.org 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: Original-Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.143162645030407 (code B ref 20292); Thu, 14 May 2015 18:01:03 +0000 Original-Received: (at 20292) by debbugs.gnu.org; 14 May 2015 18:00:50 +0000 Original-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 Original-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 Original-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) Original-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) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 In-Reply-To: <83617vjjmv.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:102799 Archived-At: 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.