La liste des options proposées est volontairement limitée : tout l’intérêt (ou son absence) de ce type de sondage réside dans le fait de forcer les participants à faire un choix.
Les réponses multiples sont interdites pour les mêmes raisons.
Il est donc inutile de se plaindre au sujet du faible nombre de réponses proposées ou de l’impossibilité de choisir plusieurs réponses.
76,78 % des personnes sondées estiment que ces sondages sont ineptes.
Sais-tu que Git peut servir de client subversion, et donc faire des updates et des commits entre un dépôt local Git vers un dépôt distant Subversion ? Du coup ça permet les branches locales, d'avoir la totalité du dépôt en local, bref, du décentralisé quoi.
Et sinon, c'est quoi « l'expansion de mots-clefs » dans Subversion ?
Non, c'est le fait de mettre des clé/tag dans un fichier source que SVN va remplacer par une données au moment où on lui demande (date, nom du fichier, revision ou même une propriété que l'on set).
Perso, je suis contre les keywords, c'est plutôt ingérable à la fin même si ça facilite la vie pour identifier des livraisons.
Les keywords ne cadrent pas du tout avec la manière de faire sous git. Par compte, rien n'empèche d'écrire un script qui injecte des numéros de version lors du processus de création d'une archive.
La proposition de sondage est plus ancienne que la dépêche sur Darcs, et de plus, on est limités à 9 réponses possibles. Il manque une option "autres" qui aurait pu servir, c'est vrai ...
Pour un usage local, il est simple et efficace, et, à ma connaissance, irremplaçable.
Il n'y a pas que les projets logiciels qui ont besoin de conserver un historique des évolutions, il y a aussi:
- Les écrits au long cours (cours, mémoires, thèses).
- Les petits scripts qui évoluent tout le temps.
- Certains fichiers de configuration.
- Son carnet d'adresse
- ...
Pour ma part, RCS me sert surtout dans le premier cas. Il est un compagnon essentiel des processeurs de textes tels Tex et Roff.
> On ne pourrait avoir une case avec un commentaire pour dire pourquoi on plusse ou moinse ?
non, mais par contre en général lorsqu'on demande de moinser un message le contraire peut se produire.
La réciproque est fausse aussi. Il faudrait comparer qui est le plus vite à -10 entre un message qui demande de se faire moinsser et un message qui demande de se faire plusser (mais juste ça hein).
admettons que svn est en tête pour des raisons historiques (sinon pourquoi ?)
Bazaar se fait laminer par presque tout le monde (nan mais sérieux, quelqu'un l'utilise par plaisir celui-là ?)
Mercurial par contre est totalement à la ramasse par rapport à git
Pourquoi ?
- git c'est fun ?
- git c'est roots ?
- git il fait le café ?
- mercurial est à la traine ?
- mercurial n'est pas pratique ?
- mercurial est trop proche de svn ?
(cette belle indentation de question me rappel un de mes anciens chefs qui réorganisait constamment son code pour avoir au maximum sous cette forme, la ligne suivante toujours plus longue que la précédente...)
Bon, il est vrai que je tape souvent sur mercurial. Mais je viens de comprendre un truc (enfin) et j'en profite pour le partager avec vous tous : dans mercurial une branche n'existe que par la présence d'un commit. En gros la branche est une metadata du commit.
Donc si dans git il est possible de créer par exemple 3 branches locales dans lesquelles travailler plus tard (histoire de préparer son taff quoi), dans mercurial tant qu'on a pas de commit, la branche n'existe pas. Donc si on crée (ou croit créer...) 3 branches, lorsqu'on va vouloir switcher de l'une vers l'autre on va avoir un zoli message nous disant que ça ne fonctionne pas, que la branche est inexistante. ☿ hg branch feature1
marked working directory as branch feature1
☿ hg up default
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
☿ hg up feature1
abandon : unknown revision 'feature1' !
Ceci explique que lorsqu'on tente d'utiliser hg comme git (y compris avec bookmarks, localbranch, tasks, etc) ça ne marche jamais...
Finalement, hg et mercurial, s'ils sont équivalents, n'ont pas du tout la même façon de bosser.
Dans git, on va créer des branches locales nommées, souvent, et parfois à l'avance (histoire d'organiser).
Dans mercurial on va coder et, si besoin, on va brancher là où on le souhaite, mais au dernier moment je pense.
Et d'ailleurs, le fonctionnement de base de mercurial fait qu'on ne va pas la nommer, juste utiliser la révision initiale (ou alors utiliser bookmarks, qui permet "simplement" de nommer une révision en fait)
Bon, dans les deux cas on arrive au même résultat. Mais je pense que si on vient de git et qu'on tente d'utiliser hg de la sorte, on est très vite déçu par hg. Par contre, en comprenant un peu plus comment ça marche, ben c'est intéressant comme manière de travailler. Le point noir par contre c'est que ça force à connaître un peu plus comment fonctionnent les branches, les commits dans mercurial.
Voilou, c'était juste pour dire que je commençais enfin à comprendre comment mercurial fonctionne (et peut-être même qu'un jour j'arrêterai de troller dessus...)
ben disons que mon prompt ressemble plutôt à ça dans un dépot hg : ... at ... in ~/tmp/dev_hg/repo on default at tip
☿
La même chose pour git : ... at ... in ~/tmp/dev/repo on master
±
Et en bout de prompt j'ai la charge de ma batterie ▸▸▸▸▸▸▸▸▸▸▸▸
hum... j'ai l'impression que git était déjà plus connu que mercurial bien avant que kde ou gnome l'utilisent.
Il est évident que l'effet Torvalds / Linux joue un grand rôle.
Mais le libre est également connu pour jeter un outil pour prendre l'outil d'à côté qui serait plus intéressant.
Et concernant l'effet de masse, même si c'est pas forcément identique, côté mercurial il y a par exemple openjdk, netbeans, mozilla. En outre, une intégration plus poussée dans certains ide (ou depuis plus longtemps) et une plus grande portabilité.
Donc sans parler du coeur de ces deux systèmes, mercurial est à mon avis plus intéressant.
Donc la raison de git > mercurial (en pdm...) ne serait pas réellement plutôt du au design de mercurial moins apprécié que celui de git ?
Le nombre de développeur c'est une chose, mais comme indiqué j'ai l'impression que ça date d'avant que gnome ou kde passent à git. Et c'est ce point là qui est à mon avis intéressant
À mon avis, c'est l'effet de masse, Linux, KDE, Gnome, Fedora sont (ou seront) sous git, du coup, tu te dit que ça doit valoir la peine.
C'est exactement ça.
Au début j'étais pro-mercurial, mais pour des raisons politiques, j'ai changé pour git, et depuis je le trouve mieux.
Je sais qu'à l'époque, je reprochais à git de ne pas permettre comme dans mercurial d'avoir deux têtes dans une seule branche. Mais j'ai compris que git faisait différamment:
git:
- on rapatrie les commits distants qu'on stocke dans une branche distante
- on merge la branche distsante avec la branche locale du même nom
mercurial:
- on rapatrie les commits distants qui s'ajoutent au dépôt. Pour les branches qui on divergé, elles se retrouvent avec deux têtes.
- on merge ces deux commits de tête pour se retrouver dans un cas classique où les branches ne divergent plus.
Si on ne connaît pas bien git, on peut lui reprocher que le "detached HEAD" ne soit pas aussi biebn géré que le "dual head" sous mercurial. Dans mercurial, si je commite à un autre endroit que HEAD, ce commit sera enregistré comme faisant partie de la branche du commit parent alors qu'avec git, on peut perdre le commit et le voir un jour disparaître par garbage collector.
Quand bien même ce soit l'effet de masse, savoir que des projets sommes toutes énormes tels que GNOME ou KDE ont dégagé leurs anciens outils pour migrer vers Git est quand même une belle preuve de maturité et d'efficacité de ce dernier.
On sait que le libre fonctionne au mérite : on prend le meilleur outil, pas celui avec lequel on a un accord.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
Oui, mercurial et git se ressemblent. Mais la structure de git est très différente (tu regardes ton .git, ça n'a rien à voir), et il est en général plus rapide.
Git est aussi très efficace pour compresser les deltas (cf. git gc, git repack), et tout est bon à prendre quand on sait qu'on doit tout récupérer quand on fait un clone.
Autre truc qui m'énerve avec mercurial, c'est qu'on n'a aucun indicateur de progression quand on clone depuis le web. Alors, au bout de cinq minutes à poireauter, on se demande quand même s'il va y en avoir pour longtemps.
En revanche, git sur Windows, c'est plutôt la galère, et les Windowsiens apprécient par exemple TortoiseHG. D'ailleurs, ne dépendre que de python, et tout avoir dans un seul exécutable (contrairement aux dizaines et dizaines de binaires et/ou scripts shells pour git) rend le portage vers d'autres plateformes plus aisé.
Git, je pense que c'est typiquement un de ces outils codé par des gens qui n'en ont juste rien à talquer des windowsiens, pas par méchanceté, juste parce qu'ils s'en moquent, ce n'est pas leur problème. Mais qui sont prêts à accepter les efforts de gens qui ne s'en moquent pas pour faire le travail de portage.
C'est effectivement très facile de faire un programme qui ne marche pas sous Windows, je pense que la plupart de ce que j'ai écrit a peu de chances de tourner dessus. C'est pas volontaire, sinon j'aurai aussi tenté d'être incompatible avec Mac OS ;-).
Quand j'ai regardé (il y a déjà un bout de temps) ce n'était pas si simple avec GIT. Et ce genre de truc est bien pratique si tu veux accéder à ton dépot derrière un proxy/firewall.
Typiquement on donne accès à un dépôt Git en lecture par HTTP pour faciliter l'accès public aux sources, par contre pour modifier on passe généralement par SSH.
C'est pas faire compliqueé pour faire compliqué, c'est silmplement parce que certains proxies n'acceptent pas de faire passer le SSH (j'ai l'impression de me répéter).
> Git est aussi très efficace pour compresser les deltas (cf. git gc, git repack)
Pour les opérations réseaux comme clone, pull, push etc ..., le protocole wire de mercurial est sensiblement plus efficace que le protocole git ou même HTTP utilisé par Git.
De plus, les opérations d'optimisation du stockage sont automatisées dans mercurial (donc plus "newbie-proof"), certes, Git reste un poil plus efficace à ce niveau.
> Autre truc qui m'énerve avec mercurial, c'est qu'on n'a aucun indicateur de progression quand on clone depuis le web
Tu as l'extension standard progress pour ça, suffit de l'activer.
Mine de rien, les gens semblent utiliser git à cause/grâce à github. Beaucoup de projets sont disponible sur cette plate forme, ce qui lui donne une très grande visibilité.
J'utilise personnellement mercurial, parce que je le trouve plus simple à configurer/étendre que git, et que les extensions existantes me permettent de faire ce que je souhaites facilement.
J'utilise mercurial depuis 2 ans et je n'ai jamais fait de branche... je fais un clone du repository duquel je veux faire une branche et je l'utilise comme si c'était une branche. Au final on peut voir le un repo comme une branche et la gestions des différentes branches est à mon humble avis plus simple de cette façon.
Besoin de retrouver son code source à un moment donné ? IPoT est votre ami. Fonctionne également avec les sites Internet, les conversations IRC, les mails... bref, tout ce qui peut passer sur IP, y compris ce qui n'avait pas été prévu pour à la base.
Oui, on prononce « guite », c'est en tout cas comme ça que son créateur, Linus Torvalds, le prononce.
La preuve par l'image, dès la première minute (mais les 69 autres sont aussi riches d'enseignements): http://www.youtube.com/watch?v=4XpnKHJAok8
(Google Tech Talk: Linus Torvalds on git)
En Irlande, ils disent guit. Et ne comprennent pas quand tu dis jite, car dans ce dernier cas, ils comprendront Just Int Time. Et tout les anglophones que j'ai croisé prononcent ainsi.
• Mercurial sous Windows, au boulot, une bonne centaine de repos, à chaque fois quelques milliers de fichiers . Interface graphique sympa, pas de souci de performance (sauf peut-être dans la mise à jour des icônes dans l'explorateur, et dans le lancement de l'utilitaire de configuration), ligne de commande agréable. Pas de souci pour un travail en équipes d'une dizaine de personnes, au fur et à mesure qu'elles gagnent en expérience elles apprécient de plus en plus l'outil.
La capacité d'aller lire et modifier le code source pour déboguer un problème de configuration serveur a été un gros plus. (Mercurial étant dans ce cas installé au sein d'une installation Python standard, et non pas avec un Python intégré.)
• Git sous Linux, chez moi (et quelques essais sous Windows), une demi-douzaine de repos, à chaque fois quelques dizaines / centaines de fichiers. Interfaces graphiques qui s'améliorent (pas essayées récemment), pas de souci de performance (mais bon, en solo avec quelques commits... c'est pas vraiment un challenge).
Le format de stockage des données, les concepts derrière Git, me semblent nettement plus propres, agréables, et intuitifs que ceux de Mercurial.
Par contre, la ligne de commande de Git est nettement plus hardcore, avec des listes d'options qui calment, jusqu'à ce qu'on prenne ses marques.
* mercurial: plus facile d'accès, moins intimidant, on peut tout de suite commencer. On sent vraiment le côté user-friendly voulu par les auteurs. De la très bonne documentation, entre le wiki, le hgbook [http://hgbook.red-bean.com], et des tutoriels du type [http://hginit.com]
* git: souvent présenté de façon plus technique, plus touffue. Beaucoup de commandes, les man pages peuvent sembler un peu plus repoussantes vu le nombre de switches. Il faut apprendre à faire le tri et se concentrer sur l'essentiel. On peut avoir sans entrer dans les détails une bonne vue d'ensemble via [http://progit.org/book]
C'est peut être subjectif, mais en tout cas j'ai trouvé que pour pouvoir se servir de git, il est rapidement très utile de se donner la peine de comprendre le data-model sous-jacent (commit, tree, blobs etc...). Pour les fonctionalités relatives à la manipulation de l'historique ou aux merges avancés, c'est carrément indispensable. Franchement, le data-model semble particulièrement élégant/séduisant, et paradoxalement assez simple.
Une fois qu'on a dépassé l'étape de la découverte, on se rend vite compte que les deux scms répondront assez facilement à la plupart des besoins.
Ensuite, d'un point de vue pragmatique, l'énorme avantage de hg est que vues ses dépendances (python + je crois un peu de C), il est utilisable sur tous les os, il peut être facilement intégré dans des IDEs. On peut trouver des GUIs pratiques etc...
C'est exactement là ou git pêche un peu: par exemple, même si des efforts ont été faits ou sont en cours pour rapatrier certaines fonctionalités dans des libs, on a droit à du perl, du shell script etc... De plus, git a été développé pour linux, msysgit (le portage officiel sous windows) n'est pas aussi performant mais reste utilisable.. Les GUIs sont plus rares et semblent moins abouties.
Bref, git semble plus puissant que hg pour les fonctionnalités avancées (grâce à son data model sous-jacent avec plus de potentiel) mais il est d'un abord pas facile (doc, déploiement sur des os différents etc..). Au contraire, hg semble avoir moins de potentiel d'un point de vue purement technique, par contre l'utilisateur est choyé (déploiement aisé, doc, outils etc...)
C'est peut être subjectif, mais en tout cas j'ai trouvé que pour pouvoir se servir de git, il est rapidement très utile de se donner la peine de comprendre le data-model sous-jacent
J'ai lu en bouquin sur git, l'auteur avait justement choisi (et justifié son choix) de commencer par le "data model" de git et ça m'a rendu beaucoup plus efficace.
J'ai utilisé Mercurial et Git, d'abord Mercurial pour ses commandes beaucoup plus intuitives (surtout quand on a utilisé Subversion avant) mais git une fois maîtrisé est juste beaucoup plus puissant.
Le passage à git dans mon boulot a d'ailleurs arrêté la pratique des GUI/intégration à un IDE et depuis les fichiers commités par erreur sont beaucoup plus rares (pourtant il y a effectivement des GUI, que je n'ai testé que pour leur affichage de l'historique).
# Proposition
Posté par Florent Zara (site web personnel, Mastodon) . Évalué à 5.
[^] # Re: Proposition
Posté par Benjamin (site web personnel) . Évalué à 2.
étant dans de nombreux projets et ce débat venant souvent sur la table, cela donne des informations intéressantes !
donc votez ! :)
# git et/ou subversion
Posté par eric gerbier (site web personnel) . Évalué à 1.
- subversion pour mes projets sur sourceforge
- git pour mes petits développement locaux.
Je lui reproche essentiellement une chose : de ne pas gérer l'expansion de mots-clefs
[^] # Re: git et/ou subversion
Posté par zerkman (site web personnel) . Évalué à 4.
Et sinon, c'est quoi « l'expansion de mots-clefs » dans Subversion ?
[^] # Re: git et/ou subversion
Posté par Aldoo . Évalué à 1.
Mais dans ce cas il ne s'agit pas réellement d'une fonction de Subversion mais d'un addon pour bash (ou pour zsh ou autre).
[^] # Re: git et/ou subversion
Posté par dadou92 . Évalué à 3.
Perso, je suis contre les keywords, c'est plutôt ingérable à la fin même si ça facilite la vie pour identifier des livraisons.
[^] # Re: git et/ou subversion
Posté par Guillaume Knispel . Évalué à 1.
# cpold
Posté par CrEv (site web personnel) . Évalué à 10.
http://roland.entierement.nu/blog/2008/01/22/cpold-la-poudre(...)
[^] # Re: cpold
Posté par barmic . Évalué à 1.
mon propre système (lp, tar/diff/patch, etc.) :
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: cpold
Posté par Dabowl_75 . Évalué à 2.
# sccs
Posté par Pierre Jarillon (site web personnel) . Évalué à 2.
[^] # Re: sccs
Posté par zerkman (site web personnel) . Évalué à 1.
[^] # Re: sccs
Posté par Rémi Hérilier . Évalué à 1.
Dire que je m'en sers au taf... certes il fait bien ce qu'on lui demande mais comment dire...
/me retourne utiliser git pour se sentir au XXIe siècle.
# [x] Darcs
Posté par MsieurHappy . Évalué à 9.
[^] # Re: [x] Darcs
Posté par zerkman (site web personnel) . Évalué à 3.
[^] # Re: [x] Darcs
Posté par ZankFrappa . Évalué à 2.
[X] J'utilise darcs.
[^] # Re: [x] Darcs
Posté par Rémi Birot-Delrue . Évalué à 1.
[^] # Re: [x] Darcs
Posté par MrLapinot (site web personnel) . Évalué à 1.
[^] # ==> Moment jeu de mot pourri <==
Posté par zebra3 . Évalué à 2.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: ==> Moment jeu de mot pourri <==
Posté par CoinKoin . Évalué à 2.
# [x] RCS
Posté par Sygne (site web personnel) . Évalué à 2.
Il n'y a pas que les projets logiciels qui ont besoin de conserver un historique des évolutions, il y a aussi:
- Les écrits au long cours (cours, mémoires, thèses).
- Les petits scripts qui évoluent tout le temps.
- Certains fichiers de configuration.
- Son carnet d'adresse
- ...
Pour ma part, RCS me sert surtout dans le premier cas. Il est un compagnon essentiel des processeurs de textes tels Tex et Roff.
[^] # Re: [x] RCS
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 7.
[^] # Re: [x] RCS
Posté par bat13 . Évalué à 0.
[^] # Re: [x] RCS
Posté par bat13 . Évalué à 1.
On ne pourrait avoir une case avec un commentaire pour dire pourquoi on plusse ou moinse ?
[^] # Re: [x] RCS
Posté par CrEv (site web personnel) . Évalué à -4.
non, mais par contre en général lorsqu'on demande de moinser un message le contraire peut se produire.
note : vous pouvez moinser se message
[^] # Re: [x] RCS
Posté par totof2000 . Évalué à 6.
Voilà, c'est fait. A ton service ... :)
[^] # Re: [x] RCS
Posté par yellowiscool . Évalué à 3.
Envoyé depuis mon lapin.
# hg
Posté par CrEv (site web personnel) . Évalué à 5.
Bazaar se fait laminer par presque tout le monde (nan mais sérieux, quelqu'un l'utilise par plaisir celui-là ?)
Mercurial par contre est totalement à la ramasse par rapport à git
Pourquoi ?
- git c'est fun ?
- git c'est roots ?
- git il fait le café ?
- mercurial est à la traine ?
- mercurial n'est pas pratique ?
- mercurial est trop proche de svn ?
(cette belle indentation de question me rappel un de mes anciens chefs qui réorganisait constamment son code pour avoir au maximum sous cette forme, la ligne suivante toujours plus longue que la précédente...)
Bon, il est vrai que je tape souvent sur mercurial. Mais je viens de comprendre un truc (enfin) et j'en profite pour le partager avec vous tous : dans mercurial une branche n'existe que par la présence d'un commit. En gros la branche est une metadata du commit.
Donc si dans git il est possible de créer par exemple 3 branches locales dans lesquelles travailler plus tard (histoire de préparer son taff quoi), dans mercurial tant qu'on a pas de commit, la branche n'existe pas. Donc si on crée (ou croit créer...) 3 branches, lorsqu'on va vouloir switcher de l'une vers l'autre on va avoir un zoli message nous disant que ça ne fonctionne pas, que la branche est inexistante.
☿ hg branch feature1marked working directory as branch feature1
☿ hg up default
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
☿ hg up feature1
abandon : unknown revision 'feature1' !
Ceci explique que lorsqu'on tente d'utiliser hg comme git (y compris avec bookmarks, localbranch, tasks, etc) ça ne marche jamais...
Finalement, hg et mercurial, s'ils sont équivalents, n'ont pas du tout la même façon de bosser.
Dans git, on va créer des branches locales nommées, souvent, et parfois à l'avance (histoire d'organiser).
Dans mercurial on va coder et, si besoin, on va brancher là où on le souhaite, mais au dernier moment je pense.
Et d'ailleurs, le fonctionnement de base de mercurial fait qu'on ne va pas la nommer, juste utiliser la révision initiale (ou alors utiliser bookmarks, qui permet "simplement" de nommer une révision en fait)
Bon, dans les deux cas on arrive au même résultat. Mais je pense que si on vient de git et qu'on tente d'utiliser hg de la sorte, on est très vite déçu par hg. Par contre, en comprenant un peu plus comment ça marche, ben c'est intéressant comme manière de travailler. Le point noir par contre c'est que ça force à connaître un peu plus comment fonctionnent les branches, les commits dans mercurial.
Voilou, c'était juste pour dire que je commençais enfin à comprendre comment mercurial fonctionne (et peut-être même qu'un jour j'arrêterai de troller dessus...)
[^] # Re: hg
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
[^] # Re: hg
Posté par CrEv (site web personnel) . Évalué à 4.
... at ... in ~/tmp/dev_hg/repo on default at tip☿
La même chose pour git :
... at ... in ~/tmp/dev/repo on master±
Et en bout de prompt j'ai la charge de ma batterie
▸▸▸▸▸▸▸▸▸▸▸▸[http://stevelosh.com/blog/2010/02/my-extravagant-zsh-prompt/]
[^] # Re: hg
Posté par zebra3 . Évalué à 2.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: hg
Posté par claudex . Évalué à 3.
À mon avis, c'est l'effet de masse, Linux, KDE, Gnome, Fedora sont (ou seront) sous git, du coup, tu te dit que ça doit valoir la peine.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: hg
Posté par CrEv (site web personnel) . Évalué à 3.
Il est évident que l'effet Torvalds / Linux joue un grand rôle.
Mais le libre est également connu pour jeter un outil pour prendre l'outil d'à côté qui serait plus intéressant.
Et concernant l'effet de masse, même si c'est pas forcément identique, côté mercurial il y a par exemple openjdk, netbeans, mozilla. En outre, une intégration plus poussée dans certains ide (ou depuis plus longtemps) et une plus grande portabilité.
Donc sans parler du coeur de ces deux systèmes, mercurial est à mon avis plus intéressant.
Donc la raison de git > mercurial (en pdm...) ne serait pas réellement plutôt du au design de mercurial moins apprécié que celui de git ?
[^] # Re: hg
Posté par claudex . Évalué à 2.
Des développements qui attirent beaucoup moins de contributeurs que ceux que j'ai cité,
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: hg
Posté par CrEv (site web personnel) . Évalué à 2.
Le nombre de développeur c'est une chose, mais comme indiqué j'ai l'impression que ça date d'avant que gnome ou kde passent à git. Et c'est ce point là qui est à mon avis intéressant
[^] # Re: hg
Posté par Mildred (site web personnel) . Évalué à 2.
C'est exactement ça.
Au début j'étais pro-mercurial, mais pour des raisons politiques, j'ai changé pour git, et depuis je le trouve mieux.
Je sais qu'à l'époque, je reprochais à git de ne pas permettre comme dans mercurial d'avoir deux têtes dans une seule branche. Mais j'ai compris que git faisait différamment:
git:
- on rapatrie les commits distants qu'on stocke dans une branche distante
- on merge la branche distsante avec la branche locale du même nom
mercurial:
- on rapatrie les commits distants qui s'ajoutent au dépôt. Pour les branches qui on divergé, elles se retrouvent avec deux têtes.
- on merge ces deux commits de tête pour se retrouver dans un cas classique où les branches ne divergent plus.
Si on ne connaît pas bien git, on peut lui reprocher que le "detached HEAD" ne soit pas aussi biebn géré que le "dual head" sous mercurial. Dans mercurial, si je commite à un autre endroit que HEAD, ce commit sera enregistré comme faisant partie de la branche du commit parent alors qu'avec git, on peut perdre le commit et le voir un jour disparaître par garbage collector.
[^] # Re: hg
Posté par zebra3 . Évalué à 3.
On sait que le libre fonctionne au mérite : on prend le meilleur outil, pas celui avec lequel on a un accord.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: hg
Posté par Artefact2 (site web personnel) . Évalué à 4.
Git est aussi très efficace pour compresser les deltas (cf. git gc, git repack), et tout est bon à prendre quand on sait qu'on doit tout récupérer quand on fait un clone.
Autre truc qui m'énerve avec mercurial, c'est qu'on n'a aucun indicateur de progression quand on clone depuis le web. Alors, au bout de cinq minutes à poireauter, on se demande quand même s'il va y en avoir pour longtemps.
En revanche, git sur Windows, c'est plutôt la galère, et les Windowsiens apprécient par exemple TortoiseHG. D'ailleurs, ne dépendre que de python, et tout avoir dans un seul exécutable (contrairement aux dizaines et dizaines de binaires et/ou scripts shells pour git) rend le portage vers d'autres plateformes plus aisé.
J'ai sans doute oublié des tas de choses…
[^] # Re: hg
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 7.
[^] # Re: hg
Posté par DLFP est mort . Évalué à 4.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: hg
Posté par zebra3 . Évalué à 2.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: hg
Posté par totof2000 . Évalué à 2.
[^] # Re: hg
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
[^] # Re: hg
Posté par totof2000 . Évalué à 2.
[^] # Re: hg
Posté par zerkman (site web personnel) . Évalué à 2.
[^] # Re: hg
Posté par totof2000 . Évalué à 2.
[^] # Re: hg
Posté par zerkman (site web personnel) . Évalué à 2.
[^] # Re: hg
Posté par totof2000 . Évalué à 2.
[^] # Re: hg
Posté par DLFP est mort . Évalué à 2.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: hg
Posté par Matthieu Moy (site web personnel) . Évalué à 1.
[^] # Re: hg
Posté par gnumdk (site web personnel) . Évalué à 2.
[^] # Re: hg
Posté par barmic . Évalué à 3.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: hg
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 3.
[^] # Re: hg
Posté par GeneralZod . Évalué à 3.
Pour les opérations réseaux comme clone, pull, push etc ..., le protocole wire de mercurial est sensiblement plus efficace que le protocole git ou même HTTP utilisé par Git.
De plus, les opérations d'optimisation du stockage sont automatisées dans mercurial (donc plus "newbie-proof"), certes, Git reste un poil plus efficace à ce niveau.
> Autre truc qui m'énerve avec mercurial, c'est qu'on n'a aucun indicateur de progression quand on clone depuis le web
Tu as l'extension standard progress pour ça, suffit de l'activer.
[^] # Re: hg
Posté par Alexis Metaireau (site web personnel) . Évalué à 3.
Concernant git versus mercurial, il y à un très bon article de steve losh à ce sujet: http://stevelosh.com/blog/2010/01/the-real-difference-betwee(...)
J'utilise personnellement mercurial, parce que je le trouve plus simple à configurer/étendre que git, et que les extensions existantes me permettent de faire ce que je souhaites facilement.
[^] # Re: hg
Posté par dowst . Évalué à 1.
[^] # Re: hg
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 3.
# IPoT
Posté par Moogle . Évalué à 2.
# Prononciation de Git
Posté par Gardel . Évalué à 3.
Vous prononcez « jite » ou « guite » ?
[^] # Re: Prononciation de Git
Posté par windu.2b . Évalué à 2.
[^] # Re: Prononciation de Git
Posté par cjlano . Évalué à 2.
La preuve par l'image, dès la première minute (mais les 69 autres sont aussi riches d'enseignements):
http://www.youtube.com/watch?v=4XpnKHJAok8
(Google Tech Talk: Linus Torvalds on git)
[^] # Re: Prononciation de Git
Posté par cjlano . Évalué à 2.
http://en.wiktionary.org/wiki/File:en-us-git.ogg
À partir de la page http://en.wiktionary.org/wiki/git
[^] # Re: Prononciation de Git
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 3.
[^] # Re: Prononciation de Git
Posté par j_kerviel . Évalué à 3.
[^] # Re: Prononciation de Git
Posté par cosmocat . Évalué à 2.
cf http://en.wikipedia.org/wiki/Git_%28software%29#Name
# Git et Mercurial
Posté par Boa Treize (site web personnel) . Évalué à 3.
La capacité d'aller lire et modifier le code source pour déboguer un problème de configuration serveur a été un gros plus. (Mercurial étant dans ce cas installé au sein d'une installation Python standard, et non pas avec un Python intégré.)
• Git sous Linux, chez moi (et quelques essais sous Windows), une demi-douzaine de repos, à chaque fois quelques dizaines / centaines de fichiers. Interfaces graphiques qui s'améliorent (pas essayées récemment), pas de souci de performance (mais bon, en solo avec quelques commits... c'est pas vraiment un challenge).
Le format de stockage des données, les concepts derrière Git, me semblent nettement plus propres, agréables, et intuitifs que ceux de Mercurial.
Par contre, la ligne de commande de Git est nettement plus hardcore, avec des listes d'options qui calment, jusqu'à ce qu'on prenne ses marques.
[^] # Re: Git et Mercurial
Posté par ggins . Évalué à 0.
* git: souvent présenté de façon plus technique, plus touffue. Beaucoup de commandes, les man pages peuvent sembler un peu plus repoussantes vu le nombre de switches. Il faut apprendre à faire le tri et se concentrer sur l'essentiel. On peut avoir sans entrer dans les détails une bonne vue d'ensemble via [http://progit.org/book]
C'est peut être subjectif, mais en tout cas j'ai trouvé que pour pouvoir se servir de git, il est rapidement très utile de se donner la peine de comprendre le data-model sous-jacent (commit, tree, blobs etc...). Pour les fonctionalités relatives à la manipulation de l'historique ou aux merges avancés, c'est carrément indispensable. Franchement, le data-model semble particulièrement élégant/séduisant, et paradoxalement assez simple.
Une fois qu'on a dépassé l'étape de la découverte, on se rend vite compte que les deux scms répondront assez facilement à la plupart des besoins.
Ensuite, d'un point de vue pragmatique, l'énorme avantage de hg est que vues ses dépendances (python + je crois un peu de C), il est utilisable sur tous les os, il peut être facilement intégré dans des IDEs. On peut trouver des GUIs pratiques etc...
C'est exactement là ou git pêche un peu: par exemple, même si des efforts ont été faits ou sont en cours pour rapatrier certaines fonctionalités dans des libs, on a droit à du perl, du shell script etc... De plus, git a été développé pour linux, msysgit (le portage officiel sous windows) n'est pas aussi performant mais reste utilisable.. Les GUIs sont plus rares et semblent moins abouties.
Bref, git semble plus puissant que hg pour les fonctionnalités avancées (grâce à son data model sous-jacent avec plus de potentiel) mais il est d'un abord pas facile (doc, déploiement sur des os différents etc..). Au contraire, hg semble avoir moins de potentiel d'un point de vue purement technique, par contre l'utilisateur est choyé (déploiement aisé, doc, outils etc...)
[^] # Re: Git et Mercurial
Posté par DLFP est mort . Évalué à 2.
J'ai lu en bouquin sur git, l'auteur avait justement choisi (et justifié son choix) de commencer par le "data model" de git et ça m'a rendu beaucoup plus efficace.
J'ai utilisé Mercurial et Git, d'abord Mercurial pour ses commandes beaucoup plus intuitives (surtout quand on a utilisé Subversion avant) mais git une fois maîtrisé est juste beaucoup plus puissant.
Le passage à git dans mon boulot a d'ailleurs arrêté la pratique des GUI/intégration à un IDE et depuis les fichiers commités par erreur sont beaucoup plus rares (pourtant il y a effectivement des GUI, que je n'ai testé que pour leur affichage de l'historique).
DLFP >> PCInpact > Numerama >> LinuxFr.org
# Nouveau sondage ?
Posté par peikk0 . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.