Se você não está dando nenhuma opção para patch diferente de -pN , ele cria apenas esses arquivos quando um patch não se aplica corretamente.
Então, uma opção é parar de criar (ou aceitar) patches ruins. :)
De volta ao mundo real, isso é uma característica. Quando patch(1) não aplica um segmento de correção ao arquivo original, ele salva a cópia do arquivo original temporário como *.orig , copia o segmento rejeitado para *.rej e continua tentando aplicar segmentos de correção. A ideia é que você possa abrir o arquivo *.rej e concluir o processo de correção manualmente, copiando os bits e as peças para o arquivo corrigido. O arquivo *.orig também pode ser útil quando o processo de patch acidentalmente destrói algo, e você precisa consultar a versão original para corrigi-lo.
Nem sempre corrijo um patch ruim com o texto dos arquivos *.rej e *.orig , mas é bom tê-los, caso eu precise deles.
Depois de corrigir um patch incorreto, eu corro o script a seguir na raiz do projeto para limpar rapidamente as coisas:
#!/bin/bash
find . '(' \
-name \*-baseline -o \
-name \*-merge -o \
-name \*-original -o \
-name \*.orig -o \
-name \*.rej \
')' -delete
Eu o chamo de cleanup-after-bad-patch porque o nome longo garante parcialmente a execução deste acidentalmente, já que ele pode remover arquivos que você ainda precisa. Para ser honesto, eu normalmente o executo digitando clean Tab Enter , sendo suficiente para encontrar este script no PATH em minhas máquinas de desenvolvimento. / p>
Os padrões adicionais verificados são para os arquivos produzidos pelo meu sistema de controle de versão escolha quando encontrar o mesmo problema durante uma operação de mesclagem. Você pode querer ajustá-lo para o seu VCS / Ferramentas SCM .