Sublime Text 3. Version 3.2 (BUILD 3200)
I have just updated to the latest version.
When I am editing a file, there are orange bars that show up next to the line numbers when I create new lines.
It would make sense for these to represent unsaved changes, but saving the file does not cause the bars to change.
They also seem to change color based on if I created a new line or if I am editing within a line.
What do the markings mean?
They go away when I close and re-open the file.
That’s the new mini_diff functionality. Colored bars are shown in the gutter next to lines you add or lines you modify, and an arrow is displayed at points where you deleted lines from the file.
If you edit a file that’s in a git repository, then the markers track the state of the file since the last time you checked it in. Outside of git repositories it tracks changes since you opened the file (which is why it goes away when you close and reopen the file).
More information is available in the documentation; particularly the pages on Git Integration and Incremental Diff.
I recognise that the general approach to the mini_diff (incremental diff) feature is closely coupled to git integration but it doesn’t make much sense when git isn’t in use.
Intuitively it makes far more sense for file modification markers to represent modifications since the last save for non-git uses. Logically a save should therefore clear the markers. I spent quite some time trying to figure out why that wasn’t the case, only to realise that the present behaviour appears to be by design.
Turning off mini_diff altogether means we don’t get the indicators when working on git projects so that’s not a solution. Besides, it’s nice to have these indicators to show what’s been changed since the file was loaded.
Is there a workaround to this. eg. an api call to clear mini diff markers?
I like how it works by default in that it allows me finer control over when the diff clears (that is; while tweaking a script I can take several runs at edits and still track what’s going on), but that’s definitely a personal preference.
The view.reset_reference_document() API function could be used with this, in conjunction with an on_post_save or on_post_save_async event handler to reset the reference document used for the diff, which would clear the markers.
That should be fairly simple; I think the only gotcha would be in making sure that it doesn’t trigger for files that are in a git repo, since per issue #2689 using that API method will clear the diff status for those files too, which is probably not desirable.
Ah brilliant thanks @OdatNurd. Should have thought to recheck the API docs 
Now that just leaves the question of how to establish whether a file/tab is being tracked in git since I’d ideally want this behaviour on save for files outside of git. This could be achieved in a clumsy way (look for a .git folder up the directory tree, manually check against .gitignore etc. etc.) but I’m wondering whether there’s an elegant way ie. to query sublime for this info?
I’ll probably start knocking together a plugin for this as it’s grating with me.
Thanks again
@OdatNurd I’m still pondering whether there’s an easy way to determine a file’s git status (tracked, untracked) for the purposes of a plugin as described above. Do you have any thoughts on this, or are you none the wiser than I? 
I don’t think there’s any easy way, no; or if you will, I’m not aware of any direct way to determine if a particular path is being tracked by Sublime as being in a git repository without having to determine that information for yourself.
Prior to the official integration between Text and Merge, I created a simple plugin to add the integration myself. For that I came up with the following code that may help you out here:
def _find_git_root(path):
"""
Find the containing git repository (if any) in a given path; returns the
repository root or None if one can't be found.
"""
if os.path.isdir(os.path.join(path, ".git")):
return path
nPath = os.path.split(path)[0]
if nPath != path:
return _find_git_root(nPath)
return None
def _git_root_for_view(view):
"""
Find the git repository that the file in the provided view exists in, if
any.
"""
if not hasattr(_git_root_for_view, "cache"):
_git_root_for_view.cache = {}
if not view or view.file_name() is None:
return None
path, file = os.path.split(view.file_name())
if path not in _git_root_for_view.cache:
_git_root_for_view.cache[path] = _find_git_root(path)
return _git_root_for_view.cache[path]
The first function performs a recursive search for a .git folder within a given path and tells you where it found it (if it can). The second takes view and uses the first to find the git repository that the file that it’s editing is stored in. It caches the results of path lookups so that once it finds a git repository, it always assumes that folder is a git repo until the plugin reloads (such as when you restart Sublime).
I’m not sure how elegant it is as a solution, but it worked for me at the time. Note also that I think that it’s possible for .git to be a file in the case of work trees or something similar (but I’m not sure), in which case this would fail to find it unless you modify it to just test for the existence of .git instead of verifying that it’s a folder.
I should also mention that I only really tested it out on Linux since there’s where I do the bulk of my development, though offhand I don’t see why it wouldn’t work for other OS’s as well. It may or may not also be interesting to do more introspection to determine if what you found is actually a git repository or not.
Many thanks @OdatNurd that will certainly me to build a workaround. It’s more or less what I had in mind but that saves me a bit of time as I only dip in to Python now and then. Thanks again.
However I am a little concerned about the lack of APIs in this regard. I wonder if @wbond could chime in about whether some APIs concerning the ‘git side’ of ST will be implemented. A good start is for a plugin to be able to enquire whether a file is being tracked in git.
Dude, just let me scream it loud: it’s a such a mess with Sublime Text API, that it took for about a year and an enormous amount of luck to get to know that it have an API to control the source of Incremental diff function.
Here’s 1 like nothing pointing out where to find any API reference.