Pourquoi avoir choisi de "hard-wrapper" le texte ?

[groue]

Cela provoque des "diff" plus longs que nécessaire, comme par exemple pour le fichier Livre III/Titre VIII/Article 1728.md dans dfd5918. On a un diff qui prend trois lignes quand seule l'expression "en bon père de famille" a été remplacée par "raisonnablement". Cela uniquement dû au hard-wrapping.

[steeve]

Ca ne l'etait pas au debut, et finalement c'etait plutot illisible, puisque diff fonctionne par ligne

[sgourichon]

La tradition dans de nombreux langages de balisages (texte brut bien tradi, mais même TeX, HTML, markdown, asciidoc, etc) est en effet d'aligner sur une largeur maximale et de considérer les sauts de ligne isolés comme non significatifs. Cette façon de stocker le texte n'est donc pas surprenante.

Après, l'effet "diff plus long que nécessaire" est réel, je l'ai remarqué aussi. Alors ?

Linus a déjà tranché des discussions de ce genre (e.g. faut-il tracker les rename, cf. http://permalink.gmane.org/gmane.comp.version-control.git/217 ) en disant qu'il ne faut pas se prendre la tête sur comment c'est stocké (plusieurs raisons, voir lien ci-dessus), de toute façon c'est au moment où on regarde (ici le programme qui fait le diff) qu'on doit paramétrer.

En d'autres termes : la solution serait plutôt dans le paramétrage du viewer de diff. Je sais qu'un fichier .gitattributes permet de régler des comportements de ce genre, peut-être pas ce point précis, et est-ce que le viewer github en tient compte ?

[groue]

Merci pour vos réponses. @sgourichon tente de prouver que "on s'en fiche", et @steeve ajoute "certains s'en fichent peut-être, mais pas nous : pour améliorer la lisibilité on a fait le choix du hard-break.". Bref, selon l'usage qui doit être fait de ces données, le hard-breaking sera embêtant, ou pas, et on ne le sait pas encore. L'usage mis en avant initialement a été la lecture par un humain. Dont acte. Merci pour ce travail, en tout cas !

[sgourichon]

@groue, je ne m'en fiche pas, je suis très sensible à l'argument du diff court. La possibilité d'un diff court est le signe que les données sont bien stockées. Ce repository a beau être une initiative hack d'une demi-journée, ce genre de considération est important à terme.

L'avis de Linus Torvalds, qui me semble sage et transposable ici, n'est pas que "on s'en fiche" mais plutôt "la solution n'est pas de modifier les données qu'on stocke, stockons simplement et ajustons la façon de les lire".

Exemple :

git diff dfd5918^..dfd5918
@@ -1,6 +1,6 @@
 Article 601
 ----
-Il donne caution de jouir en bon père de famille, s'il n'en est dispensé par
-l'acte constitutif de l'usufruit ; cependant les père et mère ayant l'usufruit
-légal du bien de leurs enfants, le vendeur ou le donateur, sous réserve
-d'usufruit, ne sont pas tenus de donner caution.
+Il donne caution de jouir raisonnablement, s'il n'en est dispensé par l'acte
+constitutif de l'usufruit ; cependant les père et mère ayant l'usufruit légal du
+bien de leurs enfants, le vendeur ou le donateur, sous réserve d'usufruit, ne
+sont pas tenus de donner caution.

$ git diff --word-diff dfd5918^..dfd5918
@@ -1,6 +1,6 @@
Article 601
----
Il donne caution de jouir [-en bon père de famille,-]{+raisonnablement,+} s'il n'en est dispensé par l'acte
constitutif de l'usufruit ; cependant les père et mère ayant l'usufruit légal du
bien de leurs enfants, le vendeur ou le donateur, sous réserve d'usufruit, ne
sont pas tenus de donner caution.

[groue]

Oui, oui, Stéphane. Simplement, cet argument ne permet pas de choisir un format de stockage. C'est à dire qu'à la question "faut-il changer de format ?" il répond "non". Cependant il est muet devant la question "quel format faut-il choisir ?". Il faut donc aller voir plus loin. Dans l'usage de ces données. Et l'usage favorisé initialement, ici, a été la lecture par un humain.

[steeve]

Oui clairement le but premier, c'est la consommation par des humains (le principale probleme, IMHO).

Apres, "unwrap" le texte n'est pas tres complique non plus, ou pourquoi pas modifier les sources du scraper, quand je les aurai postees

[groue]

"Unwrap" comme tu dis n'est pas si facile que ça. Sinon nos logiciels de mails n'auraient aucune difficulté à bien gérer les paragraphes à travers de multiples niveaux de citations de texte hard-wrappé utilisant le préfixe >. Or, s'ils y arrivent à peu près aujourd'hui, on peut dire que ça leur a pris des décennies pour le faire correctement.

Voir aussi les débats rageurs pour ou contre le hard-wrapping des commits git (un débat où Linus, bizarrement, n'est pas agnostique, cette fois-ci : https://github.com/torvalds/subsurface/blob/master/README#L87)

Bref : attaquer l'unwrapping de manière naïve, c'est la promesse de se planter à un moment ou un autre. Laisser à des outils automatiques le soin de unwrapper le contenu de ce repository, c'est leur donner un travail faussement facile. Personellement, j'aurais stocké le verbatim des textes sans hard-wrap. Comme ça il n'y aurait eu aucune ambiguité.

[qwertzguy]

J'allais creer une issue similaire. Je pense que pour le stockage, il ne faut pas wrapper le texte. Au moment de l'affichage github fait de base un bon boulot pour mettre en avant le word-diff des lignes modifiées. Mais si on veux aller plus loin et faire un viewer de diff pour ces repositories, avoir le texte non-wrapper et mettre en avant uniquement le word-diff serait bien plus simple que d'essayer d'ignorer les lignes du diff due uniquement a un re-wrappage des lignes.

En gros plutot que de cite Linus et co, faut plutot se poser la question de qu'est-ce que le end-user veux: il veux un diff qui montre ce qui a effectivement ete modifie (et non le re-wrappage par exemple). Si vous devriez faire un viewer qui fait ca, quel fassons de stocker serait la plus pratique et la plus sur pour coder ce viewer?
Pour moi, ca serait soit de stocker chaque paragraphe sur une ligne (puis le viewer ferait un word-diff, soit lui meme, soit avec git), soit de stocker chaque mot du paragraphe sur sa propre ligne, du coup le line diff devient un word-diff et le client n'a cas enlever les retours a la ligne pour rendre le paragraphe plus agreable a lire.

[frenchbeard]

@qwertzguy Je suis également de l'avis d'un stockage orienté end-user, mais c'est là que je diverge un peu : si l'on arrive à une majorité d'utilisateurs qui vont effectivement le lire via un viewer qui effectuerait un "unwrap", le stockage sans hard-wrap sera avantageux; cependant, je prends mon cas (ne sera sans doute pas la majorité, il est vrai), c'est-à-dire la lecture via le client git dans un terminal splitté (un peu plus de 80 colonnes disponibles) et là, en ne hard-wrappant pas, ça devient absolument affreux dès les 100 caractères.
C'est essentiellement à titre d'exemple d'utilisation où le hard-wrap a du sens, mais on arriverait rapidement au même type de problème si les gens ont l'habitude de travailler avec de multiples fenêtres réparties sur leur écran.

[qwertzguy]

@frenchbeard Dans un terminal wrapper un texte en pipant par less (ou équivalent) est trivial. Unwrapper par contre l'est beaucoup moins. Du coup même dans votre cas, le stockage non wrapper est plus intéressant. De plus, le viewer pourrait très bien avoir une version texte.

[frenchbeard]

@qwertzguy Je n'ai pas pu obtenir de wrap satisfaisant avec ce genre d'outils (justement) sur des textes trop longs, n'affichant jamais seulement la description du commit, mais toujours des infos supplémentaires. Si tu as un exemple de cli pour un wrap en fonction de la colonne de début de display de la description, je suis preneur, en attendant, en voulant afficher plus que juste la description, on aura un problème en ne "hard-wrappant" pas.
De plus, si certaines modifications sont apportées au repo telles que suggérées dans , notamment la création de branche pour chaque modification pour suivre son évolution (#20), l'affichage dans less n'aide pas plus sans hard-wrap (ou je ne le maîtrise pas assez pour y arriver, sans "casser" l'affichage).