From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Jonathan Ganc Newsgroups: gmane.emacs.bugs Subject: bug#26066: 26.0.50; vc-git-status gives wrong result Date: Thu, 13 Apr 2017 20:42:42 -0400 Message-ID: <01922284-4265-6510-feee-dcc7301787ad@gmail.com> References: <9bf82bf1-fefa-ab84-bac1-cf748ae5ccfb@gmail.com> <87efxy59wx.fsf@users.sourceforge.net> <0d87686b-c7d2-deab-ebe4-ab1c8aa4faca@yandex.ru> <29d4a5ae-0ca0-3a86-6b9a-ab616803f39e@gmail.com> <4741bddf-9765-0d94-d0cd-b94e3e4914e1@yandex.ru> <8530cd03-0158-f198-9b14-ade983e1c7f4@gmail.com> <022c0e0a-e039-24ef-66ff-82bcedbacd93@yandex.ru> <505388da-e642-8c98-35c0-261d09ff13e1@yandex.ru> <1a23269d-1ead-1771-1afd-e2c9c5840cb4@gmail.com> <30d8b181-d869-de24-9c86-cc1dc6ec461b@gmail.com> <6ea0d89d-1a24-30fe-dd9a-26a0157a4eae@yandex.ru> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------F4169BC3BC0C2094615A5BDE" X-Trace: blaine.gmane.org 1492130606 21569 195.159.176.226 (14 Apr 2017 00:43:26 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 14 Apr 2017 00:43:26 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 To: Dmitry Gutov , npostavs@users.sourceforge.net, 26066@debbugs.gnu.org, Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Apr 14 02:43:18 2017 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 1cypKX-0005RA-PI for geb-bug-gnu-emacs@m.gmane.org; Fri, 14 Apr 2017 02:43:18 +0200 Original-Received: from localhost ([::1]:51383 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cypKb-0006cX-Ud for geb-bug-gnu-emacs@m.gmane.org; Thu, 13 Apr 2017 20:43:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37221) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cypKR-0006cE-CH for bug-gnu-emacs@gnu.org; Thu, 13 Apr 2017 20:43:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cypKI-0001wo-Od for bug-gnu-emacs@gnu.org; Thu, 13 Apr 2017 20:43:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:48074) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cypKI-0001wb-IG for bug-gnu-emacs@gnu.org; Thu, 13 Apr 2017 20:43:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cypKI-0004RX-92 for bug-gnu-emacs@gnu.org; Thu, 13 Apr 2017 20:43:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Jonathan Ganc Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 Apr 2017 00:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 26066 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 26066-submit@debbugs.gnu.org id=B26066.149213057217061 (code B ref 26066); Fri, 14 Apr 2017 00:43:02 +0000 Original-Received: (at 26066) by debbugs.gnu.org; 14 Apr 2017 00:42:52 +0000 Original-Received: from localhost ([127.0.0.1]:46273 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cypK8-0004R7-2K for submit@debbugs.gnu.org; Thu, 13 Apr 2017 20:42:52 -0400 Original-Received: from mail-qk0-f193.google.com ([209.85.220.193]:36195) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cypK6-0004Qq-9a for 26066@debbugs.gnu.org; Thu, 13 Apr 2017 20:42:50 -0400 Original-Received: by mail-qk0-f193.google.com with SMTP id v75so10463120qkb.3 for <26066@debbugs.gnu.org>; Thu, 13 Apr 2017 17:42:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=gArGKLOFfqUpVCwe/RATs00xg363sv5DrJ4x3LzXW6Q=; b=Jqq0HjHvRrvM4Jnl1X+6Yj2Uue7BGX8TExbsl5xAqv/piPhV9zx3lzPIhshwYfW0mX nFopQmlHq0CH3FT5gYQmqKEnoDiz6lrkn0vZMo5coXsMVI7NMLQ51AenvHB1aQP9sylo MUsksJ5aKbPQamur6xGYwFlIPT2r7gQLXUBgpk5Q9cddXCz3nE5AxZIGN64TCDVpfQyw SKArmkKMLk51enoYdnbY+zVtZppF+rJ0lnDuoKui1nmIKiruUgONnpAZMPLT9nZOT1Au CG4O223IlP+OvRDXKrDo6XWpN9EBXcZdhw4HxrGT0xiS5mhZZ4RrWWtzjuSmoLnmXWpZ aEaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=gArGKLOFfqUpVCwe/RATs00xg363sv5DrJ4x3LzXW6Q=; b=Xlvxczi1WKn4wZWF/ky/GJCk73pmzrmn+7r1xM9PR0LXU6gkq2VdxNHxLvwqNIFZQW LfN9GjhBiJUfIo4wOEVqHqv8BKS/BX2Nz5CiCOoQBDbwCiiGDHl/OMpAg15EJ4qnBxCt JNV1jO0sDDl8DpYrz2bVBM/snoSCgHHzNOEcP1elYDy8N9y9Yzbvk6AWLxho9pn6Vbkq CkknZCF3vCsNQhf09INiPPz5p5vcgLM9+61BEkNynvQ5hUOf52WrakMvMYMKcxPgDR8Y 4OPfuKsy8Q3OcJVt77rXbl3t7KZsPsaPZYqkTcsx4YuuEIgzdZHQCgShpBv59SSMO8Gy ZNJQ== X-Gm-Message-State: AN3rC/7q2rSuB7QcsEOuGCvuyvJNVSVkZ/ZSwa5oHZG6mz4W4Y+EDKyA QG9VZ4EM7NxPBQ== X-Received: by 10.55.15.72 with SMTP id z69mr4643370qkg.69.1492130564624; Thu, 13 Apr 2017 17:42:44 -0700 (PDT) Original-Received: from [192.168.1.200] (static-98-118-34-152.bstnma.fios.verizon.net. [98.118.34.152]) by smtp.gmail.com with ESMTPSA id z42sm272893qtb.26.2017.04.13.17.42.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Apr 2017 17:42:43 -0700 (PDT) In-Reply-To: <6ea0d89d-1a24-30fe-dd9a-26a0157a4eae@yandex.ru> 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:131553 Archived-At: This is a multi-part message in MIME format. --------------F4169BC3BC0C2094615A5BDE Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit First, I'm sorry for this delayed response. I've had a busy few days (and I needed to think about the issue)! I'm fine with decoupling the question about default-directory from the patch for git status. I have attached a patch that does not bind default-directory. (And I now have turned in the assignment paperwork to the FSF!). I continue to think that binding default-directory in vc-git-state makes the most sense. > If vc-git supports calling vc-git-state from outside of the > repository, but not some other commands, or if vc-git-state does but > some other backends' vc-xx-state does not, this will increase > inconsistency and make it harder for the programmers to write > VCS-agnostic code, which is one of the main goals of VC. But being vcs-agnostic is more for people who use vc-state or vc-state-refresh, rather than people actually writing the vc-specific functions, no? If this bug is unchanged, people using vc-state have to ask themselves: "if the backend is git, I have to bind default-directory but if it's not, I don't." That is inconsistent with vc agnosticism. > Is it necessary for correct output in other backends, in similar > scenarios? > > I agree that fixing this makes sense, but it should be done in an > organized fashion That's a valid question and a valid point. But I actually think that adding the binding in vc-git-state furthers the goal of systematically answering them. I doubt we'll be able to find, at one time, people with knowledge of more than 4 or 5 of the vc's (e.g. I know only git) who have the time to address this issue. What we can do instead, though, is to encourage people to properly write the backend specific functions. If, at some point, we notice that every vc-BACKEND-state binds default-directory, then we can move the binding to vc-state. However, this question reinforces my opinion that binding default-directory can be treated satisfactorily as a backend-specific question. The fact that I can't argue in general that an arbitrary vc system needs default-directory set suggests to me that one should leave it to the vc system to decide. For example, I could imagine a backend that wants the current directory to be the root directory of the repository, rather than the directory containing the file. --------------F4169BC3BC0C2094615A5BDE Content-Type: text/x-patch; name="0001-update-vc-git.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-update-vc-git.patch" >From cc492722e9ae974e568a2bf79121dfd8664a766e Mon Sep 17 00:00:00 2001 From: Jonathan Ganc Date: Mon, 10 Apr 2017 00:38:52 -0400 Subject: [PATCH] update vc-git --- lisp/vc/vc-git.el | 78 ++++++++++++++++++++++++++++++++++++------------------- 1 file changed, 52 insertions(+), 26 deletions(-) diff --git a/lisp/vc/vc-git.el b/lisp/vc/vc-git.el index 1a3f1bf..213bdaa 100644 --- a/lisp/vc/vc-git.el +++ b/lisp/vc/vc-git.el @@ -231,34 +231,60 @@ (defun vc-git--state-code (code) (?U 'edited) ;; FIXME (?T 'edited))) ;; FIXME +(defun vc-git--git-status-to-vc-state (code-list) + "Convert a list CODE-LIST of two-letter git status strings to a vc status. + +Each element of CODE-LIST comes from the first two characters of +a line returned by 'git status' and should be passed in the order given by 'git status'. + +\(It is necessary to allow CODE-LIST to be a list because +sometimes git status returns multiple lines, e.g. for a file that +is removed from the index but is present in the HEAD and working +tree.) " + (pcase code-list + ('nil 'up-to-date) + (`(,code) + (pcase code + ("!!" 'ignored) + ("??" 'unregistered) + ;; I have only seen this with a file that is only present in the + ;; index. Let us call this `removed' + ("AD" 'removed) + (_ (cond + ((string-match-p "^[ RD]+$" code) 'removed) + ((string-match-p "^[ M]+$" code) 'edited) + ((string-match-p "^[ A]+$" code) 'added) + ((string-match-p "^[ U]+$" code) 'conflict) + (t 'edited))))) + ;; I know of two times when git state returns more than one element, + ;; in both cases returning '("D " "??")': + ;; 1. when a file is removed from the index but present in the + ;; HEAD and working tree + ;; 2. when a file A is renamed to B in the index and then back to A + ;; in the working tree + ;; In both these instances, `unregistered' is a reasonable response. + (`("D " "??") 'unregistered) + ;; In other cases, let us return `edited'. + (_ 'edited))) + (defun vc-git-state (file) "Git-specific version of `vc-state'." - ;; FIXME: This can't set 'ignored or 'conflict yet - ;; The 'ignored state could be detected with `git ls-files -i -o - ;; --exclude-standard` It also can't set 'needs-update or - ;; 'needs-merge. The rough equivalent would be that upstream branch - ;; for current branch is in fast-forward state i.e. current branch - ;; is direct ancestor of corresponding upstream branch, and the file - ;; was modified upstream. But we can't check that without a network - ;; operation. - ;; This assumes that status is known to be not `unregistered' because - ;; we've been successfully dispatched here from `vc-state', that - ;; means `vc-git-registered' returned t earlier once. Bug#11757 - (let ((diff (vc-git--run-command-string - file "diff-index" "-p" "--raw" "-z" "HEAD" "--"))) - (if (and diff - (string-match ":[0-7]\\{6\\} [0-7]\\{6\\} [0-9a-f]\\{40\\} [0-9a-f]\\{40\\} \\([ADMUT]\\)\0[^\0]+\0\\(.*\n.\\)?" - diff)) - (let ((diff-letter (match-string 1 diff))) - (if (not (match-beginning 2)) - ;; Empty diff: file contents is the same as the HEAD - ;; revision, but timestamps are different (eg, file - ;; was "touch"ed). Update timestamp in index: - (prog1 'up-to-date - (vc-git--call nil "add" "--refresh" "--" - (file-relative-name file))) - (vc-git--state-code diff-letter))) - (if (vc-git--empty-db-p) 'added 'up-to-date)))) + (let ((status + (vc-git--run-command-string file "status" "--porcelain" "-z" + "--untracked-files" "--ignored" "--")) + code-list) + (if (null status) + ;; If status is nil, there was an error running git, likely because + ;; the file is not in a git repo. + 'unregistered + ;; If this code is adapted to parse 'git status' for a directory, + ;; note that a renamed file takes up two null values and needs to be + ;; treated slightly more carefully. + (setq code-list + (mapcar (lambda (s) + (substring s 0 2)) + (delete "" (split-string status "\0")))) + (vc-git--git-status-to-vc-state code-list)))) (defun vc-git-working-revision (_file) "Git-specific version of `vc-working-revision'." -- 2.9.3 --------------F4169BC3BC0C2094615A5BDE--