Reprise du message précédent :

Much >https://www.justinobeirne.com/google-maps-moat

Nop, j'utilisais pas mal la vue aérienne, elle a disparu au profit de ce truc, donc ça m'a marqué. Après 18, 24, 36 mois, j'sais pas
 
XaT

 
ElMuch, prescripteur de nouveauté depuis 1982.

 
Grillaid j'allais poster la meme chose

Pareil mais avec le lien qui marche dans le post : https://www.justinobeirne.com/google-maps-moat

Yo,

Question nginx, je cherche à rediriger de maniètre transparente:

- staging.quxx.foo.com sur staging.quxx.foo.com/quxx
- staging.buz.foo.com sur staging.buz.foo.com/buz

Le tout avec un proxy_pass.
Je trouve souvent l'inverse. Une idée de comment faire?

Apparament le type avait le même besoin que toi : https://serverfault.com/questions/8 [...] ied-server
Et il s'est répondu.
Autre : https://stackoverflow.com/questions [...] edirection d'une autre manière

J'avais un truc du genre, mais je pense que django me redirige pour x raisons.
 
http://staging.foo.example.com/lol fonctionne (une url qui matche rien dans le router)
 
http://staging.foo.example.com/customers me redirige vers http://staging.foo.example.com/foo (une url qui existe)

Ecrire le git hook sous Windows pour convertir automatiquement les fichiers du projet en UTF-8, c'est une grosse saveur quand même.

Stratégie de l'échec :
- filtrer sur un certain nombre d'extensions qui sont safe (.java, .xml, .txt., .md, .properties, ...)
- utiliser file --mime-encoding et regarder ce qui sort
- si c'est us-ascii ou utf-8, je fais rien
- si c'est iso-8859-1, je fais la conversion à partir de ce charset
- si c'est unknown-8bit c'est probablement du cp1252, je fais la conversion à partir de ce charset
 
ET JE CROISE LES DOIGTS

 
Comment tu fais pour détecter l'encodage d'origine? Et si tu peux le faire, pourquoi ne pas convertir tous les fichiers?

putain, je viens d'apprendre qu'une ex venait de chopper un cancer... monde de merde

Pourquoi tu fais pas juste de l'alerting et que les devs fassent les conversions eux-mêmes ?

@alt: tu pourrais probablement le faire sans `file`: tu essaies de parser en UTF-8, si ça passe pas tu regardes s'il y a des C1 dans le fichier, si non -> 8859-1 si oui -> Windows-1252.

Et tu peux pas le faire pour tous les fichiers parce-que iso-8859-1 et windows-1252 "comprennent" n'importe quel octet, donc ils ont aucun problème à "décoder" un fichier jpeg ou zip en un gros tas de merde.

 
Merci. Oui , spour ça que je disais "si on peut déterminer l'encodage d'origine", sous-entendu "si c'est du binaire on pourra par là même les exclure."

On peut le déterminer mais pas avec certitude, et potentiellement même pas pour discriminer de fichiers textuels ou binaires, d'où pré-filtrage sur des types dont on sait qu'ils sont textuels.

Cf https://github.com/chardet/chardet pour une lib de déterminations d'encodages.

 
Parce que ça ne demande aucune réflexion, que c'est chiant et que c'est donc une bonne cible d'automatisation.
Les devs de l'équipe on va leur demander beaucoup de choses, si on peut en rendre certaines transparentes ça sera parfait.
 

 
Oui, c'est le but.
Je sais d'avance que sur mon projet je n'ai pas vraiment d'encodage exotique. Je vais avoir de l'UTF-8, du cp1252 et de l'iso-8859-1.
Je cherche à détecter les deux derniers.
 
1) Le fichier ne contient aucun caractère > 127, il est détecté en us-ascii et comme c'est un subset d'UTF-8, je ne touche à rien
2) Sinon, si file renvoie iso-8859-1 c'est du iso-8859-1, je convertis
3) Sinon, si file renvoie unknown-8bit, c'est du cp1252, je convertis
 
Sur les tests que j'ai faits, ça fonctionne pas trop mal.

Le hook fait le boulot, par la modification d'encoding n'est pas commit par git. Pourtant après modification du fichier, je refais un git add dessus.
Je pédale un peu dans la semoule là.

edit: tain je crois que je vais devoir faire un post-commit hook qui fait un commit --amend

Attends en fait il y a un truc que j'avais raté: pourquoi tu fais un commit hook qui fait la conversion au lieu de faire la conversion & ajouter un commit hook qui impose l'UTF-8? Ça veut dire qu'au lieu de fixer leur environnement une fois pour toute t'as tes pouilleux qui vont continuer à balancer de la merde et potentiellement corrompre ton UTF-8 tout propre en l'interprétant en iso-8859-1 donnant un tas de mojibake qui va être converti en UTF-8 qui va ensuite être ré-ré-interprété en ISO-8859-1 ad vitam eternam. Et comme ça n'arrivera que pour le non-ascii, ça risque fort de pas être détecté et tu vas te retrouver avec "Ã\x83¢Ã\x82Â\x80Ã\x82¦" dans un commentaire ou un docstring parce-que quelqu'un aura un jour ajouté "…" dedans.

& ton truc c'est plus un job pour un filtre qu'un hook.

Les gens vont corriger leur environnement, c'est la première étape.
La deuxième était la modification de contenu au fil de l'eau.
Mais ouais, y'a un risque non-négligeable.

Je ne connaissait pas les content filters de git, effectivement ça a l'air d'être l'outil adapté. Par contre le plan c'est quoi, convertir en UTF-8 avec le clean filter ?
Ça foutra pas la grouille avec les diffs ?
 

Il y a des gens qui utilisent un lave vaisselle "pro" (à paniers) au lieu de trucs "consommateurs"?

Ouais et rien faire pour les smudge.

IDK, ptet.

Pourquoi tu fournis pas plutôt une config éditeur / IDE clean ?

 
L'absence de conversion automatique fait que ça n'est pas satisfaisant. Oui je vais demander à tous les devs de configurer leurs IDE pour que l'encodage par défaut soit l'utf-8.
Mais ça ne change pas l'existant.
Pour l'existant j'ai 3 options.
 
- Essayer de faire un git-filter-branch pour réécrire tout le repo en UTF-8. Mais ça veut dire réécrire l'intégralité de l'historique et je ne suis pas assez calé pour en appréhender toutes les conséquences. Je préfère éviter.
 
- Faire une conversion en une fois, par script, partout. Mais ça va copieusement polluer l'historique.
 
- Faire une conversion automatique au fil de l'eau. Ça me semble moins raide, mais je bloque sur le moyen technique.
 
Par contre, je ne fournis pas de conf IDE standardisée complète, c'est trop de boulot (on a IntelliJ + Eclipse). Je fournis juste une conf pour le formatage de code.

Bof, peu de lignes seront affectées par le commit. Quand tu vas blamer ça se verra quasi pas.

Pour le reformatage, tu préconiserais quoi ? Au fil de l'eau ou en masse ?
Parce que j'ai fait le même raisonnement.

En bonus c'est facilement checkable, tu fais une passe pour regarder la quantité de fichiers pas UTF-8, si t'en as pas des masses tu fix (potentiellement au cas par cas) et tu commit.

Si t'en as une tétrachiée regarder à faire ça au fil de l'eau à la place (et franchement même là je mettrais un validateur pré-commit qui fait rien et c'est le type qui édite qui se démerde), mais si t'as genre 5% de fichiers incorrectement encodés (dans lesquels t'auras généralement pas des masses de changements) tu fix et basta.

L'impact est beaucoup plus gros et il n'y a pas de potentiel problème technique, donc là le faire au fur et à mesure a plus de sens, mais l'inverse me choquerait pas non plus.

Ma préco, du one shot sur l'existant avec revue précise des modifs. En ayant fait un tour sur les config des uns et des autres.
Quitte à mettre un job de vérif pendant un temps qui vérifie qu'il n'y a pas des encoding pourris qui arrivent, avec des gages à la clé
Je suis contre le fait de modifier des fichiers de façon "silencieuse"

Il y a quelques années, j'hallucinais de voir les gens qui avaient des dizaines et des dizaines de tabs ouverts dans leur navigateur.
 
Je suis devenu ces gens

J'ai régulièrement 150 onglets, sans les extensions de gestion des tabs ça serait impossible

XaT

Plus au moins la même chose.

Pour l'UTF-8 tu fais ça d'un coup puis tu introduis une vérification qui fait foirer ton intégration continue quand des cochonneries sont détectées.

Le formatage, selon les outils tu peux le restreindre aux lignes modifiées par le commit, sinon de nouveau ton intégration continue vérifie que les fichiers modifiés sont formatés correctement et voilà, ça viendra graduellement.

T'emmerdes pas avec des git hooks, t'as aucun moyen de t'assurer que ça sera utilisé.

J'ai aucune idée de comment je vais vérifier ça sur mon intégration continue par contre.

md5sum de tes fichiers avant modif puis après modif et comparaison  
Ou alors si t'es sur une working copy git, t'appliques le fix, et tu regardes s'il t'annonce un diff

 
Pareil... sauf que mon utilisation se résume à :
 
- J'ai 30 onglets ouverts
- C'est chiant
- Je "stocke" tout via une extension
- Je recommence à zéro
- J'ai 30 onglets ouverts
- C'est chiant
- ...
 
Et au final je me suis rendu compte que je n'ai jamais rouvert une seule fois une session stockée

Pour Alt,

Niveau encodage j'ai pas demande au devs de changer, j'ai mis l'encodage dans le pom. Normalement ca paramètre l'IDE en conséquence.

Pour formatage et reencodage, a chaque fois j'ai fait un big bang avec un tag juste avant.

C'est pas la panacée, mais bon.

T'ajoutes une task qui passe sur les fichiers whitelistés, vérifies qu'ils sont décodables en utf8 et échoue dans le cas inverse? Ça me semble pas ultra compliqué… tant que le pipe CI est configurable. Mais c'est comme ajouter un linter.

 
Avec le recul, des problèmes ?

Pas vraiment.

Le tag a permis  de construire une Iso-debut de notre boulot, sur laquelle on peut reproduire les bugs pour les qualifier (existant depuis 10ans ou introduit par nous), et un diff entre le code d'avant et le code reformaté permet assez facilement de vérifier que la stack trace de prod et celle de notre versions sont cohérentes.

Côte encodage, il y a toujours un con de quebecquois pour forcer l'encodage de son IDE, ou un junior zele qui décide que UTF-8 c'est tellement mieux que iso-8859-1 et qui essaie de tout transformer mais ca dure pas et c'est l'occasion d'avoir des chocolatines

 
IL A RAISON /FOU/ /FOU/
 

 
AAAAHHHHHHHHHHHHHHHHHHHHH /FOU/ /FOU/ /FOU/