Pourquoi git pense que c'est un conflit après Cherrypick?

J'utilise TortoiseGit sur windows, j'ai 2 branches. Mais quand je passe mon cherrypick de l'autre branche, je reçois très souvent des rapports de "confilict". Mais quand j'ai essayé de résoudre ces 'conflits', beaucoup de fois je suis assez confus et en colère (comme dans le cas de la capture d'écran ci-dessous), comment cela peut-il être conflictuel? Un fichier n'a rien alors que l'autre fichier a de nouvelles lignes, cela ne pourrait pas être plus simfller. Pourquoi git traiter cela comme un conflit? Quelqu'un peut-il expliquer? Merci ..Pourquoi git pense que c'est un conflit après Cherrypick?

Source

2015-09-30 actan

Je pense que vous devriez publier ceci à la communauté de développeurs Git d'une manière ou d'une autre, car je ne vois pas de conflit du tout, et ce pourrait être un bug. Voir http://git-scm.com/community – SzG

@SzG Il y a un conflit ... regardez de près. La méthode 'toString()' est en conflit en raison du choix de cerise. –

Ce n'est pas en conflit. C'est simplement du nouveau code dans un contexte clairement défini. – SzG

Lorsque vous choisissez une cerise commettras d'une autre branche, vous faites une nouvelle commettras sur cette branche. Comme pour tout commit, il existe un risque de conflits de fusion.

Je crois que la source de votre confusion est que le commit que vous choisissez est déjà dans une autre branche, et que vous avez déjà résolu tous les conflits de fusion pour ce commit. Donc, intuitivement, il semble que ce commit devrait être portable dans une autre branche sans aucun problème. Le problème est que lorsque vous choisissez cette validation dans une autre branche, la base sur laquelle ce commit est situé a changé. Par conséquent, vous pouvez (et vous le faites souvent) obtenir des conflits de fusion.

Source

2015-09-30 04:50:13

Le texte entre les marqueurs de conflit n'indique aucun conflit.Le conflit est entre rien et quelque chose dans le même contexte, qui est la définition même de l'absence de conflit. Je suis déconcerté aussi. – SzG

Dans votre image ci-dessus, il y a un conflit _massive_, avec environ 30 lignes de nouveau code provenant du choix de la cerise commit '9bd0f1f ... ' –

Non, ce n'est pas un conflit du tout. C'est juste un morceau de nouveau code ajouté à un contexte clairement défini dans la branche source. – SzG

J'ai reproduit un cas où il y a un vrai conflit derrière un non-conflit apparent rien-à-rien.

base commit:

foo 
bar 
baz

un commit sur le maître supprime baz

foo 
baz

un commit sur une autre branche ajoute quelque chose à la même position

foo 
spam 
bar 
baz

Lorsque je tente de fusionner la branche en maître, je reçois ce conflit:

foo   
<<<<<<< HEAD 
=======  
spam   
bar   
>>>>>>> plus 
baz

Apparemment, une fausse alarme, rien sur le maître, a ajouté quelque chose sur l'autre branche.

Mais en réalité, l'alarme n'est pas fausse, mais l'information mise dans le fichier par Git est définitivement fausse: elle liste bar, supprimée sur le maître, comme ajoutée sur l'autre branche. Donc, Git est buggé, mais de façon très subtile et surprenante. Ils essayent apparemment d'intégrer certaines informations dans la notation >>>>>>>=======<<<<<<<, mais un conflit remove-add ne rentre pas dedans, car il a besoin d'informations supplémentaires sur la base de fusion. Ou tout autre moyen de dire "ajouté par eux" de "gardé par eux".

Source

2015-09-30 21:35:04 SzG

Pourquoi git pense que c'est un conflit après Cherrypick?

Répondre

Questions connexes