Remarque: fallengamer a fait quelques tests en 2011 (ils peuvent donc être obsolètes), et voici ses conclusions :
Les opérations
- Le fichier est modifié à la fois dans le référentiel local et en amont
git pull
:
Git conserve de toute façon les modifications locales.
Ainsi, vous ne perdriez pas accidentellement les données que vous avez marquées avec l'un des indicateurs.
- Fichier avec
assume-unchanged
indicateur: Git n'écraserait pas le fichier local. Au lieu de cela, il produirait des conflits et des conseils sur la façon de les résoudre
- Fichier avec
skip-worktree
indicateur: Git n'écraserait pas le fichier local. Au lieu de cela, il produirait des conflits et des conseils sur la façon de les résoudre
- Le fichier est modifié à la fois dans le référentiel local et en amont, essayant de toute façon d'
utiliser les résultats en effectuant un travail manuel supplémentaire, mais au moins vous ne perdriez aucune donnée si vous aviez des modifications locales.
git stash
git pull
skip-worktree
- Fichier avec
assume-unchanged
indicateur: annule toutes les modifications locales sans possibilité de les restaurer. L'effet est comme ' git reset --hard
'. ' git pull
' l'appel réussira
- Fichier avec
skip-worktree
indicateur: Stash ne fonctionnerait pas sur les skip-worktree
fichiers. ' git pull
' échouera avec la même erreur que ci-dessus. Le développeur est obligé de réinitialiser manuellement l' skip-worktree
indicateur pour pouvoir cacher et terminer l'échec pull
.
- Aucune modification locale, fichier en amont modifié
Les deux indicateurs ne vous empêcheraient pas d'obtenir des modifications en amont. Git détecte que vous avez rompu votre promesse et choisit de refléter la réalité en réinitialisant le drapeau.
git pull
assume-unchanged
- Fichier avec
assume-unchanged
indicateur: le contenu est mis à jour, l'indicateur est perdu.
' git ls-files -v
' montrerait que l'indicateur est modifié en H
(de h
).
- Fichier avec
skip-worktree
indicateur: le contenu est mis à jour, l'indicateur est conservé.
' git ls-files -v
' afficherait le même S
drapeau qu'avant le pull
.
- Avec le fichier local modifié,
Git ne touche pas le fichier et reflète la réalité (le fichier promis d'être inchangé a été changé) pour le fichier.
git reset --hard
skip-worktree
assume-unchanged
- Fichier avec
assume-unchanged
indicateur: le contenu du fichier est rétabli. Le drapeau est réinitialisé à H
(de h
).
- Fichier avec
skip-worktree
indicateur: le contenu du fichier est intact. Le drapeau reste le même.
Il ajoute l'analyse suivante:
Il ressemble skip-worktree
est d' essayer très difficile de conserver vos données locales . Mais cela ne vous empêche pas d'obtenir des modifications en amont si cela est sûr. De plus, git ne réinitialise pas le drapeau pull
.
Mais ignorer la reset --hard
commande ' ' pourrait devenir une mauvaise surprise pour un développeur.
Assume-unchanged
l'indicateur pourrait être perdu sur l' pull
opération et les changements locaux à l'intérieur de ces fichiers ne semblent pas être importants pour git.
Voir:
Il conclut:
En fait, aucun des drapeaux n'est suffisamment intuitif .
assume-unchanged
suppose qu'un développeur ne doit pas modifier un fichier. Si un fichier a été modifié - alors ce changement n'est pas important. Cet indicateur est destiné à améliorer les performances des dossiers qui ne changent pas comme les SDK.
Mais si la promesse est rompue et qu'un fichier est réellement modifié, git rétablit le drapeau pour refléter la réalité. Il est probablement correct d'avoir des indicateurs incohérents dans des dossiers généralement non destinés à être modifiés.
D'un autre côté, skip-worktree
est utile lorsque vous demandez à git de ne jamais toucher à un fichier spécifique. Cela est utile pour un fichier de configuration déjà suivi.
Le référentiel principal en amont héberge une configuration prête pour la production, mais vous souhaitez modifier certains paramètres dans la configuration pour pouvoir effectuer des tests locaux. Et vous ne voulez pas vérifier accidentellement les modifications dans un tel fichier pour affecter la configuration de production. Dans ce cas, skip-worktree
fait une scène parfaite.
Avec Git 2.25.1 (février 2020), le "En fait, aucun des drapeaux n'est suffisamment intuitif" mentionné ci-dessus est clarifié:
Voir commit 7a2dc95 , commit 1b13e90 (22 janvier 2020) par brian m. carlson ( bk2204
) .
(Fusionné par Junio C Hamano - gitster
- dans commit 53a8329 , 30 janvier 2020)
( Git Mailing list )
doc
: dissuader les utilisateurs d'essayer d'ignorer les fichiers suivis
Signature: Jeff King
Signature: brian m. Carlson
Il est assez courant que les utilisateurs souhaitent ignorer les modifications apportées à un fichier que Git suit.
Les scénarios courants pour ce cas sont les paramètres IDE et les fichiers de configuration, qui ne devraient généralement pas être suivis et éventuellement générés à partir de fichiers suivis à l'aide d'un mécanisme de modèle.
Cependant, les utilisateurs découvrent les bits supposés inchangés et ignorés et essaient de les utiliser de toute façon.
Cela est problématique, car lorsque ces bits sont définis, de nombreuses opérations se comportent comme le souhaite l'utilisateur, mais elles ne sont généralement pas utiles lorsque vous git checkout
devez remplacer un fichier.
Il n'y a pas de comportement sensé dans ce cas, car parfois les données sont précieuses, comme certains fichiers de configuration, et parfois ce sont des données non pertinentes que l'utilisateur serait heureux de jeter.
Étant donné qu'il ne s'agit pas d'une configuration prise en charge et que les utilisateurs sont enclins à abuser des fonctionnalités existantes à des fins non intentionnelles, provoquant une tristesse et une confusion générales , documentons le comportement existant et les pièges dans la documentation pour git update-index
que les utilisateurs sachent qu'ils devraient explorer d'autres solutions.
De plus, fournissons une solution recommandée pour traiter le cas commun des fichiers de configuration, car il existe des approches bien connues utilisées avec succès dans de nombreux environnements.
La git update-index
page de manuel comprend désormais:
Les utilisateurs essaient souvent d'utiliser les bits assume-unchanged
et skip-worktree
pour dire à Git d'ignorer les modifications apportées aux fichiers suivis. Cela ne fonctionne pas comme prévu, car Git peut toujours vérifier les fichiers de l'arborescence de travail par rapport à l'index lors de l'exécution de certaines opérations. En général, Git ne fournit pas un moyen d'ignorer les modifications apportées aux fichiers suivis, donc des solutions alternatives sont recommandées.
Par exemple, si le fichier que vous souhaitez modifier est une sorte de fichier de configuration, le référentiel peut inclure un exemple de fichier de configuration qui peut ensuite être copié dans le nom ignoré et modifié. Le référentiel peut même inclure un script pour traiter l'exemple de fichier comme un modèle, le modifiant et le copiant automatiquement.
Cette dernière partie est ce que je décris un pilote de filtre de contenu typique basé sur des scripts smudge / clean .
.gitignore
à des fins similaires. Cette solution fonctionnerait-elle pour vous?