From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!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, 17 Nov 2016 00:45:43 +0200 Message-ID: References: <83h977fi3p.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------13F9296C272AE6A78E3428E9" X-Trace: blaine.gmane.org 1479336374 11910 195.159.176.226 (16 Nov 2016 22:46:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 16 Nov 2016 22:46:14 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Thunderbird/50.0 Cc: gitster@pobox.com, 20292@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Nov 16 23:46:10 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c78y1-0002Yb-G9 for geb-bug-gnu-emacs@m.gmane.org; Wed, 16 Nov 2016 23:46:09 +0100 Original-Received: from localhost ([::1]:55497 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c78y4-0007So-PW for geb-bug-gnu-emacs@m.gmane.org; Wed, 16 Nov 2016 17:46:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43937) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c78xy-0007SX-IY for bug-gnu-emacs@gnu.org; Wed, 16 Nov 2016 17:46:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c78xu-000052-HT for bug-gnu-emacs@gnu.org; Wed, 16 Nov 2016 17:46:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:44542) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c78xu-0008WR-Dj for bug-gnu-emacs@gnu.org; Wed, 16 Nov 2016 17:46:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1c78xu-0003Gx-5R for bug-gnu-emacs@gnu.org; Wed, 16 Nov 2016 17:46:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Nov 2016 22:46: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.147933635312562 (code B ref 20292); Wed, 16 Nov 2016 22:46:02 +0000 Original-Received: (at 20292) by debbugs.gnu.org; 16 Nov 2016 22:45:53 +0000 Original-Received: from localhost ([127.0.0.1]:59941 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c78xk-0003GY-KY for submit@debbugs.gnu.org; Wed, 16 Nov 2016 17:45:52 -0500 Original-Received: from mail-wm0-f46.google.com ([74.125.82.46]:35135) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c78xj-0003GK-B3 for 20292@debbugs.gnu.org; Wed, 16 Nov 2016 17:45:51 -0500 Original-Received: by mail-wm0-f46.google.com with SMTP id a197so272073198wmd.0 for <20292@debbugs.gnu.org>; Wed, 16 Nov 2016 14:45:51 -0800 (PST) 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-language; bh=dSpAxbo9NInH48q79zuY+iR91PT2RfUjP7hsPe2M4/s=; b=PnhY1ZMVQsZmhc01zYr+cYRSvZKnzCE8P+f2USArRBtGPvkJI9NXxBokacCyGenSf6 yI0Rqci8qCDrsNWrDTXEHZ1yLa/+8SB4VGfLtReQVo50pR+vX7SiySErCKSEhBjOBWv1 wfcGHYnJeVKHNzFNvEDNoKjUjRlJIQtgV5oyHYCkKvP9vF0XIbaZKHEGolqZ834HaQuK RjLlUFHg92K89JcCHnBjoyXnjRWZQW4k3AFAyz6tmBXsQ6L1bVeaeDJBxXiMZHm17DoJ XBECzP8AdH7FeT8vbHPpKnN/Qv4wvcWScyjH8f3K2neoUZq4BYj5Q6ltvVOcqpzovNTK v8cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-language; bh=dSpAxbo9NInH48q79zuY+iR91PT2RfUjP7hsPe2M4/s=; b=fDCBSp9FIZSa5guad80dRTiYh3MgiBIduw671LMEXwb+VjS2qTO0nolPKUOHmyweUM X2bC1BivMqBnemj+FK9zUi/Tt8bteZegCTbxeOlJdwPnXJYKAztP/rgziz5YGiXXVULa 9IRS47gqwBaP0Dyh+KSIFy9w3vipbP8OFt2L/YqNIrykgnrVNSY/une6BTBabyPE4ZiZ IIW6v5lzNuXRzdjDJHmydVL9DAyLhRkR2sbSWjbJ3cvGu4jfM3hjjDhRLbX4JNFhfXpE 2vpN3xHP6pvLQmwyIGPHEy1MamurXjchDhDUMqnb7pGHCVNggYMmzwu+rvB5AGfB8E4n 6dZw== X-Gm-Message-State: ABUngvfmWrKsUoGCUvieXZKPh9wqYDEwz2Hyx1hk6HvBLUTqb+1dhjOrdjqa2uiRoFSZZg== X-Received: by 10.28.232.16 with SMTP id f16mr510105wmh.103.1479336345687; Wed, 16 Nov 2016 14:45:45 -0800 (PST) Original-Received: from [192.168.1.3] ([185.105.173.41]) by smtp.googlemail.com with ESMTPSA id 135sm528738wmh.14.2016.11.16.14.45.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Nov 2016 14:45:44 -0800 (PST) In-Reply-To: <83h977fi3p.fsf@gnu.org> Content-Language: en-US X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.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" Xref: news.gmane.org gmane.emacs.bugs:125773 Archived-At: This is a multi-part message in MIME format. --------------13F9296C272AE6A78E3428E9 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 16.11.2016 19:30, Eli Zaretskii wrote: > I don't even see the message you are responding to. Was it sent only > to you, Dmitry? It was addressed to both me and the bug email, but didn't arrive at the latter. I'm attaching the full message here. >> You, as a core Git developer, represent the informed minority, and as >> such, it's probably not too much to expect that you and the others can >> customize vc-git-resolve-conflicts to nil without much trouble. > > Perhaps there could be a way to customize vc-git so that it caters to > such advanced users? vc-git-resolve-conflicts is already a user option. Were you thinking of something else? --------------13F9296C272AE6A78E3428E9 Content-Type: message/rfc822; name="Re: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after \"stash pop\" stages the file.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="Re: bug#20292: 24.5; Saving Git-controlled file with merge c"; filename*1="onflicts after \"stash pop\" stages the file.eml" Received: from mxfront6h.mail.yandex.net ([127.0.0.1]) by mxfront6h.mail.yandex.net with LMTP id K4YRSjOQ for ; Thu, 27 Oct 2016 20:20:57 +0300 Received: from pb-smtp2.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) by mxfront6h.mail.yandex.net (nwsmtp/Yandex) with ESMTPS id 6yz1VxnAk1-Kuk0kXjZ; Thu, 27 Oct 2016 20:20:56 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) Return-Path: junio@pobox.com X-Yandex-Front: mxfront6h.mail.yandex.net X-Yandex-TimeMark: 1477588856 Authentication-Results: mxfront6h.mail.yandex.net; spf=pass (mxfront6h.mail.yandex.net: domain of pobox.com designates 64.147.108.71 as permitted sender) smtp.mail=junio@pobox.com; dkim=pass header.i=@pobox.com X-Yandex-Spam: 1 Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id D33A049621; Thu, 27 Oct 2016 13:20:54 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:in-reply-to:date:message-id:mime-version:content-type; s=sasl; bh=vrrDMZxxYh3jslwe0ZI2oy/JDtI=; b=TI9IEsAv1018R6NzLt1g boMtZadsz4h6vlXvwhB/Z0enwt6wT8ChlnkKjYDz2A2ieJ27Jf/QuLu3Rdav0Nsp 6OZlPh7OVcW5CsgEtqgV9qEylVXfVyS9g37KR7hsfc4TFsa0BZiyriwFgVENgj2K bjwIorT3mVKhiP/QHjniGtw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:in-reply-to:date:message-id:mime-version:content-type; q=dns; s=sasl; b=pdgpeYLZJio/VPkvlMOSuqB7rHtXIz6KmvSElScFFnTQ1g T2LyvB/gkX6nbXHohilSrZBLQefTcwsgDHZ1D3AJC6ywA2QdqOkOyrYWjKelbEFy G6MnCWiPdG0enxOVycmwORv8bQRf4EkRanGme/pgHgeiPb1rcn3khUgebvsk8= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id CB1E549620; Thu, 27 Oct 2016 13:20:54 -0400 (EDT) Received: from pobox.com (unknown [104.132.0.95]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 483C04961F; Thu, 27 Oct 2016 13:20:54 -0400 (EDT) From: Junio C Hamano To: 20292@debbugs.gnu.org Cc: Dmitry Gutov Subject: Re: bug#20292: 24.5; Saving Git-controlled file with merge conflicts after "stash pop" stages the file In-reply-to: <55528906.7060606@yandex.ru> Date: Thu, 27 Oct 2016 10:20:52 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Pobox-Relay-ID: B75BE8B6-9C69-11E6-AB10-3AB77A1B28F4-77302942!pb-smtp2.pobox.com X-Yandex-Forward: d73b28f8c179ee3553784c2a7b141268 X-Yandex-Filter: 208239 Sorry for responding to an ancient message, but you said > When a stash contains changes for several files, and "stash pop" > encounters conflicts only in some of them, the rest of the files are > stages automatically. > > So then when we unstage the files which had conflicts after > resolving those, the result is mixed. Which doesn't look right. But this is a completely normal and designed way how conflicts are resolved during any "mergy" operations in Git. It is not limited to "stash pop" (or "stash apply"). "git merge", "git cherry-pick", "git revert", "git am -3" and even "git checkout -m another-branch" share this feature. When doing a mergy operation, some paths will merge cleanly and some paths will have conflicts. A conflicted path will - leave multiple stages in the index; the common ancestor version in stage#1, the version you originally had in stage#2, and the version the mergy operation wanted to bring the changes from into your state in stage#3. - have conflicted merge result in the working tree, with the conflict markers. The way Git is designed to be used is for the user to edit the latter to come up with a conflict resolution in the working tree, then add that result to the index, after the user is satisfied with it, before continuing (typically, but not necessarily, to record the result with "git commit"). Now, what about the cleanly automerged paths? They are added to the index and this is by design. You can see why this is necessary by doing: - Start a mergy operation (e.g. "stash pop", or "git merge") that conflicts; - Resolve the conflicts in the working tree, - But before doing "git add" to tell Git that you are done with these paths, run "git diff" (no other parameters). You may have to (setq vc-git-resolve-conflicts nil) for that You will notice that this invocation of "git diff" show concisely how the result of your conflict resolution differs from either of the branch. This is used by Git users as one of the final step of verification before telling Git "I now am done with the conflict in this path and resolution is good" by issuing "git add" for the path. You will also notice that this invocation of "git diff" does not clutter with changes that have been auto-merged cleanly. At this step of the workflow to resolve conflicts, the user is concentrating on the paths that had conflicts, and it is crucial that cleanly auto-merged paths do not get in the way. The user can still view the overall picture by asking "git diff HEAD" (to see both automerged result and hand-resolved result, the latter of which may or may not have been added to the index) and "git diff --cached" (to see automerged result and hand-resolved and then "git add"'ed result). So, there is no "Bad news, everybody!" in the behaviour you observed. > What shall we do? Unstage the automatically-staged files? Revert the > changes from this bug? It seems Git really wants the changes staged > after the conflict resolution. I do not know what you thought you can achieve by "unstage the auto-merged paths?" here, but perhaps you were expecting "git diff" (no arguments) would be the way to view all the changes that a mergy operation with conflicted states brought in? If that (i.e. "view all the changes") was what you wanted to achieve, then neither "unstage the auto-merged paths" nor "automatically 'git add' upon saving the buffer" is a good solution. I was told by somebody that the message I am responding to eventually resulted in vc-git-resolve-conflicts that defaults to true in Emacs 25.1, which lead to "automatically 'git add' upon saving the buffer". I think this variable and its default is a big disservice to Git users' whose daily work involves lots of conflict resolutions in mergy operations. Running "git diff HEAD" instead of "git diff" may be the solution, if the problem were "I want to view all the changes, both already added to the index and the ones that have not been yet", though I am not sure from the "Bad news, everybody!" message if that is the problem you were trying to solve. --------------13F9296C272AE6A78E3428E9--