(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.
* 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 ».
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).
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.
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 ...
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 :
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.
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.
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 ...
> 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, ...
> Si tu lui dis de se fermer (de redémarrer ultérieurement) elle reviendra 10min plus tard
Oh, scandale ! Alors que ma Debian, elle me dit juste une fois "tu reboote, ou je ne réponds plus de rien", et après, si ça marche plus, c'est ma faute.
> Et pour ma part (pas sous debian) j'ai aucune boite de dialogue me demandant de rebooter mon ordi...
Bah t'as pas du faire souvent de mise à jour. Et tu connais comment la difference entre le message de Debian te demandant de rebooter et celui de Windows, si t'as jamais eu celui de Debian ?
[^] # Re: plugins ODT ?
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Mercurial 1.0. Évalué à 2.
[^] # Re: plugins ODT ?
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Mercurial 1.0. Évalué à 3.
(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.
[^] # Re: Multiple repositories
Posté par Matthieu Moy (site web personnel) . En réponse au journal Pourquoi Git m'importe ?. Évalué à 4.
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 ».
# Emacs et bzr
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Nouvelle version de Bazaar, le DVCS de Canonical. Évalué à 5.
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 ;-).
[^] # Re: git > bzr
Posté par Matthieu Moy (site web personnel) . En réponse au journal Pourquoi Git m'importe ?. Évalué à 2.
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.
[^] # Re: Réponses
Posté par Matthieu Moy (site web personnel) . En réponse au journal Vers la fin des LUGs ?. Évalué à 6.
[^] # Re: Multiple repositories
Posté par Matthieu Moy (site web personnel) . En réponse au journal Pourquoi Git m'importe ?. Évalué à 1.
[^] # Re: Re:
Posté par Matthieu Moy (site web personnel) . En réponse au journal Pourquoi Git m'importe ?. Évalué à 4.
Il ne sait pas de quoi il parle, mais il adore venir troller sur les journaux qui en parlent.
[^] # Re: git > bzr
Posté par Matthieu Moy (site web personnel) . En réponse au journal Pourquoi Git m'importe ?. Évalué à 3.
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 ...
[^] # Re: Un article juste ?
Posté par Matthieu Moy (site web personnel) . En réponse au journal C'est la guerre. Évalué à 3.
[^] # Re: Quelles pistes de réflection
Posté par Matthieu Moy (site web personnel) . En réponse au journal [HS] Et vous, comment avez vous construit votre maison ?. Évalué à 2.
[^] # Re: Quelqu'un peut m'expliquer la blague ?
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Le président français propose aux écoliers d'adopter un projet libre mort sur SourceForge. Évalué à 10.
http://www.google.com/search?q=pr%C3%A9sident+%C3%A9colier+f(...)
Bon, le deuxième lien devrait aider ...
[^] # Re: Remplacer ? Pas tout à fait
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Un pas de plus vers la démocratisation du sftp. Évalué à 5.
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.
[^] # Re: Et une connerie de plus
Posté par Matthieu Moy (site web personnel) . En réponse au journal Microsoft pire qu'ubuntu dans ses updates. Évalué à 3.
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.
[^] # Re: Et une connerie de plus
Posté par Matthieu Moy (site web personnel) . En réponse au journal Microsoft pire qu'ubuntu dans ses updates. Évalué à 2.
[^] # Re: Re:
Posté par Matthieu Moy (site web personnel) . En réponse au journal Git ou Mercurial ?. Évalué à 3.
[^] # Re: Re:
Posté par Matthieu Moy (site web personnel) . En réponse au journal Git ou Mercurial ?. Évalué à 6.
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.
[^] # Re: Re:
Posté par Matthieu Moy (site web personnel) . En réponse au journal Git ou Mercurial ?. Évalué à 3.
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
[^] # Re: Re:
Posté par Matthieu Moy (site web personnel) . En réponse au journal Git ou Mercurial ?. Évalué à 1.
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 ?
[^] # Re: Re:
Posté par Matthieu Moy (site web personnel) . En réponse au journal Git ou Mercurial ?. Évalué à 3.
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.
[^] # Re: Re:
Posté par Matthieu Moy (site web personnel) . En réponse au journal Git ou Mercurial ?. Évalué à 4.
[...]
> 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 ...
[^] # Re: Quelques questions comme ça
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Élections locales 2008 : participez à la nouvelle campagne Candidats.fr. Évalué à 2.
L'académie française te donne raison !
[^] # Re: Autre source
Posté par Matthieu Moy (site web personnel) . En réponse au journal morceaux choisis. Évalué à 4.
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, ...
[^] # Re: .Re: vista est vraiment un os formidable
Posté par Matthieu Moy (site web personnel) . En réponse au journal morceaux choisis. Évalué à 2.
[^] # Re: mouaich
Posté par Matthieu Moy (site web personnel) . En réponse au journal Rigolons : accélérer Vista. Évalué à 1.
Oh, scandale ! Alors que ma Debian, elle me dit juste une fois "tu reboote, ou je ne réponds plus de rien", et après, si ça marche plus, c'est ma faute.
> Et pour ma part (pas sous debian) j'ai aucune boite de dialogue me demandant de rebooter mon ordi...
Bah t'as pas du faire souvent de mise à jour. Et tu connais comment la difference entre le message de Debian te demandant de rebooter et celui de Windows, si t'as jamais eu celui de Debian ?