Sublime Forum

Change default max-parents in search


After identifying the file that caused a regression in my code, I searched for it in SM to try to find the commit that brought caused the issue. However, I couldn’t find any commit whose diff shows the introduction of the bug. I was only able to find the issue by traversing all of the commits on the repo without the search function filtering out the commits affecting other files.

In trying to figure out why I wasn’t seeing the merge-commit that caused the regression in the search, I stumbled upon the max-parents setting that helped me find that merge-commit in the search by setting it to max-parents:2 in the search query.

This raised 2 questions:

  1. Why is the default max-parents setting set to 1? Combined with the search showing all commits as being linear in the graph (ignoring branching), this causes what I believe to be a UX issue, giving a false sense to the user that he’s seeing all commits that affected the particular file when it’s not the case.
  2. Is there a way to set the default max-parents to 2 in the settings?




Max parents doesn’t have a default setting, ie. there is no limit applied at all unless you include that in the search. What may be a little confusing is that merge commits don’t have the hollow button on them. Here’s a search result on the Linux repository with a merge commit with 3 parents as the first result:



@bschaaf, he’s probably using path: or file: to track down a specific change. Those two operators (and contents:) ignore merge commits by default.



Hi all,

Thank you for sharing your feedback regarding this behavior.

To clarify why Sublime Merge has this behavior: the reason for this is that it’s very expensive to also include merge commits when searching for contents/file changes. This is also the default behavior for Git too (see:

That being said, we can look into adding a setting to control this.
For now, as noted in the search manual you can use the min-parents:0 operator to include merge commits.

- Dylan