Marotte ⛧ a écrit 8780 commentaires

Y'a moyen de considérer que dire d'un texte qu'il est 'stupide' offensera l'auteur du texte, non ?

Non, c’est stupide.

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.

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.

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é.

quel rapport avec valider les patchs etc. ?

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.

À priori seulement à condition d’utiliser conv=fdatasync

http://superuser.com/questions/730801/dd-immidiately-completes-but-actually-needs-sync

man 1 dd me dit :

fdatasync : écrire les données du fichier de sortie physiquement avant de terminer

Ce problème de débit est certes pénible, mais la machine reste utilisable malgré tout.

Pour info, cette baisse du débit ne touche pas le réseau.
100% 1768MB 84.2MB/s 00:21

Par ailleurs, depuis que j’ai transféré ce système sur la nouvelle CM, j’ai aussi google chrome qui déconne. L’affichage rame complètement.

À 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 ?

Effectivement. Merci.

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)…

Tu m’auras appris un truc, merci.

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 :)

Et avant que tu ne m’en fasses la réflexion,

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

Oui j’ai bien écrit des conneries ici je pense ;)

Donc pour moi Git c’est forcément centralisé

Euh…

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.

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.

Merci pour ton lien. J’étais passé à côté de ta réponse.

# my first ever commit with GIT! Don't greet me with an error.
> git commit -m "yippeee git!"

Howdy! So that git can give you credit for changes you make
    Please enter your name? Jon Saints
    Please enter your email? email@gmail.com
Thank you! Committing...

This replaces the more confusing error message that git shows users now:

Error 123: Look! Another stupid user is _trying_ to learn git. 

You should have known to type this first:
> git config --global user.name "Jon Saints"
> git config --global user.email "gmail@gmail.com"

You are a git DUFUS!! Just give up now. Seriously.

_o_ . Moi j’ai carrément pris ça comme une réelle volonté d’indiquer à l’utilisateur l’importance que la pertinence de ces informations revêtent pour la collaboration sur un projet :)

L’aide qui s’affiche par défaut je trouve ça assez bien. On dit toujours qu’il faut RTFM au débutant. Donc rappeler la base aux moments cruciaux est loin de me sembler délirant.

Bref, je pense que l’auteur initial de Git se souciait effectivement peu de cet aspect, si c’était logique pour lui.

D’automatiser le stash suivit d’un reset ça n’aide pas à comprendre ce qu’est ce stash.

Quand Linus a créé Git il devait faire pas mal de gestion de patch, plus que du développement à proprement parler. Git est fait pour faire de la gestion de patch (code source mais on pense aussi à la documentation…), et seulement cela, assez dans l’esprit Unix.

Bref, je pense que l’auteur initial de Git se souciait effectivement peu de l’accessibilité de son programme, son ergonomie, tant que c’était logique pour lui et son propre workflow.

Je reconnais que Git est pas non plus le logiciel que j’ai trouvé le plus facile à assimiler. Les pieuvres ça fait un peu peur ^^

Merci pour ce lien avec ces explications très claires et ces exemples. J’ai moi même commencé à rédiger ce genre de document afin de mieux mémoriser ce que j’apprends sur Git.

Mais bon, à part dire que « c’est probablement la commande la plus confusante(?) jamais écrite par des humains » nulle part est pointé ce qui peut porter à confusion…

Une fois qu’on a saisi la différence entre l’étape add et l’étape commit, l’action reset c’est clair comme du cristal de roche ;)

SVN n'étant pas simple à part pour les gens le connaissant

Je n’ai jamais travaillé avec SVN (mon utilisation à l’époque se limitait à faire des svn up pour récupérer le source de certains logiciels)

Je pensais benoîtement que SVN ayant moins de fonctionnalité (mais là encore je dis peut-être une connerie) il était plus rapide à prendre en main.

Pour en revenir à l’aspect centralisé/décentralisé j’avoue ne pas bien comprendre de quoi on parle.

Il me semble que pour travailler avec Git il est nécessaire d’avoir un dépôt de référence (un bare…) car il n’est pas possible de pousser vers un dépôt de travail (même si on peut cloner un dépôt de travail) et il n’est pas possible non plus de travailler dans un dépôt de référence…

Donc pour moi Git c’est forcément centralisé. 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, ce qui, si j’ai bien compris, n’était pas possible avec SVN.

Bon, comme vous pouvez le voir je débute avec Git, mais j’avoue que pour le peu que j’en connais (push/pull/merge/rebase/stash… le gestion des "remotes") je trouve déjà que c’est un outil vraiment puissant, utile.

Il me reste pas mal de truc à voir : cherry-picking (bon ça ça à l’air simple) bisect/3-way merge… et sûrement d’autres fonctionnalités… J’ai l’impression que les possibilités sont quasi infinies avec le système de hooks…

Plutôt d’accord avec toi sur le fait qu’un outil simple à utiliser a plus de chance d’être adopté (et correctement utilisé). Par contre :

même si l'architecture de git est bien pensée, son interface comme sa doc sont catastrophiques.

Que leur reproches-tu au juste ?

Essaye de mettre un exit 0 à la fin de ton fichier rc.local…

Je te dis ça car j’ai eu ce problème… Par contre je ne sais pas si tu n’as pas un autre problème, vu le "connection refused"

Dernier commit de 2013… (visiblement), tu aimes les logiciels plus maintenus toi :)

Cela dit ce logiciel est peut-être très bien. Ce serait bien que la personne qui a moinssé ton commentaire dise pourquoi elle l’a fait :/

Pourquoi trois fois ?

Parce que j'aime bien avoir le code produit pas ma société sur un serveur que ma société maîtrise.

Gitlab est un service mais c’est aussi un logiciel, libre, que tu peux installer sur un de tes serveurs ;)

https://gitlab.com/gitlab-org/gitlab-ce

Si tu ne veux pas que la note affecte la visibilité du commentaire tu peux « surfer à -42 »… Tu dois avoir un bandeau en bas de la page, en cliquant sur la valeur « Seuil » tu peux choisir -42, tous les commentaires seront visibles.