Pas de couleurs maintenant non plus, ça n'a pas changé sur ce point il me semble (perso, ça ne me gêne pas trop dans ce cas).
C'est à dire que pour faire des diff avant un commit, je trouve ça bien pratique la couleur, sachant que je passe le plus clair de mon temps dans mon terminal.
donc « bloat » c'est vraiment pas le mot que j'emploierais pour ce logiciel.
J'ai utilisé celui-la parce que je ne voyais pas quel autre mot utiliser.
Ceci dit, s'il faut comparer les binaires, soyons complets:
J'avoue être surpris la.
Bon, les tailles de binaires:
fossil:
libsqlite3.so.0: 802Ko
libssl.so.1.0.0: 384Ko
libcrypto.so.1.0.0: 2Mo
libreadline.so.6.3: 291Ko
libdl-2.19.so: 19Ko
libtinfo.so.5.9: 168Ko
fossil: 1.3Mo
total: 4.925Mo (en considérant les Ko comme Kio, c'est à dire en les divisant par 1024).
git:
libpcre.so.3.13.1: 438Ko
libresolv-2.19.so: 83Ko
librt-2.19.so: 32Ko
git: 1.7Mo
total: 2.24Mo (idem, Ko=>Kio).
Vainqueur: git. Du simple au double, quand même, bien que je n'aie pas intégré les lib communes (la flemme).
Je suis le premier surpris, je ne m'attendais pas a ça, et il ne faut pas oublier qu'on est en train de comparer des torchons et des serviettes.
Pire, c'est de l'édition de liens dynamique, si ça se trouve la moitié du code dans les lib chargées par fossil n'est pas utilisé. Il faudrait des binaire liés en statique, pour en avoir vraiment le cœur net.
La seule chose que tout ça prouve, c'est que comparer la taille du binaire exécutable et d'une seule lib est super partiel. Et que les dépendances des paquets Debian sont foireuses, parce que dans aptitude j'ai pas vu la moitié de ces libs pour fossil...
PS: libgit.a, c'est pour les outils qui utilisent git, git lui-même ne s'en sert pas. Édition de liens statique, d'ailleurs, si je me trompe pas.
[^] # Re: Fossil
Posté par freem . En réponse au journal Le danger github. Évalué à 0.
C'est à dire que pour faire des diff avant un commit, je trouve ça bien pratique la couleur, sachant que je passe le plus clair de mon temps dans mon terminal.
J'ai utilisé celui-la parce que je ne voyais pas quel autre mot utiliser.
Ceci dit, s'il faut comparer les binaires, soyons complets:
Sur une Debian stable:
Le binaire fossil importe (
ldd $(which fossil) | cut -f1 -d' '):Celui de git:
J'avoue être surpris la.
Bon, les tailles de binaires:
fossil:
total: 4.925Mo (en considérant les Ko comme Kio, c'est à dire en les divisant par 1024).
git:
total: 2.24Mo (idem, Ko=>Kio).
Vainqueur: git. Du simple au double, quand même, bien que je n'aie pas intégré les lib communes (la flemme).
Je suis le premier surpris, je ne m'attendais pas a ça, et il ne faut pas oublier qu'on est en train de comparer des torchons et des serviettes.
Pire, c'est de l'édition de liens dynamique, si ça se trouve la moitié du code dans les lib chargées par fossil n'est pas utilisé. Il faudrait des binaire liés en statique, pour en avoir vraiment le cœur net.
La seule chose que tout ça prouve, c'est que comparer la taille du binaire exécutable et d'une seule lib est super partiel. Et que les dépendances des paquets Debian sont foireuses, parce que dans aptitude j'ai pas vu la moitié de ces libs pour fossil...
PS: libgit.a, c'est pour les outils qui utilisent git, git lui-même ne s'en sert pas. Édition de liens statique, d'ailleurs, si je me trompe pas.