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: Sun, 9 Apr 2017 22:16:24 -0400 Message-ID: <22831afe-cda8-2061-f747-8eb457943e49@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> <7fccafd3-e2c2-204a-05a0-a930a4cbb7e4@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1491790639 4175 195.159.176.226 (10 Apr 2017 02:17:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 10 Apr 2017 02:17:19 +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 Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Apr 10 04:17:12 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 1cxOtD-0000ur-Aq for geb-bug-gnu-emacs@m.gmane.org; Mon, 10 Apr 2017 04:17:11 +0200 Original-Received: from localhost ([::1]:60254 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cxOtJ-0005Ag-5C for geb-bug-gnu-emacs@m.gmane.org; Sun, 09 Apr 2017 22:17:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42621) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cxOt9-0005AS-RD for bug-gnu-emacs@gnu.org; Sun, 09 Apr 2017 22:17:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cxOt4-0004Ep-Pi for bug-gnu-emacs@gnu.org; Sun, 09 Apr 2017 22:17:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:42156) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cxOt4-0004Ei-Jr for bug-gnu-emacs@gnu.org; Sun, 09 Apr 2017 22:17:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cxOt4-0006oo-EV for bug-gnu-emacs@gnu.org; Sun, 09 Apr 2017 22:17: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: Mon, 10 Apr 2017 02:17: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.149179059426160 (code B ref 26066); Mon, 10 Apr 2017 02:17:02 +0000 Original-Received: (at 26066) by debbugs.gnu.org; 10 Apr 2017 02:16:34 +0000 Original-Received: from localhost ([127.0.0.1]:40352 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cxOsb-0006ns-QS for submit@debbugs.gnu.org; Sun, 09 Apr 2017 22:16:34 -0400 Original-Received: from mail-qk0-f195.google.com ([209.85.220.195]:36540) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cxOsa-0006ne-Jy for 26066@debbugs.gnu.org; Sun, 09 Apr 2017 22:16:32 -0400 Original-Received: by mail-qk0-f195.google.com with SMTP id v75so17313314qkb.3 for <26066@debbugs.gnu.org>; Sun, 09 Apr 2017 19:16:32 -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:content-transfer-encoding; bh=zY7GKnVSlZIG+/JTjjgKh2YLqemWEKGSJMkcDBOkJbc=; b=hBZa0YnUTRxx6SYEFp3qSJiecCLh8hkpSZfmayExiMwakXL0n9nV/mAflaM2GrBRgS 4psmfWcnOiO0+gqRjX1n3MRbU7+LsjI98tfEwN26dWntc7liU5OzHK19zr4J4xuohuaS hD2Vwa/eg7yQbKgMQxWvV/dN9aMgCeHJxKqcrYH32VICvlqGqP8f3ddDfSrwZ+Oh5s7o LDWfxr1v5zdxHCwt7BYUsp97bNrjtqVzwjTIH4MbsBt3pI4pOB2ETEFSMQi9YL6Zo2nF rF2pxL5xI96vTvs4z7MAV+PZmrsASNZ9+OOgMq3K5Q2rj27UjIfZMmtPlVacykW1MNSW bh9A== 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:content-transfer-encoding; bh=zY7GKnVSlZIG+/JTjjgKh2YLqemWEKGSJMkcDBOkJbc=; b=HyVdEiIna7pZmO6q/I/RIxbFBfoIkq2tvCihJem4/AabsFlKviul+N/3yPiFB9h2+M LJzFkMHNWVrFRWBOboth7c7lW5LFZNc6yraJrv2fyiZbW2QOsFr9pJSndnCBYd8xeOsa p4aMrE3aknt8XnxT09hKHU/pq9B+Mec8UmRFrcSzs7gMJ9Paxp1dbPNfL2domnOaDFWF ncUSsItF2xNjnzpCbTBQrc12VSIPxFp4mf/eFmclkiW2GmOG5m3e13CWIJE/QHwR/cMY ESpQjJDB16av9m+y4OmR/6V1qhlsvqu72aU04+3IVE6vMwerxXk1m/KdmksiBQar4Z8H hnsw== X-Gm-Message-State: AFeK/H2nOoZU46LlMBXpvfzptY8laUuyt/O7Z8LibcejaeSiCRZ7RCbASKQYPi7SdbwCAg== X-Received: by 10.55.31.1 with SMTP id f1mr41404392qkf.255.1491790587028; Sun, 09 Apr 2017 19:16:27 -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 z4sm7903233qkc.68.2017.04.09.19.16.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 09 Apr 2017 19:16:26 -0700 (PDT) In-Reply-To: <7fccafd3-e2c2-204a-05a0-a930a4cbb7e4@gmail.com> 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:131427 Archived-At: Hi, I am just checking if anyone has had a chance to review my proposed improvement to vc-git-status? I have been using it without problem but I would love to get feedback. Jonathan On 03/30/2017 11:16 PM, Jonathan Ganc wrote: > I have attached my proposed patch to use 'git status' for finding the > git status of files. > > I have also attached git-test.sh, which generates a subdirectory > git-test with files in all the relevant git states I could think of > (if you use it, look at the mods, repo2, repo3 directories for > interesting files). > > I then verified that 1) my function gives the same result as > vc-git-dir-status-files where vc-git-dir-status-files shows the file, > with one exception: if a file has a merge conflict (i.e. the status is > "UU"), my function returns conflict; 2) it is the same speed as the > current vc-git-state. > > I may try eventually try rewriting vc-git-dir-status-files using this > since it appears to be about an order of magnitude faster than the > current implementation. > > On 03/22/2017 10:18 PM, Jonathan Ganc wrote: >> Hi, >> >> Thanks for both responses. >> >> >>>> 3. It would be nice to be able to show mutiple directory trees at >>>> once in Neotree, though this is not as important. >>> >>> If it's unable to show the non-current projects, how is the bug >>> triggered? default-directory would have to be outside of the project. >> >> I'm not actually sure why it is causing me problems. I just tried >> using Neotree and encountered this problem. I didn't try anything >> special besides opening the window. I'm not sure how/why Neotree sets >> default-directory. I need to look into this. >> >> >>> The problem might have gone unnoticed until now because file's >>> status is cached, and because it can only be apparent if several >>> projects are opened at the same time. >>> >>> While the problem is fairly obvious, a proper fix would most likely >>> touch other backends and commands, to the point that the >>> default-directory binding might have to be done inside vc-call-backend. >> >> Yeah, I'm not really sure what the workflow should be; I'm just >> getting started with the vc functions in emacs. One issue, though, is >> that default-directory can only be set for functions that identify a >> filename, because we need to have a directory to set things to. For >> this reason, I don't know that one could generally set >> default-directory in vc-call-backend. It could make sense to set >> default-directory for vc-git--run-command-string (although to get >> vc-git-state to work, one would still need to set it for >> vc-git--empty-db-p). >> >> It's worth nothing there seems to be inconsistency within vc-git. >> Some commands like vc-git-checkin, vc-git-next-revision, do set >> default-directory to the directory of the input file; other comands >> like vc-git-merge-branch seem to do the opposite and assume the root >> is already given by default-directory. >> >> At the very least, the documentation for vc-git-state should note >> that default-directory needs to be set. >> >>> >>> There is a very simple workaround on the caller's side, though: bind >>> default-directory inside the Neotree code, to the respective project >>> root (or just the file's parent directory). That will be necessary >>> anyway for it to work in the released Emacs versions. >>> >> >> That may be the best answer. I am not so familiar with the Neotree >> code but it should be doable. >> >>>> 2. I would like to be able to color directories as well as files. I >>>> don't know if that is something that would have a component in >>>> vc-git.el / vc-....el or would go entirely in some package (e.g. >>>> Neotree) >>> >>> This differs from one version control system to another, but Git >>> doesn't actually track directories. So the notion of "directory >>> status" is poorly defined. But see the previously mentioned >>> diff-hl-dired-mode. >>> >> >> You're right, in principle, but atom handles it by coloring >> directories based on if they have modified files within. I don't know >> if there is a "canonical" way to do this, although one idea would be >> to return a list of all file status in the directory, e.g. >> `(up-to-date modified ignored)`. >> >> I started looking through diff-hl. It looks like it has a bunch of >> neat and useful features, though I admit I was a bit confused by the >> workflow. >> >