all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Jonathan Ganc <jonganc@gmail.com>
To: Dmitry Gutov <dgutov@yandex.ru>,
	npostavs@users.sourceforge.net, 26066@debbugs.gnu.org
Subject: bug#26066: 26.0.50; vc-git-status gives wrong result
Date: Wed, 22 Mar 2017 22:18:25 -0400	[thread overview]
Message-ID: <a96a4c5f-1bd6-3756-2189-460d76f44b98@gmail.com> (raw)
In-Reply-To: <022c0e0a-e039-24ef-66ff-82bcedbacd93@yandex.ru>

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.






  reply	other threads:[~2017-03-23  2:18 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-12  2:42 bug#26066: 26.0.50; vc-git-status gives wrong result Jonathan Ganc
2017-03-14 13:45 ` npostavs
2017-03-16  0:42 ` npostavs
2017-03-16  0:48   ` Dmitry Gutov
2017-03-16  2:40     ` Jonathan Ganc
2017-03-21  9:19       ` Dmitry Gutov
2017-03-21 16:10         ` Jonathan Ganc
2017-03-22 12:11           ` Michael Heerdegen
2017-03-22 16:20           ` Dmitry Gutov
2017-03-23  2:18             ` Jonathan Ganc [this message]
2017-03-31  3:16               ` Jonathan Ganc
2017-04-10  2:16                 ` Jonathan Ganc
2017-04-10  2:58                 ` npostavs
2017-04-10  3:26                 ` Dmitry Gutov
2017-04-10  4:41                   ` Jonathan Ganc
2017-04-10  6:05                     ` Eli Zaretskii
2017-04-10  7:35                     ` Thien-Thi Nguyen
2017-04-10 23:46                     ` Dmitry Gutov
2017-04-10  4:43                   ` Jonathan Ganc
2017-04-10 23:26                     ` Dmitry Gutov
2017-04-11  0:07               ` Dmitry Gutov
2017-04-11  3:52                 ` Jonathan Ganc
2017-04-11 13:08                   ` Jonathan Ganc
2017-04-11 23:27                     ` Dmitry Gutov
2017-04-11 23:36                       ` Dmitry Gutov
2017-04-14  0:42                       ` Jonathan Ganc
2017-04-23 18:21                         ` Jonathan Ganc
2017-04-23 22:28                           ` Noam Postavsky
2017-04-23 22:45                             ` Stefan Monnier
2017-04-24  0:50                             ` Jonathan Ganc
2017-04-24  9:20                               ` Andreas Schwab
2017-04-25 15:38                                 ` Jonathan Ganc
2017-04-25 23:49                                   ` Dmitry Gutov
2017-04-26  3:18                                     ` Jonathan Ganc
2017-05-01  1:43                                       ` Dmitry Gutov
2019-06-24 23:01                                         ` Lars Ingebrigtsen
2020-08-10 15:05                                           ` Lars Ingebrigtsen
2017-05-01  1:57                         ` Dmitry Gutov
2017-05-01 19:22                           ` Jonathan Ganc
2017-05-01 19:42                             ` Eli Zaretskii
2017-05-01 22:13                             ` Dmitry Gutov
2017-03-18  2:38     ` Jonathan Ganc

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a96a4c5f-1bd6-3756-2189-460d76f44b98@gmail.com \
    --to=jonganc@gmail.com \
    --cc=26066@debbugs.gnu.org \
    --cc=dgutov@yandex.ru \
    --cc=npostavs@users.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.