J’ai testé minetest, un gros serveur américain et un petit serveur dont quelqu’un avait parlé dans un journal ici. C’est marrant, vraiment interactif. Ça rappelle les partie de Légo de son enfance. Bon… au bout d’un moment c’est lassant…
Je me suis remis à jouer un peu à Megaglest pour ma part. Contre l’IA, j’arrive plus à gagner les scénarios que j’avais pourtant réussi à maîtriser il y a quelques années :)
Il y a un mode "histoire" qui a été commencé, je trouve ça carrément bien comme gameplay… mais bon, ça « finit » vite… j’imagine que ça représente un max de travail à développer.
Si je comprends correctement la notion d’« arrondi bancaire » c’est justement la méthode qui permet de ne privilégier ni le trésor ni le contribuable… (ni la banque ni le client, etc…)
L’utilisation du caractère nul plutôt qu’un point-virgule c’est parce que c’est le seul caractère que je suis assuré de ne pas rencontrer dans le chemin d’un fichier… alors que le point virgule :
Si j’ai un fichier avec ce genre de nom, pouf le script (il prendrait 'tl' comme nom de fichier)…
Il y aurait aussi la solution de ne spliter qu’un nombre restreint de colonnes (les trois premières) mais ça devient plus compliqué avec awk…
Donc j’aimerais d’abord être sûr que c’est à cause du caractère nul comme séparateur que j’ai ce comportement. D’après la lecture du manuel ça ne devrait pas poser de problème.
Pourquoi tu n’installes pas avec l’image ISO officielle "netinst" de Stretch, puis tu installes Cinnamon ensuite depuis les dépôts ?
Lors de l’installation choisi le mode "expert", ça te demandera de choisir quel environnement tu veux. Tu peux soit :
ne pas en installer, tu n’auras que le mode texte, pour en installer un (Cinnamon) ensuite toi-même : apt-get install cinnamon*
si tu n’es pas à l’aise avec le mode texte tu peux en installer un léger (donc ni Gnome ni KDE), pour « avoir un truc » au moins… ensuite quand tu as installé cinnamon tu peux le gicler…
Et ne t’inquiète pas à cause du mot « expert », en fait tout ce que cela va changer c’est que l’installer va te poser beaucoup plus de questions (te laisser plus de choix donc), le principe est simple : si tu ne sais pas répondre à une question, tu laisses le choix par défaut.
[*] Je ne connais pas Cinnamon, je ne sais pas s’il vient avec un "display manager", il sera peut-être judicieux d’en installer un (en même temps que tu installes Cinnamon), par exemple lightdm.
Donc l'avantage de systemd réside dans la facilité d'inclusion des logiciels dans un maximum de distribution en minimisant les efforts à fournir par leurs auteurs.
Un de ses avantages.
Mais en tant qu'utilisateur d'une distribution unique, je ne vois pas pourquoi j'irai faire l'effort d'installer, comprendre, et potentiellement jouer avec, casser et perdre du temps à réparer
Et bien pour t’éviter de devoir à chercher à comprendre comment fonctionne chaque script d’init en particulier !
un outil qui ne m'apporte aucune plus-value à l'heure actuelle.
Si ça ne t’apporte aucune plus-value j’imagine que c’est parce que tu as une utilisation très basique de ton système d’init. Dans ce cas tu ne vas pas passer X temps à trifouiller dans systemd, tu l’installes et ça marche tout seul hein…
Avec systemd tu peux notamment avoir des dépendances entre services. Par exemple un serveur oueb qui doit attendre qu’un SGBD soit dispo.
Évidemment, tu peux faire la même chose avec sysV, tu peux même tout faire avec sysV vu que ce sont des scripts shell… mais du coup ce n’est pas forcément fait pareil sur toute les distributions… et même selon l’admin ou le mainteneur qui fait ce script.
systemd apporte indéniablement une homogénéisation à ce niveau là : ton unit systemd il fonctionne pareil sur n’importe quel système qui utilise systemd, ce n’est pas le cas avec un script d’init un poil évolué.
Télécharger des fichiers non exécutable (vidéos, image, audio) ne pose plus de risques de sécurités depuis longtemps.
Si. Il peut y avoir exploitation d’une faille du logiciel qui ouvre le fichier. C’est devenu je pense moins courant que les autres exemples que tu cites, effectivement.
Au final, quels sont les vrais risques de télécharger n'importe quoi sur Internet (des vidéos, des musiques) à part avoir des tas de fenêtre de pub (le problème le plus courant, selon moi) ?
Un risque qui est pourtant réel, c’est que la machine serve discrètement à un petit (ou moyen) groupe de personnes partageant des intérêts communs… à faire des trucs pas forcément avouables, ou chiants (genre DDoS). La grande majorité des gens, y compris moi, n’utilise pas toute sa puissance de calcul de son desktop en permanence.
Si c’est fait en bonne intelligence, c’est à dire sans mettre la machine à genoux, les gens ne diront rien, n’en sauront rien.
n'importe quoi sur Internet
n’importe quoi c’est vague.
Je dirais que ça dépend à la fois de la curiosité et de la naïveté chaque utilisateur (le fait que l’ordi puisse être « pourri »), plus que de la fiabilité purement technique de l’OS :) Même une bonne distribution GNU/Linux, il suffit d’un clic (sur un sh téléchargé par exemple), tout est automatisé… ça arrive peu, pour la simple raison que Linux sur les ordinateurs personnels c’est pas bézef.
Je suis tout à fait satisfait de ne pas l’utiliser.
L'avez vous deployé en production sans trop de difficulté
Non. Donc c’était sans trop de difficulté.
est ce que le suivi des corrections et de sécurité est à la hauteur de Debian
Tu apprendras que par politesse et par respect envers les autres distributions moins bien loties, on évite de provoquer des comparaisons avec Debian, qui est unanimement reconnue comme étant « hors concours ».
Si du code très mal écrit fonctionne. S’il ne provoque pas d’incident parce que les cas théoriques qui le feraient exploser ne se présentent pas dans le contexte dans lequel on l’utilise, même s’il est de fait : plus dur à faire évoluer ou à reprendre, on peut décider de ne pas y toucher pour se concentrer sur autre chose. C’est pour ça que tant de commentaires du type "TODO: améliorer le bousin" ou "TODO: vérifier l’input" perdurent au fil des années.
Après c’est sûr que quand tu vois des traitements planter parce que "l’utilisateur avait saisi une date dans le champ téléphone" tu te dis "what the fuck?!"…
Je suis en train de reprendre un code PHP avec par endroit : <?php } ?> :/
Vouloir installer quatre distributions, assez semblables, en multiboot sur un disque externe, c’est pour une autre raison que le masochisme ?
le premier commence à faire la gueule et ne démarre pas avec un message du genre "kernel panic"
Tu as fait le partitionnement manuellement lors des installations ? Il y a une possibilité que l’un ou l’autre des installers se mélange les pinceaux… au niveau de GRUB justement.
1M, c'est la taille des blocs lors d'une écriture avec dd, il semblerait.
Oui, c’est pour ça que je demande. Ça peut modifier les performances de dd. Il y a une taille de bloc optimal qui correspond généralement à N×taille de bloc du device… Cela dit, de là à ce que ça influe autant j’ai un doute, je disais ça comme ça.
La je sèche un peu… entre tag, tree et branch. Ce que j'imagine : les développeurs vont créer une branche de dev, bosser dessus, la tagger pour réconciliation quand "c'est prêt", réconcilier puis enfin supprimer la branche ?
Ce n’est pas obligatoire de tagger, un tag est juste un raccourci sur un commit (parce que c’est plus facile d’utiliser, par exemple, v2.1 que 6b0a7b9a2d489b438a0357587823b60e6c2f1387).
Par contre un tag pourrait effectivement être utilisé pour indiquer qu’une branche doit être mergée… soit en « avance rapide », s’il n’y a pas de conflit (ça peut donc se faire automatiquement en utilisant les "hooks" (des scripts qui se lancent automatiquement sur certaines actions sur un dépôt)).
S’il y a des conflits (selon l’algorithme utilisé, y’en a pas mal différents…), il faut que quelqu’un édite les marqueurs de conflit dans les fichiers afin que le merge aboutisse. Cette personne peut aussi dire : « ta branche je veux pas me faire chier à la merger, alors attends que je finisse de merger les autres branches de tes petits camarades qui codent pas comme des gorets, puis tu mergeras ensuite à partir de la nouvelle version pour régler tes conflits toi-même. » ;) Et abandonner le merge de cette branche.
Pour le nom des branches je dirais que les deux possibilités évidentes pour créer des branches c’est soit une branche par développeur, soit une branche par fonctionnalité. On peut bien sûr toujours aussi imaginer faire les deux… et d’autres.
Avec une branche par fonctionnalité, si deux dév travaillent sur une même fonctionnalité, si les deux push dessus depuis leur propre copie locale, c’est le premier qui est servi :)
Imagine le workflow suivant d’un développeur :
Début de journée, je mets à jour ma branche locale NouveauModule depuis le branche distante, disons qu’elle n’a pas changé depuis hier, je suis à jour. C’est bien, au boulot.
Je travaille sur cette branche, au bout d’un moment c’est prêt, j’ai fini ma tâche pour cette fonctionnalité, je nettoie éventuellement mon historique (rebase), parce que j’ai pu commiter localement par commodité pour X raisons, autant regrouper (fixup) les changements de ces commits, souvent peu utiles pour l’historique du projet… Et je push sur le dépôt de référence.
Et là paf, merde, entre temps un autre dév. a pushé son travail sur cette même branche. La branche distante étant maintenant « en avance de 1 commit par rapport à ma branche locale » je ne peux pas pousser comme ça (je pourrais forcer avec --force, si le serveur le permet, ce n’est pas recommandé, c’est pas gentil…), je dois donc d’abord merger moi même (en pullant) son travail, là pareil, si le collègue en question a travaillé sur d’autres fichiers, où à d’autres endroits dans le fichier et que l’algorithme de git est capable de le faire automatiquement il le fera, je pourrait ensuite pousser mon propre travail. Sinon suite au pull je me retrouve dans un état intermédiaire, avec les fichiers « marqués », là il faut éditer les fichiers pour les réconcilier, et le merge peut se terminer. Ensuite je pourrai pousser.
Une autre possibilité que le merge dans ce cas, c’est le rebase. Qui consiste (là encore j’espère qu’on me corrigera si je me trompe), à au lieu de créer un « commit de merge », à placer tous (ou une partie) de nos commits à partir duquel on dérive de la branche distante, en haut en cette branche. Donc il d’y a plus de « branchement », notre branche locale peut être pousser car elle représente la version distante (avec les travail de notre collègue) + seulement nos commits depuis, qui suivent quoi…
Je pense qu’on peut se contenter d’une seule des commandes, entre merge et rebase, pour un workflow défini… (hors le rebase qu’on peut faire soit même en local, pour modifier son historique avant de « publier » ses changements). Il y a des subtilités dont je ne pense pas avoir fait le tour et fonctionnellement elles me semblent équivalentes, elles n’aboutiront simplement pas au même historique. Mais le résultat, une fusion de branche, sera le même quant au contenu des fichiers à la fin de l’opération.
Et oui, du coup quand NouveauModule est de l’histoire ancienne, on supprime généralement la branche pour créer la branche NouveauModule2, que le nom des branches soit parlant. L’historique ne sera pas perdu, mais fusionné.
En plus ça m’a l’air assez simple de faire le travail de validation de patch avec Git. Celui qui valide les patches c’est celui qui crée une branche dans son propre dépôt dans le seul but de merger la branche machin et la branche bidule (voir seulement certains de leurs commits), en résolvant éventuellement les conflits, et ensuite fait un merge final de celle-ci depuis LE master "officiel", depuis lequel on va livrer notre application, qui se trouve potentiellement sur un autre dépôt git que celui des développeurs, auquel lui seul à accès.
stef@medusa:/tmp/foo.git$ git branch habon
stef@medusa:/tmp/foo.git$ git checkout habon
Basculement sur la branche 'habon'
stef@medusa:/tmp/foo.git$ git status
Sur la branche habon
nothing to commit, working tree clean
stef@medusa:/tmp/foo.git$ git push stef@medusa:/tmp/plop.git habon
Enter passphrase for key '/home/stef/.ssh/id_rsa':
Décompte des objets: 3, fait.
Écriture des objets: 100% (3/3), 206 bytes | 0 bytes/s, fait.
Total 3 (delta 0), reused 0 (delta 0)
To medusa:/tmp/plop.git
* [new branch] habon -> habon
Ensuite il n’y a plus qu’à :
stef@medusa:/tmp/plop.git$ git branch
habon
stef@medusa:/tmp/plop.git$ git checkout habon
Basculement sur la branche 'habon'
stef@medusa:/tmp/plop.git$ ls
hello
pour ne pas laisser le dépôt distant perdu sans savoir sur quel branche il est.
oui car si j’ai bien compris c’est la branche pointée qui sert si quelqu’un d’autre veut cloner ce dépôt. Ça ne peut être deux états, deux commits (ou dans l’exemple, un commit et un dépôt vide)…
En espérant pas dire de connerie… Si on l’autorise (donc il faut déjà configurer cela après l’init du premier dépôt) ça rend le dépôt de travail distant « inconsistant » ça veut sûrement dire qu’on ne peut plus vraiment s’en servir comme dépôt de travail avant de « s’aligner » (avec le reset) et donc perdre potentiellement des choses qui aurait été faites de ce côté… Peut-on stasher dans ce cas ? Le dépôt dans cet état, s’il est cloné, quel est le résultat ?
[^] # Re: Pas tombé loin :-)
Posté par Marotte ⛧ . En réponse au message Sens interdit dans la barre de tache. Évalué à 3.
https://linuxfr.org/wiki/aide-edition#code
[^] # Re: un truc pas très connu racheté par microsoft....
Posté par Marotte ⛧ . En réponse au sondage Joueur ou non joueur. Évalué à 2.
J’ai testé minetest, un gros serveur américain et un petit serveur dont quelqu’un avait parlé dans un journal ici. C’est marrant, vraiment interactif. Ça rappelle les partie de Légo de son enfance. Bon… au bout d’un moment c’est lassant…
Je me suis remis à jouer un peu à Megaglest pour ma part. Contre l’IA, j’arrive plus à gagner les scénarios que j’avais pourtant réussi à maîtriser il y a quelques années :)
Il y a un mode "histoire" qui a été commencé, je trouve ça carrément bien comme gameplay… mais bon, ça « finit » vite… j’imagine que ça représente un max de travail à développer.
[^] # Re: Merci
Posté par Marotte ⛧ . En réponse au journal Cohérence des fonctions d'arrondi. Évalué à 4.
Si je comprends correctement la notion d’« arrondi bancaire » c’est justement la méthode qui permet de ne privilégier ni le trésor ni le contribuable… (ni la banque ni le client, etc…)
[^] # Re: c'est possible
Posté par Marotte ⛧ . En réponse au message find, sort & nul char. Évalué à 2.
L’utilisation du caractère nul plutôt qu’un point-virgule c’est parce que c’est le seul caractère que je suis assuré de ne pas rencontrer dans le chemin d’un fichier… alors que le point virgule :
Si j’ai un fichier avec ce genre de nom, pouf le script (il prendrait 'tl' comme nom de fichier)…
Il y aurait aussi la solution de ne spliter qu’un nombre restreint de colonnes (les trois premières) mais ça devient plus compliqué avec awk…
Donc j’aimerais d’abord être sûr que c’est à cause du caractère nul comme séparateur que j’ai ce comportement. D’après la lecture du manuel ça ne devrait pas poser de problème.
[^] # Re: Preuve formelle et supervision de la fabrication et de la distribution
Posté par Marotte ⛧ . En réponse au journal HiFive1: Un Arduino à 320Mhz entièrement libre pour 2017. Évalué à 3.
Qui désigne ces hackers ?
[^] # Re: Merci
Posté par Marotte ⛧ . En réponse au journal Des "basheries". Évalué à 5.
$ find . -name '*.cpp' -print | xargs grep 'if ( isNarrow_ )'Il vaut mieux utiliser
… -print0 | xargs -0 …, si par exemple tu as des espaces ou des guillemets dans tes noms de fichier.# Salut
Posté par Marotte ⛧ . En réponse au message Stretch en live USB. Évalué à 3.
Pourquoi tu n’installes pas avec l’image ISO officielle "netinst" de Stretch, puis tu installes Cinnamon ensuite depuis les dépôts ?
Lors de l’installation choisi le mode "expert", ça te demandera de choisir quel environnement tu veux. Tu peux soit :
apt-get install cinnamon*Et ne t’inquiète pas à cause du mot « expert », en fait tout ce que cela va changer c’est que l’installer va te poser beaucoup plus de questions (te laisser plus de choix donc), le principe est simple : si tu ne sais pas répondre à une question, tu laisses le choix par défaut.
[*] Je ne connais pas Cinnamon, je ne sais pas s’il vient avec un "display manager", il sera peut-être judicieux d’en installer un (en même temps que tu installes Cinnamon), par exemple lightdm.
[^] # Re: systemd
Posté par Marotte ⛧ . En réponse au journal Devuan a deux ans . Évalué à 6.
Un de ses avantages.
Et bien pour t’éviter de devoir à chercher à comprendre comment fonctionne chaque script d’init en particulier !
Si ça ne t’apporte aucune plus-value j’imagine que c’est parce que tu as une utilisation très basique de ton système d’init. Dans ce cas tu ne vas pas passer X temps à trifouiller dans systemd, tu l’installes et ça marche tout seul hein…
[^] # Re: systemd
Posté par Marotte ⛧ . En réponse au journal Devuan a deux ans . Évalué à 9.
Avec systemd tu peux notamment avoir des dépendances entre services. Par exemple un serveur oueb qui doit attendre qu’un SGBD soit dispo.
Évidemment, tu peux faire la même chose avec sysV, tu peux même tout faire avec sysV vu que ce sont des scripts shell… mais du coup ce n’est pas forcément fait pareil sur toute les distributions… et même selon l’admin ou le mainteneur qui fait ce script.
systemd apporte indéniablement une homogénéisation à ce niveau là : ton unit systemd il fonctionne pareil sur n’importe quel système qui utilise systemd, ce n’est pas le cas avec un script d’init un poil évolué.
[^] # Re: Botnet
Posté par Marotte ⛧ . En réponse au message Les dangers sur Internet ?. Évalué à 5.
Si. Il peut y avoir exploitation d’une faille du logiciel qui ouvre le fichier. C’est devenu je pense moins courant que les autres exemples que tu cites, effectivement.
# Botnet
Posté par Marotte ⛧ . En réponse au message Les dangers sur Internet ?. Évalué à 5.
Un risque qui est pourtant réel, c’est que la machine serve discrètement à un petit (ou moyen) groupe de personnes partageant des intérêts communs… à faire des trucs pas forcément avouables, ou chiants (genre DDoS). La grande majorité des gens, y compris moi, n’utilise pas toute sa puissance de calcul de son desktop en permanence.
Si c’est fait en bonne intelligence, c’est à dire sans mettre la machine à genoux, les gens ne diront rien, n’en sauront rien.
n’importe quoi c’est vague.
Je dirais que ça dépend à la fois de la curiosité et de la naïveté chaque utilisateur (le fait que l’ordi puisse être « pourri »), plus que de la fiabilité purement technique de l’OS :) Même une bonne distribution GNU/Linux, il suffit d’un clic (sur un sh téléchargé par exemple), tout est automatisé… ça arrive peu, pour la simple raison que Linux sur les ordinateurs personnels c’est pas bézef.
[^] # Re: Capté
Posté par Marotte ⛧ . En réponse au journal Programmer ça craint. Évalué à 2.
CQFD
# Houpla
Posté par Marotte ⛧ . En réponse au journal Devuan a deux ans . Évalué à 10.
Haha !
Non
Je suis tout à fait satisfait de ne pas l’utiliser.
Non. Donc c’était sans trop de difficulté.
Tu apprendras que par politesse et par respect envers les autres distributions moins bien loties, on évite de provoquer des comparaisons avec Debian, qui est unanimement reconnue comme étant « hors concours ».
# Une piste peut-être
Posté par Marotte ⛧ . En réponse au message Sudoers et mot de passe. Évalué à 2.
Ça n’aurait pas un rapport avec :
https://bugzilla.redhat.com/show_bug.cgi?id=1020147
?
Est-ce que tu as la même chose si tu fais :
ssh -l apache -t host 'sudo -n /bin/systemctl stop httpd.service'C’est juste une idée…
[^] # Re: Capté
Posté par Marotte ⛧ . En réponse au journal Programmer ça craint. Évalué à 8.
Non, c’est stupide.
[^] # Re: Capté
Posté par Marotte ⛧ . En réponse au journal Programmer ça craint. Évalué à 8.
Si du code très mal écrit fonctionne. S’il ne provoque pas d’incident parce que les cas théoriques qui le feraient exploser ne se présentent pas dans le contexte dans lequel on l’utilise, même s’il est de fait : plus dur à faire évoluer ou à reprendre, on peut décider de ne pas y toucher pour se concentrer sur autre chose. C’est pour ça que tant de commentaires du type "TODO: améliorer le bousin" ou "TODO: vérifier l’input" perdurent au fil des années.
Après c’est sûr que quand tu vois des traitements planter parce que "l’utilisateur avait saisi une date dans le champ téléphone" tu te dis "what the fuck?!"…
Je suis en train de reprendre un code PHP avec par endroit :
<?php } ?>:/# Bonjour
Posté par Marotte ⛧ . En réponse au message Problème multiboot distributions linux sur disque dur externe. Évalué à 2.
Vouloir installer quatre distributions, assez semblables, en multiboot sur un disque externe, c’est pour une autre raison que le masochisme ?
Tu as fait le partitionnement manuellement lors des installations ? Il y a une possibilité que l’un ou l’autre des installers se mélange les pinceaux… au niveau de GRUB justement.
[^] # Re: Salut
Posté par Marotte ⛧ . En réponse au message Débit ridicule HD et SSD (suite). Évalué à 2.
Oui, c’est pour ça que je demande. Ça peut modifier les performances de dd. Il y a une taille de bloc optimal qui correspond généralement à N×taille de bloc du device… Cela dit, de là à ce que ça influe autant j’ai un doute, je disais ça comme ça.
[^] # Re: git != svn
Posté par Marotte ⛧ . En réponse au journal Git : les bases et guide d'utilisation en mode centralisé (à la SVN). Évalué à 2.
Merci pour le lien. Cela dit je vais devoir aussi travailler avec du Git 1.7… mais c’est bien de voir que ça continue d’évoluer.
[^] # Re: git
Posté par Marotte ⛧ . En réponse au journal Git : les bases et guide d'utilisation en mode centralisé (à la SVN). Évalué à 2. Dernière modification le 26 novembre 2016 à 03:10.
Ce n’est pas obligatoire de tagger, un tag est juste un raccourci sur un commit (parce que c’est plus facile d’utiliser, par exemple, v2.1 que 6b0a7b9a2d489b438a0357587823b60e6c2f1387).
Par contre un tag pourrait effectivement être utilisé pour indiquer qu’une branche doit être mergée… soit en « avance rapide », s’il n’y a pas de conflit (ça peut donc se faire automatiquement en utilisant les "hooks" (des scripts qui se lancent automatiquement sur certaines actions sur un dépôt)).
S’il y a des conflits (selon l’algorithme utilisé, y’en a pas mal différents…), il faut que quelqu’un édite les marqueurs de conflit dans les fichiers afin que le merge aboutisse. Cette personne peut aussi dire : « ta branche je veux pas me faire chier à la merger, alors attends que je finisse de merger les autres branches de tes petits camarades qui codent pas comme des gorets, puis tu mergeras ensuite à partir de la nouvelle version pour régler tes conflits toi-même. » ;) Et abandonner le merge de cette branche.
Pour le nom des branches je dirais que les deux possibilités évidentes pour créer des branches c’est soit une branche par développeur, soit une branche par fonctionnalité. On peut bien sûr toujours aussi imaginer faire les deux… et d’autres.
Avec une branche par fonctionnalité, si deux dév travaillent sur une même fonctionnalité, si les deux push dessus depuis leur propre copie locale, c’est le premier qui est servi :)
Imagine le workflow suivant d’un développeur :
Début de journée, je mets à jour ma branche locale NouveauModule depuis le branche distante, disons qu’elle n’a pas changé depuis hier, je suis à jour. C’est bien, au boulot.
Je travaille sur cette branche, au bout d’un moment c’est prêt, j’ai fini ma tâche pour cette fonctionnalité, je nettoie éventuellement mon historique (rebase), parce que j’ai pu commiter localement par commodité pour X raisons, autant regrouper (fixup) les changements de ces commits, souvent peu utiles pour l’historique du projet… Et je push sur le dépôt de référence.
Et là paf, merde, entre temps un autre dév. a pushé son travail sur cette même branche. La branche distante étant maintenant « en avance de 1 commit par rapport à ma branche locale » je ne peux pas pousser comme ça (je pourrais forcer avec --force, si le serveur le permet, ce n’est pas recommandé, c’est pas gentil…), je dois donc d’abord merger moi même (en pullant) son travail, là pareil, si le collègue en question a travaillé sur d’autres fichiers, où à d’autres endroits dans le fichier et que l’algorithme de git est capable de le faire automatiquement il le fera, je pourrait ensuite pousser mon propre travail. Sinon suite au pull je me retrouve dans un état intermédiaire, avec les fichiers « marqués », là il faut éditer les fichiers pour les réconcilier, et le merge peut se terminer. Ensuite je pourrai pousser.
Une autre possibilité que le merge dans ce cas, c’est le rebase. Qui consiste (là encore j’espère qu’on me corrigera si je me trompe), à au lieu de créer un « commit de merge », à placer tous (ou une partie) de nos commits à partir duquel on dérive de la branche distante, en haut en cette branche. Donc il d’y a plus de « branchement », notre branche locale peut être pousser car elle représente la version distante (avec les travail de notre collègue) + seulement nos commits depuis, qui suivent quoi…
Je pense qu’on peut se contenter d’une seule des commandes, entre merge et rebase, pour un workflow défini… (hors le rebase qu’on peut faire soit même en local, pour modifier son historique avant de « publier » ses changements). Il y a des subtilités dont je ne pense pas avoir fait le tour et fonctionnellement elles me semblent équivalentes, elles n’aboutiront simplement pas au même historique. Mais le résultat, une fusion de branche, sera le même quant au contenu des fichiers à la fin de l’opération.
Et oui, du coup quand NouveauModule est de l’histoire ancienne, on supprime généralement la branche pour créer la branche NouveauModule2, que le nom des branches soit parlant. L’historique ne sera pas perdu, mais fusionné.
[^] # Re: Bonjour
Posté par Marotte ⛧ . En réponse au journal Git : les bases et guide d'utilisation en mode centralisé (à la SVN). Évalué à 3.
En plus ça m’a l’air assez simple de faire le travail de validation de patch avec Git. Celui qui valide les patches c’est celui qui crée une branche dans son propre dépôt dans le seul but de merger la branche machin et la branche bidule (voir seulement certains de leurs commits), en résolvant éventuellement les conflits, et ensuite fait un merge final de celle-ci depuis LE master "officiel", depuis lequel on va livrer notre application, qui se trouve potentiellement sur un autre dépôt git que celui des développeurs, auquel lui seul à accès.
[^] # Re: gratter dd ?
Posté par Marotte ⛧ . En réponse au message [Résolu] Clé USB en fonctionnement ou pas ?. Évalué à 4.
À priori seulement à condition d’utiliser
conv=fdatasyncman 1 ddme dit :fdatasync : écrire les données du fichier de sortie physiquement avant de terminer
# Salut
Posté par Marotte ⛧ . En réponse au message Débit ridicule HD et SSD (suite). Évalué à 2.
À part l’affichage (qui serait à priori un autre problème) tu as concrètement des problèmes de lenteur quand ça écrit ou lit sur le disque ?
Si tu fais un "sync", ça rame ?
1M c’est la taille exacte des blocs ?
[^] # Re: git != svn
Posté par Marotte ⛧ . En réponse au journal Git : les bases et guide d'utilisation en mode centralisé (à la SVN). Évalué à 2.
Effectivement. Merci.
Ensuite il n’y a plus qu’à :
oui car si j’ai bien compris c’est la branche pointée qui sert si quelqu’un d’autre veut cloner ce dépôt. Ça ne peut être deux états, deux commits (ou dans l’exemple, un commit et un dépôt vide)…
Tu m’auras appris un truc, merci.
[^] # Re: git != svn
Posté par Marotte ⛧ . En réponse au journal Git : les bases et guide d'utilisation en mode centralisé (à la SVN). Évalué à 2.
En espérant pas dire de connerie… Si on l’autorise (donc il faut déjà configurer cela après l’init du premier dépôt) ça rend le dépôt de travail distant « inconsistant » ça veut sûrement dire qu’on ne peut plus vraiment s’en servir comme dépôt de travail avant de « s’aligner » (avec le reset) et donc perdre potentiellement des choses qui aurait été faites de ce côté… Peut-on stasher dans ce cas ? Le dépôt dans cet état, s’il est cloné, quel est le résultat ?