Git rebase “supprimé par nous” et “supprimé par eux”

Supposons que je reformule la twig d’ expérience sur master et qu’il y ait des conflits dans les fichiers. Et bien sûr, il y a des fichiers supprimés dans les deux twigs. Donc, quand je résous les conflits, en git status je vois que deleted by us deleted by them et les deleted by them . C’est très déroutant. Y a-t-il un moyen de comprendre ce qu’ils veulent dire? Qui sont- ils et qui sumsnous ?

Ou, lors du rebasage, existe-t-il un autre moyen de savoir quel fichier a été supprimé par quelle twig? Vous souhaitez imprimer le nom de la succursale?

Documentation de référence

Notez qu’une fusion par fusion fonctionne en relisant chaque validation depuis la twig de travail située au-dessus de la twig . De ce fait, lorsqu’un conflit de fusion survient, le côté signalé comme le nôtre est la série rebasée, commençant par , et la leur est la twig de travail. En d’autres termes, les côtés sont échangés.

https://git-scm.com/docs/git-rebase/2.17.0 (le plus récent: https://git-scm.com/docs/git-rebase )

Par conséquent, les fichiers “supprimés par nous” sont ceux qui ont été supprimés sur la twig sur laquelle vous effectuez un changement de nom (la dernière twig), et les fichiers “supprimés par eux” sont supprimés dans la twig chuté).

Manifestation

 $ ls a $ git log --oneline --graph --decorate --all * d055cdd (HEAD -> y) Write baz in a-file | * 487dc8c (x) Write bar in a-file |/ * 3fa0da5 (master) Write foo in a-file $ git rebase x First, rewinding head to replay your work on top of it... Applying: Write baz in a-file Using index info to reconstruct a base tree... M a Falling back to patching base and 3-way merge... Auto-merging a CONFLICT (content): Merge conflict in a error: Failed to merge in the changes. Patch failed at 0001 Write baz in a-file The copy of the patch that failed is found in: .git/rebase-apply/patch When you have resolved this problem, run "git rebase --continue". If you prefer to skip this patch, run "git rebase --skip" instead. To check out the original branch and stop rebasing, run "git rebase --abort". $ cat a <<<<<<< HEAD bar ======= baz >>>>>>> Write baz in a-file $ git checkout --ours a $ cat a bar $ git checkout --theirs a $ cat a baz 

AFAIK il n’y a pas d’interrupteur pour afficher explicitement les noms spécifiques des twigs avec les outils officiels. À moins que je ne me trompe, ce n’est qu’une des choses que vous devez apprendre à surmonter la confusion initiale.

À leur crédit, cela fait beaucoup de sens si vous y réfléchissez.

Analyse plus pédante

Le texte de la page de manuel est un peu ambigu, car il pourrait être interprété comme pertinent uniquement lorsque vous utilisez l’option --merge . Ceci est exacerbé par une seconde mention du comportement dans --strategy : “Notez l’inversion de la nôtre et de la leur comme indiqué ci-dessus pour l’option -m.” .

Cependant, je crois que cela ne contraste pas avec le comportement de git-rebase lorsque --merge est utilisé avec quand il ne l’est pas; Je crois plutôt que cela contraste avec le comportement de git-rebase avec git-merge. La section MERGE STRATEGIES est clairement extraite de la page du manuel git-merge, il est donc assez facile d’imaginer que l’auteur ait ressenti le besoin de mettre l’accent sur le swap lors de l’utilisation de rebase car ce n’est pas mentionné dans cette section. La phrase suivante, à mon avis, confirme cette interprétation: “[…] git rebase relit chaque validation depuis la twig de travail située au-dessus de la twig en utilisant la stratégie donnée […]” .

Bien que nous comprenions maintenant que la stratégie de fusion ne devrait avoir aucun impact sur les côtés (seul le choix de git-merge vs git-rebase le devrait), je --merge que la stratégie par défaut implique --merge le comportement par défaut complètement non ambigu).

Voici une copie de la réponse de SzG sur une question similaire:

Lorsque vous fusionnez , us faisons référence à la twig dans laquelle vous fusionnez, par opposition à la twig à fusionner.

Lorsque vous vous rebassez , us référons la twig en amont, et c’est la twig sur laquelle vous vous déplacez. C’est un peu contre-intuitif en cas de rebase.

La raison en est que git utilise le même moteur de fusion pour rebase, et qu’il sélectionne en fait vos données dans la twig en amont. us = dans, them = de.