我对开源项目进行了一些更改,没有花时间创建适当的补丁文件。
现在,该项目的维护者发布了一个新版本,在新的和编辑过的文件中,有一堆重命名的文件。
什么是将我的更改应用到新版本的最佳方式? 我是diff / patch使用的新手,如果我能用git完成它,那就更好了。
答案 0 :(得分:50)
如果您有两个类似的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工具来处理你的本地存储库,事情就会简单得多。
答案 1 :(得分:10)
如果项目是在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本身的知识,这需要你花一些时间才能做到 - 你应该在开始玩它之前备份你的工作。
答案 2 :(得分:4)
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,来自open-source-project-0.2的file2.c和来自你的更改的file3.c,运行
kdiff3 -o merged_file.c file1.c file2.c file3.c
答案 3 :(得分:2)
由于声誉低下,我无法发表评论。因此,我将添加一个新答案。我尝试了以上答案之一,但空白行仍然存在问题。下面的方法对我有用。
diff -uraBN upstream local > filename.patch
cd upstream
patch --dry-run -p1 -i filename.patch #highly recommended recommended
patch -p1 -i filename.patch
答案 4 :(得分:1)
您可以尝试之前向我建议的一些有趣的“差异”解决方案:首先克隆项目的最新版本。它不应该有任何本地更改。确保.git文件夹在那里。然后将工作树(即除.git文件夹之外的所有文件)复制到克隆的存储库。现在,如果您键入“git st”,您将看到所有已更改的内容。如果git st报告那些没有真正改变的文件,你还需要整理间距和行结尾(git config core.autocrlf ...)。
现在对于git st列表中的每个文件,如果你输入git diff,你会看到你的变化。
然后我会逐个编辑文件,直到git st看起来像我要提交的内容。
我不会依赖制作补丁,因为它们非常挑剔。您很可能会得到“无法应用补丁”,而上面的解决方案会为您提供一个可以按您想要的任何顺序处理的非分段更改列表。
答案 5 :(得分:0)
您可能应该关注git rebase
。甚至一个简单的git pull
也许会做你想做的事。