Pousser à distance git repo conserve l'ancien arbre dans l'index

Question

J'ai une configuration git avec deux dépôts, tous les deux sont en lecture/écriture (je code habituellement sur un, mais parfois je code sur l'autre aussi). Mon flux de travail est généralement que je travaille sur mon rapport local, et quand je suis prêt à tester mes changements, je pousse mes commits à l'autre repo distant où je construis réellement mon projet. Pour une raison quelconque, quand je pousse de local à distant, les changements sur le référentiel distant sont "inversés", ie le référentiel est mis à jour, mais l'inverse des changements (ie les changements qui ramèneraient le repo distant à son état pré-poussé) sont enregistrés dans l'index.

Par exemple, dire que j'ai un fichier avec un commentaire // This is a comment que j'ai mis à jour pour dire // This is a comment that has been updated localement, puis poussé à mon repo à distance, je reçois le texte suivant sur mon repo à distance:

remote_repo$ git diff --cached 
-// This is a comment that has been updated 
+// This is a comment 

Évidemment, je peux les amener dans le même état en exécutant git reset --hard, mais y a-t-il un autre moyen de le faire et/ou de l'automatiser? Je m'attends à ce que la plupart des gens suggèrent d'ajouter un hook post-réception qui court git reset --hard, mais j'espère que c'est configurable d'une manière propre.

Answer 1

Vraisemblablement, vous poussez vers la branche qui est actuellement vérifiée sur l'autre repo.

L'option de configuration applicable est receive.denyCurrentBranch. Son but original (et je crois que le défaut actuel ... donc je suis surpris si vous n'avez pas rencontré cette option auparavant) était d'éviter la situation de "changements inverses d'index" en rejetant simplement les poussées qui mettraient à jour la tête actuelle .

Tant que vous gardez l'arbre de travail sur le "autre" repo propre, il n'y a aucune raison pour laquelle vous ne pouvez pas avoir votre gâteau et le manger. Si vous définissez receive.denyCurrentBranch à updateInstead, alors git ira de l'avant et mettra à jour la tête, puis fera un checkout pour synchroniser l'index et l'arbre de travail - tant qu'ils sont propres.

Si vous voulez vivre dangereusement, vous pouvez configurer même autour de cette restriction en utilisant le crochet push-to-checkout.

MISE À JOUR - ne songeais pas à cet angle car les arbres liés de travail ne sont pas mentionnés dans la question, mais comme torek souligne: si vous utilisez des arbres de travail liés (c.-à-git worktree add) dans le repo recevant une poussée , le paramètre receive.denyCurrentBranch ne protégera pas la branche à laquelle un arbre de travail lié est extrait; seul l'arbre de travail principal est protégé. Si nécessaire, j'imagine que vous pourriez écrire un crochet post-réception pour imiter le comportement de updateInstead pour les arbres liés.