Handling of symlinked files

[dhaley]

Very similar to issue #1, I am getting a stack trace when accessing a symlink (in a git repo) that references a file in another git repo.

This happens with the latest HEAD.

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

[nonsequitur]

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

[dhaley]

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.

[nonsequitur]

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?

[domq]

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.

[buster]

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..

[nonsequitur]

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.

[buster]

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).

[nonsequitur]

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.)

[domq]

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).