Reprise du message précédent :

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

 
Sinon y a le rapport du GIEC pour vous remonter le moral.

 
Ben c'est pile ce que je comptais proposer comme workflow (le scenario #3 dans mon post d'origine, merge de develop/master dans la branche avant la PR), mais je sens bien que l'outil me dit de faire autrement ici Il encourage le rebase, et trop aller contre l'outil c'est jamais bon.

Tout simplement le merge de develop/master dans ta branche peut faire péter tes tests, donc je suis partisan du je veux pouvoir le tester sur mon poste en local tranquillement avant de lancer un build qui a des fortes chances de faire perdre 10 min à Jenkins pour keudal.

Evidemment je ne parle pas de changements triviaux, mais sur une semaine il peut se passer pas mal de choses surtout sur une app en plein dev (refactoring, ...)

 
On est pile à la croisée des chemins en fait (avec ~20 dev sur deux équipes), pas encore concerné par le scenario 2 que tu décris mais avec la volonté de passer sur gitlab pour envisager l'avenir sereinement. Oui ptet que d'ici pas si longtemps il faudra que le reviewer (ou un autre type encore) merge c'est une possibilité à envisager. J'aimerais ne pas être face au mur si ça arrive.

  ça fait des cross merges = grosses merdes (sauf si ton merge de résolution est fast-forwardé, mais j'ai jamais vu ça en standard)

Jamais eu aucun soucis, on est 11 dev, plus de 2900 PR. Ça juste dans ma COGIP actuelle, bien plus dans l'ancienne où on procédait de la même façon.

Quelqu'un a un bon TLDR à propos de Credit Suisse ? Je croyais que planquer l'argent sale des dictateurs et oligarques était un marché de niche stable, rentable et non spéculatif  

 
Ha ben je veux bien ton feeback sur les cross merge du coup aussi

Chez nous le(s) reviewer(s) approuvent, une fois que c'est approuvé et que tous les CI sont verts[0], ça va dans la queue pour merger, ya plus d'humain impliqué. S'il y a un conflit le merge échoue et le dev doit le fixer (généralement en rebase mais l'outil dit rien).

[0] ou bypassé, on a 2-3 règles qui imposent des reviews par des experts spécifiques si tu les trigger, auquel cas tu peux soit justifier de ce que tu fais, soit trouver un autre chemin

Bah ça rend l'histo moche, ça crée des ambiguités dans le graph, ça montre les changements dans le mauvais sens donc les conflits sont plus difficies à résoudre, c'est difficile à rebaser, et si tu rebase t'en as pas besoin. Et quand t'en prends l'habitude ça augmente le risque de foxtrot (de pousser un merge avec les parents inversés, et donc de swapper ton --first-parent)

J'aime pas les cross merges.

Sinon. Quand vous dev dans une feature branch vous ne faites jamais de merge/rebase du master en cours de route ?  
Sur des projets très actifs perso je fais ça en permanence pour ne pas accumuler trop de conflits et de merde avant le merge/rebase final.

 
Putain, oui j'ai vu...

 
Les changements dans le mauvais sens c'est une mauvaise idée en effet (ça oblige à être bien réveillé quand on regarde pour comprendre ce qui se passe, c'est moyen), et le 'difficile à rebaser' clairement oui, ici je pense être le seul à savoir rebase une branche qui a eu des merges réguliers (--preserve-merges & cie) et ça ne fait pas partie des choses que je souhaite exiger de la part de mes collègues...

 
Si, régulièrement.

Tu utilises quelle stratégie pour merge ta feature dans develop/master ? Ici on squash sous un seul commit, donc l'historique reste facile à review.

Régulièrement oui. Mais dépend aussi de la feat.: si c’est de l’exploration moins. Si c’est dans des trucs qui bougent peu donc les risques sont faibles, mins aussi.

 
J'ai l'impression que mes collègues sont plus à l'aise avec l'idée de mettre au point leur feature (3-5j) puis de l'adapter à l'état courant du code plutôt que de se prendre les changements durant la phase de conception en fait.

Oui non, mais normalement on en rencontre pas, parce que la résolution de conflits on la fait pas via merge, les merges c’est uniquement par le bot à l’intégration dans la mainline.

Faut qu'ils s'adaptent alors. Si j'ai une feature branch au long cours tous les matins je vais rebase develop dessus pour pouvoir avoir les derniers changements et éviter les changements de dernière minute super relou alors que ma feature est prête.

3-5j ça va.... à moins d'avoir du code super jeune et avec plein de dev dessus la base ne devrait pas trop bouger entre temps.

Bingo ^^' mais ça se gère ça va.

Ici la policy de base c’est  
 

• un seul commit: rebase puis merge —ff
• plusieurs, rebase puis merge —no-ff  

Si la PR a des trucs moyennement liés (c’est un combat que j’ai abandonné) tu peux demander un rebase puis merge —ff. Le merge squash est une option de dernier recours, principalement pour des contrib externes qu’on veut pas passer des jours à faire des allers/retours pour fixer les commits & messages de commits.
 
Le merge direct est aussi possible mais ultra rare, c’est généralement pour des meta-branches qui ont eu des merges dedans (= mauvaises idée au carré) parce que le bot ne sait pas rebase les commits de merge et refuse de le faire.

aprés si c'est vraiement la merde de merger tout d'un seul coup il est possible de faire du merge incremental
 
qu'est-ce qu'on peut s'amuser avec git

 
J'ai longtemps cherché si on pouvait faire ça proprement

C'est assez curieux je dois dire

En gros tout est parti d'un des actionnaires principal de Crédit Suisse, la Saudi Nationnal Bank, dont le chairman a eu une comm....assez foireuse. A la question "est-ce que vous comptez investir plus dans Credit Suisse", sa réponse sortie du coeur c'est "Absolutely not". Il a expliqué juste après qu'en fait ils approchaient du seuil de 10% en tant qu'actionnaire, et que dépasser ce seuil déclenche plein de devoirs / scrutiny dont ils avaient pas envie. En fin de compte sa raison est entendable est pas du tout problématique, mais évidemment tout le monde a retenu le absolutely not.

Mardi Credit Suisse a rendu public un rapport disant qu'ils avaient trouvé que leur controles internes avaient surement des manquements, ce qui n'a rien fait pour améliorer l'hémorragie de cash qui plombe la boite, vue que les investisseurs se barrent, et les gens qui ont des dépots se barrent chez la concurrence.

Secoue un peu le tout, et bam,l'action dévisse en bourse, les autorités suisses ont du suspendre sa cotation, et trouver une solution d'urgence.
Ça a été fait durant le week end, en "poussant" UBS à racheter Credit Suisse, pour en gros le 1/3 du prix, avec en plus une garantie de la banque centrale Suisse au cas où la due dilligence revele des trucs pas clean, la confederation se porte garante a hauteur de 8-10Mds je crois. Ça grince un peu des dents en Suisse parce que l'idée d'une fusion circulait depuis un moment, mais c'était vu comme peu concurrentiel (y'a une chiée d'autres banques en Suisse, que ce soit des petites banques privées, ou des petits banques de détail (déjà chaque canton a la sienne, judicieusement nommée Banque Cantonale Vaudois, Genevoise, Zurichoise, etc...). Et là magiquement, plus de soucis de concurrence, ça va passer crème . je pense que Berset (notre président tournant) a du se faire pourrir par tous ses collègues étrangers en mode "toi et ton pays de cons vous ne foutez pas le merdier, ou ça va chier", et à un moment meme un socialiste respectable sait devenir pragmatique en Suisse

Le plus "rigolo" c'est que Credit Suisse a du cash, et satisfait aux règles de couvertures des dépots, donc techniquement ils sont pas noyés loin de là.

Bref, le crédit suisse est vu comme un actif tellement toxique qu'UBS a perdu 14% dès l'ouverture (c'est revenu à la normale)

Excellent Patrick Boyle sur ce sujet : https://www.youtube.com/watch?v=q0So9sqLLfY

Doit y’avoir moyen scripter facilement un merge commit par commit jusqu’à tomber sur un conflit

Ici c'est merge de tout l'histo des devs d'une branche. Avec rebase au fur et à mesure.
J'essaye d’instiller le squash avant merge.

     
 
Merci

 
Ya lui https://www.youtube.com/watch?v=FMZ2_-Ny_zc  si ce genre d'approches t'intéresse
 

fear
 

Qui s'en fou ?

Je trolle mais pas vraiment. Je ne dois pas travailler sur des solutions compliquée impliquant plusieurs centaines de personnes parce que la seule chose qui m'intéresse dans l'historique est le log du tag de prod ou de la branche d'intégration.

Dans quels cas tu as besoin de plus ?

Mouais, en vrai tout le monde s'en tapait pas mal je pense. Ça couinait car des emplois vont devenir redondants surtout.

Côté banque de détail si t'es particulier ou PME t'as au moins 3-4 options.
La partie gestion d'actif fusionne: plutôt cool d'avoir un gros acteur suisse, ils sont face à BlackRock, Vanguard, Lyxor, Amundi... de toute manière.

 
(cf les articles du Temps, j'ai pas été faire un sondage pour voir ce que le Suisse moyen en pense. Perso je m'en fou complètement, je suis chez UBS pour mon compte courant, et j'ai pas de gestion de fortune)
 
en retail y'a plein d'options c'est sur, mais je pense que Raffaisen, les banques cantonales ou les trucs genre Cler vont faire la gueule devant la taille du réseau potentiel que va donner UBS + Credit Suisse
 
Pour la gestion de patrimoine idem pour les petits acteurs : Safra-Sarasin ou Lombard-Odier (même si j'imagine que qqn va chez les petits pour le service plus personnel, j'en sais rien j'ai pas de gestion de de patrimoine)

Le réseau ça coûte cher, les agences qui se cannibalisent c'est le premier truc qui va dégager.
De toute façon plus ça va, plus les particuliers s'en foutent. Cler par exemple c'était la banque Coop, rachetée par la BKB pour en faire leur division 100% en ligne et mobile.

Et si t'as besoin d'une certaine relation client pour une hypothèque ou pour ta PME, généralement valait mieux éviter ces deux de toute manière.

La banque privée c'est pas non plus un domaine où l'offre de CS/UBS me semble avoir une quelconque pertinence.

Y en a qui font oublier ont fait du react + threejs (wrappé par un compo react), j'ai une question sur le passage de props et rendering, histoire d'être sûr d'avoir compris s'il y a possiblement une feinte (ou pas).

Oui.
 
J'ai du implémenter rebase via merges dans l'API github, parce que c'est pas une opération supportée, donc le merge commit par commit c'est exactement ce que ça fait
 
Par contre c'est naturellement pas compatible avec le renvoi de tous les conflits, ou alors faut faire ton merge 2x.

Mais t'as pas besoin de toute la matrice sauf si tu veux pointer exactement la première paire de commits qui conflicte. Tu peux facilement merger la branche sur master commit par commit, puis tour folder. Ça va te donner le conflit que tu crées de ton côté, qui est ce qui t'intéresse le plus (l'autre tu peux le retrouver assez facilement via blame).

La "solution compliquée" c'est un pipeline d'intégration automatisé, une fois que ça roule ça roule, et si tes besoins sont simples t'as des outils off-the-shelf.

que?

Bisect, et les opérations via first-parent (c'est une option de log — utile pour une recherche pickaxe — et blame), si ton histo est propre ça permet de pruner massivement ton espace de recherche initiale, pour te donner soit ce que tu veux, soit une fenêtre de recherche beaucoup plus petite (les commits d'une PR).
 
Si t'as pas besoin de ça tant mieux pour toi

Je réitère pour les Lyonnais : qqun connait Astrée Software ?

C'est quoi ta question ?

Pour faire simple, j'ai des composants d'UI qui fournit des options d'affichage/modélisations.  
Je souhaite les passer en props à un composant qui se trouve au même niveau que ces derniers.  
Dans ce composant, il y a un canvas et d'autres sous-composants et un rendu avec <mesh></mesh> et les outils threejs qui va avec.  

Mon objectif, c'est de pouvoir fournir les propriétés à ce composant, mais sans forcer le re-render.  
Sinon ça me réinitialise la scène et c'est la merde.
Est-ce possible ? Si oui, c'est quoi l'astuce ?

Mais peut être que c'est pas pas possible, ou alors les composants UI doivent être directement dans le canvas?

Je suis pas du tout expert React, et encore mois en hybride web/3D.

 
Je ne suis plus à Lyon mais non je ne connais pas.

Ils sont sur Saint Etienne pas Lyon je crois.

3 pages sur les merges git, franchement l'époque du fichier copié sur le FTP c'était quand même plus simple