Show staging status #118
Comments
|
This is a feature I am currently working on. Thanks. |
|
+1 |
|
I have a branch called staged with what I have so far. Some notes:
Here is a screenshot using the DeepBlueSee color scheme: I would love to have some feedback on all of this from any interested parties. |
|
Just got this worked into my theme. Looks great. |
|
Cool stuff. I've just started to use gitGutter and it's amazing... |
|
@maffiou There is a new feature (pulled in from the branch I linked previously) that lets you choose a commit to compare against. You can find it in the command palette. @mcmillion I am still working on this, its quite tricky. I have a pull request #136 but I am not convinced it is ready for prime time just yet. It does show the staged status even if the file is dirty now. If you pull the latest code, I would love any feedback. |
|
@jisaacks Sorry for not responding earlier, I've been stupidly busy lately. I'm using gitGutter every single day and love it. 👍 Will try the latest version when I can risk it. :) |
|
@maffiou Thanks man! BTW, did not know about flattr, just went and created an account. |
|
@jisaacks I just tried your branch. I'm afraid it won't work cleanly with my default theme :( This might be an issue for MarkHMorrison/nexus-theme#9 |
|
It might also be an issue with https://github.com/Benvie/JavaScriptNext.tmLanguage/blob/master/JavaScriptNext.tmTheme#L1493 not sure how to apply patches or where to apply them. |
|
@Raynos I am not exactly sure I understand what your issue is, but I think you are saying that of the 2 themes you want to use, Nexus, and JavaScriptNext, neither define the appropriate values needed for this branch. The values that need to be defined (for git gutter in general) look like this:
Then for this branch, it adds:
The way these color defs work in sublime text, is, each So when something needs to be colored like markup.inserted.git_gutter.staged sublime checks for the following values and uses the first one it finds:
It looks like those themes define the markup.inserted etc. without the git_gutter or staged pieces, which should still work, except staged/unstaged changes will not be colored differently. If you want to modify/patch the theme to make it work as desired for this branch, you just need to edit the theme and add the appropriate values. Alternatively if you just want to grab a theme to play with this branch that already has the needed color defs, you can use this theme |
|
@jisaacks can we get these changes merged into master behind opt in config flags. It makes it easier to try these changes without having to manually install a branch of gitgutter in sublime. Same thing for the protected regions branch. |
|
@Raynos actually, I think there is a way to tag a branch and have it installable as a separate version via Package Manager. I will look into that when I get some free cycles. I would rather not merge half baked features into master. |
|
@jisaacks
... and the scopes in DeepBlueSee:
Some Questions: Should it be Could this be merged and released yet? |
|
Hmm... I am not sure if this should be separate issue or comment here... I was checking possible options for |
|
I like this idea as it should by quite easy to realize and seems straight forward. I was thinking about the approach suggested by PR #136 to combine diffs from staging area and HEAD but found it quite heavy. I think I'll pick up this idea. |
An idea how to handle Compare against staging areaI find selecting the Compare against staging area manually possibly not to be so user friendly and a bit tricky on the other hand.
So here is an idea: GitGutter compares against the HEAD by default, but can compare the view against the current branch, too. When comparing against...
These two options would allow comparing against both staging area and latest commit without any additional command. So all change markers will disapear as soon as a file gets staged. The staging status is shown in the status bar. Any further changes will start to add new gutter icons and the status bar text displays staged and modified. |
|
@deathaxe I am not sure I follow. What is the difference between HEAD and the current branch? Don't the both point to the same commit? |
|
Yes this is the point. The question is, how and when to enable people to compare against the staging area. One option would be to add a But if a view's file is not in the staging area, GitGutter needs to fallback to the HEAD anyway to have something to compare against. This can happen in two ways:
Option 2 interferes with the feature of selecting a compare target per repository. Example: 2 tabs showing files of the same repo are open. 1 staged, 1 modified. User has the staged view on top editing something while compared against staging area. Now he switches to second (modified) tab. The compare target is reset to HEAD as not contained in the staging area. Switching back to the staged view, would now no longer compare against staging area as HEAD is the new target. -> No-Go. Option 1 is the better idea, as it would automatically compare against HEAD for unstaged files and compare against staging area if a file is staged. The new command would be named like So the question is: Do I need to add this explicit command and setting value for it or can I automatically compare against staging area, if HEAD is the selected compare target? Doing so would extend the meaning of HEAD to include a staged file if available automatically without user interaction. If a user still wants to compare against the latest committed file the |
|
I think you are going down the rabbit hole with this comparing to the staging area stuff. The idea is to 'simply' compare to the HEAD as usual, but have different icons to indicate if the hunk is staged or not. [I do realize this is not actually simple to implement...] |
|
This is what I wanted to avoid because this requires to read both the staged and commited file, compare both to the view and merge results. This costs much more effort and time on large files. Even worse, a new scope is needed for a new set of icons, which will then need to be added to all color schemes to show up correctly. This is the approach from PR #136. Just switching between staged and commited files would just need to add one further method to read the staged file content. Nothing else need to be changed. The staging are is handled like any other compare target. |
This is precisely what I was attempting to solve in my branch. I was getting results but its a very complex problem. Probably more complex than all of the rest of git gutter. And it's an edge case. Not worth the complexity in my opinion. Although it would be cool. |
The open view can be compared against its staged counter part, if available as comparing against any other target is possible by a command. Known Issues: As a file from staging area can be read by `git show` only, this won't work with smudge filters.
The open view can be compared against its staged counter part, if available as comparing against any other target is possible by a command. Known Issues: As a file from staging area can be read by `git show` only, this won't work with smudge filters.
|
Was there any progress on this? I see there is still a "staged" branch. I'm upgrading a colour scheme to the "sublime-color-scheme" format and have these scopes:
Are all these scopes still used? The new SublimeLinter4 sets colours via its settings file rather than custom scopes defined in the color scheme. It has this setting to set the error colour:
Any plan to set colours a similar way? |
|
|
If you use the scope It looks like it would need a refactoring, but except from that I don't really see disadvantages. Nonetheless I am not sure whether we should expose that to the settings. |
Would it be possible to show an indicator for lines of files that have been staged?
The text was updated successfully, but these errors were encountered: