Discussion :

[grunt2000]

Bonjour,

J'ai la situation suivante, avec des commits de thème c et d'autres de thème d, parce qu'il y a eu de fausses manipulations : c₁, c₂, d₁, c₃, d₂, d₃.
Je voudrais rassembler tous les commits c_m et tous les commits d_n en deux commits C et D séparés.

Un git rebase -i me propose ceci :

pick c₁
pick c₂
pick d₁
pick c₃
pick d₂
pick d₃

Si je travaille avec squash, je pense n'arriver qu'à cette situation, avec la pratique que je maitrise :

pick c₁ + c₂
pick d₁
pick c₃
pick d₂ + d₃

Comment à partir de là (ou d'avant) adjoindre c₃ à c₁ + c₂ pour constituer C,
et d₂ + d₃ à d₁ pour constituer D ?

Merci !

[Marco46]

On est d'accord que t'es sur une branche privée ? C'est à dire non publiée sur un repo de collaboration ?

[Marco46]

La seule solution que je vois c'est de créer une nouvelle branche, puis de reset --hard le HEAD de cette nouvelle branche sur c2.

Ensuite tu cherry-pick c3.

Ça te donne une branche avec c1, c2, c3.

Il ne te reste plus qu'à cherry-pick les commits du thème d.

Puis tu reset --hard le HEAD de ta branche initiale au niveau du parent de c1 et tu merge en fast forward.

Du coup tu te retrouves avec c1, c2, c3, d1, d2, d3 et tu peux donc faire ton rebase -i sans soucis pour obtenir c, d.

EDIT : Il va de soit que dans cette explication les noms c1, c2 etc ... font référence au contenu des commits et non aux sha-1. D'où ma question initiale.

[Marco46]

Je viens de percuter à la relecture que dans le titre il y a marqué commits distants.

On ne rebase pas de commits publics. Donc fin de l'histoire !

[grunt2000]

Oh pardon !
C'est une faute d'expression. Je voulais dire : des commits distants entre eux sur la même branche,
et pas des commits en remote !

La problématique est la suivante : après être passée plusieurs mois sur une version 2 d'une application,
mon équipe se rend compte que des commits de la version 1 n'ont pas été repris, par oubli.
On va devoir faire cherry-pick dessus. Mais voilà certains d'entre-eux, de surcroit, on étés faits en confettis. Et je me retrouve avec la situation que je décris.
Avant de procéder au cherry-pick de mes commits de la version 1 vers la version 2, j'aimerais rassembler les petits commits de la version 1 en gros commits pour les appliquer d'un seul coup, et proprement.

[Marco46]

Ah tu fais bien de préciser le contexte, vous avez donc 2 branches d'intégration des développements parce que une ligne de dev a divergé, et vous souhaitez reprendre des commits de la 1ère ligne pour les mettre dans la 2ème.

Du coup la solution que je te proposais est parfaitement applicable. Simplement tu intègreras les commits rebasés dans la 2ème ligne de dev depuis une branche de travail au lieu de partir de la 1ère ligne de dev.

Je ne sais pas si je suis clair c'est toujours difficile de parler de l'arbre git textuellement sans avoir l'arbre sous les yeux !

[grunt2000]

Ce serait tout à fait ça !

Mais je lis aussi ceci :
qui dit qu'en déplaçant simplement l'ordre des picks lors d'un rebase -i, cela changerait l'ordre des commits.

quel crédit faut-il lui accorder ?
Parce que ça a l'air puissant, au point que c'en est vaudou, je trouve.

[Marco46]

Ça dépend si t'as des changements qui se basent sur d'autres changements dans le parent. Le reordering peut te mettre un sacré merdier.

De toutes manières le git rebase te permettra de faire des modifs et de gérer les conflits lors de l'exécution mais il faut bien comprendre que le rebase interactif c'est fait pour nettoyer l'historique d'une branche privée avant de la rendre publique.

Tu peux parfaitement faire comme ça du moment que tu joues le rebase -i sur une branche de travail en local destinée à être merge sur ta 2ème branche d'intégration des devs (ta v2).

Rien ne t'empêche non plus d'essayer les deux solutions. Tant que tu n'as pas publié tes modifs ya pas de soucis. C'est tout l'intérêt de git par rapport à une solution centralisée comme svn.

[grunt2000]

Je suis d'accord avec toi !
Là, c'est pour préparer au transport des commits après coup et temporairement.

Je vais tirer une branche V1' en local depuis V1
et depuis V1' extraire mes deux commits, de la manière que tu dis.

J'irai alors sur V2, je tirerai une branche V2' et j'y cherry-pickerai C et D.
Sitôt fait, je détruirai V1' dont je me serai servi que fugitivement.

[Marco46]

Résolu ? :p

[Obsidian]

Bonjour à tous,

On ne rebase pas de commits publics. Donc fin de l'histoire !

Ça dépend tout de même de ce que l'on appelle « public », ce qui prend d'ailleurs tout son sens dans les projets libres et open source, qui sont par nature ouverts à un personnel intéressé mais non identifié à l'avance.

C'est le cas avec le développement du noyau linux, par exemple, dans lequel la branche principale officielle « linux » (celle de Linus lui-même, donc) est bien gravée dans le marbre, mais où « linux-next » qui est bien la branche mouvante sur laquelle les développeurs doivent désormais travailler et qui va produire les lignées qui seront in fine intégrées au prochain noyau, elle, voit bien sa tête régulièrement reconstruite.

C'est d'ailleurs assez déstabilisant quand on aborde à la fois le développement Linux et Git en particulier, quand on ne connaît pratiquement ni l'un ni l'autre, ce qui pouvait arriver avec des choses comme le projet Eudyptula, quand on avait écrit quelques modules du noyau (en général cantonnés au Hello World) et quand on collabore uniquement avec des patches envoyés par courrier, qui est toujours la procédure en vigueur. Autant un git pull fonctionnait toujours sur la branche principale, autant à chaque fois, sur linux-next, ce même git pull finit par échouer lamentablement au bout de quelques jours sur linux-next alors qu'il fonctionne aussi bien que sur la branche principale. On voit alors le logiciel peiner pendant un moment, essayer de faire des résolutions très compliquées puis, au bout d'un moment, rendre la main à l'utilisateur en lui demandant de régler les conflits.

À ce stade, beaucoup de gens préfèrent abandonner et re-télécharger au propre la branche et ses 2 Gio de données dans un nouveau dépôt. Mais quand on l'a fait trois ou quatre fois, on fait un peu de recherche, on découvre git fetch, git remote update et les opérateurs « .. » et « ... ».

[Marco46]

Bizarre ce que tu dis parce que sa Sainteté himself recommande de ne jamais rebaser des commits publics (par public on entend des commits que quelqu'un d'autre aura eu l'opportunité de pull).

I want clean history, but that really means (a) clean and (b) history.

People can (and probably should) rebase their _private_ trees (their own
work). That's a _cleanup_. But never other peoples code. That's a "destroy
history"

[...]

- Minor clarification to the rule: once you've published your history in
some public site, other people may be using it, and so now it's clearly
not your _private_ history any more.

So the minor clarification really is that it's not just about "your
commit", it's also about it being private to your tree, and you haven't
pushed it out and announced it yet.

Bon après le mail date de 2009 donc il a pu changer d'avis depuis

[grunt2000]

Résolu ? :p

Hé ... !
Attends d'abord que je réussisse !

Mais tes explications sont claires, je devrais m'en sortir.

[Obsidian]

Bizarre ce que tu dis parce que sa Sainteté himself recommande de ne jamais rebaser des commits publics (par public on entend des commits que quelqu'un d'autre aura eu l'opportunité de pull).

Ah mais ça n'est pas incompatible !

Tout ce que tu as exposé est vrai et relève d'ailleurs des règles de bonne pratique avant même d'être des directives officielles dans un projet. À dire vrai, linux-next date grosso-modo de cette époque également et je pense que c'est précisément pour éviter de polluer la branche principale que celle-ci a été mise en place, même si d'autres remplissaient déjà tacitement ce rôle, comme -mm.

D'abord, si je ne dis pas d'âneries, la branche linux-next est réinitialisée à l'état courant à chaque sortie d'un nouveau noyau (ce qui est facile à vérifier car le prochain, le 4.14, sortira dans deux jours) et donc déplacée sur le commit correspondant, ce qui, de fait, casse l'historique des copies locales tirées par les gens. Ensuite, en réalité, le problème rencontré est le même que celui que les développeurs au niveau individuel : la plupart de ce qui compose linux-next est en fait formé par la fusion de branches distantes et distinctes, correspondant chacune à un sous-ensemble particulier et supervisé par un mainteneur désigné. Ce sont ces mêmes branches qui seront ensuite, in fine, soumises à Linus et c'est lui qui les intégrera dans son arbre.

Ces branches sont généralement déjà construites à l'aide de cherry-picks, dans le sens où elles sont censées déjà être au propre. Mais comme on n'est jamais à l'abri d'une erreur et, surtout, qu'on ne peut pas garantir à l'avance qu'un jeu de modifications donné n'aura pas d'effets de bords dans un environnement qui intègre d'autres jeux de modifications, l'idée est d'intégrer le tout et de compiler un noyau de test (linux-next) pour s'assurer que tout fonctionne, et pour corriger le tir si nécessaire. En principe, ce sont les mêmes branches qui sont réimportées, donc on va retrouver essentiellement les mêmes commits. On trouve soit des ajouts ou suppressions mineures (par exemple, un seul commit sur toute une lignée), soit un ajout d'un gros bloc consécutif parce que l'équipe n'était pas prête auparavant, soit plus rarement la suppression d'un gros bloc parce que les nouveautés qu'il apporte ne fonctionnent tout simplement pas. En général, on peut s'attendre à le voir réapparaître quelques jours plus tard, le plus souvent à sa place initiale (donc réinséré au milieu de l'historique).

On ne viole donc pas la loi énoncée plus haut car l'historique est bien conservé, mais pas là où on l'attend : il l'est en fait sur les branches de développement individuelles de chaque équipe.

Par exemple, ce soir, ma branche linux-next pointait le commit référencé 536f8ff5e005b424e716c886fd7963f20f00926e et après un remote update, elle est passée à 5515cf16e270538121e4fa9283fed86c6cfd8c9c. On peut s'apercevoir que ces deux têtes convergent et rejoignent la branche de Linus à partir de 5dfeaac15f2b1abb5a53c9146041c7235eb9aa04, c'est-à-dire une vingtaine de commits après 4.14-rc1, sortie il y a deux mois et qu'elle accuse tout de même 12000 commits dans ce laps de temps.

$ git rev-list --count master..536f8ff5e005b424e716c886fd7963f20f00926e
12204
$ git rev-list --count master..5515cf16e270538121e4fa9283fed86c6cfd8c9c
12606
$ git rev-list --count 5515cf16e2..536f8ff5e0
353
$ git rev-list --count 536f8ff5e0..5515cf16e2
755
$ git rev-list --count 536f8ff5e0...5515cf16e2
1108

On passe donc, en un jour ou deux, de 12204 à 12606 commits, que 353 d'entre eux disparaissent (~2 %) et 755 apparaissent (~5 %), soit 1108 (~8 %) commits seulement qui ne sont pas communs aux deux versions.

C'est flagrant avec l'option « --first-parent » entre origin/master et les deux références ci-dessus, successivement. On passe de 163 à 170 commits, tous des fusions (normal). On y retrouve quasiment la même liste de branches, dans l'ordre (à quelques différences minimes), mais à par une poignée de branches au début de la liste (en bas) auquel on ne touche plus, la totalité des branches réimportées ont changé de somme SHA1.