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.
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.
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.
Ça veut bien dire que tu veux synchroniser les branches et obtenir — dans ton dépôt — les fichiers de ton collègue et vice-versa, n'est-ce pas ? Dans ce cas, il s'agit d'un merge ordinaire.
Plus précisément, ici, tu vas d'abord faire un « commit » en local, et git verra que les seuls changements apportés à ton dépôt par rapport à l'état précédent est l'ajout de tes deux fichiers « Mon_Fichier1 et 2 ». Et c'est exactement cela qui sera enregistré dans le commit. Quand tu vas faire « git push » ensuite, c'est ce commit-là qui sera envoyé et qui appliquera les mêmes changements au dépôt distant. Donc, même si ton collège fait la même chose de son côté avec les siens, vous vous retrouverez avec la somme des deux changements et aucun de vous n'aura marché sur les pieds de l'autre.
Sinon, prend le problème à l'envers :
– Soit tu veux récupérer uniquement les « noms » de fichiers à leur place dans le dépôt, sur le FS. Dans ce cas, que doit-il se passer si tu en ouvres un ?
— Soit tu veux justement récupérer le contenu de la branche « distante » puisque ces fichiers appartiennent à ton collègue → merge ordinaire, là aussi ;
— Si tu veux simplement afficher les fichiers de ton collègue, que doit-il se passer si celui-ci a eu la bonne idée de créer chez lui un fichier qui existait déjà chez toi sous le même nom ? La question n'est pas anodine car elle va nous permettre de savoir ce que tu as réellement en tête et, de là, t'orienter correctement. Peut-être même est-ce pour cela que tu as cette idée : justement pour savoir si un nom de fichier est libre ou déjà réservé…
— Vous souhaitez travailler chacun de votre côté et exporter à la fin uniquement les choses qui vous intéressent vers un dépôt commun officiel qui, lui, doit être synchrone : voir la solution de NeoX ;
— Tu souhaites avoir une « vue » sur le dépôt de ton collègue (et réciproquement) sans avoir à l'importer directement au sein du tien ? C'est le principe de la branche « remote ». Celle-ci est répliquée en local quand tu fais « git fetch » (et notamment, tous les objets associés sont rappatriés) mais reste distincte, et reflète l'état de la branche distante même si celle-ci est reconstruite. Tu peux ensuite y associer une vraie branche locale sur laquelle tu peux éventuellement travailler et fusionner l'avancée de la branche distante. C'est le cas de « master » (local) et « origin/master » (remote) quand tu utilises le modèle par défaut. Si tu veux jeter un œil à ce qui se passe à côté, tu peux faire un checkout sur la branche remote et revenir ensuite sur la tienne.
La clés privée est-elle dans un format lisible (permettant par exemple de l'exporter sur un support non informatique)?
Ça dépend de la méthode de chiffrage que tu as choisie. Si c'est un système s'appuyant sur une passphrase, alors il suffit d'écrire cette passphrase telle quelle dans le fichier concerné.
Aurais-tu une estimation de l'impact sur les ressources machine?
Aucune idée, parce que je n'utilise pratiquement pas les partitions chiffrées. En fait, j'ai créé quelques fichiers ordinaires de quelques méga-octets que je monte en loopback lorsque j'en ai besoin et qui sont ensuite exploités comme des volumes habituels. Ils me servent à contenir les quelques informations réellement confidentielles comme des listes de mots de passe. Je les monte et démonte sur demande à l'aide d'un script lorsque j'ai besoin de les consulter.
Si tu sais à quel endroit est déjà monté ton périphérique amovible, alors une simple ligne de commande du style :
[ -e /répertoiredetaclé/tonfichier ] && cryptsetup --key-file /répertoiredetaclé/tonfichier open /dev/tapartition MonVolume && mount /dev/mapper/MonVolume /monpointdemontage
… devrait suffire. Après, il te suffit de l'ajouter aux scripts de démarrage gérés par init ou systemd selon ta distribution (et son âge). Tu peux également demander à udev ou systemd (là encore, selon la distrib et son âge) de définir un événement correspondant à l'insertion de la clé sur lequel le script sera appelé, après montage de la clé.
Par contre, les volumes ne seront pas automatiquement démontés si tu retires la clé après les avoir montés. Tu peux demander à le faire faire de la même façon mais si un processus quelconque (par exemple un shell) est au même moment dans un des répertoires de ta partition chiffrée, le démontage échouera.
Je ne sais pas s'il « existe un logiciel » tout fait et dédié à cette tâche en particulier mais, à mon avis, si tu utilises cryptsetup ou une solution similaire, tu dois pouvoir t'en sortir avec un simple script. Le problème est que si tu veux que ta partition soit montée au boot, ton périphérique amovible doit être présent dès ce moment et à chaque démarrage. De fait, ça en fait un périphérique un peu moins amovible.
Quel comportement souhaites-tu obtenir ? Est-ce que tu veux déverrouiller automatiquement tes partitions dès lors que tu introduis un dongle une ou clé USB spéciale dans l'emplacement idoine ?
Hello,
En fait, c'est un peu comme emménager dans une maison vide : il y a beaucoup de place mais celle-ci va très vite être exploitée.
Tu n'as pas besoin d'autant de places pour démarrer mais, très vite, tu vas devoir d'une part installer tous les logiciels qui t'intéressent et, d'autre part, te laisser de la place pour ton propre dossier personnel « home ». Enfin, le système lui-même doit avoir suffisamment de place pour travailler (création des logs, des différents fichiers temporaires, etc).
L'avantage est que les logiciels que tu vas rapatrier sous Linux sont libres, qu'ils sont donc proposés par défaut sur les serveurs de la distribution que tu utilises et qu'à tout moment, tu peux demander à faire installer le logiciel dont tu as besoin à l'aide d'une simple commande (« apt-get » sur les systèmes basés sur Debian, « yum » ou « dnf » sur les RedHat/CentOS/Fedora, etc). Le produit est installé en quelques secondes sans que tu aies, généralement, à rebooter ou à faire quoi que ce soit d'autres. Certaines lignes de commandes te proposent même d'installer directement le package adéquat si tu appelé une commande inconnue sur ton système mais qui correspond à un package recensé.
Il est toujours un peu délicat d'estimer correctement la place à allouer à chaque partition quand on refait un PC depuis zéro, mais si tu le réinstalles effectivement depuis le départ et que tu disposes d'un disque dur assez large, alors ce n'est pas la peine de se restreindre a priori.
man signifie « manuel » et sert à afficher la page de manuel de la commande qui t'intéresse. Y recourir doit devenir un réflexe et c'est souvent vers elle qu'on te renverra en premier lieu chaque fois que tu demanderas de l'aide. Indice : on sort de la page concernée en appuyant sur « Q » (toujours bon à savoir la première fois).
Essaie man mkdir, par exemple.
et cat je ne compte pas lutiliser, je lai juste appris cette aprem, alors cest sortis tout seul
cat, tu l'utiliseras tout le temps. :-) Et probablement à tort, comme tout le monde. « cat » signifie catenate et sert à concaténer sur la sortie standard le contenu de tous les fichiers dont tu auras précisé le nom, successivement et dans l'ordre. C'est utile en soi, mais comme le résultat est envoyé sur la sortie standard, laquelle est elle-même renvoyée vers l'écran à défaut d'instructions contraires, alors ça devient utile pour visualiser facilement le contenu d'un fichier, même si tu n'en spécifies qu'un seul. En ce sens, ça rend le même service que la commande « type » sous DOS.
Les UUOC dont on te parle dans les autres commentaires viennent du fait qu'il est tentant de se servir de cette commande pour afficher le contenu du fichier puis le rediriger vers une autre commande à l'aide d'un pipe « | », alors que les opérateurs de redirection « < » et « > » servent précisément à cela, et qu'il est bon de prendre l'habitude de les utiliser directement, plutôt qu'instancier un processus qui, effectivement, n'était pas nécessaire.
t jai bosser la fonction ln mais javoue ne pas vraiment avoir compri lutiliter davoir deux fichier liee , je comprend pas le but du concept
C'est très pratique quand plusieurs fichiers doivent avoir le même contenu, ou qu'un même fichier doit porter plusieurs noms. Il faut se souvenir qu'UNIX a été d'emblée un système multi-utilisateurs et que jusqu'à une époque pas très lointaine (jusqu'à la fin des années 90, en gros), l'espace disque était limité et précieux.
Quand tu crées un lien dur (ln tout seul), tu donnes en fait plusieurs noms au même fichier. Quand tu édites ce fichier, tu vois tes modifications quelque soit le nom sous lequel tu l'ouvres ensuite et (surtout) il n'y a qu'un seul exemplaire des données sur le disque. Tous les noms renvoient vers le même endroit physique. Une fois déclarés, tous les liens sont semblables. Il n'y a pas de moyen de savoir a posteriori si une entrée est le nom original d'un fichier ou s'il s'agit d'un lien dur.
Le système conserve le nombre de liens durs référençant un même fichier (dans l'inode). Chaque fois que tu effaces un fichier, ce nombre est décrémenté et ce n'est que lorsqu'il arrive à zéro (donc quand plus aucun lien ne référence le fichier) que l'espace disque qu'il occupe est réellement libéré.
C'est utile si, par exemple, tu souhaites mettre par défaut un fichier en lecture seule dans le répertoire de tous les utilisateurs de ton système. Cela évite de consommer de l'espace inutilement avec des copies et laisse malgré tout la latitude à chacun de l'effacer quand ça lui chante. Lorsque tous les utilisateurs ont effacé leur propre « copie », l'espace disque est libéré.
C'est très pratique également si tu veux faire apparaître un même fichier à différents endroits d'une même partition, lorsque les processus qui doivent y accéder ne peuvent se promener librement sur la totalité de l'arborescence, soit à cause de droits d'accès en vigueur, soit lorsque tu utilises chroot.
Les liens symboliques, à présent, sont des fichiers distincts qui ne contiennent qu'une simple chaîne de caractères, qui correspond au chemin d'accès au fichier original. En ce sens, ils ressemblent un peu aux raccourcis *.lnk mais ils ne contiennent aucune autre information et surtout, ils sont gérés directement au niveau du système de fichiers par l'OS, si bien que n'importe quel programme faisant un open sur un lien symbolique ouvrira en fait le fichier pointé et pas le lien symbolique lui-même, de façon complètement transparente et ce même si le programme n'est pas explicitement prévu pour.
C'est utile pour toutes sortes d'applications : pour créer des alias, mais également pour être automatiquement redirigé vers le fichier à utiliser à un moment donné (lequel peut changer), etc. On les utilise notamment dans /lib et /usr/lib pour rediriger une version d'une bibliothèque vers la bonne sous-version.
Les liens durs et les liens symboliques ont chacun leurs avantages et leurs inconvénients, mais une chose est certaine : quand on y a goûté, on n'a plus envie de revenir en arrière. Ceci est également vrai pour Unix en général, et pour les logiciels libres de façon plus globale encore. :-)
Pas spécialement un lien symbolique : ln sert d'abord à créer un lien dur, ce qui a d'ailleurs longtemps été la norme avant même l'existence des liens symboliques. On en retrouve une trace dans la man page de ln :
CONFORMITÉ
POSIX.2. Toutefois, POSIX.2 (1996) ne parle pas des liens symboliques. Ceux-ci ont été introduits par BSD, et n'existent pas dans Système V release 3 et antérieurs.
Aujourd'hui, ils tombent un peu en désuétude et mériteraient justement d'être ré-enseignés proprement. Je pense que c'est précisément parce qu'ils n'existent pas sous Dos/Windows mais qu'a contrario, les raccourcis Windows ressemblent de loin aux liens symboliques que les gens ont fini par prendre l'habitude de n'utiliser que ceux-là.
Il ne faudra pas s’attendre toutefois à ce que la parité fonctionnelle soit complètement respectée. Certains points cruciaux ne seront pas gérés, notamment les DRM pour la diffusion des contenus multimédias, et surtout la prise en charge des GPU pour les calculs 3D.
Sinon, pour le reste, j'en pense la même chose qu'à peu près tout le monde. Le fait d'avoir « activé sur demande » le plug-in me permet de mesurer combien sont rares les fois où j'en ai réellement besoin (surtout quand les pages qui le réclament ne le font que pour diffuser de la pub). Mais si elles sont rares, elles ne sont pas totalement inexistantes : certains sites (notamment des sites d'informations) persistent à diffuser leur vidéos en Flash et, bien sûr, je suis attaché à un certain nombre de jeux Flash assez bien réalisés qu'il serait dommage de ne pas pouvoir émuler d'une manière ou d'une autre.
Comme son nom l'indique, « touch » sert à « toucher au fichier ».
Autrement dit, cela sert à obtenir le même comportement qu'en faisant un « open » dessus, à l'exclusion de toute autre opération associée. Donc, formellement, ça crée le fichier s'il n'existe pas et ça met à jour les timestamps dans tous les cas.
Par défaut, la valeur des nouveaux timestamps correspondent à l'heure courant mais il est possible de passer une option pour antidater un fichier (ou le dater dans le futur), parce qu'il aurait été idiot de définir une autre commande rien que pour ce cas.
Si tu utilises « > fichier » à la place, non seulement ça ne marchera pas en zsh mais en plus ça tronquera ton fichier s'il existe déjà (= le videra entièrement).
une de mes connaissances utilise un système embarqué maison pour faire de la domotique. Son problème est que de temps en temps son système ne communique plus avec UN équipement
Avez-vous une idée de ce qui pourrait résister à un reboot mais pas à un down puis up ? Car là je bloque.
À vue de nez un conflit d'adresse. Deux machines doivent partager la même adresse à un moment donné. Ça arrive de temps en temps quand tout un réseau est fait pour utiliser le DHCP mais que l'on a oublié qu'une machine a été configurée dans son coin avec une adresse statique…
ou sinon justifier un peu pourquoi ton choix s'est porté vers cette distribution…
Avec un peu de recherche, on tombe sur ça : http://www.linuxmao.org/AV+Linux
Donc, c'est une distribution de Linux orientée musique et ça justifie donc pleinement son choix.
Maintenant, ça n'explique pas pourquoi « ses comptes ne sont plus reconnus systématiquement ».
La seule fois où ça m'est arrivé avec une machine aux comptes locaux (pas de LDAP ou assimilé) était sous Fedora 20 avec une Gnomerie/Lennarterie/Freedesktoperie : GDM perdait sa connexion avec DBus pour une raisons inconnue et c'était par ce biais qu'il authentifiait les utilisateurs, même quand la session était ouverte, mais l'écran verrouillé. Et comme toutes les touches de contrôles (Ctrl-Alt-F1, Ctrl-Alt-Backspace) étaient désactivées « pour le bien de l'utilisateur » (y compris SysRq), il n'y avait aucun moyen de s'en sortir. La seule façon que j'ai trouvée pour ne pas perdre les données qu'il y avait derrière était de faire un ssh depuis une machine tierce et d'envoyer dbus-send --print-reply --type=method_call --system --dest=org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager.UnlockSessions
Par contre, il est clair que ce cas de figure est exceptionnel, expérimental, et purement inadmissible. Mais surtout, en tout état de cause, ça revient au redémarrage. Il n'y a aucune raison d'avoir à réinstaller.
Pouvez vous m'aider SVP car je pense que je vais revenir a windows,que l'on dit instable et merdique mais qui demarre toujours …lui !!
« Démarre toujours » ? Tu t'emportes un peu là ! En presque 20 ans, je n'ai JAMAIS eu à réinstaller un Linux à cause d'une panne. Pas une fois. Il y a bien eu quelques dysfonctionnements occasionnels mais rien que je n'aie pu réparer. J'aimerais pouvoir en dire autant de Windows. Et même quand Windows démarre, on sait à quel point il peut devenir inutilisable au bout d'un certain temps lui aussi.
On peut t'aider mais il nous faut plus de détails : nous ne sommes pas derrière ton écran pour voir ce que tu vois.
Perso, soit il n'existe pas et il faut qu'on se débrouille seuls, soit il existe et il mérite juste une condamnation pour non assistance à personnes en danger.
S'il revient, il va surtout nous dire : « alors je peux pas vous laisser seuls deux petits millénaires sans que vous vous foutiez sur la gueule, bande de petits salopards ? » :-)
Un grand merci, à mon tour (et un peu tard), pour ce journal de qualité qui me révèle l'étendue de mon ignorance dans le domaine alors même que j'utilise des logiciels de versioning comme tout le monde et de longue date (en ayant commencé avec CVS).
Cela dit :
Reste un petit goût amer, comment un produit si efficace peut-il avoir une interface en ligne de commande aussi inconsistante, imprévisible sans qu'on l'ait remis à plat ?
Vous aussi, ça vous défrise de faire git checkout sur un nom de branche pour l'activer ?
Vous aussi, vous vous demandez pourquoi il faut faire un git checkout -b pour créer une branche et un git branch -d pour la supprimer ?
Pas vraiment puisqu'en réalité, ce ne sont pas les commandes officielles pour faire cela mais des raccourcis bien pratiques. Et si tout le monde les prend en exemple, c'est bien parce que les développeurs les utilisent et qu'ils ont une raison d'être.
L'interface de Git, c'est un peu comme le jeu « Pyramide ». Personne ne comprend de quoi il s'agit, jusqu'au moment où on explique qu'il s'agit simplement de trouver des mots en rapport avec d'autres dans un contexte donné (celui-là même qui manque en général). Du coup, les commandes servent chacune à gérer un thème en particulier, et ont un comportement par défaut :
git branch → Affiche les branches existantes ;
git branch nomdebranche → Crée une branche ;
git branch -f nomdebranche → Force la création d'une branche (sémantique habituelle de -f) ;
git branch -d nomdebranche → Efface une branche (delete) ;
Présenté comme cela, ça se tient. Les options « -b » et « -B » de checkout permettent ensuite de faire cela à la volée, parce qu'on fait rarement l'un sans l'autre.
J'avais essayé ce tutoriel : http://pcottle.github.io/learnGitBranching/ bien pratique pour se faire la main quand on part de rien (Je n'arrive plus à savoir, malheureusement, si je l'ai découvert ici, sur la tribune ou en cherchant des tutoriels par moi-même…).
Cela dit, j'admets que cela concerne uniquement « branch » et que l'on pourrait disserter longtemps sur la pertinence du reste du langage de git.
Vous aussi vous avez bookmarké la moitié de Stack Overflow et vous collectionnez les cheat cheet sur Git ? …
[^] # Re: Je propose la création d'un langage informatique
Posté par Obsidian . En réponse à la dépêche Questionnaire LinuxFr.org pour la présidentielle française 2017. Évalué à 5.
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. :-)
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…
Ç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.
# Git et compagnie
Posté par Obsidian . En réponse au message Questionnaire logiciel libre pour mémoire de master éco-socio. Évalué à 6.
Je viens de contribuer (anonymement) à ce questionnaire et cela m'évoque un point qui appelle une petite remarque. On peut lire notamment, à plusieurs reprises :
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.
[^] # Re: Conflits de merge ?
Posté par Obsidian . En réponse au message Git : comment merger une arborescence de fichiers ? (pas leur contenu). Évalué à 2.
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.
[^] # Re: Conflits de merge ?
Posté par Obsidian . En réponse au message Git : comment merger une arborescence de fichiers ? (pas leur contenu). Évalué à 3.
Bonjour,
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.
# Conflits de merge ?
Posté par Obsidian . En réponse au message Git : comment merger une arborescence de fichiers ? (pas leur contenu). Évalué à 3.
Salut,
J'ai moi aussi un peu de mal à voir où tu veux en venir. Je lis :
Ça veut bien dire que tu veux synchroniser les branches et obtenir — dans ton dépôt — les fichiers de ton collègue et vice-versa, n'est-ce pas ? Dans ce cas, il s'agit d'un merge ordinaire.
Plus précisément, ici, tu vas d'abord faire un « commit » en local, et git verra que les seuls changements apportés à ton dépôt par rapport à l'état précédent est l'ajout de tes deux fichiers « Mon_Fichier1 et 2 ». Et c'est exactement cela qui sera enregistré dans le commit. Quand tu vas faire « git push » ensuite, c'est ce commit-là qui sera envoyé et qui appliquera les mêmes changements au dépôt distant. Donc, même si ton collège fait la même chose de son côté avec les siens, vous vous retrouverez avec la somme des deux changements et aucun de vous n'aura marché sur les pieds de l'autre.
Sinon, prend le problème à l'envers :
– Soit tu veux récupérer uniquement les « noms » de fichiers à leur place dans le dépôt, sur le FS. Dans ce cas, que doit-il se passer si tu en ouvres un ?
— Soit tu veux justement récupérer le contenu de la branche « distante » puisque ces fichiers appartiennent à ton collègue → merge ordinaire, là aussi ;
— Si tu veux simplement afficher les fichiers de ton collègue, que doit-il se passer si celui-ci a eu la bonne idée de créer chez lui un fichier qui existait déjà chez toi sous le même nom ? La question n'est pas anodine car elle va nous permettre de savoir ce que tu as réellement en tête et, de là, t'orienter correctement. Peut-être même est-ce pour cela que tu as cette idée : justement pour savoir si un nom de fichier est libre ou déjà réservé…
— Vous souhaitez travailler chacun de votre côté et exporter à la fin uniquement les choses qui vous intéressent vers un dépôt commun officiel qui, lui, doit être synchrone : voir la solution de NeoX ;
— Tu souhaites avoir une « vue » sur le dépôt de ton collègue (et réciproquement) sans avoir à l'importer directement au sein du tien ? C'est le principe de la branche « remote ». Celle-ci est répliquée en local quand tu fais « git fetch » (et notamment, tous les objets associés sont rappatriés) mais reste distincte, et reflète l'état de la branche distante même si celle-ci est reconstruite. Tu peux ensuite y associer une vraie branche locale sur laquelle tu peux éventuellement travailler et fusionner l'avancée de la branche distante. C'est le cas de « master » (local) et « origin/master » (remote) quand tu utilises le modèle par défaut. Si tu veux jeter un œil à ce qui se passe à côté, tu peux faire un checkout sur la branche remote et revenir ensuite sur la tienne.
[^] # Re: SpiderOak
Posté par Obsidian . En réponse au message Sauvegardes incrémentales en ligne, chiffrées localement ?. Évalué à 5.
J'ai lu « MultideskOS » sur le coup. Heureusement que j'ai revérifié… :-)
[^] # Re: Probablement…
Posté par Obsidian . En réponse au message Chiffrer disque avec clés de chiffrement stockée sur périphérique amovible. Évalué à 3.
Ça dépend de la méthode de chiffrage que tu as choisie. Si c'est un système s'appuyant sur une passphrase, alors il suffit d'écrire cette passphrase telle quelle dans le fichier concerné.
Aucune idée, parce que je n'utilise pratiquement pas les partitions chiffrées. En fait, j'ai créé quelques fichiers ordinaires de quelques méga-octets que je monte en loopback lorsque j'en ai besoin et qui sont ensuite exploités comme des volumes habituels. Ils me servent à contenir les quelques informations réellement confidentielles comme des listes de mots de passe. Je les monte et démonte sur demande à l'aide d'un script lorsque j'ai besoin de les consulter.
[^] # Re: Probablement…
Posté par Obsidian . En réponse au message Chiffrer disque avec clés de chiffrement stockée sur périphérique amovible. Évalué à 3. Dernière modification le 17 novembre 2016 à 03:02.
Si tu sais à quel endroit est déjà monté ton périphérique amovible, alors une simple ligne de commande du style :
[ -e /répertoiredetaclé/tonfichier ] && cryptsetup --key-file /répertoiredetaclé/tonfichier open /dev/tapartition MonVolume && mount /dev/mapper/MonVolume /monpointdemontage
… devrait suffire. Après, il te suffit de l'ajouter aux scripts de démarrage gérés par init ou systemd selon ta distribution (et son âge). Tu peux également demander à udev ou systemd (là encore, selon la distrib et son âge) de définir un événement correspondant à l'insertion de la clé sur lequel le script sera appelé, après montage de la clé.
Par contre, les volumes ne seront pas automatiquement démontés si tu retires la clé après les avoir montés. Tu peux demander à le faire faire de la même façon mais si un processus quelconque (par exemple un shell) est au même moment dans un des répertoires de ta partition chiffrée, le démontage échouera.
# Probablement…
Posté par Obsidian . En réponse au message Chiffrer disque avec clés de chiffrement stockée sur périphérique amovible. Évalué à 3.
Je ne sais pas s'il « existe un logiciel » tout fait et dédié à cette tâche en particulier mais, à mon avis, si tu utilises cryptsetup ou une solution similaire, tu dois pouvoir t'en sortir avec un simple script. Le problème est que si tu veux que ta partition soit montée au boot, ton périphérique amovible doit être présent dès ce moment et à chaque démarrage. De fait, ça en fait un périphérique un peu moins amovible.
Quel comportement souhaites-tu obtenir ? Est-ce que tu veux déverrouiller automatiquement tes partitions dès lors que tu introduis un dongle une ou clé USB spéciale dans l'emplacement idoine ?
[^] # Re: des reponses
Posté par Obsidian . En réponse au message Quelques questions avant de me lancer dans linux.. Évalué à 3.
Hello,
En fait, c'est un peu comme emménager dans une maison vide : il y a beaucoup de place mais celle-ci va très vite être exploitée.
Tu n'as pas besoin d'autant de places pour démarrer mais, très vite, tu vas devoir d'une part installer tous les logiciels qui t'intéressent et, d'autre part, te laisser de la place pour ton propre dossier personnel « home ». Enfin, le système lui-même doit avoir suffisamment de place pour travailler (création des logs, des différents fichiers temporaires, etc).
L'avantage est que les logiciels que tu vas rapatrier sous Linux sont libres, qu'ils sont donc proposés par défaut sur les serveurs de la distribution que tu utilises et qu'à tout moment, tu peux demander à faire installer le logiciel dont tu as besoin à l'aide d'une simple commande (« apt-get » sur les systèmes basés sur Debian, « yum » ou « dnf » sur les RedHat/CentOS/Fedora, etc). Le produit est installé en quelques secondes sans que tu aies, généralement, à rebooter ou à faire quoi que ce soit d'autres. Certaines lignes de commandes te proposent même d'installer directement le package adéquat si tu appelé une commande inconnue sur ton système mais qui correspond à un package recensé.
Il est toujours un peu délicat d'estimer correctement la place à allouer à chaque partition quand on refait un PC depuis zéro, mais si tu le réinstalles effectivement depuis le départ et que tu disposes d'un disque dur assez large, alors ce n'est pas la peine de se restreindre a priori.
Bon courage et bienvenue sous Linux.
[^] # Re: etonnant moyen d'apprendre
Posté par Obsidian . En réponse au message Recherche d'exercices a faire avec le SHELL Unix. Évalué à 2.
« Our free trial of kung-fu has expired ! »
[^] # Re: shell unix
Posté par Obsidian . En réponse au message Recherche d'exercices a faire avec le SHELL Unix. Évalué à 4.
Bonjour,
man signifie « manuel » et sert à afficher la page de manuel de la commande qui t'intéresse. Y recourir doit devenir un réflexe et c'est souvent vers elle qu'on te renverra en premier lieu chaque fois que tu demanderas de l'aide. Indice : on sort de la page concernée en appuyant sur « Q » (toujours bon à savoir la première fois).
Essaie man mkdir, par exemple.
cat, tu l'utiliseras tout le temps. :-) Et probablement à tort, comme tout le monde. « cat » signifie catenate et sert à concaténer sur la sortie standard le contenu de tous les fichiers dont tu auras précisé le nom, successivement et dans l'ordre. C'est utile en soi, mais comme le résultat est envoyé sur la sortie standard, laquelle est elle-même renvoyée vers l'écran à défaut d'instructions contraires, alors ça devient utile pour visualiser facilement le contenu d'un fichier, même si tu n'en spécifies qu'un seul. En ce sens, ça rend le même service que la commande « type » sous DOS.
Les UUOC dont on te parle dans les autres commentaires viennent du fait qu'il est tentant de se servir de cette commande pour afficher le contenu du fichier puis le rediriger vers une autre commande à l'aide d'un pipe « | », alors que les opérateurs de redirection « < » et « > » servent précisément à cela, et qu'il est bon de prendre l'habitude de les utiliser directement, plutôt qu'instancier un processus qui, effectivement, n'était pas nécessaire.
C'est très pratique quand plusieurs fichiers doivent avoir le même contenu, ou qu'un même fichier doit porter plusieurs noms. Il faut se souvenir qu'UNIX a été d'emblée un système multi-utilisateurs et que jusqu'à une époque pas très lointaine (jusqu'à la fin des années 90, en gros), l'espace disque était limité et précieux.
Quand tu crées un lien dur (ln tout seul), tu donnes en fait plusieurs noms au même fichier. Quand tu édites ce fichier, tu vois tes modifications quelque soit le nom sous lequel tu l'ouvres ensuite et (surtout) il n'y a qu'un seul exemplaire des données sur le disque. Tous les noms renvoient vers le même endroit physique. Une fois déclarés, tous les liens sont semblables. Il n'y a pas de moyen de savoir a posteriori si une entrée est le nom original d'un fichier ou s'il s'agit d'un lien dur.
Le système conserve le nombre de liens durs référençant un même fichier (dans l'inode). Chaque fois que tu effaces un fichier, ce nombre est décrémenté et ce n'est que lorsqu'il arrive à zéro (donc quand plus aucun lien ne référence le fichier) que l'espace disque qu'il occupe est réellement libéré.
C'est utile si, par exemple, tu souhaites mettre par défaut un fichier en lecture seule dans le répertoire de tous les utilisateurs de ton système. Cela évite de consommer de l'espace inutilement avec des copies et laisse malgré tout la latitude à chacun de l'effacer quand ça lui chante. Lorsque tous les utilisateurs ont effacé leur propre « copie », l'espace disque est libéré.
C'est très pratique également si tu veux faire apparaître un même fichier à différents endroits d'une même partition, lorsque les processus qui doivent y accéder ne peuvent se promener librement sur la totalité de l'arborescence, soit à cause de droits d'accès en vigueur, soit lorsque tu utilises chroot.
Les liens symboliques, à présent, sont des fichiers distincts qui ne contiennent qu'une simple chaîne de caractères, qui correspond au chemin d'accès au fichier original. En ce sens, ils ressemblent un peu aux raccourcis *.lnk mais ils ne contiennent aucune autre information et surtout, ils sont gérés directement au niveau du système de fichiers par l'OS, si bien que n'importe quel programme faisant un open sur un lien symbolique ouvrira en fait le fichier pointé et pas le lien symbolique lui-même, de façon complètement transparente et ce même si le programme n'est pas explicitement prévu pour.
C'est utile pour toutes sortes d'applications : pour créer des alias, mais également pour être automatiquement redirigé vers le fichier à utiliser à un moment donné (lequel peut changer), etc. On les utilise notamment dans /lib et /usr/lib pour rediriger une version d'une bibliothèque vers la bonne sous-version.
Les liens durs et les liens symboliques ont chacun leurs avantages et leurs inconvénients, mais une chose est certaine : quand on y a goûté, on n'a plus envie de revenir en arrière. Ceci est également vrai pour Unix en général, et pour les logiciels libres de façon plus globale encore. :-)
[^] # Re: shell unix
Posté par Obsidian . En réponse au message Recherche d'exercices a faire avec le SHELL Unix. Évalué à 2.
Pas spécialement un lien symbolique : ln sert d'abord à créer un lien dur, ce qui a d'ailleurs longtemps été la norme avant même l'existence des liens symboliques. On en retrouve une trace dans la man page de ln :
Aujourd'hui, ils tombent un peu en désuétude et mériteraient justement d'être ré-enseignés proprement. Je pense que c'est précisément parce qu'ils n'existent pas sous Dos/Windows mais qu'a contrario, les raccourcis Windows ressemblent de loin aux liens symboliques que les gens ont fini par prendre l'habitude de n'utiliser que ceux-là.
[^] # Re: la fin des jeux en flash et des videos de chatons ?
Posté par Obsidian . En réponse au journal Flash info. Évalué à 5.
Ben, de toutes façons :
Sinon, pour le reste, j'en pense la même chose qu'à peu près tout le monde. Le fait d'avoir « activé sur demande » le plug-in me permet de mesurer combien sont rares les fois où j'en ai réellement besoin (surtout quand les pages qui le réclament ne le font que pour diffuser de la pub). Mais si elles sont rares, elles ne sont pas totalement inexistantes : certains sites (notamment des sites d'informations) persistent à diffuser leur vidéos en Flash et, bien sûr, je suis attaché à un certain nombre de jeux Flash assez bien réalisés qu'il serait dommage de ne pas pouvoir émuler d'une manière ou d'une autre.
[^] # Re: À quand une émission de téléréalité ?
Posté par Obsidian . En réponse au journal "Meilleur dev de France" ?. Évalué à 4.
Pas sûr.
Et c'est bien ça le plus triste, d'ailleurs…
[^] # Re: shell touch
Posté par Obsidian . En réponse au journal La sortie de `ls` vient de changer. Évalué à 4.
Comme son nom l'indique, « touch » sert à « toucher au fichier ».
Autrement dit, cela sert à obtenir le même comportement qu'en faisant un « open » dessus, à l'exclusion de toute autre opération associée. Donc, formellement, ça crée le fichier s'il n'existe pas et ça met à jour les timestamps dans tous les cas.
Par défaut, la valeur des nouveaux timestamps correspondent à l'heure courant mais il est possible de passer une option pour antidater un fichier (ou le dater dans le futur), parce qu'il aurait été idiot de définir une autre commande rien que pour ce cas.
Si tu utilises « > fichier » à la place, non seulement ça ne marchera pas en zsh mais en plus ça tronquera ton fichier s'il existe déjà (= le videra entièrement).
# Conflit d'adresse ?
Posté par Obsidian . En réponse au message Coupure de connexion réseau. Évalué à 9.
À vue de nez un conflit d'adresse. Deux machines doivent partager la même adresse à un moment donné. Ça arrive de temps en temps quand tout un réseau est fait pour utiliser le DHCP mais que l'on a oublié qu'une machine a été configurée dans son coin avec une adresse statique…
[^] # Re: Ras le bol des couteaux
Posté par Obsidian . En réponse au message super marre de Linux !!!!. Évalué à 5.
Avec un peu de recherche, on tombe sur ça : http://www.linuxmao.org/AV+Linux
Donc, c'est une distribution de Linux orientée musique et ça justifie donc pleinement son choix.
Maintenant, ça n'explique pas pourquoi « ses comptes ne sont plus reconnus systématiquement ».
La seule fois où ça m'est arrivé avec une machine aux comptes locaux (pas de LDAP ou assimilé) était sous Fedora 20 avec une Gnomerie/Lennarterie/Freedesktoperie : GDM perdait sa connexion avec DBus pour une raisons inconnue et c'était par ce biais qu'il authentifiait les utilisateurs, même quand la session était ouverte, mais l'écran verrouillé. Et comme toutes les touches de contrôles (Ctrl-Alt-F1, Ctrl-Alt-Backspace) étaient désactivées « pour le bien de l'utilisateur » (y compris SysRq), il n'y avait aucun moyen de s'en sortir. La seule façon que j'ai trouvée pour ne pas perdre les données qu'il y avait derrière était de faire un ssh depuis une machine tierce et d'envoyer dbus-send --print-reply --type=method_call --system --dest=org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager.UnlockSessions
Par contre, il est clair que ce cas de figure est exceptionnel, expérimental, et purement inadmissible. Mais surtout, en tout état de cause, ça revient au redémarrage. Il n'y a aucune raison d'avoir à réinstaller.
« Démarre toujours » ? Tu t'emportes un peu là ! En presque 20 ans, je n'ai JAMAIS eu à réinstaller un Linux à cause d'une panne. Pas une fois. Il y a bien eu quelques dysfonctionnements occasionnels mais rien que je n'aie pu réparer. J'aimerais pouvoir en dire autant de Windows. Et même quand Windows démarre, on sait à quel point il peut devenir inutilisable au bout d'un certain temps lui aussi.
On peut t'aider mais il nous faut plus de détails : nous ne sommes pas derrière ton écran pour voir ce que tu vois.
[^] # Re: Dieu n'existe pas
Posté par Obsidian . En réponse au journal Paris sous les balles. Évalué à 4.
S'il revient, il va surtout nous dire : « alors je peux pas vous laisser seuls deux petits millénaires sans que vous vous foutiez sur la gueule, bande de petits salopards ? » :-)
[^] # Re: Mécontent de PA
Posté par Obsidian . En réponse à la dépêche PulseAudio 6.0 et 7.0. Évalué à 5.
Une LFS, bien sûr ! :-)
(→[])
[^] # Re: La réponse 4
Posté par Obsidian . En réponse au sondage Combien de fois répondez-vous à un sondage donné ?. Évalué à 6.
e) Je m'appelle Sergio. Personne ne va plus vite que Sergio !
[^] # Re: Une autre ! Une autre ! Bon, d'accord.
Posté par Obsidian . En réponse au journal Testez votre intuition. Évalué à 4.
Ce qui ferait au total 1200 kilomètres en 8 heures, soit 150 kilomètres par heure, sur les 200 pourtant attendus.
[^] # Re: Euh…
Posté par Obsidian . En réponse au message question sur sed et /dev/urandom. Évalué à 3.
Ctrl+V Ctrl+O, probablement.
Sinon
echo -e "\033c"marche bien aussi.[^] # Re: Pocket
Posté par Obsidian . En réponse au journal Firefox 38.0.5 : bien plus qu'une version de maintenance. Évalué à 1.
Aïe !
# Git branch
Posté par Obsidian . En réponse au journal Git a fêté ses 10 ans hier .... Évalué à 3. Dernière modification le 21 mai 2015 à 13:32.
Un grand merci, à mon tour (et un peu tard), pour ce journal de qualité qui me révèle l'étendue de mon ignorance dans le domaine alors même que j'utilise des logiciels de versioning comme tout le monde et de longue date (en ayant commencé avec CVS).
Cela dit :
Pas vraiment puisqu'en réalité, ce ne sont pas les commandes officielles pour faire cela mais des raccourcis bien pratiques. Et si tout le monde les prend en exemple, c'est bien parce que les développeurs les utilisent et qu'ils ont une raison d'être.
L'interface de Git, c'est un peu comme le jeu « Pyramide ». Personne ne comprend de quoi il s'agit, jusqu'au moment où on explique qu'il s'agit simplement de trouver des mots en rapport avec d'autres dans un contexte donné (celui-là même qui manque en général). Du coup, les commandes servent chacune à gérer un thème en particulier, et ont un comportement par défaut :
git branch → Affiche les branches existantes ;
git branch nomdebranche → Crée une branche ;
git branch -f nomdebranche → Force la création d'une branche (sémantique habituelle de -f) ;
git branch -d nomdebranche → Efface une branche (delete) ;
Présenté comme cela, ça se tient. Les options « -b » et « -B » de checkout permettent ensuite de faire cela à la volée, parce qu'on fait rarement l'un sans l'autre.
J'avais essayé ce tutoriel : http://pcottle.github.io/learnGitBranching/ bien pratique pour se faire la main quand on part de rien (Je n'arrive plus à savoir, malheureusement, si je l'ai découvert ici, sur la tribune ou en cherchant des tutoriels par moi-même…).
Cela dit, j'admets que cela concerne uniquement « branch » et que l'on pourrait disserter longtemps sur la pertinence du reste du langage de git.
Je suis obligé de dire que oui. :-)