I made some changes to an open source project without taking time to create proper patch files.
Now, the maintainer of the project released a new version, and among new and edited files, there are a bunch of renamed files.
Whats is the best way to apply my changes to the new version ?
I'm completely new to diff/patch use, and If I can get it done with git, it would be better.
If the project is under git and you haven't committed your changes locally, you can simply do git diff > file.patch to get patchable diff data. If you have committed the changes locally, you can do git log to find the commit before you and than git diff commit_string > file.patch.
If the project isn't under git, or if you d/l source without cloning the repository (as the title suggests), you can use diff -urN original_dir new_dir > file.patch to create the patch file. In both cases you can try use patch later to apply the patch.
However, consider using git tools to merge your changes with the new version, since git is able to track filename changes too. You'll need to learn great deal about git itself, and it will take you some time to get it right - you should probably backup your work before starting to play with it.
You could try something that was suggested to me here before, an interesting "diffing" solution: first clone the latest version of the project. It shouldn't have any local changes. Make sure the .git folder is there. Then copy your working tree, that is all your files EXCEPT the .git folder, to the cloned repo. Now if you type "git st" you will see everything that was changed. You'll need to sort out also the spacing and line endings (git config core.autocrlf ...) if git st reports files that don't really have changes in them.
Now for each file in git st list, if you type git diff you'll see your changes.
Then I would edit the files one by one, until git st looks like what I want to commit.
I wouldn't rely on making patches because they are extremely picky. You'll most likely get a "can't apply patch", whereas the solution above gives you a list of unstaged changes which you can work on in any order you want.
Git has support for detecting renaming of files, so if you are lucky it will help you with that. The following is an approximate draft of what you should do.
Import the original version:
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
Now you can apply your original changes in a separate branch:
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
Then you update to the newer version:
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
So far everything is checked in into the git repository, now is the time to start to try to merge your changes:
git checkout -b merge_test open-source-project-0.2
git pull . my_changes_001
Good luck...
If you want to merge files manually I really recommend using KDiff3. Assuming file1.c is from open-source-project-0.1, file2.c from open-source-project-0.2 and file3.c from your changes, run
kdiff3 -o merged_file.c file1.c file2.c file3.c
If you have two directories a and b that are similar, and you want b to be the same as a, you can create and apply a patch with:
$ diff -u b a > ba.diff $ patch -i ba.diff
Suppose you have directories local (containing your local version of upstream1.0), upstream1.0, and upstream1.1. To create and apply your changes to upstream1.1:
$ diff -u upstream1.0 local > my.diff $ cd upstream1.1 $ patch -i ../my.diff
Check the documentation for patch, and try to convince the upstream maintainers to use git. Things will be much simpler if you can use git tools to work with your local repository.