Gitextensions: Diálogo de confirmación: las líneas seleccionadas en la etapa no funcionan

bueno, para la operación habitual de copiar / pegar, la selección de toda la línea no funciona ...

Pero estoy de acuerdo en que el algoritmo debería admitir archivos recién creados. Aunque no estoy seguro de cómo hacerlo ...

Bueno, piensa con calma. En la situación de cometer, es muy inusual copiar texto de un diff. He visto otras soluciones, donde se copia toda la línea, lo cual está bien. Creo que la función de copia es una característica agradable en este caso. Sé que está utilizando la misma vista al diferenciar un archivo. Entonces, tal vez una clase separada (¿delegado?), Que maneje solo la funcionalidad del documento de confirmación, haría aquí.

No entiendo de qué estás hablando. El problema existe desde hace mucho tiempo y es muy molesto. Lo estoy experimentando no cuando preparo líneas de recién creadas, sino de archivos ya rastreados, pero también modificados. Triste, pero sigo sin seguir los pasos para reproducir (((aparece inesperadamente

No he tenido ningún problema con esta función desde hace bastante tiempo. Una vez que pueda reproducirlo, avísenos; de lo contrario, es casi imposible solucionarlo ...

Bueno, definitivamente no funcionó en 2.25, en 2.26 de alguna manera parece funcionar, pero no hubo una solución oficial para esto. Tuve un compromiso que no pude dividir debido a ese comportamiento, así que tuve que cometerlo "tal cual". De lo que estoy hablando es del comportamiento en gitx, que es una de las mejores interfaces de usuario en este momento. es intuitivo y claro. Cuando selecciona una línea dentro de la diferencia durante la confirmación, se selecciona toda la línea y en el lado derecho aparece exactamente un botón "línea (s) de escenario" dependiendo de si seleccionó una o más líneas. si hace clic en él, las líneas se organizan o, viceversa, no se organizan. Disfrutaría ver algo similar en gitextensions.

Por ahora: Parece que funciona si seleccionas exactamente las líneas completas que quieres (des) escenificar y ningún personaje más o menos. Entonces, ¿tal vez podamos cerrar el problema y reabrirlo, cuando estén claros más detalles de lo que sucede?

"Por ahora: Parece que funciona si seleccionas exactamente las líneas completas que quieres (des) escenificar y ningún personaje más o menos. Entonces, ¿tal vez podamos cerrar el problema y volver a abrir, cuando haya más detalles de lo que sucede?"

No puedo aprobar esto. Ayer recibí el error y seleccionar líneas completas no ayudó. Recuerdo que en algunas versiones antiguas esto ayudó algunas veces, pero no ahora. (Probablemente después de la versión que eliminó la capacidad de restablecer línea (s) antes de prepararlas).

Como dije anteriormente: si tiene un caso que puede reproducir, guarde ese estado para que otros (o usted) puedan intentar solucionar el problema. ¡Sin un caso de prueba reproducible, esto nunca se puede arreglar!

No sé si es mejor abrir un nuevo número o no, pero empezaré comentando aquí. Con mucho gusto abriré una nueva edición si eso es mejor.

Me di cuenta de que obtengo el error anterior cuando intento trazar líneas mientras "Mostrar archivo completo" está activado. Si lo apago, funciona bien. Esto me está sucediendo constantemente en este momento. Estaba usando la versión 2.26, pero acabo de actualizar a la 2.28 y todavía está sucediendo.

referencias # 636

Tuve este mismo problema ayer (en el proyecto GitExtensions nada menos). Algunas líneas de un archivo pueden organizarse pero otras no. Intentaré reproducirlo esta noche.

Reproduzco este error para el archivo .sln en codificación UTF8 con BOM. El problema solo aparece cuando la codificación diferencial en el cuadro combinado es UTF8. Cuando cambio a la codificación predeterminada, todo funciona correctamente.

Creo que el problema principal porque la lista de materiales cambia los números de línea

Acabo de observar un problema similar en Git Extensions v2.28. Con un archivo creado usando terminaciones de línea Unix, agregado usando Extensiones Git, recibí advertencias de que las terminaciones de línea no se modificarían en mi espacio de trabajo, pero serían reemplazadas por terminaciones de línea de Windows si revisaba los archivos nuevamente. Después de esto, realicé dos cambios en el archivo. Luego, intentar organizar solo el segundo trozo falla, alegando que el parche está dañado. La puesta en escena del primer fragmento parece funcionar bien. La herramienta git de la línea de comandos no tiene problemas para preparar solo el segundo trozo, a pesar de los finales de línea, por lo que parece ser un error en las extensiones de Git.

Eliminar el archivo y hacer un "git checkout" para obtener una versión con los finales de línea correctos, soluciona el problema; ahora puedo usar Git Extensions para organizar el segundo trozo del parche de forma aislada sin causar errores.

Sin embargo, hubo un error de parche corrupto similar cuando intenté desmontar ambos trozos, uno por uno; no me gustó cuando ya no quedaban más trozos en el área de ensayo.

El problema parece originarse en la codificación de un archivo o tal vez en los finales de línea como se mencionó anteriormente. Me sucedió hoy en el proyecto ac # que contiene un comentario con cadenas de caracteres alemanes (Latin1, windows-1251?) Y en una línea cambió (por cualquier motivo) la codificación del archivo. El archivo fue reformateado por VS2010. Desde exactamente esta línea en adelante, cada línea siguiente no se puede organizar a través de GE (2.40, pero también en versiones anteriores). La puesta en escena en core-git funciona bien.

Acabo de actualizar a 2.40 desde 2.31 y esta característica ahora parece completamente rota. Parece que no puedo organizar ninguna línea en ningún archivo. Lo intenté con archivos C ++ codificados con ANSI y archivos C # codificados con UTF-8, que la mayoría de las veces solía funcionar en 2.31 (solía tener problemas con la última línea del archivo).

"... el parche falló ... el parche no se aplica ..."

+1

Error corregido a670f1501103fbe0d214ab76811a33353cab87af introducido en 2.40

fd96875589f22851a691fa1f0f989816a77458aa soluciona el problema de BOM

Muchas gracias Janusz. Reconstruí GitExtensions, reemplacé los archivos en Archivos de programa y funciona muy bien.

Me di cuenta de que si un archivo tiene una línea vacía al final y lo elimina, GitExtensions no puede realizar este cambio; sin embargo, este era el defecto existente que mencioné en mi comentario anterior.

Esta fue una solución rápida. Cuando lo probé, encontré otro caso en el que la etapa no funciona. Intentaré reescribir el algoritmo de una manera más sencilla.

Si alguien reproduce este error con 2.41 o posterior, vuelva a abrirlo.

Actualmente tengo este problema con 2.43. No puedo "Organizar líneas seleccionadas" en ninguna parte de ningún archivo si "Ignorar cambios de espacio en blanco" está marcado. (Desafortunadamente, cuando está desmarcado, muchos de los archivos que tengo que confirmar tienen todas las líneas del archivo eliminadas y luego todas las líneas agregadas nuevamente. No estoy seguro de por qué; posiblemente podría ser una cosa de tabulaciones contra espacios, pero eso sería Sería peculiar ya que uno de estos archivos es un .csproj que normalmente no se edita a mano y, por lo tanto, no debería estar sujeto a ese cambio de configuración).

Esta función no funciona con espacios en blanco ignorados. Se parece más a un problema de EOL.

Esto me pasó con 2.48 en el siguiente escenario:
Tools->Settings->Git config->Line Endings: Not set
Establecer los finales de línea en cualquiera de las opciones resolvió el problema. Parece que not set en la vista effective es un problema de configuración y, en mi opinión, debería mostrarse como tal.

La variante específica de esto, pero como se informó anteriormente por grantbowering, ocurre para mí cuando "Ignorar los cambios de espacios en blanco iniciales y finales" o "Ignorar todos los cambios de espacios en blanco" está habilitado con GitExtensions 2.51.03, Windows 10 de 64 bits:

1. Modifica un archivo.
2. Comandos> Confirmar
3. Pase el mouse sobre la ventana de diferencias del diálogo de confirmación.
4. Desde la barra de herramientas superior que aparece, habilite "Ignorar los cambios de espacios en blanco iniciales y finales" y / o "Ignorar todos los cambios de espacios en blanco".
5. Haga clic en una línea modificada en la diferencia.
6. Presione la tecla "S" para colocar la línea seleccionada: error: patch failed: ... error: ... patch does not apply .

Ver # 3493.

El viernes 29 de junio de 2018 a las 8:03 p.m., per1234 [email protected] escribió:

La variante específica de esto, pero como se informó anteriormente
https://github.com/gitextensions/gitextensions/issues/684#issuecomment-12332133 por
grantbowering ocurre para mí cuando "Ignore los espacios en blanco iniciales y finales
cambios "o" Ignorar todos los cambios de espacios en blanco "está habilitado con GitExtensions
2.51.03, Windows 10 de 64 bits:

1. Modifica un archivo.
2. Comandos> Confirmar
3. Pase el mouse sobre la ventana de diferencias del diálogo de confirmación.
4. En la barra de herramientas superior que aparece, habilite "Ignorar encabezados y
   cambios de espacios en blanco finales "y / o" Ignorar todos los cambios de espacios en blanco ".
5. Haga clic en una línea modificada en la diferencia.
6. Presione la tecla "S" para organizar la línea seleccionada: error: parche fallido:
   ... error: ... el parche no se aplica.

-
Recibes esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/gitextensions/gitextensions/issues/684#issuecomment-401501721 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ADdhsSZcDBHHn25q6HhRfvdkTdM5pjbsks5uBsA3gaJpZM4AFHeS
.