Mi-Avril, GitHub a appliqué les sanction du gouvernement américain contre certaines sociétés russes en suspendant les comptes GitHub des employés de ces sociétés. Par contre, oups, cette action a purement et simplement supprimé tous les issues et pull requests ouverts par ces comptes. Les dépôts Git contenant des commits écrits par ces comptes ne sont pas affectés, mais les issues et pull requests contiennent des information précieuses sur les raisons de ces changements : solutions explorés, logs, etc. Pour ma part, il n'est pas rare que je creuse les archives Python pour rechercher une courriel ou un ticket vieux de 10 à 25 ans pour comprendre pourquoi le code actuel est écrit d'une certaine manière. Et là je suis bien content d'arriver à retrouver les archives !
Ces comptes ont été suspendus sans avertissement, ni possibilité de sauvegarder leur travail. Ils peuvent faire une demande pour prouver qu'ils respectent les conditions d'utilisation de GitHub pour que leur compte soit débloqué. Ils doivent fournir un document officiel d'identité et une photo en selfie (le formulaire n'indique pas s'il faut porter un poulpe).
Le mainteneur Jesse Squires des projets Quick et Nimble titre sur Twitter "GitHub can't be trusted" et décrit la situation en détail dans son article : https://www.jessesquires.com/blog/2022/04/19/github-suspending-russian-accounts/
Deux jours après la publication de cet article (21 avril 2022), le directeur des relations publiques de GitHub indique que GitHub a débloqué les comptes, restauré les issues et pull requests. Il explique que GitHub n'a qu'un seul mécanisme pour supprimer l'ensemble des nuisances causées par des spammeurs et ils ont réutilisé ce mécanisme pour bloquer des comptes russes.
Du coup, GitHub doit appliquer les sanctions du gouvernement américain ou pas ? Ce n'est pas clair.
Pour rappel, depuis Juillet 2019, GitHub empêche les habitants (citoyens?) de pays soumis aux sanctions américains d'utiliser leurs services, comme la Crimée, Cuba, la Corée du Nord, et la Syrie. GitHub doit se conformer aux lois d'exportation américaine comme ils font du business aux Etats-Unis d'Amérique.
L'Iran a négocié (!) le droit d'utiliser GitHub et a obtenu une exception en Janvier 2021.
GitHub interdit à une personne physique de créer deux comptes. Il n'est pas possible de séparer ses activités professionnelles de son activité "dans son temps libre". D'ailleurs, en France, évitez d'utiliser votre matériel (ordinateur) professionnel pour contribuer dans votre libre, le droit d'auteur français est plutôt du côté de l'employeur (à bon entendeur !).
Cet incident me rappelle combien il est important de mettre un maximum d'information dans le message de commit : allez lire les commits le noyau Linux, de délicieuses nouvelles romancées ! Avec Git, chaque développeur a maintenant une copie intégrale et exacte de l'ensemble des commits. Il a moins de problèmes de perte de données suite à un accident ou mauvaise manipulation, forge qui supprime volontairement des données, problème légal, etc. Par contre, évitez de stocker vos mots de passe et clés privées dans Git, car là, justement, c'est très dur à supprimer :-)
# Enfumage
Posté par Benjamin Henrion (site web personnel) . Évalué à -10.
"L'Iran a négocié (!) le droit d'utiliser GitHub et a obtenu une exception en Janvier 2021."
Et pour les entreprises iraniennes?
Git était soit disant "décentralisé", finalement il n'est pas si "décentralisé" que ça.
[^] # Re: Enfumage
Posté par moi1392 . Évalué à 10. Dernière modification le 22 avril 2022 à 15:09.
git EST décentralisé, ce sont les gens qui l'utilisent qui choisisent de centraliser leur travaux sur le service github.
Et en l'occurence les travaux des personnes bloquées par github qui sont dans des répos git sont toujours présents dans ces dépots, sur github ET ailleurs, car git est décentralisé. La perte d'information concerne ce qui n'est pas dans un dépot git.
[^] # Re: Enfumage
Posté par Benjamin Henrion (site web personnel) . Évalué à -10.
Bitcoin EST décentralisé, de par son infrastructure de full nodes qui ont une copie de toutes les transactions.
Quel est l'équivalent sous Git?
[^] # Re: Enfumage
Posté par Jean Gabes (site web personnel) . Évalué à 10.
Bah… git lui même.
Je ne comprends pas la question en fait.
[^] # Re: Enfumage
Posté par xoddark . Évalué à 4. Dernière modification le 22 avril 2022 à 16:01.
Je ne suis pas expert de l’écosystème des crypto-monnaies (Bitcoin ou autre), donc il y aura sûrement des approximations et/ou inexactitudes.
Je dirais que dire que Bitcoin est décentralisé n'a pas de sens, comme dire que Git est décentralisé. Git et Bitcoin sont des outils (voir ensemble d'outils) qui permette de travailler ou de gérer des transactions de manière décentralisée.
Pour l'histoire de l'équivalence, je dirais que l'ont peu considérer que l'équivalent de Bitcoin dans l’écosystème git est le dépôt git du kernel linux. C'est avec lui que tout à commencer, il contient tout l'historique des commits (au moins depuis les débuts avec Git), il permet à un grand nombre de personne de travailler ensemble sur un dépôt commun.
Git est un outil permettant un travail coopératif décentralisé, comme la blockchain est un outil permettant une gestion décentralisée de transaction. Mais dans les deux cas, au final il y a une synchronisation (centralisation ?) dans une base de donnée (dépôt git vs blockchain) même si celle-ci peut-être dupliqué.
Pour le cas de GitHub, l'équivalence cotée crypto serais une plateforme d'échange (ex: Coinbase). L'une comme l'autre recrée un point de centralisation, au moins pour tout ce qui n'est pas dans la base de donnée elle-même (dépôt git ou blockchain).
ça te semble plus clair ?
PS: Il y aurait moyen de faire encore plus détaillé, avec plus de comparaison, mais ça demanderais plus du temps pour faire ça bien ^
[^] # Re: Enfumage
Posté par ted (site web personnel) . Évalué à 8.
Pour utiliser Git il n'y a pas besoin d'utiliser un serveur dédié.
Imagine deux développeurs, sur deux ordinateurs, chacun ayant une copie du dépôt. Ils pourraient très bien pousser/tirer les commits directement d'un ordinateur à l'autre avec ssh. Cela est possible parce que chaque utilisateur a une copie intégrale du dépôt avec tous les commits passés (c'est ce que fait
git clonepar defaut).Un LUG en Lorraine : https://enunclic-cappel.fr
[^] # Re: Enfumage
Posté par Misc (site web personnel) . Évalué à 3.
C'est marrant, parce que c'était précisément le cas qu'un plugin de bzr cherche à rendre plus simple.Il y a aussi une de mercurial. Et je suis sur d'avoir vu la fonctionnalité dans svk, mais j'arrive pas à retrouver le code.
Et pourtant, j'ai jamais vu personne l'utiliser (la feature, j'ai bien croisé 2/3 personnes qui utilisent bzr/hg un jour).
Donc en théorie, on peut faire plein de choses. En pratique, ç'est pas du tout ce qui est fait (et pourtant, j'ai fait des hackatons, etc)
C'est un chouia plus compliqué, il faut un 3eme dépôt. Vu que chaque dev a son clone et utilise une copie de travail, on ne doit pas pousser dessus.
Du coup, si tu as un dépôt partagé, je suis pas sur de voir l'avantage d'en avoir un 2eme (pour un total de 4), surtout que tout le monde a déjà une copie en local.
Et est ce qu'on a parlé aussi des histoires de droits d’accès unix ? Parce qu'en général, c'est le truc un peu chiant a mettre correctement pour un dépôt "bare".
Donc bon, on peut, tout comme on peut faire un serveur HTTP purement en bash.
[^] # Re: Enfumage
Posté par Psychofox (Mastodon) . Évalué à 3.
Je ne vois pas ce que les droits de fichiers unix ont à voir là-dedans, ils ne sont pas sauvés dans l'index du repo.
[^] # Re: Enfumage
Posté par Misc (site web personnel) . Évalué à 3.
Le commentaire parle de "pousser/tirer d'un ordi à l'autre". Donc je comprends qu'il faut donner des accès symétriques, donc donner le droit d'écrire à 2 utilisateurs.
Si je veut pousser sur ton PC, il faut bien que je puisse me connecter et avoir le droit d'écrire dans le dépôt, et donc, il faut avoir les bons droits. Ensuite, ça fait des années que j'ai plus fait ça (je mets gitea et basta), donc peut être que ça se fait sans souci maintenant.
Par souci, je parle de ce qui va arriver un umask incorrect, ou devoir mettre des stickys bits sur les répertoires, etc.
[^] # Re: Enfumage
Posté par Toufou (site web personnel) . Évalué à 1.
Tu prends une clef USB en vfat normalement y a pas de soucis… Après je ne l'ai fait qu'une seule fois, j'ai peut-être eu de la chance.
[^] # Re: Enfumage
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 3.
Pour avoir utilisé bzr comme décrit (juste via ssh) je peux témoigner que c'était parfaitement facile à utiliser. Ça fait plus de dix ans, donc les détails m'échappent peut-être, mais si je ne m'abuse il n'y avait rien à faire d'autre que d'installer un serveur openssh sur la machine qui devait servir de dépôt de code central.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Enfumage
Posté par Misc (site web personnel) . Évalué à 3.
Sauf erreur de ma part, on parle pas de dépôt central, mais d'avoir justement 2 personnes sans dépôt central.
Je cite: "Ils pourraient très bien pousser/tirer les commits directement d'un ordinateur à l'autre avec ssh."
C'est le détail. Théoriquement, tu peux te passer de dépôt central. En pratique, personne ne le fait, sauf quand tu es seul avec 1 PC (et encore, c'est un dépôt central si tu as qu'un dépôt).
[^] # Re: Enfumage
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 2.
C'est ça. Désolé. Je m'exprime très mal.
Après tout dépend de la méthode de travail choisie. Mais encore une fois, il n'y avait rien de plus à faire qu'une commande bzr en indiquant le compte, la machine cible, et le protocole pour pouvoir utiliser bzr sur ssh sans rien installer de plus que ces deux outils.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Enfumage
Posté par Psychofox (Mastodon) . Évalué à 5.
Vous confondez dépôt central avec serveur git.
A et B peuvent collaborer en utilisant le repo lambda sur le serveur git X. B et C collaborer en utilisant le repo Alpha du serveur git Y et A et D utiliser le repo Beta du serveur git Z. Ça fonctionne et il n'y a pas de centralisation.
Alors bien sûr c'est bien plus facile si A, B , C et D utilisent le même serveur git et c'est là que vient la centralisation, d'autant plus si on utilise une forge qui permet de faire et accepter de merger des pull request venant d'un autre dépôt car ça encourage tous les utilisateurs à utiliser le même serveur.
[^] # Re: Enfumage
Posté par GaMa (site web personnel) . Évalué à 2.
Du coup, si tu as un dépôt partagé, je suis pas sur de voir l'avantage d'en avoir un 2eme (pour un total de 4), surtout que tout le monde a déjà une copie en local.
En même temps c'est un peu la base de tirer d'un repo git.
Ça a même donner la terminologie Pull Request (Svp, tirez mes patch de tel repos/tel branch, ça corrige tel bug).
Je sais pas si c'est le standard principal pour envoyer des patches sur le kernel mais c'est standard
Après, oui, il faut que tu ais un dépôt accessible publiquement pour que des gens puissent tirer de celui-ci. Et donc oui, les gens ont en général un dépôt publique en plus de leur dépôt "de travail". Mais ce dépôt n'a pas à être le même pour tout le monde. Même sur github, on fait des clones des dépôts des projets auxquels on veut contribuer. (C'est sur le même serveur certes, mais c'est des dépôts différents)
T'as l'option
core.sharedRepositorypour avoir un dépôt accessible en écriture au niveau du groupe unix.Matthieu Gautier|irc:starmad
[^] # Re: Enfumage
Posté par moi1392 . Évalué à 4.
git est décentralisé de la même façon, c'est jsute que tu peux avoir plusieurs sous réseaux séparées (encore heureux, certains ne veulent pas partager leur code, et chaque machine n'a pas vocation à accueillir tout le code géré par git…) et que la synchronisation n'est pas automatique, c'est une action utilisateur.
[^] # Re: Enfumage
Posté par Misc (site web personnel) . Évalué à 8.
Git est distribué plus que décentralisé. Le D de DVCS, c'est pour "distributed", pas "decentralized". Mais un projet, c'est plus que son code et il reste toujours des points qui sont pas distribué. Par exemple, la production des tarballs (et leur signatures, par définition), ou les outils de discussions (que ça soit des mailling listes, des chats divers et variés, etc).
Et ce qui importe c'est pas la décentralisation, mais la mobilité. Si il était facile de bouger une liste des discussions de A à B, ça serait sans doute moins un souci. Si le bug tracker était aussi mobile que le code, ça serait moins un souci, etc.
[^] # Re: Enfumage
Posté par moi1392 . Évalué à 4.
C'est peut-être juste une question de terminologie, mais pour moi distribué signifie que chaque utilisateur à une copie complète du dépot.
Décentralisé signifie qu'il n'y a pas de dépot qui a un status différent des autres. J'ai vu écrite la notion de "dépot central" et de "on peut faire entre deux personne des échanges" dans ce fil de discussion, et ça me fait penser que les personnes disant cela n'ont pas saisi ce qu'est vraiment la puissance du concept de distribué dans git.
La notion de dépot central n'existe pas sous git, c'est une convention mise en place par les utilisateurs de git sur chaque projet particulier.
J'ai personnellement 3 machine sur lesquelles j'ai des répos partagés avec du code sur lequel je bosse en plus de 2 machines sur lesquelles j'ai des répo nus (bare repository dans la terminologie git)
Et la plupart des répos présents sur ces 3 machines de travail ont 4 remotes : les 2 autres machines et les 2 dépots nus.
Il n'y a pas de repo ou de machine "centrale", c'est décentralisé et ça ne pose aucun soucis, Et même si je devais choisir un repo qui me servirait de "référence", je serais bien embeté car ça n'est pas toujours le même qui à les derniers (il est rarement seul d'ailleurs, je synchronise mes commit assez vite sur d'autres machines selon là ou je bosse) ni le même qui est en retard sur les autres.
[^] # Re: Enfumage
Posté par xoddark . Évalué à 1.
Oui c'est sans doute un problème de terminologie.
Je dirais qu'effectivement Git est un système de version distribué. Cette fonctionnalité permet à ses utilisateurs de travailler de façon décentralisée.
Mais au final c'est l'organisation de travail qui est décentralisé ou pas, mais pas Git.
[^] # Re: Enfumage
Posté par Misc (site web personnel) . Évalué à 2.
Mais en pratique, quasiment personne ne fait ça, sauf des gens qui bossent en solo.
Faut quand même voir que ne pas avoir 1 dépôt qui sert de référence, c'est l'équivalent de s'envoyer des fichiers LibreOffice par email pour collaborer et faire des modifs.
Et c'est pas parce qu'une organisation marche pour expliquer la continuité dans l'univers Marvel que ç'est une méthode à reproduire.
[^] # Re: Enfumage
Posté par xoddark . Évalué à 1.
Et s'il n'y a pas un, mais plusieurs dépôt de référence (exemple le noyaux Linux) ?
# Training annuel
Posté par Misc (site web personnel) . Évalué à 10.
interdit de créer 2 comptes gratuits, cf point B.3.
Le point important, c'est quand même "gratuit".
Si, si, il suffit de payer (4 US$ par mois). Bien sur, la question de qui paye se pose, tout comme celle d'utiliser son compte personnel pour une activité professionnelle, comme pour des réseaux sociaux.
[^] # Re: Training annuel
Posté par Elfir3 . Évalué à 3.
Ou pas. Le propriétaire du compte doit payer son entreprise pour l'activité qu'elle lui permet de générer sur son profil. Grâce à ça, il pourra négocier de meilleurs contrats par la suite.
# Le DVCS du futur, c'est Fossil
Posté par Guillawme (site web personnel, Mastodon) . Évalué à 2.
C'est exactement parce que toutes ces informations sont précieuses pour un projet que Fossil offre la possibilité de stocker tout ça dans le dépôt. C'est expliqué dans sa documentation, et d'ailleurs tout le site web de Fossil est en fait servi depuis le dépôt lui-même. Fossil utilise SQLite, donc le dépôt est un fichier unique. Pour monter un dépôt partagé (+ site web, wiki, forum, tickets, etc. si on veut), il suffit d'installer Fossil sur un serveur et de lui dire de servir le dépôt.
[^] # Re: Le DVCS du futur, c'est Fossil
Posté par fearan . Évalué à 8.
Eh Fossil a dire !
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Le DVCS du futur, c'est Fossil
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 4.
Si l'avis de quelqu'un qui n'a rien compris à Git mais qui a dû se mettre, contrainte et forcée, à utiliser Fossil, la partie wiki, compte. Je trouve que, finalement, Fossil est super facile à utiliser après la phase d'apprentissage initiale.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Le DVCS du futur, c'est Fossil
Posté par Jérôme FIX (site web personnel) . Évalué à 1.
Comme git… C'est utilisable après la phase d'apprentissage initiale.
[^] # Re: Le DVCS du futur, c'est Fossil
Posté par Faya . Évalué à 7.
https://xkcd.com/1597/
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.