Gitextensions: Dialogue de validation - Les lignes sélectionnées ne fonctionnent pas

bien pour l'opération habituelle de copier / coller la sélection de la ligne entière ne fonctionne pas ...

Mais je suis d'accord que l'algorithme devrait prendre en charge les fichiers nouvellement créés. Je ne sais pas comment le faire cependant ...

Eh bien, pensez-y doucement. Dans la situation de validation, il est très inhabituel de copier du texte à partir d'un diff. J'ai vu d'autres solutions, où toute la ligne est copiée, ce qui est bien. Je pense que la fonction de copie est une fonctionnalité intéressante dans ce cas. Je sais que vous utilisez la même vue, lorsque vous différez un fichier. Alors peut-être qu'une classe distincte (délégué?), Qui gère uniquement la fonctionnalité de document de validation ferait l'affaire ici.

Je ne comprends pas de quoi vous parlez. Le problème existe depuis longtemps et est très ennuyeux. Je ne le vis pas lors de la mise en place de lignes à partir de fichiers nouvellement créés, mais à partir de fichiers déjà suivis, mais simplement de fichiers modifiés. Triste, mais je n'ai toujours pas obtenu les étapes pour reproduire ((il apparaît de manière inattendue

Je n'ai eu aucun problème avec cette fonctionnalité depuis un bon moment maintenant. Une fois que vous êtes en mesure de le reproduire, veuillez nous le faire savoir, sinon un correctif est presque impossible ...

Eh bien, cela n'a certainement pas fonctionné dans la version 2.25, dans la version 2.26, cela semble fonctionner, mais il n'y avait pas de correctif officiel pour cela. J'avais un commit que je ne pouvais pas diviser à cause de ce comportement, donc je devais le commettre "tel quel". Ce dont je parle, c'est le comportement de gitx, qui est actuellement l'un des meilleurs ui. c'est intuitif et clair. Lorsque vous sélectionnez une ligne dans le diff pendant la validation, la ligne entière est sélectionnée et sur le côté droit apparaît exactement un bouton "ligne (s) d'étape" selon que vous avez sélectionné une ou plusieurs lignes. si vous cliquez dessus, les lignes sont mises en scène ou - vice versa sans mise en scène. aimerait voir quelque chose de similaire dans les gitextensions.

Pour l'instant: cela semble fonctionner si vous sélectionnez exactement les lignes entières que vous voulez (dé) mettre en scène et pas plus ou moins de caractère. Alors peut-être pourrons-nous clore le problème et rouvrir, lorsque plus de détails sur ce qui se passe seront clairs?

"Pour l'instant: cela semble fonctionner si vous sélectionnez exactement toutes les lignes que vous voulez (dé) mettre en scène et pas plus ou moins de caractère. Alors peut-être que nous pourrons fermer le problème et rouvrir, quand plus de détails sur ce qui se passe seront clairs?"

Je ne peux pas approuver cela. Hier encore, j'ai l'erreur et la sélection de lignes entières n'a pas aidé. Je me souviens que dans certaines anciennes versions, cela a parfois aidé, mais pas maintenant. (Probablement après la version qui a supprimé la possibilité de réinitialiser les lignes avant de les préparer).

Comme je l'ai dit plus tôt: si vous avez un cas que vous pouvez reproduire, veuillez enregistrer cet état afin que d'autres (ou vous) puissent essayer de résoudre le problème !! Sans un cas de test reproductible, cela ne peut jamais être corrigé!

Je ne sais pas si je ferais mieux d'ouvrir un nouveau numéro ou non, mais je vais commencer par commenter ici. J'ouvrirai volontiers un nouveau numéro si c'est mieux.

J'ai remarqué que j'obtiens l'erreur ci-dessus lorsque j'essaie de mettre en scène des lignes alors que "Afficher le fichier entier" est activé. Si je le désactive, cela fonctionne bien. Cela se produit régulièrement pour moi en ce moment. J'utilisais la version 2.26, mais je viens de passer à la version 2.28 et cela se produit toujours.

références # 636

J'ai eu ce même problème hier (sur le projet GitExtensions pas moins). Certaines lignes d'un fichier peuvent être préparées mais d'autres non. Je vais essayer de le reproduire ce soir.

Je reproduis cette erreur pour le fichier .sln en encodage UTF8 avec BOM. Le problème n'apparaît que lorsque l'encodage diff dans la zone de liste déroulante est UTF8. Lorsque je passe au codage par défaut, tout fonctionne correctement.

Je pense que le problème principal car la nomenclature change les numéros de ligne

Je viens d'observer un problème similaire dans Git Extensions v2.28. Avec un fichier créé à l'aide de fins de ligne Unix, ajouté à l'aide d'extensions Git, j'ai reçu des avertissements indiquant que les fins de ligne ne seraient pas modifiées dans mon espace de travail, mais seraient remplacées par des fins de ligne Windows si je retirais à nouveau les fichiers. Suite à cela, j'ai apporté deux modifications au fichier. Ensuite, la tentative de mettre en scène uniquement le deuxième morceau échoue, affirmant que le correctif est corrompu. La mise en scène du premier morceau semble fonctionner correctement. L'outil git en ligne de commande n'a aucun problème à mettre en scène juste le deuxième morceau, malgré les fins de ligne, donc cela semble être un bogue dans les extensions Git.

Supprimer le fichier et faire un "git checkout" pour obtenir une version avec les fins de ligne correctes, résout le problème - maintenant je peux utiliser les extensions Git pour mettre en scène le deuxième morceau du correctif de manière isolée sans causer d'erreurs.

Cependant, il y avait une erreur similaire de corruption de correctif lorsque j'ai tenté de désinstaller les deux morceaux, un par un - cela n'aimait pas quand il n'y avait plus de morceaux dans la zone de préparation.

Le problème semble provenir de l'encodage d'un fichier ou peut-être des fins de ligne comme mentionné ci-dessus. Cela m'est arrivé aujourd'hui dans le projet ac # contenant un commentaire avec des chaînes de caractères allemands (Latin1, windows-1251?) Et en une ligne, il a changé (quelle qu'en soit la raison) le codage du fichier. Le fichier a été reformaté par VS2010. À partir d'exactement cette ligne, chaque ligne suivante ne peut pas être mise en scène via GE (2.40, mais aussi dans les versions antérieures). La mise en scène dans core-git fonctionne très bien.

Je viens de passer à 2.40 de 2.31 et cette fonctionnalité semble maintenant complètement cassée. Je n'arrive pas à mettre en scène des lignes dans aucun fichier. J'ai essayé à la fois des fichiers C ++ encodés ANSI et des fichiers C # encodés UTF-8, qui fonctionnaient la plupart du temps en 2.31 (utilisés pour avoir des problèmes avec la dernière ligne du fichier).

"... le correctif a échoué ... le correctif ne s'applique pas ..."

+1

a670f1501103fbe0d214ab76811a33353cab87af corrigé un bug introduit dans la version 2.40

fd96875589f22851a691fa1f0f989816a77458aa corrige le problème de nomenclature

Merci beaucoup Janusz. J'ai reconstruit GitExtensions, remplacé les fichiers dans Program Files et cela fonctionne très bien.

J'ai remarqué que si un fichier a une ligne vide à la fin et que vous le supprimez, GitExtensions est incapable de mettre en place ce changement, mais c'était le défaut existant que j'ai mentionné dans mon commentaire précédent.

C'était une solution rapide. Quand je l'ai testé, j'ai trouvé un autre cas où l'étape ne fonctionne pas. J'essaierai de réécrire l'algorithme de manière plus simple.

Si quelqu'un reproduit ce bogue avec 2.41 ou version ultérieure, veuillez le rouvrir.

J'ai actuellement ce problème avec 2.43. Je ne peux pas "Mettre en scène les lignes sélectionnées" n'importe où dans un fichier si "Ignorer les changements d'espace blanc" est coché. (Malheureusement, lorsqu'il n'est pas coché, de nombreux fichiers que je dois valider ont toutes les lignes du fichier supprimées, puis chaque ligne est ajoutée à nouveau. Je ne sais pas pourquoi; cela pourrait être une chose entre tabulations et espaces, mais ce serait être particulier car l'un de ces fichiers est un .csproj que l'on n'édite normalement pas à la main et ne devrait donc pas être soumis à ce changement de paramètres.)

Cette fonctionnalité ne fonctionne pas avec les espaces ignorés. Cela ressemble plus à un problème EOL.

Cela m'est arrivé avec 2.48 dans le scénario suivant:
Tools->Settings->Git config->Line Endings: Not set
La définition des fins de ligne sur l'une des options a résolu le problème. On dirait que not set dans la vue effective est un problème de configuration et, à mon avis, devrait être affiché comme tel.

La variante spécifique de ceci, mais comme indiqué précédemment par grantbowering, se produit pour moi lorsque "Ignorer les changements d'espaces de début et de fin" ou "Ignorer toutes les modifications d'espaces" est activé avec GitExtensions 2.51.03, Windows 10 64 bits:

1. Modifiez un fichier.
2. Commandes> Valider
3. Passez la souris sur la fenêtre de comparaison de la boîte de dialogue de validation.
4. Dans la barre d'outils du haut qui apparaît, activez «Ignorer les modifications des espaces de début et de fin» et / ou «Ignorer toutes les modifications des espaces».
5. Cliquez sur une ligne modifiée dans le diff.
6. Appuyez sur la touche "S" pour mettre en scène la ligne sélectionnée: error: patch failed: ... error: ... patch does not apply .

Voir # 3493.

Le vendredi 29 juin 2018, 20h03 per1234 [email protected] a écrit:

La variante spécifique de ceci mais comme indiqué précédemment
https://github.com/gitextensions/gitextensions/issues/684#issuecomment-12332133 par
Grantbowering se produit pour moi lorsque "Ignorer les espaces de début et de fin
changes "ou" Ignorer toutes les modifications d'espaces "est activé avec GitExtensions
2.51.03, Windows 10 64 bits:

1. Modifiez un fichier.
2. Commandes> Valider
3. Passez la souris sur la fenêtre de comparaison de la boîte de dialogue de validation.
4. Dans la barre d'outils supérieure qui apparaît, activez "Ignorer les
   les changements d'espaces de fin "et / ou" Ignorer tous les changements d'espaces ".
5. Cliquez sur une ligne modifiée dans le diff.
6. Appuyez sur la touche "S" pour mettre en scène la ligne sélectionnée: erreur: échec du correctif:
   ... erreur: ... le correctif ne s'applique pas.

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/gitextensions/gitextensions/issues/684#issuecomment-401501721 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ADdhsSZcDBHHn25q6HhRfvdkTdM5pjbsks5uBsA3gaJpZM4AFHeS
.