Marotte ⛧ a écrit 8719 commentaires

  • [^] # Re: git != svn

    Posté par  . En réponse au journal Git : les bases et guide d'utilisation en mode centralisé (à la SVN). Évalué à 3.

    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.

  • [^] # Re: git != svn

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

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

  • [^] # Re: git != svn

    Posté par  . 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,

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

  • [^] # Re: git != svn

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

    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.

  • [^] # Re: git != svn

    Posté par  . En réponse au journal Git : les bases et guide d'utilisation en mode centralisé (à la SVN). Évalué à 2.

    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: git != svn

    Posté par  . En réponse au journal Git : les bases et guide d'utilisation en mode centralisé (à la SVN). Évalué à 2.

    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 ^^

  • [^] # Re: git != svn

    Posté par  . En réponse au journal Git : les bases et guide d'utilisation en mode centralisé (à la SVN). Évalué à 2.

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

  • [^] # Re: git != svn

    Posté par  . En réponse au journal Git : les bases et guide d'utilisation en mode centralisé (à la SVN). Évalué à 2.

    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…

  • [^] # Re: git != svn

    Posté par  . 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 à 13:59.

    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 ?

  • # Une idée

    Posté par  . En réponse au message rc.local. Évalué à 3. Dernière modification le 24 novembre 2016 à 23:43.

    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"

  • [^] # Re: dvd95

    Posté par  . En réponse au message Équivalent à DVD Shrink. Évalué à 3.

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

  • [^] # Re: cache mémoire

    Posté par  . En réponse au message [Résolu] Clé USB en fonctionnement ou pas ?. Évalué à 5.

    Pourquoi trois fois ?

  • [^] # Re: ce n'est pas un problème d'outillage

    Posté par  . En réponse au journal Git : les bases et guide d'utilisation en mode centralisé (à la SVN). Évalué à 7.

    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

  • [^] # Re: Une modération dissuasive

    Posté par  . En réponse au sondage Comment vous inciter à contribuer plus souvent à LinuxFr.org ?. Évalué à 2.

    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.

  • # Bonjour

    Posté par  . En réponse au journal Git : les bases et guide d'utilisation en mode centralisé (à la SVN). Évalué à 8.

    Mon besoin est de créer un repository central et de travailler à la manière de SVN.
    Remarque : GIT est à la base conçu pour travailler de manière décentralisée.

    Je ne connais pas SVN, c’est peut-être pour ça que je ne comprends pas ton journal…

    Git est bien conçu pour travailler de manière décentralisée, on peut cloner n’importe quel dépôt (même un dépôt de travail) cependant le dépôt de référence (ie: bare repository) représente bien une centralisation du développement ?

    Voilà, est-ce que tu pourrais expliquer un peu plus ton idée, la problématique que tu as en utilisant Git « normalement » ?

  • # Bonjour

    Posté par  . En réponse au message [Echec]Config de base APACHE [Post fermé]. Évalué à 5.

    Je ne sais pas si ton problème vient de là mais pour la directive DocumentRoot d’Apache il faut indiquer un répertoire, pas un fichier.

  • [^] # Re: SQL

    Posté par  . En réponse au journal Linux en rémission ?. Évalué à 2.

    Sybase

    J’utilise des scripts de supervision qui font appel à Sybase pour faire quelques requêtes sur des instance MS SQL. C’est vrai que ça marche très bien.

    Cela dit je me demande à quel point les deux ont pu diverger et si, pour la partie serveur, Sybase pouvait être utilisé à la place de MS SQL…

  • [^] # Re: pour que tu comprennes pourquoi ta question est moinsée par des sans cœurs

    Posté par  . En réponse au message programmation python. Évalué à 0.

    Tu aurais pu utiliser un TL;DR comme il se doit, à savoir au début de ton commentaire et moins long que le message lui-même ;)

  • [^] # Re: droit sur /etc

    Posté par  . En réponse au message droit sur /etc. Évalué à 2.

    Merci pour ta réponse.

    je pense aux applications java, en particulier dans le fichier /etc/xxxx/xxxxx.properties

    et bien mets les bons droits sur ce fichier ce sera déjà ça :)

    Si j’ai une application Java à installer hors dépôt officiels elle va dans /opt et ne met pas de fichiers ailleurs.

    Parce que si les utilisateurs doivent s’identifier ils devraient utiliser chacun un fichier qui est dans leur $HOME, avec des droits à 0600

  • [^] # Re: Carte son

    Posté par  . En réponse au message De nomade à sédentaire, je cherche un PC à tout faire!. Évalué à 3.

    Oui c’est vrai que 8Hz c’est très bas, même pour un subwoofer.

    Je viens de faire le test chez moi avec Audacity, j’entends rien en dessous de 18Hz, et de toute façon j’ai une atténuation pas possible en dessous de 30Hz, mes enceintes sont pas faites pour.

    Pour les aigus j’entends jusqu’à 20kHz, j’ai testé à 21kHz, là j’entends vraiment plus rien (j’ai pas cherché la limite exacte…), pourtant clairement le son sort vu la réaction de ma chatte :)

  • [^] # Re: Carte son

    Posté par  . En réponse au message De nomade à sédentaire, je cherche un PC à tout faire!. Évalué à 2. Dernière modification le 16 novembre 2016 à 18:17.

    8Hz, c'est inaudible tout court (sauf peut-être pour les baleines ?)

    Ben voyons… C’est parce que les infrasons sont inaudibles qu’on se casse le cul à fabriquer du matos audio capable de les reproduire… Faut arrêter avec ce poncif. Oui, les infrasons sont perceptibles par les humains (quand la pression acoustique est suffisante bien entendu). On les "entend" avec la cage thoracique.

    Il semblerait d’ailleurs que les sempiternelles valeurs limites, 20Hz et 20kHz, soient loin d’être exactes, sur Wikipédia à plusieurs endroits il est fait mention de l’intervalle 16-16000Hz

    https://fr.wikipedia.org/wiki/Audition_humaine#Limites_de_la_perception_auditive

  • # Un conseil

    Posté par  . En réponse au message Écouter sa musique en bonne qualité ?. Évalué à 3.

    Une idée qui me vient à la lecture du commentaire de Zenitram.

    Enfin bon j'imagine que vous écoutez tous de la musique et que vous avez déjà réfléchi a tout ça, donc si vous pouviez me donner des réponses et décrire votre système ce serait super sympa.

    À mon avis si tu veux le meilleur rapport qualité prix (et t’épargner quelque branchements) tu devrais regarder du côté des enceintes amplifiées dites « de monitoring ».

  • [^] # Re: Avis.

    Posté par  . En réponse au message Écouter sa musique en bonne qualité ?. Évalué à 2.

    Si je te diffuse un signal continu à 18kHz et que j’ajoute un autre signal, par intermittence à disons à 20030Hz, tu vas « entendre » ce second signal, car la pression acoustique changera, tu n’entendras pas le premier signal de la même manière…

    Les fréquences en dessous de 20Hz sont aussi « audible », car elles font vibrer la cage thoracique.

    Par ailleurs je me suis toujours demandé quelle était l’incertitude sur cette valeur bien arrondie de 20 et 20000 ;)

  • [^] # Re: Quelques trucs pour la timidité

    Posté par  . En réponse au journal J-7 avant de faire mes premières conférences. Évalué à 2. Dernière modification le 15 novembre 2016 à 22:36.

    Le côté mécanique, je l'ai plus vu avec des gens qui apprenaient un texte par cœur qu'avec des gens qui avaient trop répétés.

    À trop répéter tu peux avoir tendance à apprendre par cœur, sans même t’en rendre compte.

    Annonce directement à l'audience que tu n'es pas à l'aise avec la prise de parole en public,

    Pas sûr que ça serve à grand chose

    Pareil, ça sert même à rien. C’est une manière de refuser à tes auditeurs de porter leur propre jugement. C’est impoli*.

    De toute façon quelqu’un de mal à l’aise ça se remarque très vite, puisse que de toute façon tout le monde sait que ça ne vient pas comme ça (même si comme pour tout certains sont plus doués que d’autres), c’est tellement naturel qu’en général ton auditoire se fout que tu balises, et tous ceux qui sont (ou pensent) être mal à l’aise en s’exprimant en public ne te plaindront pas :)

    Et surtout, repose-toi 1000 fois la question: quel est le pire qui puisse arriver si je stresse à mort? Quand tu auras admis que la réponse est "pas grand chose", tu seras bien plus détendue.

    Le pire qui puisse arriver c’est que ton message ne passe pas, ou moins bien.

    [*] j’exagère un peu hein ;)

  • [^] # Re: repartitionner le disque

    Posté par  . En réponse au message boot rescue blem . Évalué à 2. Dernière modification le 15 novembre 2016 à 22:18.

    ca marche aussi si tu reinstalles windows qui va gentillement ecraser l'amorce du disque pour toi sans te demander si tu as un linux quelque part.

    Je me demande à quel point cette décision revêt un caractère politique chez Microsoft. Il n’y a pas la moindre raison technique… et pour ce qui est de l’expérience utilisateur, si Linux est sur la machine, l’utilisateur ne sera pas choqué par un écran de boot loader…

    MS doit continuer de considérer qu’un autre OS installé sur la même machine est un virus/ennemi potentiel :/ En tous cas pour l’informatique personnelle…

    Et j’ajouterais que s’ils se tiraient une balle dans le pied en supprimant carrément l’autre OS (en jore nan mais c’était une feature…) ça me ferait bien rire.