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 ?
stef@medusa:/tmp$ mkdir plop.git
stef@medusa:/tmp$ cd plop.git/
stef@medusa:/tmp/plop.git$ git init
Dépôt Git vide initialisé dans /tmp/plop.git/.git/
stef@medusa:/tmp/plop.git$ cd ..
stef@medusa:/tmp$ mkdir foo.git
stef@medusa:/tmp$ cd foo.git/
stef@medusa:/tmp/foo.git$ git init
Dépôt Git vide initialisé dans /tmp/foo.git/.git/
stef@medusa:/tmp/foo.git$ touch hello
stef@medusa:/tmp/foo.git$ git add hello
stef@medusa:/tmp/foo.git$ git commit -m'hop'
[master (commit racine) 6b0a7b9] hop
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 hello
stef@medusa:/tmp/foo.git$ git push stef@medusa:/tmp/plop.git master
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)
remote: error: refusing to update checked out branch: refs/heads/master
remote: error: By default, updating the current branch in a non-bare repository
remote: error: is denied, because it will make the index and work tree inconsistent
remote: error: with what you pushed, and will require 'git reset --hard' to match
remote: error: the work tree to HEAD.
remote: error:
remote: error: You can set 'receive.denyCurrentBranch' configuration variable to
remote: error: 'ignore' or 'warn' in the remote repository to allow pushing into
remote: error: its current branch; however, this is not recommended unless you
remote: error: arranged to update its work tree to match what you pushed in some
remote: error: other way.
remote: error:
remote: error: To squelch this message and still keep the default behaviour, set
remote: error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.
To medusa:/tmp/plop.git
! [remote rejected] master -> master (branch is currently checked out)
error: impossible de pousser des références vers 'stef@medusa:/tmp/plop.git'
stef@medusa:/tmp/foo.git$
C’est il me semble le comportement par défaut de ne pas le permettre.
Il est possible très facilement de pousser vers un dépôt de travail. Si le dépôt distant a un accès SSH, il n'y a rien à configurer.
Juste pour voir si j’ai bien compris. Dans ce cas on ne pousse pas vraiment, on se connecte en SSH à distance et on « tire » (en clonant) depuis là-bas :)
C’est tout aussi décentralisé car il est possible de commiter (ou créer une branche en local) et travailler dessus sans avoir à joindre le dépôt de référence
Dans le cadre du développement logiciel, Git va de consort avec les différentes sur-couches, tu ventes toi-même un service comme Github, sa facilité d’accès, sa valeur ajoutée… Ces sur-couches, ainsi que tout le reste de la forge logicielle, n’est pas aussi décentralisé que Git lui-même. Tu ne la migres pas d’un clone magique comme tu peux le faire avec les fichiers suivis eux-mêmes. Ces fichiers sont effectivement partout localement, en principe, selon leur popularité plus précisément, exactement comme un torrent…
Si on sort du cadre du développement logiciel (avec bugtracker et CI, au minimum…) et qu’on considère juste Git pour ce qu’il est, c’est absolument décentralisé je te l’accorde.
Je pense à l’utiliser pour mon $HOMEDIR. C’est un moyen qui me semble plutôt efficace pour installer rapidement mon environnement sur une nouvelle machine, ainsi qu’avoir un historique et pouvoir revenir en arrière en cas d’erreur. Je pense que pour cet usage, je ne devrais pas forcément utiliser un dépôt bare sur une seule machine, mais simplement lier les $HOMEDIR les uns aux autres, au grès de mes envies, selon l’environnement où je travaille à un instant T (et surtout celui sur lequel j’étais à T-1…)
Même là, le fait d’avoir un dépôt qui centralise, sur un NAS par exemple c’est intéressant. Pour le répertoire /etc c’est pratique aussi. Je ne serais pas surpris de voir dans l’avenir des distributions intégrer plus git, pourquoi pas pour la gestion des packages et de la configuration.
perso je n'ai pas encore tout compris mais assez pour faire mon taf
J’en arrive à la même conclusion, je pense forcément en apprendre un peu plus mais je ressens aucun obligation de devoir tout assimiler pour collaborer sur du code.
[^] # 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 ?
[^] # Re: git != svn
Posté par Marotte ⛧ . En réponse au journal Git : les bases et guide d'utilisation en mode centralisé (à la SVN). Évalué à 3.
C’est il me semble le comportement par défaut de ne pas le permettre.
[^] # 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. Dernière modification le 25 novembre 2016 à 23:17.
Juste pour voir si j’ai bien compris. Dans ce cas on ne pousse pas vraiment, on se connecte en SSH à distance et on « tire » (en clonant) depuis là-bas :)
[^] # 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.
Et avant que tu ne m’en fasses la réflexion,
Oui j’ai bien écrit des conneries ici je pense ;)
[^] # 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. Dernière modification le 25 novembre 2016 à 22:55.
Je vais être plus précis.
Dans le cadre du développement logiciel, Git va de consort avec les différentes sur-couches, tu ventes toi-même un service comme Github, sa facilité d’accès, sa valeur ajoutée… Ces sur-couches, ainsi que tout le reste de la forge logicielle, n’est pas aussi décentralisé que Git lui-même. Tu ne la migres pas d’un clone magique comme tu peux le faire avec les fichiers suivis eux-mêmes. Ces fichiers sont effectivement partout localement, en principe, selon leur popularité plus précisément, exactement comme un torrent…
Si on sort du cadre du développement logiciel (avec bugtracker et CI, au minimum…) et qu’on considère juste Git pour ce qu’il est, c’est absolument décentralisé je te l’accorde.
Je pense à l’utiliser pour mon $HOMEDIR. C’est un moyen qui me semble plutôt efficace pour installer rapidement mon environnement sur une nouvelle machine, ainsi qu’avoir un historique et pouvoir revenir en arrière en cas d’erreur. Je pense que pour cet usage, je ne devrais pas forcément utiliser un dépôt bare sur une seule machine, mais simplement lier les $HOMEDIR les uns aux autres,
au grès de mes envies, selon l’environnement où je travaille à un instant T (et surtout celui sur lequel j’étais à T-1…)Même là, le fait d’avoir un dépôt qui centralise, sur un NAS par exemple c’est intéressant. Pour le répertoire /etc c’est pratique aussi. Je ne serais pas surpris de voir dans l’avenir des distributions intégrer plus git, pourquoi pas pour la gestion des packages et de la configuration.
[^] # 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.
J’en arrive à la même conclusion, je pense forcément en apprendre un peu plus mais je ressens aucun obligation de devoir tout assimiler pour collaborer sur du code.