Reprise du message précédent :

 
J'ai eu une fois à m'en servir en + de 20 ans sur un serveur en caraf heureusement que j'utilise vi d'habitude (les commandes en ":" de vim viennent d'ex/ed)

À chaque fois que j’essaie de l’utiliser pour rigoler je me retrouve exactement dans la “typical novice’s session with the mighty ed”.

encore jamais utilisé, mais j'ai peut-être fait des trucs improbables pour éviter (et aussi je fais pas beaucoup d'admin)

 
Même pas un nano? En général c'est sur celui-ci que j'ai fini, quand j'ai dû intervenir sur des serveurs avec aucun éditeur décent d'installé

En même temps la vraie solution c’est tramp, sauf si c’est vraiment pas une option genre parce qu’il faut bouncer à travers des screen / tmux (je crois pas que tramp sache faire)

Je crois qu'absolument personne ne l'utilise encore. Ce serait du pur masochisme.
Par défaut, un vi très basique est devenu "the standard editor".

Dans l'interview de Ken Thompson, il explique qu'ed fonctionne comme il fonctionne parce qu'il a été créé au temps où les écrans cathodiques n'existaient même pas. C'est un éditeur pour éditer sur imprimante. Donc c'était tout sauf interactif : il y a une erreur à la ligne 20, alors lance une commande pour remplacer le caractère o par 0 de la ligne 20 et réimprime moi les lignes 18 à 22:
20s/o/0/
18,22p.

Dès que les écrans se sont généralisés, vi est devenu le "visual editor".

Ceci. Si y'a 0 editeur qui ressemble à vi, je fini aussi sur nano, car il a un avantage majeur : les raccourcis sont affichés en bas de l'écran  

 
Fun fact en faisant vi Bill Joy a écrit termcap (une database 'flatfile' listant les capacités des différents terminaux) + des routines utilisant termcap, et ce sont ces routines qui ont donné curses par la suite

110 vues sur mon screenshot de terminal Vous êtes combien à lurker ici ?

Je l'ai personnellement affiché 6 fois pour une durée d'environ 40 secondes à chaque fois.

 
J'ai besoin d'un peu plus de temps pour que ça vienne perso

C'est les couleurs, très écolo.

Une petite question sur github/gitlab (je n'utilise git que directement d'habitude, donc pas l'habitude des surcouches) : vu qu'à la fin d'une pull request/merge request c'est lui qui fait le merge et pas moi, comment résoudre les conflits de merge s'il y en a ?    
 
De ce que je vois gitlab propose 2 réponses insatisfaisantes :  

• une résolution par l'interface web
• une résolution en local à base de rebase de ma branche sur un master up-to-date

Dans la première solution je n'ai pas les modifs en local, donc je ne peux pas tester/compiler/etc donc je résous au doigt mouillé ici    
 
Dans la seconde solution il faut rebase, se taper les conflits, force-push pour mettre à jour la branche de feature. Ayant toujours privilégier les merge depuis des années plutôt que les rebase "car tu comprends un historique faux mais linéaire c'est bien plus lisible lol" j'aimerais ne pas en arriver à ça et ne pas avoir à inscrire des force-push de feature branch dans la pratique courante    
 
Je vois bien une troisième solution mais pas dingue non plus, le dev merge master dans sa feature branch avant la pull-request, pour se prendre les conflits et pouvoir les résoudre, puis push / merge request et donc merge de la feature branch dans master. Mais ça fait un aller-retour de merge (un double merge) alors que sémantiquement je veux juste faire un merge de la feature-branch dans develop moi ici.
 
Pour info dans le workflow actuel : git merge de la feature-branch dans master, résolution de conflits, si ok on push. Un seul sens de merge, ni rebase ni force-push ni rien    
 
 
Je veux bien votre éclairage sur ces outils du tur-fu    
 

Ici ça rebase la feature-branch jusqu'à l'absence de conflit avec master.

Ouais c’est super parce que t’as des changements dans ton commit de merge qui se retrouve tout crapoux et régulièrement faux, et naturellement pas testé.
 
IME le standard c’est tu rebase et tu résous les conflits comme ça t’as une branche propre et correcte, ça fait aussi un meilleur histo.
 
Chez nous on a aussi un mode hypermagique: si le dernier commit d’une PR est un commit de merge, il peut être réutilisé pour résoudre les conflits.
 
Mais je crois pas avoir vu ça chez qui que ce soit d’autre, et c’est très peu utilisé chez nous, le workflow normal c’est tu rebase pour résoudre tes conflits. De toute manière le mode d’intégration par défaut fait un rebase (ce que certains outils appellent “merge semi-linéaire”, et s’il y a qu’un commit il est directement intégré en tête de branche en rebase + fast-forward)

 
Clairement pas, tu as un commit de merge qui n'a été pushed qu'après avoir été mis au point, testé, etc justement   Tant qu'il ne compile pas/ne marche pas tu revois ta copie.
 

 
C'est plus que discutable le meilleur histo   sur un scénario comme ceci :  
 

 
l'historique qui reflète réellement ce qui s'est passé, le fait que le dev ait lieu en parallèle, d'où et quand il est parti de master, où il va, etc, c'est le merge à gauche, pas le rebase à droite.

 
En quoi c'est pertinent ?

Astrée software ça parle a qqun ici?

 
Le but de Git c'est pas d'écrire un bouqin d'histoire, mais de pouvoir comprendre les évolutions et/ou revenir en arriere sur des etats utiles de la codebase.

 
En préservant l'historique un développeur peut facilement se remettre à la place du dév de la feature, dans le contexte de l'époque avec le vrai état du code tu comprends pourquoi tel choix plutôt que tel autre.
 
Le merge est plus simple, moins error-prone que le rebase (où on peut perdre des trucs), il combine naturellement toute ta feature branch en un seul commit de merge sur la branche master (sans pour autant te forcer au squash), et c'est parfait pour partager ta feature branche si besoin.
 
Rebase + squash à part voir un historique linéaire je vois pas l'avantage   et déjà c'est pas un avantage fou le côté linéaire, à part si tu suis les commits avec ton doigt dans un GUI ce que personne ne fait... pour moi rebase c'est vraiment pour nettoyer ta feature-branch avant le merge.

 
Justement un historique à base de merge se prête bien mieux à ça

 
On ne peut pas vraiment muscler "autour" du genou, c'est en grande partie composée de tendons et ligaments. Quand on parle de kiné pour renforcer le genou en cas de déchirure c'est bullshit.
 
Par contre tu peux renforcer le quadriceps et l'ischios-jambier qui permettent de compenser une potentielle instabilité du genou, sans être le remède miracle.
 
Effectivement je continue le renforcement musculaire chez le kiné. Enfin c'est du renforcement léger avec surtout un gros travail sur la propriocéption.
 
De mon côté j'ai repris depuis plusieurs semaines l'entrainement des jambes à la salle de musculation.
 
Mon kiné est vraiment très sceptique quant au fait que je ne me fais pas opérer. J'ai l'impression qu'il ne jure que par le premier chirurgien (celui qui voulait m'opérer le tibia). Quand je lui ai dit ce midi que le ski c'était passé nickel il était dubitatif.
 

 
C'est ce que j'ai fait hier soir en rentrant, ce matin c'était presque revenu à la normal et je peux à nouveau tendre ma jambe sans avoir une douleur aigüe.

Je vais privilégier le double merge du coup je pense pas trop le choix

 
je vois ton idée, mais si tu pars d'un trunk A-B-C-D-E, et que t'as branché à B, certes les choix de ta branche dérivent du code tel qu'il était à B. Mais si tu rebases en E, tu dois réevaluer ces choix avec l'état du code à E puisque tu dois rentre ton code compatible avec E, donc au final est-ce que c'est pertinent de garder le "voici le contexte qui était B"

Ben dans le cas du merge tu as "on est parti de B, au moment du merge on a vu que C-D-E amenaient des changements, il a fallu adapter le code" soit à peu près la réalité. Dans le cas du rebase tu as "faisons semblant d'avoir développer la feature depuis E, mais en fait c'est pas vrai ça reste un truc basé sur B puis adapté pour coller à E" donc probablement différent ce que tu aurais fait si tu étais parti de E réellement.

Je suis ptet un vieux con hein mais entre ça et l'absence des octopus merge & cie je trouve l'outil frustrant pour l'instant

C'est pas le scénario dont je parle.

On s'en tape le cul par terre. Je laisse pas trainer des commits de wip que j'ai fait & push en fin de journée au cas où, et pourtant c'est "réellement ce qui s'est passé", bah c'est pareil. Si tu veux faire un récapipitulatif de toutes les merdes tu lets mets dans le commit de merge ou quoi (surtout s'il y a eu des fausses pistes qui ont pas abouti), tu laisse pas trainer ça dans l'histo sous prétexte que c'est comme ça que ça s'est passé.

Ce sont les commits qui te donnent cette info.

On a perdu beaucoup plus de trucs sur des commits de merge que sur des rebase.

Quand un dev rebase sa branche, il sait quel était l'intent de chaque commit, résoudre les conflits (ou les incompatibilités) revient à se remettre dans se cadre, et à nettoyer exactement les changements du commit en cours.

Quand un dev merge, dans un sens il se tape l'intégralité des changements de sa PR sans contexte clair, et dans l'autre il se tape des changements qu'il a pas faits ce qui les rend encore moins clairs.

Encore une fois, faut aller relire, avec le doigt si nécessaire. Un rebase ça n'exclue pas un merge.

Si c'est le cas ya une sérieuse merde dans le processus, et il est surprenant que tu arrives à juste résoudre des conflits sans tout réécrire.

Ce n'est pas ce que dit l'outil. Il dit: pour rajouter cette fonctionnalité au code, je pars de E, et j'applique les changements X, Y, Z. C'est effectivement ce qui se passe lors d'un rebase. Et effectivement, l'historique du développement de la fonctionnalité est perdu. Je pense que ça ne sert à rien, et que vouloir afficher ça complexifie un truc qui l'est déjà trop.

Pouvoir comprendre les évolutions et/ou revenir en arrière sur des états utiles de la codebase pour moi ça veut dire

• pouvoir faire du git bisect sur des commits qui marchent
• pouvoir tester la branche master avant le merge VS après le merge
• voir les features arriver clairement dans master (par les commit de merge)

Tout ça -> git merge

Je ne parle pas des wip (qui se font rebased), les wip c'est de l'ordre du brouillon donc oui ça disparaît ça. J'ai jamais critiqué le rebase d'une branche locale j'en abuse moi même tous les jours.
Il y a 3 niveaux pour moi : ta branche local avec son bordel (les wip), sa version nettoyée que tu proposes au merge, et la version finale qui est la feature qu'on voit arriver dans 'master' par le merge.

Sauf que lors du merge tu réconcilies la version finale (aboutie) de ta feature avec master, plutôt que de te réinsérer dans chaque étape intermédiaire du développement.

 
Encore une fois tu peux avoir le meilleur des deux mondes en faisant un rebase sur master de ta PR avant de faire un commit de merge vers master.
Si jamais la temporalité des développements est vraiment importante au point d'être scrupuleusement respectée dans l'historique, c'est que vous ordonnez vos devs avec le cul ou que vous avez des PR beaucoup trop longues.

bon, en plus des nouveaux -10000 annoncés par meta la semaine dernière, c'est amazon qui vient d'annoncer -9000 de plus (cette fois aws et twitch entre autre dans la charrette)  

Et pour la 3e fois, de suite, un rebase n'empêche pas un merge.

Oui?

Et tu vas faire des rebase / changements entre (1) et (2), et entre (2) et (3). Bah si t'as (3) qui est bloqué à cause de conflits, tu rebase pour les résoudre.

Oui, et quand tu dois résoudre des conflits dedans ça fait de la merde qui n'apporte rien. Ça ne fait que rendre les blame moins clairs.

 
Possible, 1 semaine la plupart du temps je dirais. Sur une appli C++ en cours de dev c'est à peu près le temps pour rajouter une feature en tout cas. Je ne dirais pas que la temporalité a besoin d'être scrupuleusement respectée, juste qu'on peut l'avoir pour un coup quasi nul en fait  

Bah le coût n'est pas nul : je rejoins masklinn, c'est plus simple de demander à la personne qui a fait le dev de rebase (et plus généralement de garder sa PR mergable) plutôt qu'à la personne qui doit clore la PR d'être capable de faire le merge elle-même.

 
Si on imagine que le merge n'est pas fait par le développeur (ici c'est le dév qui merge) j'entends l'argument.

 
alors que Credit Suisse après un -6000, va surement rajouter un -10000...mais personne n'en parle, les petits banquiers souffrent et le monde détourne les yeux
 
Tous ensemble, sauvons Crédit Suisse !!!!
 
 

 
Si c'est le dev qui merge effectivement il y a peu de différence.

Bon faut a minima que je trouve comment désactiver le merge fast-forward et le semi-linear history dont parlait masklinn.

Xavier je trouve que tu te prends vachement la tête, personnellement je dev dans ma branche comme tout le monde. Puis lorsque je crée ma PR/MR je regarde si je suis en retard sur develop/master, si c'est le cas je pull la dernière version que je merge dans ma branche, en résolvant conflits si il y'a et je demande la review de ma PR/MR.

Mais ici je présume que vous allez passer dans un autre mode, puisque tu poses la question de comment gérer le problème via gitlab?

'fin voilà ici depuis plusieurs années le merge est automatique (à la merge trains / merge queues) parce que l'échelle était trop grande pour que les merges manuels passent, tu savais pas tester ton merge avant de te faire griller par un nouveau merge, donc les gens finissaient par tester leur PR, essayer de merger, résoudre, pas re-tester, et pousser un truc pété (de juste des incompatibilités sémantiques à conflits mal résolus).