Я внес некоторые изменения в проект с открытым исходным кодом, не затрачивая время на создание правильных файлов исправлений.
Теперь разработчик проекта выпустил новую версию, а среди новых и отредактированных файлов есть куча переименованных файлов.
Каков наилучший способ применить мои изменения к новой версии?
Я совершенно новичок в использовании diff/patch, и если я смогу сделать это с помощью git, было бы лучше.
Если у вас есть два каталога 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 для получения патчей данных diff. Если вы внесли изменения локально, вы можете сделать git log, чтобы найти фиксацию перед вами, а не git diff commit_string > file.patch.
Если проект не находится под git или если вы используете источник d/l без клонирования репозитория (как следует из названия), вы можете использовать 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 не будет похож на то, что я хочу зафиксировать.
Я не стал бы полагаться на создание патчей, потому что они очень разборчивы. Скорее всего, вы получите "не применять патч", тогда как вышеприведенное решение дает вам список неустановленных изменений, с которыми вы можете работать в любом порядке.
Вероятно, вы должны смотреть на git rebase. Возможно, даже простой git pull будет делать то, что вы хотите.