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?

  • When you say large repositories are you pushing/pulling relatively small groups of files, and it's still slow? While I haven't worked in really large repositories my experience with Magit is I use it for small coding changes, while I use C-x v (built in) if I know there is going to be 100-1000+ files. – Greth Aug 9 '18 at 13:06
  • Committing, pushing, and pulling are all fine. It's just logging and specifically logging and limiting to files. The slow down also only seems out of control when magit is told the repository is at /ssh:.... – jrm Aug 10 '18 at 14:08
  • Ah, reading from here do you have --graph or --graph --color enabled? The manual suggests to disable both commands for any large repositories. – Greth Aug 11 '18 at 13:47
  • The value of magit-log-section-arguments is 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

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.

| improve this answer | |
  • "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 mistyped ssh:// path. – tarsius Aug 25 '18 at 12:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.