Matthieu Moy a écrit 3251 commentaires

Le RPN, c'est un langage à pile.

Pour (1 + 2) * (3 - 4), tu fais

1 2 + 3 4 - *

et je vois pas comment tu pourrais faire sans séparateur (entrée ou espace, c'est pareil).

Bien plus de 10 ans. J'ai appris à l'utiliser sous word 5, vers 1990 je crois.

Et c'est du XML "tout-sur-une-ligne", donc un diff bête et méchant dessus ne fait pas grand chose d'intéressant.

http://www-verimag.imag.fr/~moy/opendocument/

(même texte que celui cité plus bas sur le Wiki de Mercurial)

En fait, à partir du moment où on a un truc un peu flexible, et qu'on connait odt2txt, c'est assez facile de générer des diffs sur ces fichiers.

Par contre, c'est un diff visuel, mais hors de question de l'appliquer avec patch. Plus généralement, je ne crois pas qu'il existe de bons outils de merge sur ce genre de fichiers.

http://www.kernel.org/pub/software/scm/git/docs/RelNotes-1.5(...)

Deprecation notices
-------------------

* From v1.6.0, git will by default install dashed form of commands
(e.g. "git-commit") outside of users' normal $PATH, and will install
only selected commands ("git" itself, and "gitk") in $PATH. This
implies:

- Using dashed forms of git commands (e.g. "git-commit") from the
command line has been informally deprecated since early 2006, but
now it officially is, and will be removed in the future. Use
dash-less forms (e.g. "git commit") instead.

- Using dashed forms from your scripts, without first prepending the
return value from "git --exec-path" to the scripts' PATH, has been
informally deprecated since early 2006, but now it officially is.

- Use of dashed forms with "PATH=$(git --exec-path):$PATH; export
PATH" early in your script is not deprecated with this change.

Users are strongly encouraged to adjust their habits and scripts now
to prepare for this change.


Les raisons pour ça, entre autres :

* Les git-bidule ne permettent pas les aliases. Par exemple, chez moi, « git st » fait « git status », mais pour que « git-st » le fasse aussi, Git ne peut pas.

* Les git-bidule ne permettent pas les options globales, genre « git --no-pager foo ».

A noter qu'Emacs est en train de migrer vers bzr.

http://thread.gmane.org/gmane.emacs.devel/90798/focus=91834

Et ça s'est un peu fighté sur les mailing-lists de Bazaar et Emacs à partir du moment où les gens ont comparé les performances de bzr avec celles de git (par exemple, "bzr log" met 1 minute avant de commencer à afficher le log sur une machine moderne).

Bon troll, c'est bientôt vendredi ;-).

Oui, ce qui une pas bête idée du tout.

Ceci dit, y'a pas de solution parfaite : avec SVK, si tu déplaces ta copie de travail, ça met aussi le bronx. Mais l'argument est que ça arrive moins souvent de déplacer sa copie de travail que de faire des conneries avec les .bidules/ à l'intérieur de la copie de travail.

Au passage, avec Git, on peut simuler un comportement à la SVK en positionnant $GIT_DIR. Mais évidemment, si on a plusieurs repositories, c'est affreusement pas pratique de devoir changer la variable d'environnement à chaque fois qu'on change de copie de travail. C'est plus un truc pour cas particuliers dans des scripts que vraiment adapté à une utilisation quotidienne.

C'est surtout qu'ils se sont (enfin) rendus compte que LUG voulait dire « Linux User Group », et que comme il-faut-dire-gnu-linuske-et-pas-linusque, il se sont tous renommés en GLUG.

Un détail : la syntaxe « git-clone » est dépréciée en faveur de « git clone » (avec un espace, pas un tiret).

Non, de toute évidence.

Il ne sait pas de quoi il parle, mais il adore venir troller sur les journaux qui en parlent.

Par exemple, un grep récursif qui ne touche pas aux données de git, ça se fait avec

grep toto -rn *

(enfin, sauf si on veut que grep regarde aussi dans des fichiers cachés dans le répertoire racine)

Avec subversion, le même va ignorer le .svn à la racine, mais pas les autres. Résultat, c'est beaucoup plus facile de foutre en l'air (là, j'ai pris grep, mais on peut faire pareil avec un « perl -pi -e ... » ...) une copie de travail svn qu'une copie de travail avec git. Par contre, les conséquences d'une corruption du .git/ sont en général plus désastreuses avec Git qu'avec SVN ...

Un volontaire pour nous faire un version robuste aux retours à la ligne dans les noms de fichiers ?

D'autant que pour l'écologie, les noix de lavage venant d'Inde, on a vu mieux ...

Rooh, l'effet linuxfr ... J'ai tappé « président écolier français » dans google pour sortir une source d'actualité qui permettrait d'expliquer, et bam, le premier lien pointe ici même :

http://www.google.com/search?q=pr%C3%A9sident+%C3%A9colier+f(...)

Bon, le deuxième lien devrait aider ...

Et ça existe depuis très longtemps. La nouveauté, c'est de pouvoir facilement faire un chroot.

Avec le sftp actuel, par défaut, on a accès à tout ce que peut faire l'utilisateur sur la machine distante (i.e. en général, lecture à peu près partout dans / et lecture-écriture dans $HOME). Pour un fournisseur d'accès, c'est pas très classe, il ne veut pas que l'utilisateur puisse voir en dehors de son $HOME, bref, que le / qu'il voit soit son $HOME physique.

Sinon, sftp, c'est pas du tout un truc « lourd », c'est juste un programme que le démon ssh peut lancer, et qui obéit à quelques requetes assez simples (lister un répertoire, uploader et télécharger un fichier, ...).

Contrairement au ftp classique, y'a pas de bidouille à rouvrir une nouvelle connexion pour telecharger un fichier ou quoi, tout passe dans le même tunnel, et donc beaucoup moins de soucis avec les firewalls et les NATs.

URL ?

Moi, sur https://rhn.redhat.com/rhn/sales/LoginInfo.do , ils me demandent de payer pour au moins un de leurs services pour y accéder.

Et la version download gratuite de la RHEL, elle est où ?

Rooh, le UUOC, j'ai honte ;-).

J'utilise git depuis environ 1 an, j'ai contribué très peu de code à Git, donc, je serais loin de me classer dans la catégorie « expert ». Mais moi, j'ai vraiment utilisé à la fois Git et SVN (j'ai aussi eu la joie de faire du support SVN auprès de 200 étudiants qui l'utilisaient à plein temps pendant un mois, c'est assez instructif). J'ai aussi fait l'effort d'apprendre à peu près correctement bzr et mercurial, et je connais assez bien GNU Arch (ayant contribué pas mal de code à la branche Bazaar et à Xtla, l'interface pour Emacs).

Rien d'impressionnant, mais je crois que quand je compare Git et SVN, je sais à peu près de quoi je parle.

Toi, tu te permet de critiquer Git, alors que de toute évidence, tu ne sais absoluement pas de quoi tu parles, tu ignores tout de cet outil. Je sais bien qu'on est Vendredi, mais si tu pouvais avoir des arguments pour troller, ça serait cool, ça élèverait le débat.

$ cat ~/.zsh-history | grep git | wc -l
206
$ cat ~/.zsh-history | grep svn | wc -l
139
$ cat ~/.zsh-history | grep cd | wc -l
298
$ cat ~/.zsh-history | grep ls | wc -l
228

Bah, fais un truc :

alias ls='sleep .5; ls'
alias cd='sleep .5; cd'

Bosses avec ça une journée, et tu comprendras ce que je ressent quand j'utilise SVN tout en connaissant Git.

Sinon, j'ai toujours pas compris le rapport entre les perfs, le fait de bosser seul, ou le checkout de Gentoo.

Allez, fais-nous rire : tu as utilisé Git combien de temps dans ta vie pour le comparer à SVN ?

> Avec subversion il suffit d'un "svn cp" (tu as toujours la traçabilité de l'historique).

Et pour le merge, tu fais comment avec SVN ?

> > - puissante visualisation d'historique
>
> Pareil.

Non, t'as jamais vu gitk ou n'importe quel équivalent pour dire ça. Premier truc : avec SVN, tu ne vois que l'historique des branches, jamais l'historique des merge. Il manque un truc capital pour comprendre l'historique. SVN voit un arbre, Git voit un DAG.

Après, essayes de voir l'historique de deux fichiers ensembles avec SVN.

> > - performance
>
> Si t'es tout seul à l'utiliser... (c'est l'hypothèse de Hank Lords).

Lapin compris. Git est incroyablement plus rapide que SVN, que tu l'utilise tout seul ou pas, c'est un fait.

Bon, je te propose un truc : si tu veux faire un comparatif Git Vs SVN, utilise un peu les deux. Là, tu parles de manière affirmative d'un truc que tu connais à peine, c'est dommage.

> Si tu es tout seul, un "DSCM" est sans intérêt.
[...]
> Je connais mal git et mercurial.

Peut-être que ceci explique cela. Pour avoir pas mal utilisé git et subversion, franchement, tout seul ou pas, y'a pas photo, git est très loin devant. Rien que pour les perfs, avoir un repository facile 2 fois plus petit en espace disque, et à peu près toutes les opérations courrantes pour lesquelles l'outil répond instantanément, c'est déjà un plus considérable. Après, je pourrais parler des vrais avantages de Git sur Subversion, mais bon ...

http://www.academie-francaise.fr/langue/questions.html#plein

L'académie française te donne raison !

> En attendant, Debian sort régulièrement des version correctives de Debian Stable (4.0, 4.0r1, 4.0r2, ...).

C'est très différent quand même. Les mises à jour de Debian, c'est soit pour les paquets volatiles, soit pour des trous de sécurité. Les service-pack de Windows, y'a des vrais nouveaux trucs, des changements de comportements, ...