0

I have six large .ipynb files in a git repo (100mb to 200mb each). They have diffs, but I don't want to check them in yet. The problem is that they seem to be the reason why magit becomes extremely slow. Running C-x g to start magit can take 30 seconds or more. Even just moving the cursor around the magit buffer is equally slow.

I did M-x magit-toggle-verbose-refresh to try to track it down & found that all the time is in magit-insert-unstaged-changes (see below), so it looks like the delays are being caused by magit processing these huge diffs.

So, is there any way to tell magit to skip loading and displaying diffs for large files? Or, is there something else going on & some work-around for it?


From *Messages* after M-x magit-toggle-verbose-refresh:
Refreshing buffer ‘magit: NNStructure’...
  magit-insert-error-header                          3.431e-06 
  magit-insert-diff-filter-header                    0.002442839 
  magit-insert-head-branch-header                    0.005406666 
  magit-insert-upstream-branch-header                0.003334082 
  magit-insert-push-branch-header                    3.1035e-05 
  magit-insert-tags-header                           0.004107144 
  magit-insert-status-headers                        0.018795686 !
  magit-insert-merge-log                             0.001669273 
  magit-insert-rebase-sequence                       3.0892e-05 
  magit-insert-am-sequence                           1.3767e-05 
  magit-insert-sequencer-sequence                    3.9812e-05 
  magit-insert-bisect-output                         1.0249e-05 
  magit-insert-bisect-rest                           9.736e-06 
  magit-insert-bisect-log                            1.011e-05 
  magit-insert-untracked-files                       0.010132087 !
  magit-insert-unstaged-changes                      19.848880685 !!
  magit-insert-staged-changes                        0.098007356 !!
  magit-insert-stashes                               0.001236391 
  magit-insert-unpushed-to-pushremote                3.9012e-05 
  magit-insert-unpushed-to-upstream-or-recent        0.012927924 !
  magit-insert-unpulled-from-pushremote              2.755e-06 
  magit-insert-unpulled-from-upstream                0.002045877 
Refreshing buffer ‘magit: NNStructure’...done (20.012s)
2
  • You could either tell git to treat them as binary files (no diff will be generated), or else tell git to pretend that they haven't actually changed (which you would then need to remember and revert when the time came to deal with them). Magit would benefit in either case.
    – phils
    Commented Mar 11 at 3:44
  • I want git to continue treating them as text, not binary, but I want magit to not try to process the diffs.
    – hjs
    Commented Mar 11 at 4:28

1 Answer 1

0

https://git-scm.com/docs/gitattributes says:

Marking files as binary

Git usually guesses correctly whether a blob contains text or binary data by examining the beginning of the contents. However, sometimes you may want to override its decision, either because a blob contains binary data later in the file, or because the content, while technically composed of text characters, is opaque to a human reader. For example, many postscript files contain only ASCII characters, but produce noisy and meaningless diffs.

The simplest way to mark a file as binary is to unset the diff attribute in the .gitattributes file:

*.ps -diff

This will cause Git to generate Binary files differ (or a binary patch, if binary patches are enabled) instead of a regular diff.

File patterns can always be a specific filename without any wildcards, if you don't want this to apply to *.ipynb files generally.

3
  • I had seen this option mentioned elsewhere. But, I don't want to change how git treats the files. They're json, and I'd like git to continue to treat them as text, not as binary. I just want magit to stop pulling and processing the diff.
    – hjs
    Commented Mar 11 at 4:26
  • Well Magit is simply processing what git gives it. What's the problem with setting them to binary temporarily, and removing that config once you're ready to commit them?
    – phils
    Commented Mar 11 at 9:06
  • Especially when you can use git diff --text to see the diff when you want to (so you can have your cake and eat it too).
    – phils
    Commented Mar 11 at 11:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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