On ne présente plus git, le gestionnaire de versions écrit au départ par Linus Torvalds pour remplacer BitKeeper pour le développement du noyau Linux.
Comme l'année dernière, les développeurs lancent un sondage pour améliorer git avec le feedback des utilisateurs.
Si vous utilisez git, et si vous voulez bien consacrer quelques minutes à ce questionnaire, c'est par là que ça se passe (avant le 10 septembre):
http://www.survey.net.nz/survey.php?94e135ff41e871a1ea5bcda3(...)
Journal Sondage pour utilisateurs de git
19
août
2007
# C'est fait :)
Posté par Frédéric-Emmanuel Picca . Évalué à 3.
C'est vraiment agréable de pouvoir travailler lorsque l'on est pas connecté à internet. en gros le distribuée, c'est très bien.
[^] # Re: C'est fait :)
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: C'est fait :)
Posté par Frédéric-Emmanuel Picca . Évalué à 1.
L'utilisation s'est beaucoup améliorée ces derniers temps, avec l'ajout de git-gui, une interface graphique qui permet de mieux appréhender l'histoire du "stage" et de préparer ses commits.
Mais une fois que l'on a compris cette histoire et bien on se trouve à utiliser 5 commandes à tout casser.
git init (1 fois au début) ou git clone
git add
git rm
git pull
git commit
et de temps à autre
git reset
[^] # Re: C'est fait :)
Posté par Matthieu Moy (site web personnel) . Évalué à 4.
http://www.kernel.org/pub/software/scm/git/docs/user-manual.(...)
et beaucoup de pages de man.
C'est encore loin d'être parfait, et globalement, on sent que git a été fait par des très bons codeurs, mais bien moins bons pour l'interface utilisateur et la doc (il y a des tas de cas où git montre à l'utilisateur des trucs qui devraient être des détails d'implémentation). Mais ça s'améliore vraiment.
[^] # Re: C'est fait :)
Posté par Bonnefille Guilhem (site web personnel) . Évalué à 2.
Personnellement, je regrette la disparition de cogito. Aujourd'hui, Git offre (bien) plus d'une centaine de sous-commande, mélangeant les commandes quotidiennes, des commandes occasionnelles ou dédiée à une façon de faire (git-bissect par exemple), des commandes de niveau implémentation ("plumbing" comme ils disent).
Perso, je ne me sert plus que de git-gui, car sinon je sais jamais quelle (série de) commande effectuer pour faire des tâches quasi rudimentaire.
Espérons qu'il finiront par trouver une solution à ce problème de "mélange".
# git et mercurial
Posté par Adrien . Évalué à 2.
Il semble de mercurial possède une très bonne doc, est porté sous windows et possède quasiment les même caractéristique de git.
Quels sont les avantages, à part la rapidité, de git par rapport à mercurial ? Peut-on les utiliser ensemble dans un même projet sans grosse perte de performance ?
[^] # Re: git et mercurial
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
A l'époque, il me semble que Linus ou un autre avait tenter de passer le code sous mercurial, mais le temps de convertion entre 2 repository aurait pris quelques années !
"La première sécurité est la liberté"
[^] # Re: git et mercurial
Posté par ribwund . Évalué à 6.
Pour la lenteur tu dois confondre avec darcs ou monotone.
La grosse différence est dans le fait que mercurial conserve l'information de descendance au niveau des fichiers, alors que git ne le fait que au niveau du changelog.
Il est donc au contraire plus facile de trouver un ancêtre commun pour 2 révisions d'un même fichiers (dans tous les cas l'ancêtre commun se trouve de façon linéaire).
Egalement git ne stocke pas les informations de renommage ou de copie, mais il utilise une heuristique pour les detecter après coup, alors que mercurial les stocke.
Finalement le format de hg a été conçu avec comme idée de minimiser le nombre de seek (mettre a jour la copie de travail à n'importe quel revision se fait en O(total des tailles de fichiers), un commit se fait en O(1) seeks), le stockage était dès le début efficace (il a fallu attendre les packs pour que git ne prenne pas une place énorme).
Malgré le fait que hg soit écrit en python (avec le noyau en C), il n'a pas à rougir de git au niveau de la vitesse, certaines opérations sont plus longues avec git, d'autres avec hg.
sinon je ne sais pas de quel conversion tu parles, mais le kernel a un repo hg: http://www.kernel.org/hg/linux-2.6/
quelques liens:
Mercurial: http://www.selenic.com/mercurial/wiki/
l'excellent livre de Brian O'Sullivan: http://hgbook.red-bean.com/
(c'est pas encore la version finale, le livre est sous licence libre)
Site proposant un hébergement pour mercurial : http://sharesource.org/
[^] # Re: git et mercurial
Posté par Matthieu Moy (site web personnel) . Évalué à 7.
Niveau perfs, git et mercurial se valent à peu près. git est un peu plus rapide une fois que le cache est "chaud", alors que Mercurial prends en compte les accès disque, donc, est un peu plus rapide pour le premier accès à des fichiers.
L'import du noyau Linux dans Mercurial, ça n'aurait pas pris quelques années, c'est fait, et maintenu en synchro : http://www.kernel.org/hg/linux-2.6/
Finalement, Mercurial et Git sont assez proches. Comme différences, je dirais :
* Gestion des renomages : Mercurial enregistre les renomages au moment du commit (copy + delete), git les detecte après coup.
* Git est écrit en C, concu pour être scriptable en shell facilement, Mercurial est écrit en Python, conçu pour être extensible via des plugins
* hg est conçu pour être simple (au niveau de l'interface utilisateur, mais aussi un code source petit : 32000 lignes de python), git est conçu pour être puissant et flexible. Si c'est simple, tant mieux, mais ça n'est pas prioritaire.
* "hg commit" prends le contenu des fichiers au moment où on fait le commit. "git commit" prends le contenu des fichiers au moment où on a fait un "git add" pour la dernière fois. C'est très puissant, par exemple pour faire des commits partiels, mais assez déroutant au début (c'est le fameux "index").
* Git a un format de stoquage remarquablement compact (un facteur 10 par rapport à Subversion sur certains projets, par exemple, le repository Linux fait 174Mo avec git, et 463 avec hg), mais il n'est pas utilisé par défaut. Il faut lancer "git gc" de temps en temps pour recompresser le repository.
* "git blame" a quelque chose qu'à ma connaissance personne d'autre ne fait : il detecte les déplacements de code à l'intérieur et à l'extérieur du fichier. Donc, il est capable de dire que telle ligne du fichier toto.c à été au départ commité dans le fichier titi.c à telle ou telle date, ...
Mais :
* Les deux sont très rapides
* Les deux utilisent des checksums pour identifier les révisions (hérités de monotone)
* Les deux fonctionnent avec un repository par arbre de travail, et des push/pull/merge (hérités de BitKeeper paraît-il)
* Les deux ont un moyen de gérer des files de patchs (mq et stgit, mais je connais pas bien)
* Les deux ont une commande pour réappliquer une branche sur un autre (rebase et transplant)
...
Bref, il y a des différences entre les deux, mais c'est difficile de dire si l'un est meilleur que l'autre. Je crois que c'est surtout une question de goût. Perso, je n'ai pas encore fait mon choix définitif.
[^] # Re: git et mercurial
Posté par ced . Évalué à 1.
C'est le genre de détail qui me fait vraiment préférer git. D'autant plus que pour faire un commit à la façon d'hg, on tape simplement "git commit -a".
En gros pour faire simple c'est simple, et pour faire complexe c'est pas plus complexe que nécessaire. (mode delarue<) Puissance, maîtrise, efficacité, productivité.
[^] # Re: git et mercurial
Posté par ribwund . Évalué à 2.
par exemple que se passe t'il si on fait:
on modifie a # a est deja tracked
git commit
[^] # Re: git et mercurial
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
Exemple bête : tu veux faire un commit selectif sur les fichiers A.txt, B.txt, mais pas les autres :
$ git add A.txt
$ git add B.txt
$ git commit -m "commit selectif machinbidule"
Dans ce cas, tu aurais pu faire la même chose avec
$ git commit -m "..." A.txt B.txt
mais c'est assez pratique aussi de pouvoir prendre ton temps pendant que tu sélectionne les fichiers que tu veux. Par exemple, juste avant de commiter, tu peux faire « git diff » pour voir ce que tu as dans ton arbre de travail mais pas dans l'index, et « git diff --cached » pour voir ce que tu vas vraiment commiter. Avec des outils comme « git add --interactive » ou « git gui », tu peux même faire un commit selectif au niveau des portions de patch.
Avec la plupart des gestionnaires de versions, tu as des interfaces graphiques pour faire des commits selectifs. Tu sélectionne un certain nombre de fichiers, et tu as un bouton « commit » quelque part. Tu peux voir l'index comme ce système de selection de fichiers, mais c'est stoqué sur le disque, donc persistant entre deux appels.
Ceci dit, les commit selectifs, il faut s'en méfier. Ça veut dire que ce que tu commites n'a probablement jamais existé en temps que tel sur le disque, donc que ça n'a jamais vraiment été testé. Mais même pour des commits non-selectifs, ça peut être pratique. Par exemple, tu as un paquet de changement dans ton arbre de travail, et tu veux vérifier que tu n'as pas fait de conneries. « git diff » te montre ce qu'il te reste à vérifier, et en faisant « git add », tu valides le changement. A ce moment, tu ne fais commit que quand « git diff » ne dit plus rien (« git status » te donne la même info sous une autre forme).
C'est assez pénible au départ, mais on s'y fait, et après quelques semaines d'utilisation, c'est le système des autres outils que je trouve bizare ;-).
[^] # Re: git et mercurial
Posté par ribwund . Évalué à 2.
hg qnew new_cset.diff
modifie a;
hg qref a
...
quand on est satisfait:
hg qdel -r tip # commit definitivement
# bazaar
Posté par wilk . Évalué à 1.
En particulier, quelque chose que je trouve pratique c'est qu'il permet toute sortes d'organisations, y compris de travailler en centralisé, voir de mixer décentralisé/centralisé.
http://bazaar-vcs.org/Tutorials/CentralizedWorkflow
[^] # Re: bazaar
Posté par ribwund . Évalué à 2.
[^] # Re: bazaar
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
Avec bzr, tu peux faire quelque chose comme :
$ bzr checkout bzr+ssh://je-sais.pas/ou rep
$ cd rep
hack hack hack
$ bzr commit -m foo
Le commit se fait sur la branche distante, de manière atomique. C'est à dire que soit ta branche est à jour, et le commit se fait, soit tu n'es pas à jour, et on te demande de faire un update.
Avec les autres que je connais, tu peux faire presque ça, en vérifiant avant que tu es à jour, mais il y a toujours une fenêtre de temps pendant laquelle quelqu'un d'autre peut faire un commit. Bref, avec bzr, tu peux, si tu veux, t'assurer que tu n'auras jamais un historique non-linéaire.
Mais la grosse différence, c'est surtout la simplicité de l'interface utilisateur. En une commande, tu dis que « update » doit aller chercher à une URL, et que « commit » doit mettre tes changements au même endroit, ... (et en bonnus, les utilisateurs de CVS/SVN n'ont pas besoin de changer tout de suite leur modèle de pensée).
[^] # Re: bazaar
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
Mais en fait, perso, ce qui me donne envie de quitter bzr, c'est surtout que je n'ai aucune confiance en Canonical pour la maintenance future du logiciel. Ils m'ont déjà fait perdre des dizaines d'heures en me laissant bosser sur Bazaar 1 avant de fouttre mon boulot à la poubelle, maintenant, ils ré-écrivent l'histoire en laissant plus ou moins entendre que le mot Bazaar a toujours désigné bzr, et que l'ancien s'appelait Baz [http://bazaar-vcs.org/Branding]. Maintenant, ils jouent aux marqueteux avec les numéros de versions (passage de 0.18 à 0.90, parce que 0.19, ça faisait pas assez bien). Les gros projets (Mozilla, Linux, OpenSolaris, X.org, ...) migrent petit à petit vers des solutions décentralisées, et pour l'instant, bzr n'a pas réussi à en convaincre un vraiment important. Bref, git et Mercurial me paraissent plus sûrs niveau pérénité.
Pour travailler en centralisé avec git, ce que je fais, c'est que je met un « git push » dans le hook « post-commit ». C'est pas tout à fait équivalent, mais ça ressemble à ce que fait « bzr bind ».
[^] # Re: bazaar
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
[^] # Re: bazaar
Posté par wilk . Évalué à 1.
hg avec ces 32000 lignes de python capables de gérer le kernel est pour ce coup assez bluffant.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.