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: Thu, 14 May 2015 17:53:12 +0300 Message-ID: <83617vjjmv.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> <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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1431615275 19468 80.91.229.3 (14 May 2015 14:54:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 14 May 2015 14:54:35 +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 Thu May 14 16:54:24 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 1YsuWl-0005m7-5w for geb-bug-gnu-emacs@m.gmane.org; Thu, 14 May 2015 16:54:23 +0200 Original-Received: from localhost ([::1]:55035 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YsuWk-0005rb-KN for geb-bug-gnu-emacs@m.gmane.org; Thu, 14 May 2015 10:54:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47896) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YsuWV-0005bN-0N for bug-gnu-emacs@gnu.org; Thu, 14 May 2015 10:54:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YsuWQ-00030i-Ah for bug-gnu-emacs@gnu.org; Thu, 14 May 2015 10:54:06 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:35164) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YsuWQ-00030b-8b for bug-gnu-emacs@gnu.org; Thu, 14 May 2015 10:54:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YsuWP-0006dI-SO for bug-gnu-emacs@gnu.org; Thu, 14 May 2015 10:54:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 May 2015 14:54: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.143161520725410 (code B ref 20292); Thu, 14 May 2015 14:54:01 +0000 Original-Received: (at 20292) by debbugs.gnu.org; 14 May 2015 14:53:27 +0000 Original-Received: from localhost ([127.0.0.1]:45139 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YsuVp-0006be-Sm for submit@debbugs.gnu.org; Thu, 14 May 2015 10:53:27 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:36581) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YsuVm-0006bF-BG for 20292@debbugs.gnu.org; Thu, 14 May 2015 10:53:23 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NOC00L00H5X6S00@a-mtaout20.012.net.il> for 20292@debbugs.gnu.org; Thu, 14 May 2015 17:53:15 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NOC00LLYHCQ6O10@a-mtaout20.012.net.il>; Thu, 14 May 2015 17:53:15 +0300 (IDT) In-reply-to: <5553F93C.9010205@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:102781 Archived-At: > Cc: monnier@iro.umontreal.ca, esr@snark.thyrsus.com, 20292@debbugs.gnu.org > From: Dmitry Gutov > Date: Thu, 14 May 2015 04:24:12 +0300 > > Report a bug in Git, I think. > > I believe it's your turn to report a Git bug now. ;) So we do turns on this? > 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. 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. Anyway, the fact that it takes a long time for a fix to percolate shouldn't preclude us from reporting it. > > 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. 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. _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. > 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'. 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 know all the stashed files, how about invoking "git reset" for all of them? It cannot hurt, can it? > 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. I'm talking about conflicts, not about the number of files. How many times did you have conflicts in "stash pop"? I almost never have them. > 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. > The current behavior is bad because it looks random. I agree it's bad, but only if (a) there are multiple changed files, and (b) some, but not all, of them have conflicts. Otherwise, the behavior is correct. By contrast, the previous behavior was always wrong. > 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. Not for uncommitted changes that were stashed, it ain't. 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. > 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 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. Having them staged means that I might inadvertently commit them with my next "git commit", something that wasn't supposed to happen before the stash. > It's hard for me to tell without knowing exactly why Git conflates conflict resolution and staging. It's a bug.