git status arrasta-se em SSHFS por VPN: mude o trabalho

Copie um ficheiro de 200 MB e ele voa. Execute git status no mesmo diretório e a espera é longa o suficiente para mudar de contexto. Essas duas observações não se contradizem, porque a transferência em massa mede o débito enquanto o Git mede quantas pequenas perguntas ao sistema de ficheiros pode fazer por segundo, e uma árvore remota montada transforma cada pergunta numa ida e volta. Ajustar a VPN não corrige uma carga de trabalho mal formada.

Porque status é a referência errada

O Git tem de saber de muitos ficheiros: quais estão modificados, quais não estão rastreados e se os dados de índice em cache ainda correspondem ao que está no disco. Por SSHFS cada uma dessas observações pode ser uma operação de rede. A unidade de trabalho aqui é o número de ficheiros, não os megabytes.

É por isso que o primeiro status depois de um clone é lento, e por isso os seguintes podem ser ainda mais lentos numa árvore cheia de saída de compilação. A análise dos não rastreados percorre diretórios que talvez não te interessem, e cada passo é outro pedido pelo link. Num caminho de 40 ms uma árvore com alguns milhares de entradas torna-se alguns milhares de idas e voltas. Não é preciso capturar pacotes para confirmar essa aritmética.

Um teste de download diz que o link está bem; não diz nada sobre se mil leituras pequenas terminam esta tarde.

Mude a árvore de trabalho, não os botões de afinação

Um clone local põe a árvore de trabalho, o índice e as operações Git na mesma máquina. Um pull passa a ser um passo de rede visível em vez de o ser cada verificação de ficheiro.

Isto encaixa sempre que o programador consegue manter a fonte necessária localmente, o que é a maioria das vezes. Também afina a fronteira entre commit e implementação, porque editar um ficheiro local já não altera por acidente um serviço remoto em execução; a alteração tem de ser enviada e implementada como tudo o resto. O preço é que o código existe em dois sítios, por isso decida que cópia é a autoritativa e como uma correção urgente no servidor volta ao repositório. Essa conversa é mais barata do que um comando status que ninguém quer executar.

Se o espaço de trabalho tem de ficar remoto, execute o Git lá

Por vezes o espaço de trabalho não pode mudar: a compilação precisa desse ambiente, os dados são demasiado grandes ou a política mantém a fonte no anfitrião. Então execute o Git e as ferramentas de desenvolvimento relevantes junto dos ficheiros, através de uma shell remota aprovada ou de um ambiente de desenvolvimento remoto. O editor pode ficar no portátil enquanto o seu backend trabalha junto da árvore de trabalho.

As operações caras acontecem então localmente no anfitrião remoto, e a rede transporta o tráfego do editor em vez de milhares de chamadas stat. É a mesma correção de um clone local, expressa como escolha de implementação e não como migração.

A sincronização é um fluxo de trabalho com donos, não uma cache

Um espaço de trabalho sincronizado pode reduzir leituras remotas repetidas, mas não é uma cache transparente. Precisa de um dono para cada alteração, de uma regra para conflitos e de um acordo sobre ficheiros gerados que ambos os lados consideram seus. Sem essas regras o arranjo cria desacordo em vez de comodidade.

Um sincronizador bidirecional sem elas produz um problema diferente do que resolveu, normalmente uma fusão que ninguém consegue atribuir. Evite executar dois processos Git sobre uma árvore de trabalho partilhada, a menos que compreenda como se coordenam.

Depois afine, e mantenha o SSH sensato

Quando o arranjo está correto, dois parâmetros mudam sobre quantos ficheiros o Git tem de perguntar: status.showUntrackedFiles e a cache dos não rastreados atrás de core.untrackedCache. Nenhum muda o que custa cada pergunta ao longo de 40 ms; mudam apenas quantas perguntas existem. Rode um botão só quando as idas e voltas forem locais.

Meça o tempo do comando que te irrita em vez de raciocinar a partir de um teste que copia um ficheiro grande, e deixe em paz a cifra SSH suportada. Uma cifra obsoleta não encurta uma ida e volta; acrescenta um segundo problema que sobrevive ao primeiro. A referência do git status vale uma leitura, porque o comando faz muito mais trabalho do que o nome sugere.