Até ontem meu settings.json para Windows Terminal tem este perfil para Git Bash:
...,
"defaultProfile": "{my_guid}",
"profiles":
{
"defaults": {},
"list":
[
{
"guid": "{my_guid}",
"hidden": false,
"name": "Git Bash",
"source": "Git"
},
...
]
}
...
que simplesmente funcionou, eu poderia usar o perfil e defini-lo como padrão.
Hoje este perfil não é reconhecido, o Windows Terminal abre com um aviso para o perfil padrão não encontrado e o perfil do Git Bash não está na lista suspensa.
Eu sei que posso apenas definir o perfil para usar o caminho para o executável do Git Bash, mas quero saber o que mudou.
Por que o perfil usando o atributo source funcionou antes? Por que não funciona mais? Onde está a documentação ou a nota de lançamento que especifica isso?
O
"source"
atributo indica um " Perfil Dinâmico " ou uma " Extensão de Fragmento JSON " para Windows Terminal. Embora as extensões de fragmento JSON sejam um recurso relativamente novo, no momento desta resposta, o documento da Microsoft para o"source"
atributo ainda menciona que elas são usadas para perfis dinâmicos. Portanto, peço desculpas por minha opinião anterior sobre esta resposta assumir que este era um perfil dinâmico.O Windows Terminal inclui geradores internos para perfis dinâmicos para WSL (qualquer distribuição instalada), PowerShell Core e Azure (embora pareça ser mais um gerador estático). Você pode encontrar os geradores neste diretório da fonte.
As extensões de fragmento JSON são usadas para aplicativos de terceiros, como o Git Bash, que recentemente adicionou isso como um recurso em seu instalador .
Depois que você confirmou que o Git Bash realmente estava usando o
"source"
atributo, decidi experimentar o instalador e confirmar o uso das extensões de fragmento. Como esperado, vejo a mesma coisa que você faz em meussettings.json
perfis (e na interface do usuário de configurações):E em
C:\ProgramData\Microsoft\Windows Terminal\Fragments\Git
, posso ver a extensão real (git-bash.json
):Eu honestamente não tenho certeza. O recurso parece bastante robusto, em meus testes limitados. A única maneira que eu poderia quebrar era fazer algo patológico, como:
"guid"
atributo manualmenteQuase tudo o que tentei foi recuperável ou esperado:
Desinstalando o Git para Windows -- Removido corretamente o fragmento. O Windows Terminal foi inteligente o suficiente para remover as pastas pai vazias na reinicialização.
Excluindo o próprio perfil em
settings.json
-- Como o fragmento ainda existe, ele é recriado automaticamente assim que as alterações são salvas.