2010-09-13 22 views
1

J'ajoute de nouveaux fichiers (qui étaient auparavant présents en tant que fichiers non-suivis) et les valide. Lorsque je checkout avant cette validation, ces fichiers sont supprimés. Ils ne devraient pas.git checkout HEAD ~ 2 (exemple) supprime les fichiers non suivis s'ils ont été ajoutés avec la dernière validation

Peu importe si .gitignore répertorie ces fichiers ou non (ce qui nécessite de faire git add -f ...).

+1

Etes-vous sûr que vous êtes le pouvoir de suggérer ce qui * devrait * arriver? Cela me semble parfaitement logique. ces fichiers n'existent pas au moment de votre paiement. –

Répondre

3

Ils ne doivent pas être supprimés.

Oui, ils le devraient. Les validations sont des états historiques. Vous vérifiez un état avant qu'ils ont été commis, donc ils ne devraient pas être là. Imaginez-vous travailler sur votre projet dans un an. La moitié des fichiers ont été renommés, il y a des dizaines de nouveaux fichiers, et pour une raison quelconque, vous décidez de vérifier la version d'aujourd'hui. Vous ne voudriez sûrement pas que toutes ces douzaines de fichiers se contentent de l'encombrer! Ils n'appartiennent pas là! (Et bien sûr "les fichiers non suivis ... ajoutés avec la dernière validation" n'a pas de sens - si vous les avez validés, ils sont maintenant suivis.)

Si les fichiers vraiment devraient ont été dans l'ancien commit, probablement ce que vous voulez faire est d'utiliser un rebase interactif (git rebase -i <start commit> <branch>, d'autres instructions fournies par git) pour écraser un couple commits ensemble. Vous devrez peut-être également réorganiser les validations, en poussant le commit "ajouter ces fichiers" plus loin dans l'historique auquel il appartient. Ou, si vous remarquez cela juste après avoir oublié d'ajouter les fichiers, ajoutez-les simplement et utilisez commit --amend pour modifier le commit précédent au lieu de créer un fichier séparé. Enfin, si vous avez vraiment ce jeu dans l'historique de cette façon (d'autres ont tiré de sorte que vous ne voulez pas rebasier/modifier), vous pouvez vérifier l'ancien commit, puis vérifier les fichiers de la plus récent engagement:

git checkout <old-commit> 
git checkout <new-commit> file1 file2 dir1 dir2/file3 ... 
+0

Vos conclusions sont justes, car finalement propres.En effet je ne veux pas modifier l'historique - seule la dernière proposition s'applique. Seul but de cette action: comparer le comportement du programme cible à cause d'un bug. Votre solution avec deux checkouts fournit le même effet que ma solution avec diff/checkout/apply – Rob

+0

Pour être précis: techniquement il est tout à fait possible de ne pas supprimer les fichiers lors du retour à un commit précédent: Imaginez un grand pas en arrière . Alors que la «machine» travaille en interne à travers l'histoire, à chaque frontière entre «suivi» et «non suivi», elle pourrait décider de laisser ce (s) fichier (s) dans cet état juste au-delà de cette frontière. – Rob

+0

@Rob: Donc, vous pensez que lorsque vous extrayez un ancien commit, vous devriez vous retrouver avec l'union des fichiers existants de ce commit vers le futur? Si votre code charge dynamiquement tous les plugins disponibles, et s'il existe des plugins dans la future version qui ne fonctionneront pas avec l'ancienne version, que se passe-t-il s'il existe deux branches divergentes ayant le commit extrait comme ancêtre? quelle version de la branche à mettre dans l'arbre? Ce n'est pas du tout une idée cohérente.Si vous vérifiez un état, le VCS doit effectivement mettre les choses dans cet état – Cascabel

2

Vérifiez simplement HEAD à nouveau et vous récupérez ces fichiers. Git checkout HEAD ~ 2 rétablit le répertoire de votre référentiel à suivi statut que vous aviez il y a deux ans. C'est un comportement totalement attendu.

+0

+1: Git n'a aucune idée si vous avez ajouté ces objets nouvellement suivis juste avant le checkin où vous les avez validés (d'habitude, vous devriez donc les supprimer) ou si vous les avez laissés traîner dans votre dépôt (décidément inhabituel, pourquoi ne les avez-vous pas ajoutés plus tôt?). –

+0

Pourquoi ne les ai-je pas ajoutés plus tôt? Parce que je suis un humain ... et cela m'empêche de reconstruire les anciens commits. – Rob

+0

Vérifiez l'état git avant de valider et vérifiez si tous les fichiers requis sont validés/suivis. – halfdan

0

Solution possible lorsque la dernière livraison ne contient que les ajouts de fichiers:

$ git diff HEAD^ >diff 
$ git checkout HEAD^ 
$ git apply diff 

A cette époque, la branche se détache et contient les fichiers précédemment trassez. Dorénavant, d'autres vérifications dans l'historique des validations sont possibles et cohérentes.

0

Vous aimeriez peut-être que git commit --amend ajoute du contenu au précédent commit que vous avez oublié.