2010-02-11 5 views
4

Dans le GitFaq je peux lire, quegit change la date de modification des fichiers

Git définit l'heure actuelle comme l'horodatage sur chaque fichier qu'il modifie, mais seulement ceux-ci.

Cependant, j'ai essayé cette séquence de commande (EDIT: ajouté séquence de commande complète)

$ git init test && cd test 
Initialized empty Git repository in d:/test/.git/ 

$ touch filea fileb 

$ git add . 

$ git commit -m "first commit" 
[master (root-commit) fcaf171] first commit 
0 files changed, 0 insertions(+), 0 deletions(-) 
create mode 100644 filea 
create mode 100644 fileb 

$ ls -l > filea 

$ touch fileb -t 200912301000 

$ ls -l 
total 1 
-rw-r--r-- 1 exxxxxxx Administ  132 Feb 12 18:36 filea 
-rw-r--r-- 1 exxxxxxx Administ  0 Dec 30 10:00 fileb 

$ git status -a 
warning: LF will be replaced by CRLF in filea 
# On branch master 
warning: LF will be replaced by CRLF in filea 
# Changes to be committed: 
# (use "git reset HEAD <file>..." to unstage) 
# 
#  modified: filea 
# 

$ git checkout . 

$ ls -l 
total 0 
-rw-r--r-- 1 exxxxxxx Administ  0 Feb 12 18:36 filea 
-rw-r--r-- 1 exxxxxxx Administ  0 Feb 12 18:36 fileb 

Maintenant, ma question: Pourquoi git changer l'horodatage du fichier fileb? Je m'attendrais à ce que l'horodatage soit inchangé.

Mes commandes causent-elles un problème?
Peut-être qu'il est possible de faire quelque chose comme un git checkout . --modified à la place? J'utilise git version 1.6.5.1.1367.gcd48 sous mingw32/windows xp.

Répondre

2

Cela ne se produit pas sur un système de fichiers Linux. Je l'ai testé le scénario exact que vous avez décrit et mes temps de modification sont conservés pour les fichiers qu'il me reste intacte:

[email protected]:~/Desktop/test$ ls -la tests/BusTests.* 
-r--r--r-- 1 sean sean 8 2010-02-11 11:53 tests/BusTests.c 
-r--r--r-- 1 sean sean 1 2010-02-11 11:51 tests/BusTests.h 

[email protected]:~/Desktop/test$ git status -a 
# On branch master 
# Changes to be committed: 
# (use "git reset HEAD <file>..." to unstage) 
# 
#  modified: tests/BusTests.c 
# 

[email protected]:~/Desktop/test$ git checkout . 

[email protected]:~/Desktop/test$ ls -la tests/BusTests.* 
-r--r--r-- 1 sean sean 1 2010-02-11 11:55 tests/BusTests.c 
-r--r--r-- 1 sean sean 1 2010-02-11 11:51 tests/BusTests.h 

Je soupçonne que c'est un bogue inconnu dans la construction de mingw32 de Git, vous pouvez le signaler à les développeurs: http://code.google.com/p/msysgit/issues/list

Il serait intéressant de voir si le timbre de modification BusTests.h est modifiée lorsque vous n'extrayez le fichier modifié:

git checkout -- tests/BusTests.c 
+0

Merci pour votre effort, 'git checkout - tests/BusTests.c' fonctionne comme prévu. – tanascius

+0

J'ai ajouté une séquence de commandes complète à ma question ... peut-être que vous pouvez essayer de reproduire cela une fois de plus? – tanascius

0
git ls-files -m | xargs git co -- 

aide à vérifier seulement les fichiers modifiés. Mais je ne peux toujours pas expliquer, pourquoi git checkout provoque les problèmes.

0

J'ai remarqué un problème similaire avec git reset --hard à partir de msysgi t version 1.7.0.2. Avant, il ne modifiait que l'horodatage des fichiers modifiés. Maintenant, il change l'horodatage de tous les fichiers. Je suis retourné à l'utilisation de 1.6.5.1 pour cette raison, car il n'a pas ce problème :)

Questions connexes