Vscode: git.enabled should hide the Git icon and disable ctrl+shift+g

[Tyriar]

From http://stackoverflow.com/a/33956083/1156119

"git.enabled": false,

I tried it and was expecting the icon to be hidden. It's also unclear whether git.autofetch does anything if git.enabled is set to false.

[joaomoreno]

Closing as won't fix. git.autofetch is ignored if git is disabled.

[DanTup]

@joaomoreno Is there any significant reason not to hide the icon when disabled? It seems a bit pointless and there were loads of complaints about Visual Studio re-enabling and showing Git stuff when people turn it off.

It doesn't seem unreasonable to expect the icon for a disabled feature to disappear; some of us use other source control applications and/or different git clients and would rather a cleaner UI.

[Tyriar]

I saw someone comment about this on Twitter yesterday https://twitter.com/SoftwareFailed/status/758705581859504128

For those who don't use Git, this only make the editor feel more heavy by exposing UI that isn't used.

[joaomoreno]

loads of complaints about Visual Studio re-enabling

@DanTup If that's the case, it is a bug and we'll fix it. Did it happen to you?

The reason for not fixing this is a technical one. There is currently no way to dynamically add/remove activity icons. But since that's the only reason, I'll leave it open.

[DanTup]

loads of complaints about Visual Studio re-enabling

@DanTup If that's the case, it is a bug and we'll fix it. Did it happen to you?

This was full-fat Visual Studio. Yes it happened to me, and I'm sure the VS Team know about it as @markrendle put an extension in the gallery about it :(

I was just using it as an example; some people just don't want to use Git and would prefer if the IDE didn't keep teasing them about it :)

[joaomoreno]

Actually another reason to not do this is to keep UI stable (eg: show disabled actions instead of removing them).

@stevencl Thoughts?

[stevencl]

In general it's best to show disabled actions since that helps communicate to the user that an action is unavailable in a particular context, but may be available if they take another action, or in a different context.

For example, here is somebody asking why they can't use git in VS Code: http://stackoverflow.com/questions/29965319/git-is-not-enabled-in-this-workspace-in-vs-code

Perhaps somebody else on their team turned git off in the workspace settings. This particular user is unaware that git has been disabled and so needs some feedback telling them what they need to do to enable git.

I'm curious though what the rationale for the setting is in the first place? What problem are we solving by exposing this setting? If a side effect of the setting is that it incorrectly communicates to users that they can use this to remove the whole Git viewlet, perhaps we need to consider rewording the setting?

[DanTup]

In general it's best to show disabled actions

I think there's a big difference between "actions that don't apply now" and "functionality that has been turned off globally". Some people just don't want your Git integration (whether it's because they're using the command line, GH4W or even a different source control system). Visual Studio is annoying enough with it's aggressive enabling of the Git provider; Code could learn from its mistakes.

IMO it makes absolutely no sense to permanently show a Git button that will never work because the user has explicitly turned the feature off. One of the attractive things about Code is that it's clean and unbloated (and extensible! earlier comments suggest extensions will never be able to add icons if they're fixed?).

[stevencl]

Thanks for the feedback @DanTup. I agree, there is a big difference between actions that don't apply now and functionality that has been turned off globally. If the intent of this setting is to completely turn off the functionality then it would make sense to remove any trace of the functionality. I'd just like to clarify with @joaomoreno if that is indeed the case.

We also have to consider the case where this is turned off in workspace settings and then shared with a team. This is a corner case, but in this case the person that is trying to figure out why they don't see any Gut UI might not be the person that disabled git for this workspace.

[DanTup]

Sure, that's totally valid; I hadn't considered the workspace-level setting :)

[joaomoreno]

Not valid any more.