Je ne pense pas qu'un commit Git puisse enregistrer une intention comme "arrêter le suivi de ce fichier, mais ne le supprimez pas".
La mise en œuvre d'une telle intention nécessitera une intervention en dehors de Git dans tous les référentiels qui fusionnent (ou rebasent sur) un commit qui supprime le fichier.
Enregistrer une copie, appliquer la suppression, restaurer
La chose la plus simple à faire est probablement de dire à vos utilisateurs en aval d'enregistrer une copie du fichier, d'extraire votre suppression, puis de restaurer le fichier. S'ils tirent via rebase et "portent" des modifications au fichier, ils obtiendront des conflits. Pour résoudre de tels conflits, utilisez git rm foo.conf && git rebase --continue(si la validation en conflit comporte des modifications en plus de celles du fichier supprimé) ou git rebase --skip(si la validation en conflit n'a été modifiée que sur le fichier supprimé).
Restaurer le fichier comme non suivi après avoir extrait un commit qui le supprime
S'ils ont déjà récupéré votre validation de suppression, ils peuvent toujours récupérer la version précédente du fichier avec git show :
git show @{1}:foo.conf >foo.conf
Ou avec git checkout (par commentaire de William Pursell; mais n'oubliez pas de le retirer de l'index!):
git checkout @{1} -- foo.conf && git rm --cached foo.conf
S'ils ont pris d'autres mesures depuis le retrait de votre suppression (ou s'ils tirent avec rebase dans une HEAD détachée), ils peuvent avoir besoin d'autre chose que @{1}. Ils pourraient utiliser git log -gpour trouver le commit juste avant de retirer votre suppression.
Dans un commentaire, vous mentionnez que le fichier que vous souhaitez «décompresser, mais conserver» est une sorte de fichier de configuration nécessaire à l'exécution du logiciel (directement à partir d'un référentiel).
Conserver le fichier par défaut et l'activer manuellement / automatiquement
S'il n'est pas totalement inacceptable de continuer à maintenir le contenu du fichier de configuration dans le référentiel, vous pourrez peut-être renommer le fichier suivi de (par exemple) foo.confà foo.conf.default, puis indiquer à vos utilisateurs après cp foo.conf.default foo.confavoir appliqué la validation de changement de nom. Ou, si les utilisateurs utilisent déjà une partie existante du référentiel (par exemple un script ou un autre programme configuré par le contenu du référentiel (par exemple Makefileou similaire)) pour lancer / déployer votre logiciel, vous pouvez incorporer un mécanisme par défaut dans le lancement / processus de déploiement:
test -f foo.conf || test -f foo.conf.default &&
cp foo.conf.default foo.conf
Avec un tel mécanisme défaillant en place, les utilisateurs devraient être en mesure de tirer un commettras qui renomme foo.confà foo.conf.defaultsans avoir à faire un travail supplémentaire. De plus, vous évitez d'avoir à copier manuellement un fichier de configuration si vous effectuez des installations / référentiels supplémentaires à l'avenir.
La réécriture de l'historique nécessite de toute façon une intervention manuelle…
S'il est inacceptable de conserver le contenu dans le référentiel, vous voudrez probablement l'éliminer complètement de l'historique avec quelque chose comme git filter-branch --index-filter …. Cela revient à réécrire l'historique, ce qui nécessitera une intervention manuelle pour chaque branche / référentiel (voir la section «Récupération à partir de la rebase en amont» dans la page de manuel git rebase ). Le traitement spécial requis pour votre fichier de configuration serait juste une autre étape à effectuer lors de la récupération de la réécriture:
- Enregistrez une copie du fichier de configuration.
- Récupérez de la réécriture.
- Restaurez le fichier de configuration.
Ignorez-le pour éviter la récurrence
Quelle que soit la méthode que vous utilisez, vous souhaiterez probablement inclure le nom du fichier de configuration dans un .gitignorefichier du référentiel afin que personne ne puisse à git add foo.confnouveau par inadvertance (c'est possible, mais nécessite -f/ --force). Si vous avez plus d'un fichier de configuration, vous pouvez envisager de les `` déplacer '' tous dans un seul répertoire et d'ignorer le tout (en `` déplaçant '', je veux dire changer l'endroit où le programme s'attend à trouver ses fichiers de configuration, et obtenir les utilisateurs (ou le mécanisme de lancement / déploiement) pour copier / déplacer les fichiers vers leur nouvel emplacement; vous ne voudriez évidemment pas git mv un fichier dans un répertoire que vous ignorerez).