La question pour moi aujourd'hui n'est pas git ou pas git mais quel serveur git. Pull request Branch based (github, gitlab) vs commit based (gerrit, phabricator)
Perso j'ai adoré Gerrit, son utilisation des refspec que j'utilise encore manuellement ailleurs,son commit id pour tracer un fixe quand on supporte plusieurs version long terme etc…
Dommage que github est écrasé la concurrence, gerrit avait de bien meilleur idée mais une ihm vielotte
Si vous deviez choisir un DCVS, choisiriez-vous git ou autre chose ?
Hein?
Tu as lu le lien?
Je cite : "In a 2022 survey by Stack Overflow, Git had a market share of 94%, so much so that the following year, Stack Overflow stopped asking which version control system people used."
Si tu veux être dans les 6%, tu sais pourquoi tu le choisis donc tu ne poses pas cette question, sinon tu sais déjà la réponse à cette question donc tu ne poses pas non plus cette question.
PS : et dans les 6%, la grande majorité est la gestion du passé, avec du vieux SVN (en 2024, ouch) ou Mercurial que les gens ont eu sans doute pas eu le courage de changer. Source.
Lire ce qui se tient entre la conclusion et le titre ne peut pas faire de mal non plus si je peux me permettre de répondre un peu à votre manière :-). Sinon, pour éclaircir mon propos :
« Shoulda, coulda, woulda, my biggest regret is not money, it is that Git is such an awful excuse for an SCM. It drives me nuts that the model is a tarball server. Even Linus has admitted to me that it’s a crappy design. It does what he wants, but what he wants is not what the world should want. »
À un moment l'effet d'entraînement de la masse, de la mode, et de la célébrité, ne pourrait-il pas être amené à céder le pas à des considérations plus techniques ? C'est l'objet de ma question.
Pas nécessairement. Ça fait des années que j'ai un dépôt Mercurial sur Savannah qui est répliqué sur GitHub et la synchronisation entre les deux se fait de manière transparente grâce à hg-git.
Pour nous émanciper des géants du numérique : Zelbinium !
et dans les 6%, la grande majorité est la gestion du passé, avec du vieux SVN (en 2024, ouch)
Pourquoi le "vieux" SVN (2000) serait moins pertinent que Git (2005) ? Dans un certain nombre de cas, cela fait aussi bien l'affaire. Pourquoi changer quelque chose qui fonctionne et qui, dans certains cas, donne satisfaction ?
Oui, le côté décentralisé est une vraie différence.
Mon commentaire était interrogatif sur le fait que le changement pour le changement (ou pour suivre une mode) n'est pas une justification suffisante lorsque l'outil utilisé donne satisfaction pour le cas d'usage.
Pourquoi changer quelque chose qui fonctionne et qui, dans certains cas, donne satisfaction ?
Car les gens ne le connaissent pas/plus et il n'a aucun avantage (Git peut faire du centralisé aussi si tu veux, pas besoin d'apprendre autre chose pour ça), et passer de SVN à Git est en une commande, ça va niveau difficulté.
Et oui, SVN était déjà vieux à la naissance en pratique, et encore plus aujourd'hui où SVN n'a aucun écosystème comparé à Git.
Pas de soucis si tu as envie de garder ton petit plaisir SVN, mais pas la peine de faire croire que c'est un choix rationnel (non, ça ne l'est pas) plutôt que sentimental/émotionnel/résistance au changement.
PS : je suis assez vieux pour avoir utilisé CVS au début, puis SVN quelques années, avant de migrer simplement à Git pendant mon abandon de Sourceforge.
pour le présent : pour pouvoir accueillir de nouvelles personnes comme contributrices (en sortie d'école ou en junior, elles connaîtront toujours un DCVS et probablement git, et très probablement pas SVN). Donc pour éviter de limiter son public cible de contribution
pour le futur : éviter de passer pour un projet un peu désuet englué dans sa dette technique (encore plus vrai pour CVS, RCS, etc.)
parce qu'à un moment pour avancer il faut sortir de sa zone de confort
pour avoir un DVCS écrit en langage_hype_du_jour
pour avoir son outil de CVS/SCM qui existe encore dans une version encore prise en compte de son système d'exploitation préféré / distribution préférée
parce que tu contribues à X autres projets qui eux sont sur un DVCS alors tu peux éviter d'avoir 2 ou plus outils différents avec des syntaxes différentes et des fonctionnements différents
parce que tu peux, personne n'est obligé, mais c'est possible alors pourquoi pas essayer
pour avoir des nouvelles fonctionnalités comme le fediverse, l'IA, la chaîne de blocs ou le café sur IP…
Et oui, SVN était déjà vieux à la naissance en pratique,
Il faut peut-être pas exagérer, avant SVN il n'y avait pas grand chose d'autre et SVN est quand même un très gros progrès par rapport à CVS en termes de facilité d'utilisation.
Il a vieilli assez vite après (malgré pas mal d'efforts pour incoroporer quelques bonnes idées de Git), mais c'est pas une raison.
Si je pouvais1, j'essaierai pijul, on avait eu ici même de superbes discussions sur la théorie des patchs pour gérer le code source à la place de snapshots de système de fichier (ce que fait git).
Je ne me souviens plus dans quel contenu exactement, je vous laisse suivre l'étiquette pijul et lire les commentaires.
je peux techniquement tester, mais je manque de temps libre et de motivation pour utiliser un outil qui doit faire face à git avec ses 94% de marché. J'avais essayé de tester il y a quelques années, mais j'ai été bloqué à cause de l'implémentation custom du client ssh pour accéder au service pijul hébergé à la github. ↩
jujutsu, comme ça tu peux avoir la confusion jiu-jitsu ou ju-jitsu (deux autres écritures du même art martial) ou même juju, tout en étant pénible à rechercher dans un moteur pour le Web.
Pour ma part, j’espère trouver un cas d’utilisation pour fossil. Sûrement pour un projet privé, vu que pour tout ce qui a besoin de visibilité, GitHub est de fait le meilleur choix…
# La suite
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 2.
Quelqu’un connaît-il la suite de l’histoire ? Si vous deviez choisir un DCVS, choisiriez-vous git ou autre chose ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: La suite
Posté par Tangi Colin . Évalué à 4.
La question pour moi aujourd'hui n'est pas git ou pas git mais quel serveur git. Pull request Branch based (github, gitlab) vs commit based (gerrit, phabricator)
Perso j'ai adoré Gerrit, son utilisation des refspec que j'utilise encore manuellement ailleurs,son commit id pour tracer un fixe quand on supporte plusieurs version long terme etc…
Dommage que github est écrasé la concurrence, gerrit avait de bien meilleur idée mais une ihm vielotte
[^] # Re: La suite
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 02 juillet 2024 à 21:36.
Hein?
Tu as lu le lien?
Je cite : "In a 2022 survey by Stack Overflow, Git had a market share of 94%, so much so that the following year, Stack Overflow stopped asking which version control system people used."
Si tu veux être dans les 6%, tu sais pourquoi tu le choisis donc tu ne poses pas cette question, sinon tu sais déjà la réponse à cette question donc tu ne poses pas non plus cette question.
PS : et dans les 6%, la grande majorité est la gestion du passé, avec du vieux SVN (en 2024, ouch) ou Mercurial que les gens ont eu sans doute pas eu le courage de changer. Source.
[^] # Re: La suite
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 4.
Lire ce qui se tient entre la conclusion et le titre ne peut pas faire de mal non plus si je peux me permettre de répondre un peu à votre manière :-). Sinon, pour éclaircir mon propos :
À un moment l'effet d'entraînement de la masse, de la mode, et de la célébrité, ne pourrait-il pas être amené à céder le pas à des considérations plus techniques ? C'est l'objet de ma question.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: La suite
Posté par Krunch (site web personnel) . Évalué à 1.
J'ai du mal de comprendre les raisons qui pousseraient un projet à passer de Mercurial à git.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: La suite
Posté par barmic 🦦 . Évalué à 4.
github
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: La suite
Posté par Claude SIMON (site web personnel) . Évalué à 3. Dernière modification le 04 juillet 2024 à 06:22.
Pas nécessairement. Ça fait des années que j'ai un dépôt Mercurial sur Savannah qui est répliqué sur GitHub et la synchronisation entre les deux se fait de manière transparente grâce à hg-git.
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: La suite
Posté par nico4nicolas . Évalué à 3.
Pourquoi le "vieux" SVN (2000) serait moins pertinent que Git (2005) ? Dans un certain nombre de cas, cela fait aussi bien l'affaire. Pourquoi changer quelque chose qui fonctionne et qui, dans certains cas, donne satisfaction ?
[^] # Re: La suite
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
La question est sur les DVCS. Pas trop le point fort de SVN (ou CVS)
https://en.m.wikipedia.org/wiki/Comparison_of_version-control_software
Après ça ne veut pas dire que SVN ou CVS ne sont plus utilisés (par choix ou pour des raisons historiques)
https://www.openbsd.org/anoncvs.html
https://github.com/openbsd
Ou cf la dépêche récente Ancestris avec son SVN
[^] # Re: La suite
Posté par nico4nicolas . Évalué à 2.
Oui, le côté décentralisé est une vraie différence.
Mon commentaire était interrogatif sur le fait que le changement pour le changement (ou pour suivre une mode) n'est pas une justification suffisante lorsque l'outil utilisé donne satisfaction pour le cas d'usage.
[^] # Re: La suite
Posté par Zenitram (site web personnel) . Évalué à 2.
Car les gens ne le connaissent pas/plus et il n'a aucun avantage (Git peut faire du centralisé aussi si tu veux, pas besoin d'apprendre autre chose pour ça), et passer de SVN à Git est en une commande, ça va niveau difficulté.
Et oui, SVN était déjà vieux à la naissance en pratique, et encore plus aujourd'hui où SVN n'a aucun écosystème comparé à Git.
Pas de soucis si tu as envie de garder ton petit plaisir SVN, mais pas la peine de faire croire que c'est un choix rationnel (non, ça ne l'est pas) plutôt que sentimental/émotionnel/résistance au changement.
PS : je suis assez vieux pour avoir utilisé CVS au début, puis SVN quelques années, avant de migrer simplement à Git pendant mon abandon de Sourceforge.
[^] # Re: La suite
Posté par nico4nicolas . Évalué à 2.
Ma question était : dans le cas où SVN donne satisfaction, pourquoi changer pour Git ?
Ta réponse dit que :
Tout ces points sont vrais mais je n'ai pas la réponse à ma question.
[^] # Re: La suite
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
langage_hype_du_jour[^] # Re: La suite
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 6.
Il faut peut-être pas exagérer, avant SVN il n'y avait pas grand chose d'autre et SVN est quand même un très gros progrès par rapport à CVS en termes de facilité d'utilisation.
Il a vieilli assez vite après (malgré pas mal d'efforts pour incoroporer quelques bonnes idées de Git), mais c'est pas une raison.
[^] # Re: La suite
Posté par Claude SIMON (site web personnel) . Évalué à 3.
À propos de vieilleries, il y a encore quelqu'un qui utilise ou a utilisé Bazaar ? À une époque, c'était le seul VCS disponible sur mon N900…
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: La suite
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 2.
À l’époque où j’en utilisais encore, c’était celui-ci. Ça date.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: La suite
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 6.
Si je pouvais1, j'essaierai pijul, on avait eu ici même de superbes discussions sur la théorie des patchs pour gérer le code source à la place de snapshots de système de fichier (ce que fait git).
Je ne me souviens plus dans quel contenu exactement, je vous laisse suivre l'étiquette pijul et lire les commentaires.
je peux techniquement tester, mais je manque de temps libre et de motivation pour utiliser un outil qui doit faire face à git avec ses 94% de marché. J'avais essayé de tester il y a quelques années, mais j'ai été bloqué à cause de l'implémentation custom du client ssh pour accéder au service pijul hébergé à la github. ↩
[^] # Re: La suite
Posté par cosmocat . Évalué à 4.
En tant que petit nouveau, il y a aussi jujitsu :
https://github.com/martinvonz/jj
https://lwn.net/Articles/958468/
https://theo.daron.be/blog/jujutsu-an-alternative-to-git/
Il essaye de corriger des défauts de git tout en utilisant un dépôt git et en étant compatible.
[^] # Re: La suite
Posté par Benoît Sibaud (site web personnel) . Évalué à 5.
jujutsu, comme ça tu peux avoir la confusion jiu-jitsu ou ju-jitsu (deux autres écritures du même art martial) ou même juju, tout en étant pénible à rechercher dans un moteur pour le Web.[^] # Re: La suite
Posté par Guillawme (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 03 juillet 2024 à 19:17.
Pour ma part, j’espère trouver un cas d’utilisation pour fossil. Sûrement pour un projet privé, vu que pour tout ce qui a besoin de visibilité, GitHub est de fait le meilleur choix…
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.