2010-06-23 5 views
2

J'essaie d'obtenir git pour me permettre des fusions très manuel en raison de la façon dont mon code est (longue histoire, il est explained here). Je l'ai presque fait comme je le voulais, juste quelque chose qui manque dans une situation spécifique. Ne devrait pas être trop difficile: J'ai le pilote personnalisé pour utiliser WinMerge avec quelque chose comme c:/wm/winmerge.exe $1 $2 $3 (dans c: /wm/wmrg.sh), git config merge.mnl.driver = "c:/wm/wmrg.sh %B %A %A" et le echo *.xml merge=mnl > $GIT_DIR/info/attirbutes.Git fusionner problème de pilote

Maintenant quand je git merge dev, il ouvre WinMerge un laissez-moi faire le travail - brillant. Juste travail na pas dans la situation suivante:

Avoir mes deux branches (maître et dev) engagé avec quelques modifications en attente dans dev à fusionner en production.

  1. Retour à master
  2. Renommer des fichiers sans rapport avec les changements (permet de dire, certains readme.txt à Manual.txt) dans dev et commettre
  3. Aller à dev et fusionner ces changements de master Le nouveau pilote entre en jeu et vous demande s'il doit passer ces configs aux autres fichiers en dev. [] Vous quittez WinMerge sans enregistrer, donc pas migrer les informations. Après avoir terminé la recherche XML est le txt ne sont pas filtrés et sont renommés en dev ]
  4. maintenant à la master, fusion dev

Ici, je me attends le conducteur à coup à nouveau et se comporter la même chose au sujet du XML. Pour une raison quelconque, quand vous essayez de git merge dev, il décide de fusionner tout cela!

Y a-t-il une sorte de configuration 'par branche' qui m'amène ici? peut-être après git se rend compte que je n'ai pas fait de changements après une dernière fusion, il peut simplement écraser les fichiers dans une certaine direction .. ou même, le type de fusion est basé sur une nouvelle règle plus ancienne qui trouve la situation triviale quel fichier devrait décide être conservé quel que soit son contenu ...

s'il vous plaît conseiller ..

grâce

+0

Je n'ai pas encore réussi à éviter l'intelligence GIT, mais j'ai réussi à utiliser 'cherry-pick' pour appliquer les changements de nom dans ma branche ** dev ** sans subir les auto-fusions. – filippo

Répondre

1

Je pense que je l'ai compris .. Ce que j'ai ici est en fait un problème conceptuel. Ca ne peut pas vraiment être fait en git, du moins pas comme je le voulais.

tout cet effort était de faire en sorte que lorsque mon cycle de développement est fait, j'aurais dev et maître branches au même niveau engagent. Théoriquement, ne différant que par quelques lignes qui sont propres à leur environnement, mais tout le reste du code reste le même. Si je me trompe, chaque commit dans git est identifié SHA-1 à partir de cette version, donc si un fichier diffère d'un caractère, il ne peut pas être le même commit.

Le problème que je décris ci-dessus est sera git juste être intelligent et de trouver un moyen de rendre maître et dev exactement le même basé sur mes actions, obtenant ainsi dans l'état final.

Comme je l'ai commenté, je réussi à appliquer des modifications spécifiques en arrière en utilisant cherry-pick, mais la seule façon d'avoir maître et dev correctement suivi seraient à l'aide des filtres d'extension de mot-clé (comme décrit par VonC here et here, et bien d'autres là-bas)

Merci pour toute l'aide,

f.

+0

Commentaires intéressants. Je suis d'accord avec votre conclusion. – VonC

1

Git peut considérer que:

  • depuis maître ont été fusionnées à dev (même si certains fichiers ont été laissés intacts)
  • La fusion de dev en master est triviale car le seul delta restant est les nouveaux fichiers, pas les fichiers modifiés.

Et puisque le pilote de fusion ne se lancerait que pour les fichiers communs, il ne le ferait pas dans le cas de la deuxième fusion.

+0

Je suis d'accord, ça a du sens. Je me demande s'il y a un moyen d'empêcher cela. Je regardais dans le manuel de .gitattributes et le statut de sortie de fusion pourrait avoir un certain effet ... fera quelques expériences. – filippo