git status a qu'à regarder à chaque fichier dans le référentiel de tous les temps. Vous pouvez le dire d'arrêter de regarder les arbres que vous ne travaillez pas avec
git update-index --assume-unchanged <trees to skip>
source
À partir de la page de manuel:
Lorsque ces indicateurs sont spécifiés, la
les noms d'objets enregistrés pour les chemins
ne sont pas mis à jour. Au lieu de cela, ces
les options de jeu et de désactiver la "assumer
inchangé" bits pour les chemins. Lorsque l'
"supposons inchangé" bit est sur, git
arrête le contrôle du travail de l'arborescence de fichiers
pour d'éventuelles modifications, de sorte que vous
besoin de désactiver manuellement le peu de dire
git lorsque vous modifiez l'arbre de travail
fichier. C'est parfois utile lorsque
travailler avec un grand projet sur un
système de fichiers qui a très lent lstat(2)
système d'appel (par exemple, cifs).
Cette option peut également être utilisé comme un
grossier fichier mécanisme au niveau de l'ignorer
les modifications non validées dans le suivi des fichiers
(semblable à ce que .gitignore pour
sans traces de fichiers). Git va échouer
(gracieusement) dans le cas où il doit
modifier ce fichier dans l'index par exemple
lors de la fusion dans un commit; ainsi, dans
cas de l'hypothèse-sans traces de fichier est
changé en amont, vous aurez besoin de
face à la situation manuellement.
De nombreuses opérations de git dépendent de votre
système de fichiers efficace
lstat(2) la mise en œuvre, de sorte que
st_mtime informations pour l'arbre de travail
les fichiers peuvent être bon marché vérifié pour voir si
le contenu de ce fichier ont changé de
la version enregistrée dans l'index
fichier. Malheureusement, certains systèmes de fichiers
ont inefficace lstat(2). Si votre
système de fichiers est l'un d'entre eux, vous pouvez définir
"supposons inchangé" peu de chemins
n'ont pas changé à cause git de ne pas
faire cette vérification. Notez que la définition de ce
bits sur un chemin d'accès ne signifie pas git va
vérifiez le contenu du fichier pour voir
si elle a changé - il fait que git
omettre aucune vérification et de supposer qu'il a
pas changé. Lorsque vous apportez des modifications à
de travail de l'arborescence de fichiers, vous devez
explicitement indiquer à git à ce sujet par
lâchant "assumer inchangé" peu,
que ce soit avant ou après la modification
eux.
...
Afin de mettre en "assumer inchangé"
bits, utilisez --assume-inchangé option. Pour
unset, utilisez l'option --no-supposons-inchangé.
La commande est à la base.ignorestat
variable de configuration. Lorsque cela est
vrai, les chemins de mise à jour avec git
mise à jour de l'index des chemins... et les chemins de mise à jour
avec d'autres commandes git que la mise à jour
les deux index et de l'arbre de travail (par exemple, git
s'appliquer, index, git checkout-index-u,
et git lecture de l'arbre -u) sont
automatiquement marqué comme "assumer
inchangé". À noter que "l'assumer
inchangé" bit n'est pas défini si git
mise à jour de l'index --refresh trouve le
de travail de l'arborescence de fichier correspond à l'indice de
(l'utilisation de git update-index-vraiment-actualisation
si vous souhaitez marquer comme "assumer
stable").
Maintenant, clairement, cette solution n'est d'aller travailler si il y a des parties de l'opération que vous pouvez facilement ignorer. Je travaille sur un projet de taille similaire, et il y a certainement de grands arbres que je n'ai pas besoin de vérifier sur une base régulière. La sémantique de git-le statut en faire un général O(n) problème (n nombre de fichiers). Vous avez besoin d'un domaine spécifique des optimisations à faire mieux que ça.
Notez que si vous travaillez dans une configuration de couture, qui est, si vous intégrer des modifications de l'amont par fusion au lieu de cela, alors cette solution devient de moins en moins pratique, en raison d'une modification à un --assume-inchangé objet de la fusion dans de l'amont devient un conflit de fusion. Vous pouvez éviter ce problème avec un rebasage de flux de travail.
