J'ai fait ça tout l'après-midi et je vais mourir. Problème de journal Git tronqué, résoudre T T

Question

J'ai essayé toutes les méthodes et effectué des recherches sur Baidu et Google. https://my.oschina.net/lujian...

Answer 1

Je ne connais pas la raison précise, mais j'ai déjà rencontré des situations similaires, je peux me référer à certaines expériences :

1. N'utilisez pas git sur msys ou cygwin, utilisez le git officiel. Parce que git sur cygwin pense qu'il s'agit d'un environnement Linux, le codage par défaut est UTF et Windows n'utilise pas UTF, donc lors de l'ajout, il ne sera pas reconnu comme Windows et ne sera pas transcodé pour vous, ce qui entraînera un code tronqué.

2. S'il y a un problème d'encodage, n'essayez pas de modifier la configuration par défaut au préalable, mais référez-vous au 1

3. Ne copiez pas directement les dépôts git de différentes plateformes. Git lui-même a effectué beaucoup de travail de compatibilité, comme les fins de lignes. Si vous le copiez directement, git ne pourra pas modifier les fins de ligne, puis lorsque vous git status, vous constaterez que tous les fichiers ont changé.

Eh bien, si vous utilisez à nouveau le git officiel et la configuration d'encodage par défaut, il n'y aura probablement aucun problème.

Answer 2

Laissez-moi vous montrer la configuration que j'ai utilisée git bash Je ne sais pas quelle phrase est responsable de
commitencodingL'encodage du journal soumis et enregistré dans la bibliothèque de versions. l'encodage réel enregistré dans la bibliothèque, alors il n'y a pas d'autre moyen.
logoutputencoding devrait être l'encodage utilisé pour le donner à shell S'il est différent, il doit être converti.
gui.encoding semble être l'encodage utilisé par le paramètre git bash. C'est la même chose que logoutputencoding, j'ai défini les deux sur utf-8.

[i18n]
    commitencoding = utf-8
    logoutputencoding = utf-8
[gui]
    encoding = utf-8
[core]
    quotepath = false
[i18n "commit"]
    encoding = utf-8