search

jisaacks / GitGutter

A Sublime Text 2/3 plugin to see git diff in gutter
MIT License
3.88k stars 225 forks source link

Icons are gone #543

Closed Meshparts closed 5 years ago

Meshparts commented 5 years ago

Since approximatelly one week the gitgutter icons on the right side of the row numbers are gone, making gitgutter unusable. I checked everything on Troubleshouting but no success. Interesting: I see the colored dots in the minimap on the right side of the screen, so git gutter actually works in the background it just doesn't show the icons.

Using

deathaxe commented 5 years ago

This is expected behavior if GitGutter runs on Sublime Text 3189+ with "mini_diff": true or "mini_diff": "auto" in order to not interfere with the new Incremental Diff feature of Sublime Text. In this situation GitGutter does not add gutter icons anymore to leave the space to other plugins like SublimeLinter.

We don't need two indicators about modifications at a time.

GitGutter still works in the background to add modification indicators to the minimap as @sublimehq decided not to render them using the incremental diff feature.

If you prefer GitGutter's file modification icons in the gutter, you need to set "mini_diff": false in your Preferences.sublime-settings.

_Note: Same applies to the status bar. If "show_git_status": true is set in the Preferences, no repo name or branch name are printed by GitGutter._

Meshparts commented 5 years ago

Thanks, setting mini_diff to false solved the problem. So what is the meaning of mini_diff: true? Do I need gitgutter if there is inbuild functionality now?

deathaxe commented 5 years ago

I guess this is a question of taste. Basically ST3.2 introduces the most basic functions of GitGutter:

  1. modification indicators in the gutter
  2. navigate between modifications using ctrl+, and ctrl+..
  3. revert modifications by ctrl+k, ctrl+z.
  4. ST's inline diff feature may replace GitGutter's diff popup.
  5. status bar indicator with branch name and number of modified files in the repo.

While GitGutter relies on git to calculate the modifications, Sublime Text uses its own builtin incremental diff algorithm, which might not always return the same result as git does.

All builtin actions like navigating or reverting relies on the incremental diff.

The pro is: You can revert single words in a line by simply marking them.

The contra is: If there are several modifications per line, you must select the line to make sure revert is applied to all of them.

Same for navigation: While I like ST to select each hunk while navigating, it can be annoying if there are too many interline changes.

What Sublime Text does not offer at the moment is:

  1. GitGutter's "Compare Against..." features.
  2. Modification indicators in the minimap
  3. Diff Popup
  4. Line annotations
  5. Status Bar Text Template

Basically we could create a plugin for ST3.2+ which adds the most valuable features from GitGutter

  1. GitGutter's "Compare Against..." features.
  2. Line annotations

while abandoning the ones which are provided by ST itself, which could help reducing CPU usage while editing files.

But I am not sure whether this would or should be part of a GitGutter 2.0 release or if it is worth creating a new plugin for dedicated use with ST3.2+.

I consider the required changes to result in a nearly complete rewrite of GitGutter with the heavy risk of breaking things for users of older ST releases.

Meshparts commented 5 years ago

Many thanks for the detailed comparisson. I guess I'll stck with gitgutter for the moment.

aeallord commented 5 years ago

This is expected behavior if GitGutter runs on Sublime Text 3189+ with "mini_diff": true or "mini_diff": "auto" in order to not interfere with the new Incremental Diff feature of Sublime Text. In this situation GitGutter does not add gutter icons anymore to leave the space to other plugins like SublimeLinter.

We don't need two indicators about modifications at a time.

GitGutter still works in the background to add modification indicators to the minimap as @sublimehq decided not to render them using the incremental diff feature.

If you prefer GitGutter's file modification icons in the gutter, you need to set "mini_diff": false in your Preferences.sublime-settings.

_Note: Same applies to the status bar. If "show_git_status": true is set in the Preferences, no repo name or branch name are printed by GitGutter._

Though this is a good explanation of why they disappeared it isn't quite fully answered.

  1. The mini map doesn't tell me what line numbers changed?
  2. You're assuming everyone has SublimeLinter installed?
  3. What if I as a user want your icons because GitGutter is the only plugin I'm using?

I believe this would still be a bug. Sometimes we as users want to the marked line changes and are only using GitGutter....

deathaxe commented 5 years ago

You're assuming everyone has SublimeLinter installed?

No I don't, but a couple of issues in the past were about plugins trying to create gutter icons for the same line causing conflicts. SublimeLinter was just the most popular example of such a plugin, which I had in mind.

What if I as a user want your icons because GitGutter is the only plugin I'm using?

If you prefer GitGutter's file modification icons in the gutter, you need to set "mini_diff": false in your Preferences.sublime-settings.

GitGutter adapts to the new incremental diff feature introduced with ST 3.2.

I believe this would still be a bug. Sometimes we as users want to the marked line changes and are only using GitGutter....

It is actually a fix for https://github.com/jisaacks/GitGutter/issues/541, https://github.com/jisaacks/GitGutter/issues/538 and https://github.com/jisaacks/GitGutter/issues/537

aeallord commented 5 years ago

@deathaxe thanks for the response.

Pictor13 commented 5 years ago

Probably GitGutter 2.0 should just adapt to and support the new version of Sublime, so that it's cleaned up and ready to follow future implementation on ST side.

There might be branch/tags for the old version, still supporting the features that are redundant in ST3.2+, for old users or people that won't update ST; and these branch would just integrate bug and security fixes but won't receive additional feature implementations. Or there is an idea to proceed differently, maybe not dropping the implementation for older user?

Tracking two different repositories about similar software sounds tricky, tho; I remember a year ago also the TheGreatSuspender Chrome extension author was having a similar dilemma, when starting to develop TheGreatDiscarder repository, as a parallel development that cleaned up a lot of old code and just sticked to the new native discarding feature from Chrome, making everything lighter/smoother.

deathaxe commented 5 years ago

I already thought about creating a new st3.2-2.0 branch to create something new and maybe more lightweight based on ST's core features.

But the recent feedback makes me wonder, whether it's a good way to go.

  1. Looks like there are quite a lot of devs out there, which prefer GitGutter's way of diffing.
  2. As ST does not render diffs in the minimap none off the current implementations can be dropped without breaking support it.
  3. Most features are implemented optional being active only if prerequisites like ST version are met. Not much overhead to support older features.

In the end there is not much room to lighten things much.

All I have in mind would require quite big changes, with little functional changes to the end user. But GitGutter somehow works too good to risk a lot of new bugs due to heavy changes.

_Unfortunatelly ST does not provide an API to directly manage the minidiff markers. This would have been my favourite solution - just parsing the diff and pushing lists of added/deleted/modified lines to the API.

Pictor13 commented 5 years ago

Fair enough, I understand your points and agree with you. As you said, in the end it would be more about elegance than about direct benefits for the users.

I suppose the ticket could be closed?