Obsidian a écrit 5320 commentaires

Pour exécuter une commande que vous venez de taper, pressez: C-m: Retour charriot

Il existe un raccourci pour envoyer le caractère EOF (End Of File): C-d.
…
Il est possible de supprimer un caractère avant ou après le curseur avec les raccourcis:
C-d: Supprimer le caractère qui se trouve après le curseur

On note que ça fait double-emploi…

Faire appel à l'auto-complétion de Bash peut se faire avec le raccourci: C-i: Équivalant à la touche TAB

Il est possible de manipuler ce que montre Bash à l'écran avec ces trois raccourcis:

C-l: Nettoie l'écran, pour ne montrer qu'une invite de commande vide. Similaire à la commande clear.
C-s: Stop l'affichage. Très utile quand un programme très verbeux s'exécute.
C-q Reprend l'affichage stoppé avec C-s.

Ça vaut le coup de rappeler que tous les « raccourcis » ci-dessus, même si certains d'entre eux restent interceptés par le shell, ne sont pas des combinaisons choisies arbitrairement par lui, mais font partie à la base du code ASCII.

Il est utile de rappeler également que la touche « Ctrl » n'est pas une simple meta-key comme Alt, mais sert en principe à émettre les codes de contrôle de la table ASCII (soit les codes 0 à 31 en début de table), codes qui étaient le seul moyen de piloter les appareils et terminaux lorsqu'il étaient reliés à leur hôte à l'aide d'une ligne série. Donc saisir Ctrl+A, Ctrl+B, Ctrl+C… jusqu'à Ctrl+Z, permet d'émettre les codes 1 à 26.

C'est aussi pour cela que Escape est placé juste après cette gamme, sur le code 27. ESC étant justement le code permettant de s'échapper du flux ASCII standard et d'annoncer une séquence hors-protocole, ce qui permet de passer la main à n'importe quel standard.

Et c'est pour cela encore qu'on trouve la touche sur pratiquement tous les ordinateurs et terminaux depuis les années 1960. Elle est donc réellement censée émettre un caractère à chaque fois qu'on la combine avec une lettre, et pas n'importe lequel : le code de 1 à 26, soit 0x01 à 0x1a en hexadécimal. Donc, on doit pouvoir capter la saisie de ce caractère avec un simple fgetc() ou équivalent (sauf s'il est intercepté entre les deux par une sous-fonction du shell ou autre). Essayez avec stty -icanon ; od -tx1 -vw1, par exemple. C'est totalement différent de « Alt » par exemple, qui à ma connaissance est spécifique à l'IBM PC (même si d'autres machines ont des meta-key similaires depuis longtemps) et qui n'est pas du tout tenue d'émettre quoi que ce soit (ce qui rendait d'ailleurs son exploitation compliqué quand on écrivait ses premiers programmes en BASIC).

Du coup :
- Ctrl+I : Neuvième lettre, 09 ou 0x09 → « HT Horizontal tabulation », donc le code ASCII d'une tabulation. C'est donc normal qu'elles émettent le même code. Essayez avec la commande ci-dessus pour vous en convaincre…

• Ctrl+M : Treizième lettre, 13 ou 0x0d → « CR Carriage Return », code de retour en début de ligne.

• Ctrl+L : Douzième lettre, 12 ou 0x0c → « FF Form Feed », soit littéralement : « alimentation en papier (ou même "en formulaire") ». C'est en principe à l'usage des imprimantes et cela sert à leur commander d'aspirer une feuille et de présenter le haut de la page devant la tête d'impression pour commencer à écrire dessus. Et évidemment, s'il y a déjà une feuille en cours de traitement, celle-ci est éjectée (laissant donc le reste vide) pour avancer directement à la suivante, ce qui correspond donc à un saut de page. Et sur les terminaux dont le système d'impression a été remplacé par un écran, ça revient donc à effacer la page et à replacer le curseur en haut à gauche.

Ça marche normalement sur toute imprimante qui se respecte, mais à condition que ce soit une matricielle (continue ou feuille à feuille) ou à la limite une jet d'encre, qui peuvent encore fonctionner en mode texte même si les pilotes le font de moins en moins, mais pas les laser dont le mode de fonctionnement (dépôt de poudre sur la feuille puis passage au four) leur impose de traiter toute la feuille en une seule opération, sauf si elles peuvent bufferiser le texte jusqu'au moment où il faut éjecter la page, soit une page pleine ou justement un code 12 «FF».

Côté écrans, ça marchait sur de nombreux huit bits, et notamment sur tout ce qui était Vidéotex, donc sur les Minitel et sur les 8 bits Thomson (MO6, TO8, etc.). C'était aussi plus pratique qu'un « CLS » pour avoir un écran vraiment propre et éviter le « OK » associé à la commande. Évidemment, l'une des exceptions est justement les DEC ANSI :-( Standard suivi par la console des PC, que ce soit DOS ou les consoles virtuelles de Linux, et par les XTerm. Par contre, le shell a conservé cette fonctionnalité et l'émule proprement (même si c'est lui qui le fait) et c'est pour cela qu'il en profite pour ré-afficher l'invite de commande.

• Ctrl+S Ctrl+Q : Ce sont en fait directement les codes de XON et XOFF qui sont les codes dédiés au contrôle de flux lorsque la ligne n'est pas équipé de signaux physique pour le faire (comme RTS et CTS sur RS/232). Ce n'était pas directement ASCII mais presque : la page wikipédia indique que ça a été introduit par le Teletype Model 33 en 1963, c'est-à-dire l'année de publication de la première version du standard ASCII, et ces codes sont mappés sur DC1 et DC3, sachant qu'il y a quatre code DC1 à DC4 dans ASCII et que DC signifie « Device Control ». Ce sont donc des codes génériques permettant de piloter des fonctionnalités spécifiques à chaque appareil.

Là encore, les terminaux et les premiers ordinateurs personnels fonctionnaient uniquement en mode texte, donc interrompre le flux en provenance du serveur permettait de suspendre le défilement à l'écran (c'était aussi pratique pour les imprimantes qui n'arrivaient pas forcément à suivre) et Linux mappe ça en principe, sur ses consoles virtuelles (pas sous X-Window) avec la touche Pause du PC et sa LED associée, touche qui sert initialement à ça même sur PC (apparu en 1981, pas dans les années 60). Bon, évidemment, je viens d'essayer avec une Fedora 25. Ctrl+S Ctrl-Q fonctionnent toujours mais plus la touche Pause. Bon.

• Ctrl+D enfin, correspond à « EOT End of Transmission », ce qui est bien pratique pour dire « j'ai fini de parler », surtout sur les lignes half duplex. Du coup, sur un terminal, ça sert surtout à envoyer ce que l'on vient de saisir SANS appuyer sur Return et donc embarquer un retour chariot avec le reste. Ce n'est pas, à la base, directement un raccourci pour « exit », mais saisir Ctrl+D seul permet d'envoyer une charge utile de zéro caractère, ce qui est en soi reconnu par read() comme le signal d'une fin de connexion et de la refermeture du canal. Cela va donc provoquer un EOF exactement comme la fin d'un fichier qui aurait été atteinte si ce fichier avait été redirigé vers l'entrée standard du processus avec « < ». Le shell se termine donc normalement (en le détectant) mais ça fonctionne en fait avec tout processus à l'avant plan et fait pour gérer normalement l'entrée standard. Essayez avec cat par exemple.

Purée, il y avait déjà des touches Like et Dislike à droite du clavier :)

Bonjour,

Ce n'est pas forcément très compliqué mais, comme dit ci-dessus, c'est un peu surdimensionné pour tes besoins et surtout, ça demande de mettre en place toute l'infrastructure sous-jacente, c'est-à-dire s'assurer d'avoir une liaison permanente à Internet, prévoir les backups et l'alimentation électrique (qui revient cher quand on la rapporte à une année) et administrer le serveur proprement dit au quotidien (ou presque).

Donc, beaucoup de boulot pour pas grand chose si ce n'est pas par volonté personnelle. Et le problème serait identique avec n'importe quel autre système (à commencer par Windows).

A contrario, si c'est pour toi un bon prétexte pour pratiquer le système et te lancer dans l'administration Linux, tu peux jeter un œil à GNU Mailman ou à Sympa.

On voit souvent aussi le (vieux) Majordomo, mais il semblerait qu'il ne soit pas libre et je n'arrive pas à trouver sa licence.

Et s’il invoquait Belzébuth ?

Rien que pour ça, je suis sûr que plein de gens serait prêts à l'adopter. :-)

Stoppez les rotatives ! dark_star aime s'occuper quand il s'ennuie en regardant l'intensité consommée chez lui, des fois qu'un truc ait décidé subitement de tirer 10A alors qu'avant c'était 100mA.

Et bien ça, tu vois, tu devrais le faire de temps en temps. Je me suis aperçu un jour, comme ça, qu'après le passage d'électriciens dans un appartement dans lequel je venais d'emménager, j'avais une consommation en continu de 8 ampères. Ces branques avaient bypassé le contacteur jour-nuit de mon ballon d'eau chaude de 1800 W, qui fonctionnait alors 24h/24.

Après m'être plaint et avoir reçu un coup de fil de l'entreprise concernée, resté depuis sans suite, j'ai fini par refaire le câblage moi-même.

Bonjour et bienvenue,

1) Impossible à dire de manière universelle : ça dépend du snapshot, qui va par nature remettre en place le système tel qu'il a été installé par le précédent stagiaire.

2) Oui, c'est possible. J'ose tout de même espérer que si la machine « s'éteint pour une raison ou un autre », alors son comportement lorsque tu la rallumeras sera le même que la première fois que tu l'as mise en service.

Malgré cela, avec Linux comme avec tous les autres systèmes, pour réinitialiser un mot de passe root, on accède au disque et/ou à la partition qui recèle les comptes utilisateurs depuis UN AUTRE système fonctionnel, qui lui exploite ce disque comme un volume ordinaire et peut donc le modifier à loisir.

Il arrive assez fréquemment qu'on trimballe une distribution de Linux en LiveCD (ex: Knoppix) pour aller dépanner une machine Windows, par exemple.

Blague à part, merci à tous parce qu'il serait vraiment important de faire un papier solide sur cette version. Linus indique que c'est la plus grosse release qui soit après la 4.9, et la 4.9 l'est en partie parce que c'est une LTS.

J'ai pris l'initiative d'entamer la dépêche juste après la rc2, il y a un mois et demi, pour éviter de faire comme avec la dépêche du 4.10 publiée exactement le jour de la sortie du 4.11, et parce qu'apparemment, ça manquait de traducteurs. D'habitude, je me contente de traduire les annonces des RC parce qu'elles restent souvent en plan (et que parfois, on y lit des âneries). Mais là, ça va faire deux mois et on n'a pas encore une ligne sur le contenu proprement dit.

Pourtant il y a beaucoup à en dire : l'AMD Vega, l'intel IPU l'annonce sur les diff générés automatiquement par kernel.org et qui ne seront plus signés de la clé de Linus, le pilote de l'Image Processing Unit des Intel Atom, etc et les gros headers splités dans la dernière version du noyau (qui empêchent entre autre le pilote proprio nVidia de compiler).

dd (Disk Dub) a quand même plusieurs utilités. Sa fonction principale (et originelle) sert bien à dupliquer des disques, mais il propose bien plus d'options que le simple bs.

Si spécifier la taille d'un bloc paraît inutile, c'est justement parce que cela fait double emploi avec la couche « périphérique bloc » du système d'exploitation, qui est censée lisser tout cela et nous permettre d'y accéder comme à un flux ordinaire. Par contre, quand on utilisait des raw devices, il était nécessaire de faire des accès atomiques de la taille d'un secteur et, par conséquent, alignés sur eux (pas question de copier deux demi-secteurs consécutifs, par exemple). Et là, il est quasiment impossible de manipuler sérieusement un volume sans recourir à ce genre d'outils.

En outre, dd propose ibs et obs qui permettent de spécifier une taille de bloc différente en entrée et en sortie. Utile pour le genre de périphérique, ou pour balancer des données à travers des sockets qui exigent des trames de taille fixe.

Dernier point mais non des moindres : il existe l'option noerror qui permet de continuer le traitement même en cas d'erreurs de lecture qui, sur un disque, correspondraient à des secteurs défectueux. C'est quand même un gros avantage sur cp qui, par ailleurs, n'est pas fait pour être interrompu. dd a le bon goût d'indiquer où il en est quand on le stoppe prématurément.

Du coup, il vaut mieux ne pas spécifier comme taille de bloc celle du volume entier car, à la moindre erreur, c'est justement le reste « du volume entier » qui est passé ou rempli avec des zéros. En ce sens, il est plus intéressant de choisir comme taille de bloc celle d'un secteur ou d'un bloc du système de fichier (généralement 4096 octets) et ensuite de la multiplier par un certain facteur pour profiter de la RAM disponible et limiter les appels système, mais en restant raisonnable pour les raisons évoquées. Un bloc de la taille d'une piste est généralement un bon compromis.

Au contraire, chez moi, ça fait bien longtemps que ça marche et que je n'ai plus eu à avoir recours à un câble croisé. En fait, il suffit qu'un seul des points de terminaison soit capable de se « retourner ». Et généralement, à moins d'avoir un produit d'entrée de gamme, les puces Ethernet des cartes-mères sont capables de le faire seul.

Absolument.
Un propos diffamatoire et faux est une « calmonie ».

Si, effectivement. Je ne connaissais pas la variable $BASH_COMMAND.

Tu peux décomposer le contenu de cette variable en un tableau et vérifier si l'un des éléments est une étoile seule (ou à la limite une suite d'étoiles, exclusivement).

Est-ce qu'il n'y a pas une astuce pour demander confirmation lorsque l'on tape par erreur "rm *" ?

Sous bash, la pratique habituelle (et généralement configurée par les distributions elles-mêmes) consiste à définir un alias avec alias rm=rm -i puis à utiliser « rm -f fichiers » quand on « sait ce que l'on fait ».

Une autre astuce consiste à déclarer « rm » (ou n'importe quoi d'autre) comme une fonction sous Bash pour pouvoir contrôler son comportement plus finement en fonction des paramètres, avant de rappeler l'exécutable original.

Il n'y a malheureusement pas d'option pour vérifier si on tape « * » en particulier car ce caractère est développé par le shell lui-même en la liste des fichiers du répertoire courant, et ce AVANT d'appeler l'exécutable ou la fonction. Ceux-ci n'ont alors aucun moyen de savoir si c'est un caractère joker qui a généré cette liste ou si l'utilisateur les a tous spécifiés expressément.

s/pas/plus/

Ça a existé il y a longtemps…

Bonjour,

la connexion met plusieurs minutes à s'établir (auparavant c'était moins de 10 secondes environ).

Ça, c'est généralement caractéristique d'un timeout. Ton logiciel doit chercher à se connecter à un serveur tiers qui, lui, ne doit plus répondre depuis le début de la panne et il faut attendre le délai de grâce avant que le logiciel décide d'abandonner et de passer à la solution de secours, qui peut être soit un serveur secondaire, soit des informations conservées en cache.

Ça arrive également quand c'est le DNS qui ne répond plus : toutes les connexions directement basées sur les adresses des hôtes à atteindre fonctionnent mais tout ce qui utilise un nom de domaine se met à rester plusieurs minutes en attente. Et comme cela peut être transparent pour l'utilisateur ou se trouver à un niveau très bas, il peut être parfois assez difficile d'identifier la source du problème.

Ça peut enfin se produire même si le serveur ne répondait déjà plus mais retournait quand même un refus de connexion explicite. S'il se décide à faire la carpe à la place, soit parce qu'il a réellement été éteint ou mis hors ligne, soit parce qu'un firewall trop zélé a décidé de filtrer l'ICMP, ça peut aussi engendrer les mêmes effets du jour au lendemain.

le mot de passe m'est systématiquement demandé (alors que je l'avais précédemment enregistré) et même si je l'enregistre pour toujours.

Possible qu'il s'agisse de la même cause. Si le serveur n'est plus le même, le certificat ne sera plus valide non plus.

Une autre chose qu'il m'est arrivé, notamment avec Evolution : lorsque le serveur retournait un « Internal Error » lors d'une connexion, le logiciel ne comprenait pas le code d'erreur. Il retombait donc sur le comportement « Connexion Refusée » standard et côté interface utilisateur, il me redemandait mon mot de passe en boucle, et ce pour chacune des boîtes situées sur le même serveur. :-\

bref j'ai l'impression qu'un bon vieux disque dur était soit en panne soit en fonctionnement mais pas entre les deux

Il va falloir s'y faire : c'est un disque dur quantique ! :-)

N'hésite pas à poser tes questions ici dans programmation.autre, par exemple. Histoire de mettre facilement le pied à l'étrier (par exemple : voir d'emblée ce qu'est l'index/staging area).

Autre technique intéressante : rapatrier avec Git un projet d'envergure déjà existant (le noyau Linux en étant bien sûr l'archétype, mais on peut faire moins gros), non pas pour y travailler, mais pour se faire la main en conditions réelles. C'est plus facile de voir à quoi servent les branches, les reflogs et toutes les fonctionnalités qui ont émaillé l'outil au fil du temps en explorant un dépôt bien fourni qu'en faisant des cas d'école sur un répertoire qui ne contient qu'une demi-douzaine de commits.

Enfin, n'hésite pas à choisir un client pour Git. Personnellement, j'utilise « tig » mais il en existe pléthore. C'est plus facile de se balader dans un dépôt avec ce genre d'outil qu'en utilisant simplement git log --graph

Bon courage.

Salut,

Tu as l'air d'avoir bien résumé la situation toi-même et d'avoir une vision assez précise de la chose. Il serait dommage de ne pas en profiter pour franchir le pas et approfondir le tout, en effet…

Que me conseillez-vous pour partager mes projets? Dois-je me mettre à Git? Avez-vous d'autres solutions?

Je dirais plutôt que, vu la situation, c'est « une bonne occasion de se mettre à Git ».

Plus précisément, Git est aujourd'hui aussi populaire que répandu, mais il rebute parfois un peu les néophytes comme les habitués d'autres SCM. Une fois qu'on a compris le principe général, le tout devient somme toutes assez simple mais le mieux reste quand même de se le faire expliquer par quelqu'un qui connaît bien l'outil lorsque l'on fait ses premiers pas. Après, on peut pratiquement tout utiliser sans difficulté notoire.

Sache aussi qu'il est très intéressant d'utiliser un logiciel de versioning même lorsque l'on travaille seul (et pas simplement pour le code). Ça permet de conserver automatiquement la trace des différentes versions de ce que l'on écrit sans se soucier de les classer explicitement, ça permet de revenir facilement en arrière, ça permet de forker quand on veut démarrer un nouveau projet similaire à un autre et, in fine, ça permet de partager automatiquement son travail une fois que l'on a atteint un stade intéressant pour son entourage.

C'est aussi très intéressant pour conserver un code toujours propre : en général, il est facile d'ajouter des lignes de code à un fichier existant mais il est plus difficile de prendre la décision de supprimer des blocs lorsqu'ils ont demandé du travail pour être mis au point. En général, ils finissent en commentaires jusqu'à ce qu'ils soient suffisamment vieux pour être effacés… à condition qu'on ait pensé à écrire la date dans le commentaire en question. S'appuyer sur un SCM quand on développe permet d'effacer immédiatement ce qui ne sert à rien car non seulement rien n'est définitivement perdu, mais parce qu'il est très facile de les retrouver et même les mettre en évidence à l'aide d'un diff entre deux révisions.

Et si malgré ça rien ne te séduit, tu peux quand même faire un « git init » dans ton répertoire de travail, ajouter tout ton travail dans un seul gros commit initial sans rien d'autre, et t'en servir pour le partager sur une forge officielle.

Ça me permet de me rendre compte que j'avais manqué celui-ci :

C'est une bonne nouvelle !

Mais question volontairement naïve : le registrar n'envoie pas un mail pour prévenir d'une expiration ? Surtout au bout de cinq ans…

Bonjour,

GRUB est le « loader » qui te permet de lancer soit ton système Linux dans différents mode ou en choisissant ton noyau, soit de lancer d'autres systèmes d'exploitation. Mais en principe, il est aujourd'hui configuré pour présenter un menu explicite. Si tu vois uniquement la ligne de commande, c'est que soit ta distribution est minimaliste, soit l'installation n'a pas pu aller jusqu'à son terme.

Essaie d'appuyer simplement sur « Entrée » quand tu vois ce message, pour voir s'il démarre normalement.

Bonjour,

Ce que tu décris n'a rien à voir avec chroot en particulier : tu peux monter les partitions de n'importe quel disque dur depuis un système opérationnel, fût-ce un Live CD, sans avoir à recourir à chroot en particulier. Et le plus beau : tu peux très bien monter les partitions d'un Windows quelconque depuis un système Linux, Live CD ou non, et les modifier à loisir. Et pas seulement les fichiers des utilisateurs : tu peux modifier le système, la base de registres, etc. voir réinstaller un système entier si ça te chante. En principe, c'est vrai dans l'autre sens aussi, à ceci près que Windows n'est généralement pas fait pour et ne propose pas d'outil a priori pour le faire. Il faut s'équiper.

C'est donc tout-à-fait normal en soi et heureusement qu'on peut le faire, car c'est également de cette façon qu'on dépanne les systèmes qui ne démarrent plus.

Par ailleurs, un disque dur est un support de stockage. Ce n'est pas un coffre-fort. Il n'a donc pas vocation à dissimuler son contenu a priori non plus. Au contraire, il doit en garantir l'accessibilité, la disponibilité et l'intégrité pendant toute sa durée de vie (laquelle devrait être théoriquement infinie car les particuliers établissent rarement des plans de migration).

Si tu veux protéger tes données, il faut mettre en place un dispositif de sécurité explicite et identifié à l'avance : soit tu mets physiquement un cadenas sur le boîtier de ta machine et tu paramètres ton BIOS/UEFI pour ne pas démarrer par défaut sur les lecteurs externes (certains boîtiers sont spécialement équipés pour qu'on puisse le faire), soit tu utilises un fichier ou une partition chiffrée pour y déposer les informations réellement confidentielles (voir https://linuxfr.org/forums/linux-general/posts/chiffrer-disque-avec-cles-de-chiffrement-stockee-sur-peripherique-amovible ).

L'objectif serait de pouvoir traduire les textes de lois en programmes écrit avec ce langage.

Pas bête. On appellerait ça une compilation !
On pourrait se baser sur le XML comme méta-langage et utiliser XSLT pour faire des transpositions en droit européen. :-)

Il serai possible de faire des simulations en envoyant des paramètres en entrée dans une loi et voir ce qui en sort.

Ce qui serait surtout génial, c'est de pouvoir faire des sandboxes, pour que nos chers politiques puissent s'amuser à loisir sans que ce soit automatiquement au dépens de la population…

L'idée m'est venue lorsque j'ai tenté de déchiffrer la loi sur les copropriétés pour savoir ce que j'avais le droit de faire sans passer par un avocat spécialiste.
Avec la transcription des lois en programme on pourrai faire des espèces de test unitaire pour vérifier qu'une loi n'en casse pas une autre.
Les modifications d'une loi précédente deviendrai des patch.

Ça, plus sérieusement, ça a commencé à se faire ici : « le code civil sur Github » et on parlait ici aussi.

Sur le premier lien, même si le projet est encore incomplet, il est intéressant de constater à quel point des siècles de révision de la loi et de maintien monacal de ses textes pourrait se comparer à un projet communautaire de relativement petite envergure comme il en existe des milliers sur les forges actuelles.

Je pense qu'aujourd'hui, le versioning pourrait facilement être étendu à tous les secteurs d'activité, pour devenir une méthode de travail générale « issue du monde du développement logiciel ». Au niveau managérial, c'est à prendre en compte en parallèle de la démocratisation du télé-travail, par exemple.

Je viens de contribuer (anonymement) à ce questionnaire et cela m'évoque un point qui appelle une petite remarque. On peut lire notamment, à plusieurs reprises :

Quels types de contact aviez-vous avec les autres participants du projet ?
- Mail
- Forum
- Chat
- Appels téléphoniques ou vidéo
- Contact direct
- Autre

Si historiquement c'est bien le mail qui a été le principal vecteur de l'effort de développement, il faut absolument prendre en compte aujourd'hui l'impact des logiciels de versioning et des hébergeurs de projets comme Github, qui à eux-deux permettent de prendre automatiquement en charge tout l'aspect « logistique » de la chose.

Je pense qu'aujourd'hui, il n'est pas exagéré de dire que ce type d'outil représente à lui seul autant d'activité que le reste des technologies présentées ici réunies.

Sur les projets publics, c'est à la fois le moyen le plus rapide d'obtenir et d'installer tout l'état de l'art concernant un projet en particulier, jusqu'à ses modifications les plus récentes, et c'est aussi la façon la plus certaine de retrouver le projet officiel puisque non seulement le développeur en charge du projet utilise les mêmes outils pour ses propres moyens, mais va aussi les partager par cette même voie.

Ça n'a l'air de rien mais lorsqu'un projet ne s'appuie pas dessus, la personne qui souhaite s'impliquer doit généralement retrouver le site web officiel du projet, s'assurer que c'est le bon, vérifier les dates de dernières mises à jour du contenu du site, récupérer la dernière « nightly build » ou package de développement officiel, puis récupérer les derniers patches en date sur la mailing list et les appliquer lui-même.

À l'usage, le dernier patch que j'ai envoyé et qui a donné lieu à une vraie modification l'a été sur le bugtracker du dépôt Github d'une des bibliothèques de ma distribution. Non seulement le bug tracker envoie automatiquement un mail aux personnes concernées (et/ou intéressées), mais on est également à peu près sûr que si le projet est actif, alors les développeurs le verront puisque leur espace de travail est au même endroit. En comparaison, j'avais déjà fait des bugs reports sur un bugzilla d'un projet GNOME et ils sont toujours restés lettres mortes.

Dans le même esprit, fin des années 1990, j'avais entrepris de désassembler et commenter les ROMs de mon vieux huit bit sur lequel j'avais fait mes premières armes. Cela avait beaucoup intéressé un autre développeur du même cercle, qui avait fini par faire la même chose dans son coin. Dans la première partie des années 2000, on en était encore à s'envoyer des disquettes par la poste, très occasionnellement, et qui ont fini par se perdre ou s'abîmer. Lui-même avait perdu une bonne partie de son travail à un moment, il m'avait même demandé si j'avais, moi, conservé son travail. Je n'en ai retrouvé que quelques bribes.

On a fini par laisser tomber la chose pendant près d'une dizaine d'années. Et plus récemment, un certain regain d'intérêt de la part de la communauté l'a remise au devant de la scène et comme le développeur en question s'était mis à Mercurial de son côté, j'ai fini par ouvrir un dépôt Atlassian pour les partager facilement (l'avantage supplémentaire étant que ce site permettait aussi de conserver le projet confidentiel, ce qui était nécessaire parce que les ROMs en question n'étaient pas libres à la base).

Ce qui est intéressant dans cette dernière anecdote, c'est que non seulement ce genre de structure est un formidable accélérateur pour les projets libres et/ou collaboratifs, mais que l'on constate que leur seule disponibilité est susceptible de revigorer des projets considérés comme morts depuis longtemps. On a coutume de dire que le libre s'est en majeure partie appuyé sur l'explosion du mail et de l'Internet grand public, ce qui est vraisemblable. Je pense que ces outils ont provoqué une deuxième révolution, probablement aussi importante.

Du coup, si c'est l'objet de ton étude, il serait intéressant de se pencher dessus en particulier, et de voir comment ils sont susceptibles de transformer le travail de bureau en général, spécialement à une heure ou le télé-travail est de plus en plus mis en avant.

N'hésite pas à venir redemander de l'aide si tu n'y arrives pas.

Mais d'ici là, essaie de faire « git log --patch » sur ta propre branche avant de la pousser. Cela te permettra de voir clairement quels sont les changements enregistrés par git et qui seront donc appliqués tels quels par le dépôt sur lequel tu les enverras ou qui décidera de les rapatrier lui-même.

Bonjour,

1 - encore une fois on ne merge pas les contenus des fichiers
2 - on s'arrange lui et moi pour ne pas avoir de conflit dans les noms de nos fichiers (chacun des fichiers est prefixé par nos initiales).

Dans ce cas, c'est bel et bien un merge ordinaire. Il n'y aura jamais de fusion de fichiers imposée si vous vous arrangez déjà pour ne jamais travailler sur les mêmes (et si pour une raison ou une autre, tu t'y retrouvais confronté quand même, c'est qu'il se serait passé quelque chose en amont qui nécessiterait une décision de ta part pour être résolue).

Donc, tu fais tes modifs de ton côté, tu les commites en local avec « git commit », tu pousses tes propres modifs avec « git push » et tu récupères celles de ton collègue avec « git pull ». C'est la manière habituelle de travailler.

Il faut savoir qu'avec Git, comme avec d'autres logiciels de versioning, un « git pull » est équivalent à un « git fetch » suivi d'un « git merge » de la branche distante avec son homologue locale. Une branche est formée par la lignée de ses commits successifs, chacun faisant référence au précédent, et chaque commit décrit les changements apportés à la branche par rapport à l'état précédent.

C'est donc bien l'idée : si ton collègue travaille sur des fichiers A, B et C et que tu travailles sur des fichiers X, Y, et Z, alors son commit décrira quelque chose comme « +A; +B; +C; » et le tien « +X; +Y; +Z ». Fusionner les branches importera ses propres commits dans ton dépôt, ce qui y appliquera ses modifications, dont les effets concerneront des fichiers indépendants de ceux sur lesquels tu travailles.

En résumé : tu peux très bien fusionner une branche sans avoir à fusionner de fichiers.