Handling of symlinked files about git-gutter-plus HOT 9 OPEN

Could you create a minimal scenario where the bug can be reproduced?
(Or maybe a shell script that creates such a scenario.)

from git-gutter-plus.

Here's the script to create the two repos:

https://gist.github.com/dhaley/9692370

then:

/Applications/Emacs.app/Contents/MacOS/Emacs -Q &

(add-to-list 'load-path "/.emacs.d/site-lisp/git-gutter-plus")
(add-to-list 'load-path "/.emacs.d/site-lisp/git-gutter-fringe-plus")
(add-to-list 'load-path "/.emacs.d/site-lisp/git-modes")
(add-to-list 'load-path "/.emacs.d/site-lisp/fringe-helper")
(require 'git-gutter+)
(require 'git-commit-mode)
(require 'fringe-helper)
(require 'git-gutter-fringe+)

(global-git-gutter+-mode t)

M-x toggle-debug-on-error

(find-file "/tmp/repo2/cu.aliases.drushrc.php")

Then make changes to cu.aliases.drushrc.php and a save should trigger the backtrace.

Also all libraries mentioned are the latest HEAD from github.

from git-gutter-plus.

For now, I've disabled git-gutter+ on symlinked files.

Transparently forwarding all git-gutter+ operations to the linked file would require respecting the foreign file path and directory in all git calls and passing them to all (temp) buffers created by git-gutter+ that might depend on it. I'd like to avoid all the complexities involved.

To all users:
Would such a link forwarding feature be a huge help? Then please let me know and I'll give it another thought.

Another possible solution: An option to automatically open the original file when global-git-gutter+-mode encounters a symlinked file. Would that be acceptable?

from git-gutter-plus.

To all users:
Would such a link forwarding feature be a huge help? Then please let me know and I'll give it another thought.

Count me in. My life is full of configuration files that are checked into git and that live in /etc only by virtue of a symbolic link.

from git-gutter-plus.

Hi,

i think opening the original would be the best choice.
I've recently switched to spacemacs with has some git-gutter as well, and it asks when it finds a symbolic link..

from git-gutter-plus.

it asks when it finds a symbolic link

Could you check where this is implemented?
Searching the spacemacs and the original emacs-git-gutter repos for symlink or truename gave no relevant hits.

from git-gutter-plus.

It appears to be what is mentioned here: http://stackoverflow.com/questions/15390178/emacs-and-symbolic-links which seems to be some standard emacs configuration: https://www.gnu.org/software/emacs/manual/html_node/emacs/General-VC-Options.html

Atleast in spacemacs i have not seen any problems with symlinks, but i am not sure if this is truely related to the git-gutter+ problem (as far as i can see, spacemacs uses plain git-gutter).

from git-gutter-plus.

Thanks!
So this is a feature of vc.el. The link resolution is offered when vc-follow-symlinks is non-nil.
(And when the symlink itself isn't inside a Git repo.)

@domq:
Does this help in your case?

@buster

spacemacs uses plain git-gutter

git-gutter just silently fails on symlinked files. (No diffs are shown.)

from git-gutter-plus.

vc-follow-symlinks does help, but only in the case where the symlink is the final component of the path. (I.e. vc-follow-symlinks seems to behave like file-chase-links rather than file-truename).

Maybe git-gutter+ could change to rely more on vc and vc-git's code to deal with paths, symlinks and tramp? In my current workflow, all vc commands work fine even in the "worst case" (remote file w/ symlinks in directory part of their paths).

from git-gutter-plus.