Я внес некоторые изменения в проект с открытым исходным кодом, не занимая время для создания надлежащих файлов исправления.
Теперь, специалист по обслуживанию проекта выпустил новую версию, и среди новых и отредактированных файлов, существует набор переименованных файлов.
То, каков лучший способ, должно применить мои изменения в новой версии?
Я абсолютно плохо знаком с использованием разности/патча, и Если бы я мог сделать его с мерзавцем, это было бы лучше.
Если у вас есть два похожих каталога a
и b
, и вы хотите, чтобы b
был таким же, как a
, вы можете создать и применить патч с помощью:
$ diff -ur b a > ba.diff
$ patch -i ba.diff
Предположим, у вас есть каталоги local
(содержащие ваш локальный версия upstream1.0), upstream1.0
и upstream1.1
. Чтобы создать и применить ваши изменения к upstream1.1
:
$ diff -ur upstream1.0 local > my.diff
$ cd upstream1.1
$ patch -i ../my.diff
Проверьте документацию на наличие патча и попытайтесь убедить сопровождающих апстрима использовать git. Все будет намного проще, если вы сможете использовать инструменты git для работы с вашим локальным репозиторием.
Если проект находится под git, и вы не зафиксировали свои изменения локально, вы можете просто выполнить git diff> file.patch
чтобы получить исправляемые данные различий. Если вы зафиксировали изменения локально, вы можете выполнить git log
, чтобы найти фиксацию перед вами, а затем git diff commit_string> file.patch
.
Если проект не находится под git, или если вы используете исходный код без клонирования репозитория (как следует из названия), вы можете использовать diff -urN original_dir new_dir> file.patch
для создания файл патча. В обоих случаях вы можете попробовать использовать патч позже, чтобы применить патч.
Тем не менее, рассмотрите возможность использования инструментов git для объединения ваших изменений с новой версией, поскольку git также может отслеживать изменения имен файлов. Вам нужно будет много узнать о самом git, и вам потребуется некоторое время, чтобы все исправить - вам, вероятно, следует сделать резервную копию своей работы, прежде чем начинать с ней играть.
Git поддерживает обнаружение переименования файлов, поэтому, если вам повезет, он вам в этом поможет. Ниже приводится приблизительный набросок того, что вам следует делать.
Импортируйте исходную версию:
tar zxvf open-source-project-0.1.tar.gz
mv open-source-project-0.1 open-source-project
cd open-source-project
git init
git add .
git commit -m "Initial checkin of open-source-project-0.1"
git tag open-source-project-0.1
Теперь вы можете применить исходные изменения в отдельной ветке:
git checkout -b mychanges
cp /somewhere/where/your/changes/files/are/* .
git diff
git add .
git commit -m "My changes"
git tag my_changes_001
Затем вы обновитесь до более новой версии:
git checkout master
tar zxvf open-source-project-0.2.tar.gz
mv open-source-project-0.2/* .
rmdir open-source-project-0.2
git add .
git commit -m "Update to open-source-project-0.2"
git tag open-source-project-0.2
Пока все зарегистрировано в репозитории git, теперь это время, чтобы попытаться объединить ваши изменения:
git checkout -b merge_test open-source-project-0.2
git pull . my_changes_001
Удачи ...
Если вы хотите объединить файлы вручную, я действительно рекомендую использовать KDiff3 . Предполагая, что file1.c взят из open-source-project-0.1, file2.c из open-source-project-0.2 и file3.c из ваших изменений, запустите
kdiff3 -o merged_file.c file1.c file2.c file3.c
Вы можете попробовать кое-что, что было предложено мне здесь ранее, интересное "различное" решение: сначала клонируйте последний версия проекта. Никаких локальных изменений не должно быть. Убедитесь, что папка .git есть. Затем скопируйте свое рабочее дерево, то есть все ваши файлы, ЗА ИСКЛЮЧЕНИЕМ папки .git, в клонированное репо. Теперь, если вы наберете «git st», вы увидите все, что было изменено. Вам также нужно будет отсортировать интервалы и окончания строк (git config core.autocrlf ...), если git st сообщает о файлах, в которых на самом деле нет изменений.
Теперь для каждого файла в списке git st: если вы наберете git diff, вы увидите свои изменения.
Затем я бы отредактировал файлы один за другим, пока git st не будет выглядеть как то, что я хочу зафиксировать.
Я бы не стал делать патчи, потому что они очень разборчивы. Скорее всего, вы получите сообщение «Невозможно применить патч», тогда как приведенное выше решение дает вам список неустановленных изменений, с которыми вы можете работать в любом порядке.