Doing magit-status, magit-log-popup, and =f to limit to files will try to help by building up a list of paths for completion. However, with moderately large repositories, which have a path like ssh://..., Emacs may lock up for something like five minutes (the watch is displayed and no interaction with Emacs is possible). Setting magit-completing-read-function to ignore does not help. Is there a workaround to avoid this delay?
2
1
Reading the files is done using magit-read-files, which builds the list of files using magit-list-files, which runs git like so:
git ls-files -z --full-name
I.e. this prints one long line that separates individual files using the null character instead of newlines. That is necessary to support crazy file names that contain newline characters.
This is known to cause issues with Tramp, which searches that line backwards using a regexp. Backward regexp search is known to be very slow. I will have to look into this with the Tramp maintainer at some point.
-
"But this shouldn't be an issue when not using Tramp." That's my experience, i.e, there are no problems when not using tramp. Maybe I am missing something, but when you say "That shouldn't make any difference whatsoever." I am confused. When we tell magit that the repository is at
/ssh:/...Tramp is used and that's when we see the crazy slow down. – jrm Aug 21 '18 at 18:29 -
Ah sorry, didn't realize that
/ssh:was a tramp path -- I mistook it for a mistypedssh://path. – tarsius Aug 25 '18 at 12:16
C-x v(built in) if I know there is going to be 100-1000+ files. – Greth Aug 9 '18 at 13:06/ssh:.... – jrm Aug 10 '18 at 14:08--graphor--graph --colorenabled? The manual suggests to disable both commands for any large repositories. – Greth Aug 11 '18 at 13:47magit-log-section-argumentsis the default("-n256" "--decorate"). The logging itself is not slow, it's getting the prompt to limit to to files that is crazy slow. – jrm Aug 12 '18 at 17:06