Sublime Forum

Deadly slow merge resolve


After attempting a merge when I press the resolve button the next screen shows the spinning status for 2-4 minutes.

  • The project has 20,000+ files but the file with the conflict is never more than a few thousand lines.
  • The cancel button also freezes the UI for about 4-5 seconds (every time).
  • After showing the resolve screen once subsequent resolving doesn’t have the same delay.

Not sure if this is Sublime Merge or git. There’s no status that I’m aware of so if this was git it would be nice to know what git was doing.

Is this a known issue? If not is there anyway I could help you reproduce the problem?

1 Like


Do you have a large number of modified, untracked, or staged files in your working dir?



I experience the exact same problem (only I do not have patience to wait for it to finish loading, not sure it ever does). I don’t think I experienced this a few months ago, so maybe it came with an update. I’m on Windows 10 v1809, and Sublime merge build 1116. The merge i’m in right now has 6000 staged files, and just a few unmerged and unstaged.

One interesting note is that it works just fine with when configuring smerge as a git mergetool as described here. no delay when running git mergetool.



Sorry I forgot about this! Yeah my project is a compiler with a few thousand files ( but that shouldn’t matter I think.

Have any of the ST devs tried this thing on big projects? Something seriously wrong and needs to be fixed. Can’t even use it to resolve conflicts until then.



This is still happening on OS X (10.14.6), Sublime Merge build 2032. Makes resolving in SM intolerable, and doesn’t seem related to number of untracked files or their size.

After clicking ‘save & stage’, the client will go to 100% CPU for ~30 seconds plus.

Anecdotally, while that’s the case, shows as unresponsive. Once that finishes choking, everything goes back to normal. This happens for every file needing resolving in a merge.

After resolving the largest & highest conflict files in the merge, this time seemed to go down proportionally. But even resolving single-line conflicts in files with ~20 lines was incurring this cost until those bigger files were out of the way.



@lollerbus, given that edit, does collapsing all files prior to resolving conflicts help? (i.e. before resolving the largest/highest conflict files).


  • how many files were changed?
  • roughly, how many hunks are there total?
  • roughly, how many are there in those latest/highest conflict files?


@srbs This behavior is with all of the diffs collapsed.

Will try to repro with the same merge again tomorrow and get some real numbers.

Off the top of my head, the two problem files were:
6.2 MB JSON – 150k lines with at least 100s of hunks
1.1MB JSON – 29k lines with probably dozens of hunks

Total files needing resolve: ~50, with perhaps several hundred in the commit.