2013-01-15 4 views
2

J'ai besoin de modifier un commit au tout début de l'historique de mon dépôt. Depuis ce commit il y a probablement eu des centaines de branches, fusionne et fusionne les conflits.Comment modifier un commit Git contenant des centaines de fusions et de fusions dans le passé?

J'ai essayé d'utiliser la rebase interactive avec l'option --preserve-merges, mais j'ai toujours des centaines d'erreurs de conflit semblables à "CONFLICT (content): Merge conflict in Foobar.cpp". Les re-résoudre manuellement est extrêmement difficile, voire impossible.

J'ai entendu parler de la fonctionnalité 'rerere', mais seulement maintenant, je ne l'ai donc pas activée.

+1

Les balles magiques sont disponibles sur l'allée trois. Acheter un cas entier; ils sont bon marché! –

+0

Je voudrais extraire le commit avant, modifier et valider, et ensuite fusionner le commit actuel avec lui. –

+0

Ne pas demander une balle magique ici. Je pensais juste que c'était un problème que beaucoup de gens auraient rencontré, et quelqu'un pourrait être en mesure de me diriger dans la bonne direction. Ignacio, je ne comprends pas ce que vous suggérez. Pouvez-vous s'il vous plaît développer? Merci! –

Répondre

3

Rerere ne vous aidera pas ici. Vous recherchez git filter-branch. Selon votre modification, vous pouvez utiliser le filtre d'index qui sera plus rapide que le filtre d'arborescence. Vous allez modifier tous vos SHA-1 suivants en faisant cela.

Assurez-vous d'inclure le paramètre --all afin que toutes les références soient mises à jour. Cela va ruiner tout repo qui utilise ce repo comme sous-module car les SHA-1 référenceront ceux qui n'existent pas. Vous devrez faire plus de scripts pour résoudre ce problème.

En outre, si quelqu'un avec qui vous travaillez a eu des commits non contraints, ils devront git rebase --onto leur travail exceptionnel sur la nouvelle place dans l'histoire.

Dans les années à venir, nous espérons voir plus de soutien pour la réalisation de telles manigances - en particulier lorsque des sous-modules sont impliqués.

+0

Merci! Avec des scripts intelligents, cela semble fonctionner pour les changements particuliers que je dois effectuer, car aucun de ces changements n'implique de code source réel. (Il suffit de modifier les messages de validation, d'écraser les validations et de supprimer les fichiers binaires.) –

+0

Je ne suis pas sûr que vous vouliez écraser les validations. mais vous pouvez demander à la branche filter de supprimer les validations vides. Ceux-ci peuvent se produire si un fichier que vous supprimez avait des validations qui ne l'affectaient que. Ce seront des commits vides après cela. Vous pouvez donc activer cette option pour les supprimer. Vous le savez probablement déjà, mais assurez-vous de faire des sauvegardes de votre repo avant de jouer avec filter-branch. –

-1

C'est ce que j'essaierais. Il n'y a pas de garantie, mais la peine d'essayer

  1. option Activer rerere (git config rerere.enabled true)
  2. option Activer rerere.autoupdate (git config rerere.autoupdate true)
  3. Retour à l'ancien commit et réparer, puis juste se fondre loin. J'espère que le rerere apprendra au fur et à mesure et commencera à résoudre automatiquement les conflits.
+0

Je l'ai essayé, mais pas de chance. Les mêmes conflits se produisent encore lors du rebasage. Merci quand même! –

Questions connexes