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 04:24:12 +0300 Message-ID: <5553F93C.9010205@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> 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 1431566725 17765 80.91.229.3 (14 May 2015 01:25:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 14 May 2015 01:25: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 Thu May 14 03:25:14 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 1Yshtf-00056v-Bo for geb-bug-gnu-emacs@m.gmane.org; Thu, 14 May 2015 03:25:11 +0200 Original-Received: from localhost ([::1]:52161 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yshte-0001D0-HC for geb-bug-gnu-emacs@m.gmane.org; Wed, 13 May 2015 21:25:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52837) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yshtb-0001Ae-5f for bug-gnu-emacs@gnu.org; Wed, 13 May 2015 21:25:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YshtX-0006hu-Tk for bug-gnu-emacs@gnu.org; Wed, 13 May 2015 21:25:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:34236) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YshtX-0006hN-QT for bug-gnu-emacs@gnu.org; Wed, 13 May 2015 21:25:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YshtX-0001iM-DR for bug-gnu-emacs@gnu.org; Wed, 13 May 2015 21:25:03 -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 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: Original-Received: via spool by 20292-submit@debbugs.gnu.org id=B20292.14315666646479 (code B ref 20292); Thu, 14 May 2015 01:25:03 +0000 Original-Received: (at 20292) by debbugs.gnu.org; 14 May 2015 01:24:24 +0000 Original-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 Original-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 Original-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) Original-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) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 In-Reply-To: <83zj58jvri.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:102757 Archived-At: 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.