Qu’est-ce que ce message d’avertissement Git lors de l’envoi de modifications à un référentiel distant?

La description est un peu laconique. J’ai simplement ajouté un fichier sur ma twig maître locale et l’ai renvoyé à un repo distant. Avez-vous une idée de ce qui se passe?

 avertissement: mise à jour de la twig actuelle
 avertissement: la mise à jour de la twig actuellement extraite peut entraîner une confusion,
 avertissement: comme l'index et l'arborescence ne reflètent pas les modifications contenues dans HEAD.
 avertissement: En conséquence, vous pouvez voir les changements que vous venez de faire
 avertissement: retourné quand vous exécutez 'git diff' là-bas, et vous voudrez peut-être
 avertissement: pour lancer 'git reset --hard' avant de commencer à travailler pour récupérer.
 Attention: 
 avertissement: vous pouvez définir la variable de configuration 'receive.denyCurrentBranch' sur
 avertissement: 'refuser' dans le repository distant pour interdire de pousser dans son
 avertissement: twig actuelle.
 avertissement: pour permettre de pousser dans la twig en cours, vous pouvez le définir sur "ignorer";
 avertissement: mais ce n'est pas recommandé, sauf si vous avez mis à jour son travail
 avertissement: arbre pour correspondre à ce que vous avez poussé d'une autre manière.
 Attention: 
 avertissement: pour supprimer ce message, vous pouvez le définir sur "avertir".
 Attention: 
 avertissement: Notez que la valeur par défaut changera dans une future version de git
 avertissement: refuser de mettre à jour la twig en cours sauf si vous avez la
 warning: variable de configuration définie sur «ignore» ou «warn».   

En fait, cela signifie à peu près exactement ce que cela dit: quelqu’un travaille dans le référentiel auquel vous poussez, et quelqu’un a déjà vérifié exactement la même twig que celle vers laquelle vous poussez.

C’est très déroutant, car il pense maintenant avoir vérifié la dernière version de la twig, alors que vous venez de mettre à jour la twig vers une version plus récente. Donc, quand il exécute git commit , son commit annulera essentiellement tous les commits que vous venez de faire. Et quand il court git diff il verra le contraire de tout ce que tu viens de pousser, même s’il n’a peut-être même rien changé.

Pour cette raison, il est généralement considéré comme une mauvaise pratique de transférer vers un référentiel non nu. vous ne devriez jamais pousser pour mettre à jour les référentiels, c’est-à-dire les référentiels qui n’ont pas de copie de travail attachée. À tout le moins, vous devez vous assurer que vous ne poussez pas vers la twig actuellement extraite, mais en général, vous ne devriez pas simplement insérer votre code dans le repository de quelqu’un d’autre, vous devriez leur demander de vous retirer à la place.

Dans certains cas particuliers, comme lorsque vous hébergez un site Web à partir d’un référentiel Git et que vous souhaitez mettre à jour le site Web en y accédant, il est logique de passer à la twig actuellement extraite, mais vous devez vous assurer que que vous avez installé un hook qui met à jour la copie de travail extraite, sinon votre site Web ne sera jamais mis à jour.

Si personne ne travaille dans ce repo distant, alors il devrait être possible de passer à une twig extraite.

Mais pour être plus sûr dans cette opération, vous pouvez maintenant (avec Git 2.3.0, février 2015), faire dans ce repo à distance:

 git config receive.denyCurrentBranch updateInstead 

Il est plus sécurisé que config receive.denyCurrentBranch=ignore : il ne permettra la diffusion que si vous ne remplacez pas la modification en cours.

Voir commettre 1404bcb par Johannes Schindelin ( dscho ) :

receive-pack : ajoute une autre option pour receive.denyCurrentBranch

Lors de la synchronisation entre les répertoires de travail, il peut être utile de mettre à jour la twig en cours via « push » plutôt que « pull », par exemple lors de l’envoi d’un correctif depuis une machine virtuelle pas de liberté pour installer un démon ssh et encore moins connaître le mot de passe de l’utilisateur).

La solution de contournement commune, qui consiste à insérer une twig temporaire puis à fusionner sur l’autre machine, n’est plus nécessaire avec ce correctif.

La nouvelle option est la suivante:

 updateInstead 

Mettez à jour l’arborescence de travail en conséquence, mais refusez de le faire s’il y a des modifications non validées.


Le commit 4d7a5ce ajoute plus de tests et mentionne:

Le précédent teste uniquement le cas où un chemin d’access à mettre à jour par le déploiement automatique présente un changement incompatible dans l’arborescence de travail de la cible qui a déjà été ajoutée à l’index, mais la fonctionnalité elle-même nécessite que l’arborescence de travail soit beaucoup plus propre que ce qui est testé.

Ajoutez une poignée de tests supplémentaires pour protéger la fonctionnalité des modifications futures qui, à tort (du sharepoint vue de l’inventeur de la fonctionnalité), libèrent les exigences de propreté, à savoir:

  • Un changement uniquement dans l’arborescence de travail mais pas dans l’index est toujours un changement à protéger;
  • Un fichier non suivi dans l’arborescence de travail qui serait remplacé par un déploiement automatique doit être protégé.
  • Un changement qui rend un fichier identique à ce qui est poussé rest un changement à protéger (c.-à-d. Que l’exigence de propreté de la fonctionnalité est plus ssortingcte que celle de la validation).

En outre, testez qu’une modification de l’arborescence de travail comportant uniquement des statistiques ne constitue pas une raison de rejeter un déploiement automatique.

C’est le même problème que Cette question , la solution consiste à utiliser git init --bare ou git clone --bare .