Garder les changements sur une cible mobile (comme Linux) en utilisant git

Question

J'ai un ensemble de changements qui fonctionnent parfaitement contre une certaine version de Linux, disons 2.6.25.4.

J'ai un arbre git, et créé une branche de suivi vanilla-2.6.25.4 à partir de la balise v2.6.25.4. J'ai créé une branche de ce que l'on appelle my-changes-2.6.25.4, et j'ai fait tout mon travail.

Maintenant, je voudrais rebaser mon travail au-dessus d'une nouvelle version arbitraire de Linux. Dites 2.6.28.9. Quel est le flux de travail git optimal pour y parvenir? Je sais comment créer une nouvelle branche à partir de 2.6.28.9, mais faire quelque chose comme 'git merge my-changes-2.6.25.4' donne toutes sortes de conflits d'autres choses qui ne m'intéressent pas. cassé de toute façon.

J'ai essayé de créer une nouvelle branche depuis mon travail my-changes-2.6.25.4, et de faire git rebase 2.6.28.9, en supposant que cela prendrait mes changements de 2.6.25.4 et les appliquerait au dessus de 2.6.28.9, mais Cela m'a donné des tonnes de conflits qui n'étaient pas liés à tout ce que j'ai changé.

Je ne suis pas sûr de la bonne façon de procéder. J'utilise l'arbre linux stable http://www.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6-stable.git, et je pense que certains des problèmes peuvent provenir du fait que les balises versionnées, v2.6.x.y ne sont pas toutes de la même lignée.

Est-ce que quelqu'un sait comment faire cela correctement? Un crédit supplémentaire pour avoir trouvé un moyen d'avancer automatiquement aussi loin que possible grâce à la recherche binaire pour trouver le prochain endroit où Linux a cassé mon code en changeant une interface, mais j'imagine une fois que je sais ce que j'essaie réellement de faire. .

Answer 1

Votre deuxième approche sonne à peu près juste - mais comment avez-vous invoqué rebase? Vous devez dire que vous changez quelle est votre révision de base. Je pense que vous avez besoin de quelque chose comme

# on changes-2.6.25.4 
# make new branch 
git checkout -b changes-2.6.28.9 
# double-check local changes to transport 
git log --pretty=oneline v2.6.25.4.. 
# transport changes to be against new base 
git rebase --onto v2.6.28.9 v2.6.25.4 
# should now have the same changes 
git log --pretty=oneline v2.6.28.9.. 

Une autre possibilité pour éviter d'être jetés au milieu d'un rebasage est de prendre votre liste des changements locaux et les ajouter manuellement à une nouvelle branche basée sur l'utilisation v2.6.28.9 la commande "git cherry-pick". En fait, c'est effectivement la même chose que le rebasage, mais dans un sens vous laisse plus de contrôle sur ce que vous faites.

Je pense que votre raisonnement quant à la raison pour laquelle ceci est un problème est correct: v2.6.28.9 n'est pas un descendant de la version 2.6.25.4- donc par défaut rebase essayerait d'inclure tous les changements dans la version 2.6.26. .v2.6.25.4 ainsi que le vôtre, si vous avez simplement fait "git rebase v2.6.28.9". Le rebase à un argument va essayer d'obtenir vos changements locaux comme "git log $ 1..HEAD" et ensuite les appliquer sur "$ 1" - donc vous pouvez voir que cela n'a de sens que si l'arg à rebaser est une branche qui a été mis à jour. Si vous rebassez le même tag que précédemment, rien ne se passe. Si vous modifiez une étiquette différente, les modifications apportées par d'autres personnes sont mélangées aux vôtres. Vous devez rebaser une étiquette sur une autre.