Exécution de «patch» sans générer de fichiers * .orig et * .rej

Est-il possible de dire de patchne pas générer .origet de .rejfichiers? Je trouve extrêmement ennuyeux que le patch les crée.

Si vous ne donnez aucune option à patchautre que -pN, il ne crée ces fichiers que lorsqu'un correctif ne s'applique pas correctement.

Ainsi, une option consiste à arrêter de créer (ou d'accepter) de mauvais correctifs. :)

De retour dans le monde réel, c'est une fonctionnalité. Lorsque patch(1)ne parvient pas à appliquer un segment de correctif au fichier d'origine, il enregistre durablement la copie du fichier d'origine temporaire sous *.orig, vide le segment rejeté *.rejet continue d'essayer d'appliquer des segments de correctif. L'idée est que vous pouvez ouvrir le *.rejfichier et terminer le processus de patch manuellement en copiant des morceaux dans le fichier patché. Le *.origfichier peut également être utile lorsque le processus de correction détruit accidentellement quelque chose et que vous devez vous référer à la version d'origine pour le réparer.

Je ne corrige pas toujours un mauvais patch avec le texte des fichiers *.rejet *.orig, mais c'est bien de les avoir au cas où j'en aurais besoin.

Une fois que j'ai corrigé un mauvais correctif, j'exécute le script suivant à la racine du projet pour nettoyer rapidement les choses:

#!/bin/bash
find . '(' \
    -name \*-baseline -o \
    -name \*-merge -o \
    -name \*-original -o \
    -name \*.orig -o \
    -name \*.rej \
')' -delete

Je l'appelle cleanup-after-bad-patchparce que le nom long assure partiellement contre l'exécution accidentelle, car il pourrait supprimer les fichiers dont vous avez encore besoin. Pour être honnête, cependant, je l'exécute normalement en tapant cleanTabEnter, cela suffit pour trouver ce script dans PATHsur mes machines de développement.

Les modèles supplémentaires qu'il vérifie concernent les fichiers générés par mon système de contrôle de version de choix lorsqu'il rencontre le même problème lors d'une opération de fusion. Vous pouvez l'ajuster pour vos outils VCS / SCM .

Pour dire correctif ne pas produire des sauvegardes omettre seulement les -bet toutes les --backup-...options.

Pour lui demander de ne pas créer de .rejfichiers, ajoutez l' -r -option à la commande.

L' --no-backup-if-mismatchoption évitera les fichiers ".orig".

Vous pouvez également essayer l' --mergeoption, qui crée un conflit dans le fichier.

Dans tous les cas, vous devriez avoir un moyen de revenir rapidement à un bon état si la fusion devient écrasante.

Je suis bloqué avec le patch v2.5.4 où -r -il crée des fichiers de rejet nommés -.

J'ai trouvé que, par --reject-file=exemple, une valeur vide entraîne l'échec du correctif avec le code de sortie 2 SI il essaie d'écrire un fichier de rejet. S'il n'y a aucun rejet, cela fonctionne comme prévu. Bien qu'il ne s'agisse pas d'une solution complète pour l'ancienne version du correctif, dans certaines circonstances, cela peut être acceptable ou souhaité.

Le mieux que j'ai pu trouver (certes un moyen de balayer la saleté sous le tapis) est d'utiliser -r <tmpfile>, à savoir:

# patch -r /tmp/deleteme.rej -i patchfile filetobepatched

car dans la v2.5.8, -r -crée réellement le -fichier.

patch -p1 -B / dev / null -r - <fichier.patch