TL; version DR: la branche de suivi à distance origin/master
existait autrefois, mais elle n'existe pas maintenant, donc la branche locale source
suit quelque chose qui n'existe pas, ce qui est au mieux suspect - cela signifie qu'une fonctionnalité Git différente ne peut rien faire pour vous - et Git vous en avertit. Vous vous entendez très bien sans que la fonction de "suivi en amont" fonctionne comme prévu, c'est donc à vous de changer quoi que ce soit.
Pour une autre interprétation des paramètres en amont, voir Pourquoi dois-je "git push --set-upstream origin <branch>"?
Cet avertissement est une nouveauté dans Git, apparaissant en premier dans Git 1.8.5. Les notes de publication ne contiennent qu'une petite puce à ce sujet:
- "git branch -v -v" (et "git status") n'a pas fait la distinction entre une branche qui n'est basée sur aucune autre branche, une branche qui est synchronisée avec sa branche amont, et une branche qui est configurée avec une branche amont branche qui n'existe plus.
Pour décrire ce que cela signifie, vous devez d'abord connaître les "télécommandes", les "branches de suivi à distance" et comment Git gère le "suivi d'un amont". ( Les branches de suivi à distance sont un terme terriblement imparfait - j'ai commencé à utiliser des noms de suivi à distance place, ce qui, je pense, est une légère amélioration. Ci-dessous, cependant, j'utiliserai "branche de suivi à distance" pour la cohérence avec la documentation Git. )
Chaque "télécommande" est simplement un nom, comme origin
ou octopress
dans ce cas. Leur but est d'enregistrer des choses comme l'URL complète des endroits à partir desquels vous git fetch
ou mettez à git pull
jour. Lorsque vous utilisez 1, Git accède à cette télécommande (en utilisant l'URL enregistrée) et apporte l'ensemble de mises à jour approprié. Il enregistre également les mises à jour, en utilisant des "branches de suivi à distance".git fetch remote,
Une "branche de suivi à distance" (ou nom de suivi à distance) est simplement un enregistrement d'un nom de branche tel que vu pour la dernière fois sur une "télécommande". Chaque télécommande est elle-même un référentiel Git, elle a donc des branches. Les branches sur "origine" distante sont enregistrées dans votre référentiel local sous remotes/origin/
. Le texte que vous montriez dit qu'il ya une branche nommée source
sur origin
, et les branches nommées 2.1
, linklog
et ainsi de suite suroctopress
.
(Une branche "normale" ou "locale", bien sûr, n'est qu'un nom de branche que vous avez créé dans votre propre référentiel.)
Enfin, vous pouvez configurer une branche (locale) pour «suivre» une «branche de suivi à distance». Une fois que la branche locale L
est configurée pour suivre la branche de suivi à distance R
, Git appellera R
son "amont" et vous dira si vous êtes "en avance" et / ou "derrière" l'amont (en termes de commits). Il est normal (même recommandé) que la branche locale et les branches de suivi à distance utilisent le même nom (à l'exception de la partie du préfixe distant), comme source
et origin/source
, mais ce n'est pas vraiment nécessaire.
Et dans ce cas, cela ne se produit pas. Vous avez une succursale locale qui source
suit une succursale de suivi à distance origin/master
.
Vous n'êtes pas censé avoir besoin de connaître les mécanismes exacts de la façon dont Git configure une branche locale pour suivre une branche distante, mais ils sont pertinents ci-dessous, je vais donc montrer comment cela fonctionne. Nous commençons par le nom de votre succursale locale, source
. Il existe deux entrées de configuration utilisant ce nom, orthographié branch.source.remote
et branch.source.merge
. D'après le résultat que vous avez montré, il est clair que ceux-ci sont tous les deux définis, de sorte que vous verrez ce qui suit si vous exécutez les commandes données:
$ git config --get branch.source.remote
origin
$ git config --get branch.source.merge
refs/heads/master
Mettre ces ensemble, 2 cela indique Git que votre branche source
suit votre « branche de suivi à distance », origin/master
.
Mais maintenant, regardez la sortie de git branch -a
, qui montre tous les noms de branche de suivi locaux et distants dans votre référentiel. Les noms de suivi à distance sont répertoriés sous remotes/
... et il n'y en a pasremotes/origin/master
. Vraisemblablement, il y en a eu, à un moment donné, mais c'est parti maintenant.
Git vous dit que vous pouvez supprimer les informations de suivi avec --unset-upstream
. Cela effacera à la fois branch.source.origin
et branch.source.merge
et arrêtera l'avertissement.
Cependant, il semble assez probable que vous souhaitiez passer du suivi origin/master
à autre chose: probablement origin/source
, mais peut-être l'un des octopress/
noms.
Vous pouvez le faire avec git branch --set-upstream-to
, 3 par exemple:
$ git branch --set-upstream-to=origin/source
(en supposant que vous êtes toujours sur la branche "source", et que origin/source
c'est l'amont que vous voulez - il n'y a aucun moyen pour moi de dire laquelle, le cas échéant, vous voulez réellement).
(Voir aussi Comment faire pour qu'une branche Git existante suive une branche distante? )
Je pense que la façon dont vous êtes arrivé ici est que lorsque vous avez fait un git clone
, la chose à partir de laquelle vous avez cloné avait une branche master
. Vous aviez également une branche master
, qui était configurée pour suivre origin/master
(c'est une configuration normale et standard pour git). Cela signifiait que vous aviez branch.master.remote
et que vous vous branch.master.merge
mettiez à origin
et refs/heads/master
. Mais votre origin
télécommande a changé son nom de master
en source
. Pour correspondre, je crois que vous avez également changé votre nom local de master
en source
. Cela a changé les noms de vos paramètres, de branch.master.remote
à branch.source.remote
et de branch.master.merge
à branch.source.merge
... mais il a laissé les anciennes valeurs , donc branch.source.merge
c'était maintenant faux.
C'est à ce moment que le lien «amont» s'est rompu, mais dans les versions de Git antérieures à la 1.8.5, Git n'a jamais remarqué le paramètre cassé. Maintenant que vous avez la version 1.8.5, cela indique cela.
Cela couvre la plupart des questions, mais pas celle «Dois-je résoudre le problème». Il est probable que vous ayez travaillé autour de la rupture depuis des années maintenant, en faisant (par exemple, ). Si vous continuez à faire cela, il continuera à contourner le problème - donc, non, vous n'avez pas besoin de le résoudre. Si vous le souhaitez, vous pouvez utiliser pour supprimer l'amont et arrêter les plaintes, et ne pas avoir de succursale locale marquée comme ayant du tout en amont.git pull remote branch
git pull origin source
--unset-upstream
source
L'intérêt d'avoir un amont est de rendre diverses opérations plus commodes. Par exemple, git fetch
suivi de " git merge
fera généralement la bonne chose" si l'amont est défini correctement, et git status
après git fetch
vous dira si votre dépôt correspond à l'amont, pour cette branche.
Si vous voulez la commodité, réinitialisez le fichier amont.
1git pull
utilise git fetch
, et à partir de Git 1.8.4, ceci (enfin!) Met également à jour les informations de "branche de suivi à distance". Dans les anciennes versions de Git, les mises à jour n'étaient pas enregistrées dans les branches de suivi à distance avec git pull
, uniquement avec git fetch
. Étant donné que votre Git doit être au moins la version 1.8.5, ce n'est pas un problème pour vous.
2 Eh bien, ceci plus une ligne de configuration que j'ignore délibérément qui se trouve sous remote.origin.fetch
. Git doit mapper le nom "merge" pour comprendre que le nom local complet de la branche distante est refs/remotes/origin/master
. La cartographie presque toujours fonctionne comme cela, cependant, il est donc prévisible que master
va origin/master
.
3 Ou, avec git config
. Si vous voulez juste définir l'amont sur origin/source
la seule partie qui doit changer branch.source.merge
, et le git config branch.source.merge refs/heads/source
ferait. Mais --set-upstream-to
dit ce que vous voulez faire, plutôt que de vous obliger à le faire vous-même, c'est donc une «meilleure façon».