Pourquoi Git a-t-il eu autant de battage publicitaire? … Tandis que d'autres ne le font pas? [fermé]

124

Au cours des dernières années, le battage publicitaire autour de Git a fortement augmenté. Tout le monde connaît Git, personne ne connaît les alternatives.

D'autres comme Mercurial semblent passer inaperçus. Les deux ont été publiés en 2005 et offrent des fonctionnalités similaires. En outre, Mercurial est généralement considéré comme étant plus facile à utiliser, plus intuitif et bénéficiant depuis longtemps de meilleures interfaces utilisateur. Par conséquent, on peut supposer que ce serait une alternative populaire, en particulier pour les débutants en contrôle de version distribué. Pourtant, cela semble inconnu à la plupart des gens, contrairement à Git qui a très bien réussi.

Le but de cet article est d'essayer de mieux comprendre ce phénomène.

Comment se fait-il que Git obtienne toute la part du gâteau? Ont-ils en quelque sorte utilisé un meilleur marketing? Est-ce parce que sa communauté est plus ... heu ... "verbeuse"? Est-ce à cause du nom "Linus"? Est-ce à cause de son image geek?

Qu'en penses-tu?

arnaud
la source
63
Vous êtes peut - être raison sur Linus Torvalds être la seule raison de sa popularité ...
Robert Koritnik
4
Je ne sais pas, je sens qu'ils ont été exposés à moi en quantités à peu près égales ... bien que j'aie entendu parler de git avant hg. Mais oui, Torvalds est une célébrité, donc tout ce dans quoi il est impliqué risque d'attirer l'attention.
perp
13
J'aime GitHub ... c'est tout
cnd
7
@jrwren, je commencerai ce commentaire en disant que je n'ai utilisé ni Git ni Mercurial. Si je devais apprendre le Git puis immédiatement le Mercurial (ou vice-visa), il me faudrait probablement moins de temps pour apprendre l'un d'entre eux. Celui-là, celui qui a pris moins de temps, est celui que je considérerais comme étant plus facile à utiliser. Grokking implique généralement qu’il faut un certain temps pour comprendre, ce qui est donc plus difficile à utiliser. Je ne dis pas que cela aggraverait un produit, il faut parfois une courbe d'apprentissage plus abrupte pour des outils plus puissants, mais cela change certainement la facilité d'utilisation.
zzzzBov
8
@ MarkTrapp Dieu, Mark! On dirait que tout le monde a eu une bonne discussion et ensuite il a fallu venir et faire tout le monde par la police à la porte. J'aimerais connaître un site comme StackOverflow qui permettait des discussions.
Theodore R. Smith

Réponses:

86

Je pense que des services comme GitHub ou Gitorious sont un facteur important. Il est important pour les personnes de pouvoir héberger leurs contenus quelque part et GitHub est un excellent service.

Pour mercurial, il n'y avait pas de tel service lorsque DVCS est devenu populaire (du moins aucun que je sache). Vous avez Bitbucket maintenant et probablement d’autres, mais GitHub est là depuis un certain temps, il est bien connu et cela s’améliore de mieux en mieux.

daaawx
la source
Ajoutons à cela que d’énormes projets open source utilisent git qui prend en quelque sorte la décision pour vous. On m'a "obligé" à utiliser git plusieurs fois (pour Android par exemple) mais je n'ai pas été obligé d'utiliser Mercurial ou Bazaar. Aussi, je pense que git est super :)
FeatureCreep
11
Il y a aussi Google Code et SourceForge pour hg
configurateur
7
Git est boosté par Github qui met à l’ombre les autres dépôts. Bitbucket présente certains avantages (référentiels privés gratuits) mais l'interface utilisateur est médiocre par rapport à Github
iandotkelly le
2
J'utilise Mercurial seul pour parler à GitHub ... le plugin hggit ( hg-git.github.com ) permet de découpler l'outil de la communauté. Mais peut-être pas des outils de la communauté.
bpanulla
1
CodePlex supporte également Mercurial.
Grant Palin
86

Je vois beaucoup de réponses à cette question qui s'appuient sur les sentiments de l'auteur lorsqu'il a entendu parler de l'un ou l'autre SMC. D'autres disent que tout était pur hasard. Je crois que la chance peut être retracée dans l'histoire.

Je vais parler de l'histoire.

Git et Mercurial ont été créés simultanément afin de résoudre le même problème. À cette époque, le noyau Linux était obligé de cesser d'utiliser BitKeeper , un SCM distribué exclusif qu'il utilisait depuis 3 ans. La raison en est que Larry McVoy, PDG de BitMover, la société derrière BitKeeper, a cessé de donner son logiciel gratuitement aux développeurs Linux, parce que quelqu'un de la communauté Linux l'avait fait évoluer.

Linus Torvalds, insatisfait de ce qui existait déjà, a ensuite commencé à travailler sur un tout nouveau SCM qu'il appellerait bientôt Git. Peu de temps après, Matt Mackall a lancé le projet Mercurial pour des raisons similaires.

Après avoir mis au point ces projets séparément, Matt Mackall a présenté une version avancée de son SCM et l'a comparée d'une certaine manière, en la comparant à Git (elle-même âgée de seulement deux semaines). Linus envisagea de l'utiliser au lieu de Git pour le développement du noyau, mais abandonna l'idée lorsqu'il réalisa que Mercurial utilisait Changeset pour enregistrer les modifications de révision . Il craignait que cela soit trop proche de la façon dont BitKeeper travaillait, et il ne voulait certainement rien qui puisse faire dire à quelqu'un: "Ils ont construit un clone BitKeeper".

Git était donc utilisé pour le développement du noyau au lieu de Mercurial, mais les deux étaient pertinents sur le plan technique. Le résultat final est que Git a commencé par être réellement utilisé là où il avait été conçu, alors que Mercurial n'a pas été aussi rapide que sa première grande utilisation de FOSS. Parce qu'il était doté d'un très bon design, et grâce à la persévérance de Matt Mackall, il est finalement devenu célèbre et a été utilisé pour de grands projets dans le monde réel.

Aujourd'hui, ils sont tous deux célèbres. Lequel est le plus célèbre est impossible à dire. Google Code n’a intégré Git que récemment, alors que Mercurial l’utilisait depuis longtemps. Beaucoup de projets vraiment grands et célèbres utilisent soit.

Je suppose que ce que je veux dire, c’est que lorsque la raison même pour laquelle vous avez démarré un projet disparaît, il est plus difficile de gagner en popularité, mais cela reste réalisable.

Bazaar est un autre SCM très célèbre dans le monde GNU, mais pas tellement en dehors de cela, car il a été construit dans le but de satisfaire la communauté GNU. Les logiciels vont souvent là où leurs créateurs veulent aller, et pas plus loin.

D'autre part, les GDS distribués sont clairement gagnants. Je ne vois pas beaucoup de GDS non distribués largement utilisés.

Thaddee Tyl
la source
5
J'apprécie vraiment cette histoire.
Jrwren
4
@TMN Tu as raison! En fait, lorsque la rétro-ingénierie d’Andrew Tridgell a été mise au jour et que Larry McVoy a modifié les licences de BitKeeper, il y a eu tellement de guerres de flammes que Linus Torvalds a décidé de les abandonner et s’est donné une semaine pour le remplacer. À l’époque, le véritable concurrent était Monotone, mais il était lent à pleurer. De nombreuses personnes ont construit des pièces de remplacement en même temps et tout le monde était content d’utiliser les nouveaux outils. Je pense que Git a d'abord touché 1.0, puis Mercurial; Bazar a pris presque deux ans.
Thaddee Tyl
7
"Je ne vois pas beaucoup de GDS non distribués largement utilisés." Cela dépend de l'endroit où vous vous trouvez dans l'industrie. Perforce, ClearCase et svn sont encore très largement utilisés, mais pas tellement (sauf pour svn) dans le monde open source. Oh, oui, et Visual Source Safe et MS Team, quels qu’ils soient, dans les magasins Windows.
Bob Murphy
13
Par "reverse engineering", vous entendez telneting sur le serveur et que vous tapez "help"
alternative
3
Je dirais ceci en général à propos de DVCS et de CVCS: "Tous les logiciels participent du Tao et ne doivent pas être méprisés." "Y compris les logiciels de Redmond?" "Oh, ça alors, regarde l'horloge. La classe est renvoyée."
Bob Murphy
77

Linus Torvalds

Linus est un ardent défenseur de Git et l’a fortement promu au sein du groupe Linux central pendant des années. Je suppose que c'est entièrement dû à l'influence de Linus sur la communauté * nix.

Personnellement, j'utilise toujours Subversion, mais c'est par préférence plutôt que par utilité.

Justin Shield
la source
12
Je ne pense pas que ce soit personnellement Linus, mais plutôt l’énorme visibilité de Linux. Il y a peu de choses que vous pourriez dire à quelqu'un qui n'a aucune connaissance préalable de DVCS (ou même du développement logiciel en général) plus susceptible de donner de la crédibilité que "c'est utilisé pour le Noyau Linux ".
Michael Borgwardt
6
Il est non seulement un ardent défenseur de ce projet, mais aussi celui qui en a créé les versions originales avant de le céder à Junio ​​Hamano
Marco Ceppi,
44
Quelle? Pourquoi préféreriez-vous Subversion?
configurateur
11
Ne voulez-vous pas dire que vous utilisez toujours Subversion par habitude et par inertie, plutôt que par préférence ou par utilité? C'est pourquoi je l'utilise encore, et je soupçonne la plupart d'entre nous aussi ...
Cody Grey
7
@deadalnix: Parce que Linux et Linux ont une horde de fanboys hurlants inégalés par aucun autre projet open source. Ils fonctionnent comme une équipe de rue assez efficace pour Git.
Tom Anderson
34

Le problème habituel avec le système de contrôle de version est la fusion de branches .

Vous devez avoir essayé quand cela ne fonctionne pas pour comprendre à quel point cela peut être douloureux et à quel point il est important de travailler pour pouvoir travailler librement avec des branches.

En apprenant que Linus Torvalds a écrit git pour faire cela correctement, et que dans une situation, il aurait utilisé git pour fusionner douze branches à la fois, c’est un argument très convaincant pour que git soit intéressant.

Il y a environ un an, je me trouvais dans une situation où je devais choisir entre hg et git, et la fusion ci-dessus était un facteur important dans le choix de git. La seconde est que l’organisation Eclipse est passée à git. L’outillage Eclipse devait donc être utile pour les projets Java. Avec la sortie d'Eclipse 3.7, cela s'est produit. Nous étions peut-être 6 à 9 mois plus tôt.

Pour des besoins différents, hg pourrait être tout aussi utile. Sun a choisi pour leur VCS basée sur une très enquête minutieuse. Vous voudrez peut-être trouver les livres blancs et voir quels étaient leurs raisonnements.


EDIT: Remarque, je ne dis pas que Mercurial ne peut rien faire, mais pour Java avec Eclipse - notre principal objectif - les forces du marché sont actuellement les plus puissantes pour git, même sous Windows, et nous devons rester sur nos épaules des autres, pas leurs pieds.

utilisateur1249
la source
5
+1 Tout est dans les branches. Cette analyse discute du pouvoir de fusion de git par rapport à mercurial.
Amelio Vazquez-Reina
19
@AmV: Merci de ne pas publier d'URL obfusquées.
Cody Grey
4
Je ne suis pas sûr de voir votre point ici. Vous dites qu'ils sont tout aussi bons en matière de branches (Git ne fait rien que Mercurial ne peut pas faire), mais parce que vous avez besoin d'une bonne branche, vous avez choisi Git?
Jalf
8
Je n'ai jamais vu d'exemples convaincants montrant que Git est meilleur en fusion que Mercurial, et certainement pas dans cette réponse. C'est presque comme si vous confondiez Hg avec SVN ou CVS.
Aaronaught
23

Au lieu de dire pourquoi git ou mercurial est meilleur et d’en dire que c’est la seule raison pour laquelle il est populaire, je vais me concentrer sur la communauté.

Comme je l'ai souligné plus tôt , la communauté Git est très bruyante et arrogante. La plupart défendront vigoureusement leur précieux programme. La plupart des guerres entre Git et Mercurial que j'ai vues ont été lancées par des git, qui se demandaient pourquoi tout le monde sur Terre n'utilisait pas le saint git. Des sites comme whygitisbetterthanx.com montrent même cette arrogance dans l'introduction, qui est écrite pour incendier les autres.

Je ne dis pas que tout le monde est comme ça, mais la plupart du temps, lorsque je rencontrais des git, des sites Web pro-git et des blogs pro-git, je me sentais comme si on m'avait poussé dans la gorge au lieu de le proposer comme un DVCS viable. système.


En revanche, les autres communautés DVCS ne sont pas aussi bruyantes. Je ne savais pas que Mercurial existait avant de voir un "Quel est le meilleur DVCS?" question sur SO. Alors que git apparaît partout, les autres DVCS mettent du temps à trouver.

TheLQ
la source
16
Appeler les autres arrogants n'est-il pas un peu arrogant?
21
@ Thorbjørn: C'est ça. Sauf quand je le fais; alors c'est juste correct.
Tom Anderson
6
Je pense que vous êtes devenu assez allergique à l'idiot. J'ai lu l'introduction de whygitisbetterthanx et une partie de son contenu. Je ne vois rien d'arrogant ou de provocateur. Cela a juste le biais normal, que tout ce qui est destiné à promouvoir quelque chose a.
back2dos
5
@ back2dos: il est assez arrogant en ce sens qu'il dit "Git est meilleur que tout". Et dans cette partie assez importante de son argumentation à l'appui est soit fausse et non corrigée, soit rayée, et pourtant cela ne change en rien la conclusion.
Jalf
5
@Agos: Et presque toutes ne sont pas propres à Git. Ils déplacent simplement les poteaux de but pour exclure d'autres produits.
Aaronaught
14

Je ne pense pas que Mercurial soit particulièrement discret. Kiln est construit sur Hg et les IDE comme Eclipse & Netbeans sont bien supportés depuis un certain temps.

La plupart des développeurs avec lesquels je parle semblent préférer Hg en raison du meilleur support Windows. Si nous étions des développeurs Linux, la situation serait peut-être différente.

Vous manquez également "Bazaar" qui est le véritable "DVCS oublié".

Je conviens certainement que Linus est un type très charismatique et un alpha nerd presque sans égal, de sorte que beaucoup de gens aimeraient bien Git à cause de cela. En outre, le "mythe de la création" de Git est très convaincant. Linus a passé six jours à travailler à la création de Git et à se reposer le septième - ou quelque chose du genre. Quand un produit a une histoire mémorable, il est plus facile de gagner du terrain.

mcottle
la source
6
... totalement d'accord avec: "Bazar" qui est le vrai "DVCS oublié".
dagnelies
d'accord, mais l'exposition de hg au four / joel est plus récente que celle de linus. hg joue au catchup
jk.
2
Il existe en fait un certain nombre de "DVCS oubliés", bien que nombre d'entre eux seraient probablement mieux décrits comme "profil bas", "ciblé" ou "niche".
John Gaines Jr.
13

C'est une opinion humble, mais git pourrait avoir tout ce battage publicitaire à cause de deux paramètres:

  1. C'est très efficace
  2. C'est amusant à utiliser (à la manière d'un informaticien très spécifique)

De plus, git a eu une application géniale comme github, et des projets très populaires ont décidé de l'utiliser, ce qui lui a donné beaucoup de visibilité.

Thibault J
la source
4
1. Le mercure est-il inefficace dans certains domaines? En fait, pendant longtemps, il a été plus efficace sur http, ce qui explique pourquoi le code Google l'a inclus depuis plus de 2 ans, par rapport au support git annoncé la semaine dernière et récemment devenu tout aussi performant que http. 2. OK 3. Il y a l'équivalent bitbucket.org
dagnelies le
1
Ai-je dit que mercurial était inefficace? Je ne l'ai jamais utilisé, donc je peux le dire.
Thibault J
4
cela ne règle pas du tout la question à mon humble avis, du moins pas la partie "tant que les autres ne le font pas"
jk.
1
Mercurial ne peut pas ajouter de "dossiers vides" au référentiel (je ne sais pas si cela a été corrigé maintenant), mais lorsque j'ai dû choisir un DVCS, je suis finalement allé git à cette fin. J'avais besoin de dossiers vides.
Martin Marconcini
4
@ MartínMarconcini Que voulez-vous dire par "je suis finalement allé git à cette fin"? Git ne supporte pas non plus les dossiers vides.
Max Nanasy
12

Il y a trois facteurs à l’œuvre ici, «beta geek media», «le moment est propice» et «suivez le leader»

Beta Geek Media

Il existe un certain nombre de chaînes qui discutent des "activités geek". Ils couvriraient certainement l’apparence d’un nouveau système de contrôle de version, mais ils en couvriraient davantage. Pourquoi? Parce que Linus Torvalds l’a écrit au début, en a débattu publiquement et l’a utilisée comme solution à son problème très médiatisé avec Bitkeeper. En effet, chaque fois qu'il y a une guerre de flammes sur Lkml, les médias beta geek écriront un article à ce sujet. La discussion entre git a commencé sur lkml, elle a donc eu plus de couverture que d’autres alternatives. Et les geeks bêta qui lisent slashdot comme si c'était Variety en mangeaient. Le résultat final est que git a dix fois plus d'articles que mercurial.

Le moment est venu

Les grands projets open source ayant de nombreux contributeurs rencontrent des problèmes de contrôle centralisé des sources. À mesure que l’open source se développe et que les projets ont de plus en plus de chances d’avoir de nombreux contributeurs, le problème s’aggrave. Linux est probablement le projet le plus connu qui en souffre, mais il y en a beaucoup d'autres. Avec de nombreux projets atteignant ce point, une sorte de VCS avancé était nécessaire. Git, Mercurial et Bazaar ont été les grands gagnants ici. Arch et Monotone étaient juste un peu trop tôt et ont manqué le battage médiatique.

Suivez le guide

Les gros projets ont des suiveurs qui vérifient et construisent le code régulièrement, même s'ils ne contribuent pas. Les suiveurs se familiarisent avec les outils nécessaires pour récupérer le projet qu'ils suivent, afin que ces outils deviennent plus utiles. Jetons un coup d'oeil aux projets "grand tirage au sort" pour les trois grands DVCS:

  • Git : Linux, Perl, jQuery, Ruby on Rails, Eclipse, Gnome, KDE, QT, X
  • Mercurial : Java, Mozilla, Python
  • Bazar : Ubuntu, Emacs

Git a plus de projets "grand tirage" qui l'utilisent, donc plus de gens connaissent Git, plus il y a de tutoriels écrits.

Sean McMillan
la source
1
Vous avez peut-être raison, mais votre liste de «gros tirage» est un peu trompeuse / biaisée. En consultant le site de Bazaar, ils répertorient quelques autres projets majeurs: MySQL, Bugzilla, Debian, GNU paraissent tous assez connus. La liste de Hg est également un peu plus longue.
Jalf
@jalf: une telle liste doit être subjective. J'ai compilé mes propres Linux et Gnome, mais jamais Mozilla ou Emacs. D'autres peuvent être exactement le contraire. La question est vraiment "combien de personnes vont tirer ce projet du contrôle de source"? J'ai énuméré ceux qui me semblent le plus susceptibles d'inspirer les gens à installer un vcs pour extraire la source actuelle.
Sean McMillan le
C'est suffisant. J'ai supposé qu'il s'agissait d'une tentative de liste d'objectifs (après tout, les listes des projets majeurs utilisant chaque système DVCS devraient être assez faciles à repérer) :)
jalf
12

Il s'agit principalement d'un battage publicitaire qui se renforce soi-même. Git est le plus populaire, il reçoit donc le plus de publicité, ce qui le rend de plus en plus populaire.

Git, Hg et Bzr sont de très bons systèmes DVCS, mais un nombre effrayant de personnes associent DVCS à Git et pensent que toutes les fonctionnalités attrayantes d’un DVCS sont uniques à Git. Et donc ils utilisent Git, et recommandent Git, et disent des choses comme "Git est meilleur parce qu'il peut faire de la fusion de pieuvre" (de même que Bazaar), ou "Git est meilleur parce qu'il est distribué" (comme tout DVCS, d'où le nom ), ou "Git est meilleur parce que cela facilite la création de branches et la fusion" (encore une fois, cela est vrai pour tous les DVCS).

Malheureusement, je pense que les alternatives ont également beaucoup à offrir, et je préférerais que les gens choisissent Git pour ses atouts uniques, plutôt que simplement parce qu'ils pensent que DVCS == Git.

Quand quelqu'un découvre à quel point les DVCS sont intelligents, en se dirigeant vers un DVCS spécifique, ils ne vont souvent pas dire aux autres "hé, les DVCS sont géniaux, vous devriez les utiliser", mais plutôt "le DVCS que je appris à propos de DVCS est génial, vous devriez l’utiliser ".

jalf
la source
11

Github. Github est un pionnier du codage social. Il a transformé le contrôle de version en une plate-forme sociale qui a beaucoup attiré l'attention, et il ne fait évidemment que supporter Git. Médias sociaux = plus grande adoption. Bitbucket gagne du terrain bien qu’il obtienne de nombreuses nouvelles fonctionnalités, ce qui en fait un rival probable :)

DelvarWorld
la source
7

En fait, je pense que le battage médiatique concerne toutes les rencontres DSVC.

Mais les défenseurs des droits sont simplement plus virulents, souvent plus agressifs dans leurs commentaires pour être honnêtes et aiment en parler partout.

Je pense que Mercurial sera largement utilisé, certainement aussi souvent que git, peut-être plus (Microsoft et d’autres grandes entreprises l’utilisent maintenant), mais les utilisateurs de Mercurial voulaient le plus souvent simplement un DSVC, qu’ils peuvent saisir rapidement, et non pas sur quoi fonder une religion. Donc, ils sont moins vocaux et plus réactifs dans les discussions que les discussions proactives comme certains utilisateurs git.

On ne parle certainement pas beaucoup de Bazar, car seuls quelques grands projets connus l'utilisent et aucune autre grande entreprise que Canonical n'est connue pour l'utiliser. Comparez-le à Google (git, mercurial, svn) et à de grands projets open-source, par exemple, et vous comprendrez pourquoi on n'en parle pas vraiment. Fossil est une autre source d’intérêt pour une niche de développeurs, je suppose donc qu’il est normal que ceux-ci soient entendus par ceux qui recherchent les fonctionnalités qu’ils fournissent (comme le wiki intégré, le suivi des problèmes et le forum).

Cela étant dit, je pense que nous commençons lentement à perdre du rythme et que beaucoup de développeurs ayant utilisé plusieurs solutions différentes peuvent commencer à voir laquelle correspond à leurs besoins.

De plus, Google Code Hosting et SourceForge permettent désormais à la fois git et mercurial. Il est donc devenu un choix spécifique à un projet qu'auparavant lorsque vous avez choisi git en raison de ses fonctionnalités GitHub.

Il n'y a pas de vraie guerre, juste une variété intéressante d'outils.

Klaim
la source
J'aimerais que le battage médiatique concerne les DVCS en général, mais de tout ce que j'ai vu, le battage médiatique concerne Git, et la plupart des gens pensent que DVCS et Git sont fondamentalement la même chose.
Jalf
6

Je sais qu'il y a déjà beaucoup de réponses à cette question, mais je pensais pouvoir ajouter un peu plus de perspective.

J'ai utilisé Bazaar à peu près depuis qu'il a été créé pour diverses choses. La chose la plus importante pour laquelle je l'ai utilisé était le projet AllTray, pour lequel je suis (actuellement) le seul développeur et mainteneur. Le bazar est sympa. Cela fonctionne, cela reste en dehors de mon chemin et je n’ai presque jamais à consulter une page --help ou la page de manuel correspondante. Cela dit, il y a quelques inconvénients:

  1. La plupart de ses fonctionnalités, qui devraient sans doute faire partie du VCS principal, ne le sont pas. Des fonctionnalités telles que la possibilité d'effectuer une bissection de l'historique, d'exécuter une sortie longue via un pageur ou d'avoir des branches «colocalisées» (par exemple, des référentiels de style git) sont fournies sous forme de plugins.
  2. Beaucoup de plugins ne sont pas si stables. Par exemple, la fonctionnalité de colocalisation de branches ne semble pas bien fonctionner côté serveur (du moins, je ne l’ai jamais fait fonctionner, elle a tendance à donner une erreur en disant que la branche au chemin donné n’existe pas juste en face de vous et vous pouvez voir la chose sanglante).
  3. Il n’a pas d’opération «clone», vous tirez les branches une à la fois. Vous devez faire un travail supplémentaire si vous souhaitez disposer d'un référentiel afin de pouvoir extraire efficacement de nouvelles branches.
  4. Pour certains projets, c'est extrêmement lent. Essayez «bzr branch lp: mysql» de temps en temps.
  5. Il manque un fort soutien pour les crochets; vous pouvez écrire des plugins bzr qui fournissent des hooks, mais il n’existe pas de méthode standard pour avoir des scripts de hook arbitraires côté serveur.

Je suis récemment passé à git pour le développement AllTray et envisage très rapidement de migrer tous mes projets vers git. Il y a un peu plus de temps passé à apprendre à connaître les ficelles du métier, mais cela semble en valoir la peine. Certaines choses que j'ai remarquées:

  1. git clone est une opération relativement rapide et vous donne des informations sur toutes les branches présentes dans le référentiel que vous avez cloné.
  2. L'ajout de référentiels distants supplémentaires est simple et vous permet donc de suivre, si vous le souhaitez, de nombreux référentiels comportant plusieurs branches.
  3. Le livre Pro Git est disponible en ligne et dans plusieurs formats, y compris pour les lecteurs de livres électroniques - et sa lecture n’est pas difficile.
  4. git semble beaucoup plus facile à étendre que Bazaar, et vous n'avez pas besoin d'utiliser une API particulière pour le faire. (NB: c'est à la fois un avantage et un inconvénient.)
  5. git a une bissection intégrée, et je ne saurais trop insister sur l’utilité de cette fonctionnalité.
  6. GitHub est plutôt sympa.
  7. Le gitosissystème est également très sympa. Je ne sais même pas comment on pourrait mettre en œuvre cela autrement que comme un plugin dans Bazaar, et je ne peux pas imaginer que cela serait aussi efficace.

Longue histoire courte: j'ai utilisé bzr pendant très longtemps, mais git me prouve rapidement son caractère génial.

Michael Trausch
la source
5

En utilisant git, vous avez toujours tendance à rester dans le même répertoire local lorsque vous faites du développement, et vous vous contentez git checkout branchnamede changer de branche (j'utilise tout le temps des fonctionnalités "légères", donc c'est une fonctionnalité très importante pour moi).

En examinant la documentation et les didacticiels Mercurial, il semble que la manière privilégiée de traiter différentes branches du développement consiste à créer de nouveaux référentiels par clonage. Ce tutoriel est un exemple.

Je pense que vous pouvez faire la même chose dans Mercurial et dans Git, mais pour une raison quelconque, la documentation de Mercurial (que j'ai lue) montre presque toujours des ramifications en créant un clone de référentiel.

(J'utilise git quotidiennement. J'ai peu d'expérience avec mercurial, j'ai joué avec et suivi quelques tutoriels)

Codeape
la source
2
J'ai utilisé des branches 'nommées' tout le temps en hg. Cela les soutient bien. hg branch foo, puis hg up fooplus tard ... Le clone pour une branche présente de grandes faiblesses pour le développement ordinaire.
Paul Nathan
Hmm, vous dites donc que Git est meilleur que Hg parce que si Hg supporte la fonctionnalité qui vous tient à cœur, la communauté Hg considère-t-elle une approche alternative supérieure?
Jalf
1
1: Je me demande: Pourquoi mettre l'accent sur "branche par clonage" dans la documentation de Hg (voir par exemple hgbook.red-bean.com/read/a-tour-of-mercurial-the-basics.html et mercurial.selenic. com / guide )? Pour moi, il semble tout simplement compliqué d'avoir un référentiel par branche. 2: Je ne dis pas que c'est mieux, ma réponse est plus une observation sur un sujet qui pour moi (novice en Hg) ressemble à une différence entre les deux. La différence semble être plus culturelle que technique, car Hg prend également en charge la "branche au sein du même référentiel".
codeape
3
Mercurial souffre d’une quantité d’informations en ligne obsolètes; une grande partie est propagée par des personnes qui utilisent git et ne se tiennent pas au courant des caractéristiques de mercurial au fur et à mesure de son évolution. La plupart des anciennes raisons de préférer les référentiels clonés ne s'appliquent plus dans les versions modernes de mercurial (les branches nommées peuvent maintenant être fermées et il existe un système de marque-pages qui vous donne un modèle d'utilisation similaire aux branches git si vous le souhaitez).
Stephen M. Redd le
4

Je ne sais pas combien de commérages de ce genre j'ai vu ces dernières semaines, mais ils semblent tous considérer le fait que Mercurial et / ou Bazaar sont objectivement meilleurs que Git. La convivialité semble être un thème commun. Oui, apprendre Git était étonnamment difficile après l'utilisation de CVS et de Subversion, mais pour le moment, je ne voudrais pas l'échanger contre un autre VCS, à moins que cela ne représente un changement de paradigme . Et pointer vers un tableau de fonctionnalités me dira très peu de savoir à quel point il est flexible, extensible, sécurisé et sans effort . Par exemple, utilise par défaut git-diff des couleurs et un pager. Bien sûr, je peux obtenir la même diff ... | colordiff | less -Rchose ou quelque chose du genre, mais il devrait être évident pourquoi l’un est supérieur à l’autre.

l0b0
la source
Je ne pense pas que l’argument, c’est que vous devriez donc passer d’une machine à l’autre - il est évidemment plus facile d’utiliser l’outil que vous connaissez déjà que d’en changer, peu importe la facilité avec laquelle vous vous trouvez. Je ne pense pas que les partisans du DVCS puissent vraiment prétendre que vous passez à côté d'une énorme somme en étant git au lieu de Bazaar ou de Mercurial, il n'y a pas grand-chose entre eux.
ZoFreX
3

Pour être juste, je pense que les avocats git vs. mercurial sont peu nombreux et comparés aux avocats git vs centralisés. Cependant, les raisons sont faciles à résumer:

Git est un contrôle de version pour les programmeurs. Mercurial est un contrôle de version pour les entreprises. Centralisé était un premier essai adéquat pour inventer le contrôle de version, d'autant plus qu'il avait été conçu avant la révolution des ordinateurs personnels.

Ce que j'entends par contrôle de version pour les programmeurs, c'est que les programmeurs en général privilégient la flexibilité à la facilité d'apprentissage. Après tout, nous sommes disposés à passer des années à apprendre les langues ésotériques afin de pouvoir faire en sorte que les ordinateurs fassent ce que les non-initiés ne peuvent pas. Git donne aux programmeurs la flexibilité de l’utiliser à leur guise, au prix de perdre plus de temps à apprendre à utiliser cette flexibilité en toute sécurité. Cela permet de mettre en place des restrictions pour appliquer les politiques, mais cela ne sort pas de la boîte. Notez que j'ai parlé de facilité d' apprentissage plutôt que de facilité d' utilisation . Une fois que vous l’apprenez, git est aussi facile à utiliser que tout autre VCS, et souvent plus facile en raison de sa vitesse et de ses fonctionnalités accrues.

Certains programmeurs en apprennent assez pour faire ce qu'ils veulent, puis résistent pour apprendre de nouvelles façons de le faire. Les entreprises embauchent et emploient un grand nombre de ces personnes. Elles souhaitent donc que les modifications apportées aux outils qu'elles utilisent présentent un certain degré de familiarité. Les entreprises souhaitent également que leurs programmeurs disposent de suffisamment de flexibilité pour effectuer leur travail, sans toutefois rendre la formation ou la migration initiale difficile. C'est là qu'intervient mercurial. Il a la majeure partie de la puissance de git, mais une voie de migration un peu plus facile.

Je ne pense pas qu'il soit juste de dire que git n'est populaire que pour le battage publicitaire ou l'approbation de Linus. Cela explique probablement pourquoi de nombreuses personnes l’ essaient , mais ils s’y tiennent et en font la promotion, car cela leur convient parfaitement, purement et simplement.

Karl Bielefeldt
la source
2

Le développement de NetBSD utilise CVS et c'est tout ce qui compte.

Jonathan Cline IEEE
la source
2

Il a un nom plus vif, plus pithy qui se prête bien aux jeux de mots.

Apophenia Surcharge
la source
1

Récemment, je recherchais un système de contrôle de version pour des projets personnels, alors je viens d’en essayer plusieurs. Je suis pratiquement illettré sur la ligne de commande et j'avais entendu dire que, bien que des interfaces graphiques soient disponibles, Git était vraiment destiné à être utilisé via la ligne de commande, ce qui m'a rendu un peu hésitant. Honnêtement cependant, c'était ridiculement facile à prendre en main et je l'apprécie vraiment. La documentation est un facteur déterminant dans l’adoption d’une nouvelle technologie, et Git dispose de tonnes de documents ridiculement simples, clairs et disponibles. Les autres alternatives telles que SVN et Bazaar étaient excellentes, elles ne rendaient tout simplement pas cela aussi facile que Git. Github est également un facteur important, car il est devenu si central pour le mouvement open source pour le moment. Avoir un emplacement (ironiquement) centralisé pour échanger du code et des projets est un jeu en soi.

Morgan Herlocker
la source
1

Juste mes 2 ¢ - j'ai choisi git plutôt que les alternatives parce que c'est écrit en C plutôt que dans un langage radical ou un langage trop académique de haut niveau. L'avantage est que c'est rapide et efficace et que je peux réellement RTFS si je rencontre des bugs ou des comportements que je ne peux pas expliquer. Il est également possible d'utiliser des environnements de développement auto-hébergés minuscules qui n'incluent pas d'interprètes / runtimes gigantesques, ce qui signifie que je peux directement extraire d'un dépôt git et compiler sur de tels systèmes plutôt que de devoir extraire la dernière source ailleurs et rsync.

R ..
la source
1
C’est aussi la raison pour laquelle j’ai choisi git, car il est écrit dans un langage compilé au lieu de python, et à cause de cela, je peux simplement avoir une version portable de git dans mon stylo usb avec quelques autres outils.
Coyote21
Et pourtant, c’est précisément la raison pour laquelle Facebook a choisi d’utiliser mercurial à la place: ils n’étaient pas satisfaits des performances de l’un ou de l’autre, mais trouvaient plus facile d’améliorer les performances de mercurial git Overall) par une marge significative (ce qu’ils ont fait en l’intégrant à un service de surveillance de fichiers afin de pouvoir indiquer ce qui pouvait et ne pouvait pas avoir changé ( voir les détails ici ) car il était plus facile de travailler avec Python que C.
Jules
1

Vous serez peut-être intéressé de lire pourquoi le projet de bureau GNOME a choisi git plutôt que hg et bzr, alors qu'il avait décidé de quitter svn il y a quelques années. Bien sûr, il y a eu beaucoup de discussions religieuses houleuses au cours de ce processus, mais cette page du wiki de GNOME résume bien les avantages et les inconvénients de leur application à cette communauté.

calum_b
la source
0

Sans compter qu'Apple s'est impliqué dans la transmission du message à la communauté objective c, si vous avez récemment créé une nouvelle application dans Xcode 4, vous auriez remarqué qu'il vous demande automatiquement si vous souhaitez créer un dépôt Git.

Certes, Xcode 4 n'existe que depuis quelques mois et n'influence en rien sur le succès précédent de Gits, mais nous savons tous à quel point Apple peut créer des choses en un temps record.

tutts
la source
-1

Je suis en train de passer de hg (kiln) à git (github). J'ai utilisé le four depuis environ un an maintenant. Pour moi, l'hg n'a pas d'inconvénient. Je peux faire tout ce que je dois faire. Donc c'est génial.

Pourquoi est-ce que j'utilise maintenant?

Il n'y a que trois raisons pour le moment.

  1. gitHub offre des idées géniales qui sont géniales
  2. gitHub offre d'excellentes fonctionnalités sociales
  3. Lors des présentations et des ateliers pour les développeurs, j'ai toujours publié mes exemples sur hg et git. Sur git j'ai environ 10 fois plus de visiteurs que sur hg !!

Je pense que le troisième est le plus important.

Thorsten

Thorsten
la source
-2

La chance pure, je suppose, jusqu'à présent presque impossible de prouver pourquoi quelque chose a fonctionné et d'autres pas. Linus peut construire autre chose de spectaculaire et sans succès.

Acaz
la source