Au fait, j'ai oublié de corriger pleinement la grosse connerie de ./19:

pour des raisons qui sont tout à fait valables.

Enfin tu le reconnais, il aura juste fallu 5 années!

Dommage qu'après tous les nags que tu m'as envoyés (publiquement et en privé) d'enfin merger tes contributions parce que "c'est facile", cet aveu est peu crédible.

Mon aveu est plus crédible que ton post, parce que ton post oublie "juste" les faits. Non, il n'a pas fallu 5 années pour que je reconnaisse que les contribs ne pouvaient pas être mergées telles quelles
Voir le topic de kdewin, où je l'ai de plus mentionné (tu as la mémoire courte et sélective, hmm ?): j'ai commencé à faire de quoi intégrer mes updates il y a plusieurs années, en commençant par des modifs à la doc pour faciliter l'intégration. Pas eu le temps de les finir, et puis j'ai utilisé à l'époque le seul langage que je connaissais, le C, qui est un mauvais choix. Les langages de script "P" (Perl, Python, PHP), ou encore Ruby et certainement d'autres, vont beaucoup mieux.
Si c'est pas une reconnaissance qu'il y avait de bonnes raisons de ne pas merger mes contributions, c'est quoi ?


Dans ./30:

Pourquoi veux-tu à ce point que les forkeurs prouvent qu'ils ne bluffent pas ??
Le fin du fin serait que tu fermes la maintenance de TIGCC (encore plus que ce qu'elle n'est actuellement, je veux dire) avant de nous laisser le temps de pousser, sous forme d'un changeset qui tient debout (donc pas un "commit early, release often" sur un SCM centralisé - notons que tu n'appliques d'ailleurs pas à toi-même au moins la deuxième partie de cette devise que tu viens de nous sortir), des modifs suffisamment visibles pour l'utilisateur par rapport à upstream. Des modifs, il y en a déjà, j'en ai cité une.
Modifs que tu pourrais pourtant, grâce à la GPL et au fait qu'on ne s'amuse pas à changer l'arborescence des fichiers ou faire ce genre de conneries (ben oui, c'est plus de boulot pour nous quand on merge upstream ), réintégrer dans upstream. Exactement comme on peut intégrer les tiennes tant que tu maintiens un repository, avec quelque SCM que ce soit (mais tu n'as manifestement pas envie d'utiliser mieux qu'un des pires SCM, qui ne maintient même pas l'intégrité de ses données...). Ce qu'on te demande, c'est juste de respecter notre façon de faire, dont nous ne sommes pas les seuls défenseurs.
Façon de faire qui changera probablement rapidement, de toute façon: la question n'est pas si on ouvrira l'infrastructure du fork, mais quand... La discussion de 'quand' a été lancée, parce qu'on décide ce genre de choses en groupe.

En cas d'arrêt des commits sur le CVS public de TIGCC, ce serait encore nous qui aurions le mauvais rôle, tu sais si bien y faire. Même si de notre côté, on pourrait expliquer, ce que je fais plus bas, pourquoi on travaille différemment. Sans cette super bouse de CVS, et comme le kernel Linux et Wine, qui sont, avec tout le respect que je te dois, des projets autrement plus complexes que TIGCC.
On sait très bien que tu es parfaitement capable d'arrêter de committer sur le CVS public de TIGCC. Voir l'antécédent d'avoir décidé avec Sebastian, par-derrière, de splitter le forum de TIGCC/TICT si je réagissais comme tu l'attendais, en me faisant remettre les pouvoirs d'admin par Thomas.

Git permet aussi la réécriture d'historique. Ca, c'est carrément bien pour modifier ses séries de patches tant qu'elles ne sont pas prêtes, plutôt que de committer du code pas bien fini et des bugfixes par dessus.

Ca s'appelle fausser l'Histoire.

C'est une façon de voir les choses, mais ce n'est pas la nôtre, ni celle du kernel Linux (sous forme de clones de repositories et branches), de Wine (sous forme de séries de patches) et d'autres projets. La réécriture d'historique permet de merger _toutes_ les révisions intermédiaires sur le trunk, et par là-même faciliter les bisections.
Avec SVN, que j'utilise au boulot, on fait:
* commits locaux avec réécriture d'historique au début;
* création d'une branch SVN, à laquelle j'applique les modifs locales;
* revue et éventuellement modification par quelqu'un d'autre, avec éventuellement des merges du trunk s'il est modifié entretemps;
* merge de toute la branch sur le trunk en une seule révision. Ca, c'est nul, parce que si jamais la branch introduit un problème subtil que tu ne détectes que longtemps après - c'est régulièrement le cas sur le kernel Linux, par exemple - tu ne pourras pas savoir laquelle des modifs individuelles de la branch a fait merder un cas qui fonctionnait auparavant. Si tu merges chacune des révisions, tu peux plus facilement savoir quel patch pose problème.

./19: encore une fois - comme je te l'ai d'ailleurs déjà reproché dans l'autre topic à propos d'un autre aspect touchant aux contributions - tu ne racontes que la partie de l'histoire qui t'arrange Je maintiens qu'il y a un subset des contributions qui est facile à intégrer.

Le subset en question a déjà été intégré il y a longtemps.

A vérifier

Je me souviens d'une peephole optimisation des pushes sur la pile - moins efficace que celle implémentée par Pollux dans GTC, d'ailleurs

Moins efficace comment? Exemples de code généré?

GTC est capable, sous certaines conditions d'alignement, de packer quatre move.b en move.l, ce dont est à ma connaissance incapable GCC.
!call Pollux
--- Call : Pollux appelé(e) sur ce topic ...


Si c'est pas simple de coder un peephole qui transforme
move.w #nn1,-(sp); move.w #nn2,-(sp)
en
move.l #(nn1<<16)|nn2,-(sp) | sur une plate-forme little endian, ça serait nn2 qui serait <<16
ce qui est possible parce que sur 68000, sp sera toujours aligné dans du code correct (= qui ne modifie pas exprès sp pour le rendre impair)
j'aurais tendance à voir ça comme une faiblesse du compilo. Surtout quand le compilo n'est autre que GCC, connu pour sa difficulté à comprendre, à modifier et son besoin de réarchitecturage: http://lwn.net/Articles/259157/

Quand tu l'as enfin fait, tu as codé avec de l'arithmétique sur des nombres signés (ce qui est pourtant une source connue d'embêtements), de telle sorte que le code généré dans ebook crashe une fonction de dialog/menu qui n'apprécie pas qu'on lui passe un argument négatif...

Oui, j'ai fait une erreur de programmation. Le codeur infaillible n'existe pas.

Je suis d'accord que le codeur infaillible n'existe pas
C'était une façon de faire remarquer qu'une nouvelle fois, tu n'appliques pas forcément à toi les mêmes critères que ceux que tu appliques aux autres, c'est tout.


[EDITs pour compléter et corriger une phrase écrite un peu vite qui n'avait pas de sens.]