Gitextensions: Diálogo de confirmação - Linhas selecionadas do estágio não funcionam

bem para a operação usual de copiar / colar, selecionar a linha inteira não funciona ...

Mas concordo que o algoritmo deve suportar arquivos recém-criados. Não tenho certeza de como fazer isso ...

Bem, pense fácil. Na situação de confirmação, é muito incomum copiar texto de um diff. Já vi outras soluções, onde toda a linha é copiada, o que é bom. Eu pensaria na função de cópia como um bom recurso neste caso. Eu sei, que você está usando a mesma visão, ao comparar um arquivo. Então, talvez uma classe separada (delegado?), Que lida apenas com a funcionalidade do documento de confirmação, faria aqui.

Eu não entendo o que você está falando. O problema existe há muito tempo e é muito chato. Não estou experimentando ao preparar linhas de arquivos recém-criados, mas de arquivos já rastreados, mas apenas de arquivos modificados também. Triste, mas ainda não recebi os passos para reproduzir (((aparece de forma inesperada

Não tenho problemas com esse recurso há um bom tempo. Assim que você conseguir reproduzi-lo, por favor nos avise, caso contrário, uma correção é quase impossível ...

Bem, definitivamente não funcionou no 2.25, no 2.26 de alguma forma parece funcionar, mas não houve uma correção oficial para isso. Eu tinha um commit que não pude dividir por causa desse comportamento, então tive que confirmá-lo "como está". Estou falando sobre o comportamento no gitx, que é um dos melhores da interface do usuário agora. é intuitivo e claro. Quando você seleciona uma linha dentro do diff durante o commit, a linha inteira é selecionada e no lado direito aparece exatamente um botão "linha (s) de estágio" dependendo se você selecionou uma ou mais linhas. se você clicar nele, as linhas serão encenadas ou - vice-versa, não encenadas. gostaria de ver algo semelhante em gitextensions.

Por enquanto: Parece funcionar se você selecionar exatamente as linhas inteiras que deseja (des) encenar e não qualquer caractere mais ou menos. Então, talvez possamos encerrar o problema e reabrir, quando mais detalhes do que acontece estiverem claros?

"Por enquanto: parece funcionar se você selecionar exatamente as linhas inteiras que deseja (des) encenar e não qualquer personagem mais ou menos. Então, talvez possamos encerrar o problema e reabrir, quando mais detalhes do que acontece estiverem claros?"

Eu não posso aprovar isso. Ainda ontem, tive o erro e selecionar linhas inteiras não ajudou. Lembro que em algumas versões antigas isso às vezes ajudava, mas agora não. (Provavelmente após a versão que removeu a capacidade de redefinir a (s) linha (s) antes de prepará-las).

Como eu disse antes: se você tiver um caso que possa reproduzir, salve esse estado para que outras pessoas (ou você) possam tentar consertar o problema !! Sem um caso de teste reproduzível, isso nunca pode ser corrigido!

Não sei se é melhor abrir um novo fascículo ou não, mas começarei comentando aqui. Ficarei feliz em abrir uma nova edição se for melhor.

Percebi que recebo o erro acima quando tento preparar as linhas enquanto "Mostrar arquivo inteiro" está ativado. Se eu desligar, funciona bem. Isso está acontecendo de forma consistente para mim agora. Eu estava usando a versão 2.26, mas acabei de atualizar para a 2.28 e ainda está acontecendo.

referências # 636

Eu tive esse mesmo problema ontem (nada menos do projeto GitExtensions). Algumas linhas em um arquivo podem ser testadas, mas outras não. Vou tentar reproduzi-lo esta noite.

Eu reproduzo este erro para o arquivo .sln na codificação UTF8 com BOM. O problema só aparece quando a codificação diff na caixa de combinação é UTF8. Quando mudo para a codificação padrão, tudo funciona bem.

Acho que o principal problema porque o BOM muda os números das linhas

Acabei de observar um problema semelhante no Git Extensions v2.28. Com um arquivo criado usando terminações de linha Unix, adicionado usando extensões Git, recebi avisos de que as terminações de linha não seriam modificadas em meu espaço de trabalho, mas seriam substituídas por terminações de linha do Windows se eu verificasse os arquivos novamente. Em seguida, fiz duas alterações no arquivo. Em seguida, a tentativa de preparar apenas o segundo trecho falha, alegando que o patch está corrompido. Preparar o primeiro bloco parece funcionar bem. A ferramenta git de linha de comando não tem problema em preparar apenas o segundo trecho, apesar das terminações de linha, então isso parece ser um bug nas extensões Git.

Excluir o arquivo e fazer uma "verificação do git" para obter uma versão com as terminações de linha corretas corrige o problema - agora posso usar extensões Git para preparar o segundo pedaço do patch isoladamente, sem causar erros.

No entanto, houve um erro de patch corrompido semelhante quando tentei remover o palco de ambos os pedaços, um por um - não gostei quando não havia mais pedaços na área de teste.

O problema parece ter origem na codificação de um arquivo ou talvez nas terminações de linha mencionadas acima. Aconteceu comigo hoje mesmo em um projeto c # contendo um comentário com strings de caracteres alemães (Latin1, windows-1251?) E em uma linha ele mudou (qualquer motivo) a codificação do arquivo. O arquivo foi reformatado pelo VS2010. Exatamente a partir dessa linha, cada linha seguinte não pode ser encenada por meio de GE (2.40, mas também em versões anteriores). O teste no core-git funciona bem.

Acabei de atualizar para 2.40 de 2.31 e este recurso agora parece completamente quebrado. Não consigo colocar nenhuma linha em nenhum arquivo. Eu tentei com arquivos C ++ com codificação ANSI e arquivos C # com codificação UTF-8, que na maioria das vezes funcionavam no 2.31 (costumava ter problemas com a última linha do arquivo).

"... o patch falhou ... o patch não se aplica ..."

+1

bug corrigido a670f1501103fbe0d214ab76811a33353cab87af introduzido em 2.40

fd96875589f22851a691fa1f0f989816a77458aa corrige o problema de BOM

Muito obrigado Janusz. Eu reconstruí GitExtensions, substituí os arquivos em Arquivos de Programas e funciona muito bem.

Percebi que se um arquivo tiver uma linha vazia no final e você removê-lo, GitExtensions não será capaz de realizar essa alteração, no entanto, esse era o defeito existente que mencionei em meu comentário anterior.

Esta foi uma solução rápida. Quando testei, encontrei outro caso que o estágio não funcionava. Vou tentar reescrever o algoritmo de maneira mais simples.

Se alguém reproduzir este bug com 2.41 ou posterior, reabra-o.

No momento, estou tendo esse problema com 2.43. Não posso "Preparar linhas selecionadas" em nenhum arquivo se "Ignorar alterações de espaço em branco" estiver marcada. (Infelizmente, quando está desmarcado, muitos dos arquivos que tenho que confirmar têm todas as linhas do arquivo removidas e, em seguida, todas as linhas adicionadas novamente. Não tenho certeza do porquê; poderia concebivelmente ser uma coisa de tabulações versus espaços, mas isso seria ser peculiar, pois um desses arquivos é um .csproj que normalmente não é editado manualmente e, portanto, não deve estar sujeito a alterações nas configurações.)

Este recurso não funciona com espaços em branco ignorados. Parece mais um problema EOL.

Isso aconteceu comigo com 2,48 no seguinte cenário:
Tools->Settings->Git config->Line Endings: Not set
Definir os finais de linha para qualquer uma das opções resolveu o problema. Parece que not set na visualização effective é um problema de configuração e, em minha opinião, deve ser mostrado como tal.

A variante específica disso, mas conforme relatado anteriormente por grantbowering, ocorre para mim quando "Ignorar alterações de espaço em branco à esquerda e à direita" ou "Ignorar todas as alterações de espaço em branco" está habilitado com GitExtensions 2.51.03, Windows 10 64 bits:

1. Modifique um arquivo.
2. Comandos> Commit
3. Passe o mouse sobre a janela de diferenças da caixa de diálogo de confirmação.
4. Na barra de ferramentas superior que aparece, ative "Ignorar alterações de espaço em branco à esquerda e à direita" e / ou "Ignorar todas as alterações de espaço em branco".
5. Clique em uma linha modificada no diff.
6. Pressione a tecla "S" para selecionar a linha selecionada: error: patch failed: ... error: ... patch does not apply .

Veja # 3493.

Na sexta-feira, 29 de junho de 2018, às 20h03, per1234 [email protected] escreveu:

A variante específica disso, mas conforme relatado anteriormente
https://github.com/gitextensions/gitextensions/issues/684#issuecomment-12332133 por
grantbowering ocorre para mim quando "Ignore os espaços em branco à esquerda e à direita
alterações "ou" Ignorar todas as alterações de espaço em branco "está habilitado com GitExtensions
2.51.03, Windows 10 64 bits:

1. Modifique um arquivo.
2. Comandos> Commit
3. Passe o mouse sobre a janela de diferenças da caixa de diálogo de confirmação.
4. Na barra de ferramentas superior que aparece, ative "Ignorar entrelinha e
   alterações de espaço em branco à direita "e / ou" Ignorar todas as alterações de espaço em branco ".
5. Clique em uma linha modificada no diff.
6. Pressione a tecla "S" para selecionar a linha selecionada: erro: falha no patch:
   ... erro: ... o patch não se aplica.

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/gitextensions/gitextensions/issues/684#issuecomment-401501721 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ADdhsSZcDBHHn25q6HhRfvdkTdM5pjbsks5uBsA3gaJpZM4AFHeS
.