Uruchamianie „łatki” bez generowania plików * .orig i * .rej

Czy jest możliwe, aby powiedzieć patch, aby nie generować .origi .rejpliki? Uważam, że to bardzo denerwujące, że łatka je tworzy.

Jeśli nie podajesz żadnej opcji patchinnej niż -pN, tworzy te pliki tylko wtedy, gdy łatka nie zastosuje się czysto.

Tak więc jedną z opcji jest zaprzestanie tworzenia (lub akceptowania) złych łat. :)

W prawdziwym świecie jest to funkcja. Gdy patch(1)nie zastosuje segmentu poprawki do oryginalnego pliku, trwale zapisuje tymczasową kopię oryginalnego pliku, ponieważ *.origzrzuca odrzucony segment *.reji kontynuuje próbę zastosowania segmentów poprawki. Chodzi o to, że możesz otworzyć *.rejplik i ukończyć proces łatania ręcznie, kopiując bity i kawałki do łatanego pliku. *.origPlik może być również przydatna, gdy proces łata przypadkowo wraki coś i trzeba odnosić się do pierwotnej wersji, aby go naprawić.

Nie zawsze naprawiam złą łatkę z tekstem z plików *.reji *.orig, ale miło jest mieć je na wypadek, gdyby były potrzebne.

Po naprawieniu złej poprawki uruchamiam następujący skrypt w katalogu głównym projektu, aby szybko wyczyścić rzeczy:

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

Nazywam to, cleanup-after-bad-patchponieważ długa nazwa częściowo zabezpiecza przed przypadkowym uruchomieniem tego, ponieważ może usunąć potrzebne pliki. Szczerze mówiąc, zwykle uruchamiam go pisząc cleanTabEnter, że to wystarczy, aby znaleźć ten skrypt PATHna moich komputerach programistycznych.

Dodatkowe wzorce, które sprawdza, dotyczą plików wyjściowych mojego wybranego systemu kontroli wersji, gdy napotka ten sam problem podczas operacji scalania. Możesz dostosować to do swoich narzędzi VCS / SCM .

Aby powiedzieć patchowi, aby nie tworzył kopii zapasowych, po prostu pomiń -bwszystkie --backup-...opcje.

Aby nakazać, aby nie tworzył .rejplików, dodaj -r -opcję do polecenia.

--no-backup-if-mismatchOpcja pozwoli uniknąć pliki „.orig”.

Możesz także wypróbować --mergeopcję, która powoduje konflikt wewnątrz pliku.

We wszystkich przypadkach powinieneś mieć jakiś sposób, aby szybko wrócić do dobrego stanu, jeśli scalenie stanie się przytłaczające.

Utknąłem z łatką v2.5.4, która -r -powoduje, że tworzy pliki odrzucania o nazwie- .

Odkryłem, że --reject-file=np. Pusta wartość powoduje, że łatka kończy się niepowodzeniem z kodem wyjścia 2 JEŻELI próbuje zapisać plik odrzucenia. Jeśli nie ma żadnych odrzuceń, działa zgodnie z oczekiwaniami. Chociaż nie jest to kompletne rozwiązanie dla starszej wersji łatki, w niektórych okolicznościach może to być dopuszczalne lub pożądane.

Najlepsze, co mogłem wymyślić (co prawda sposób na zamiatanie brudu pod dywan) to -r <tmpfile>:

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

ponieważ w wersji 2.5.8 -r -faktycznie tworzy -plik.

łatka -p1 -B / dev / null -r - <plik.patch