Most CVS/SVN open source projects will prefer patches to be submitted as follows:
1. First patch contains a failing test
2. Second patch contains bugfix/improvement and possibly additional testcases and maybe also changes to the initial failing test case
The smart way to do this with git is as follows:
1. Clone project, if it's a SVN project use github's git-svn import (*much* perferred to using git svn clone yourself)
2. Create an initial feature branch masterForGit, where you add stuff that is nice for working this project in a git environment; typically a .gitignore file and any local scripts you need to be able to work with the project. Make sure this project compiles well and does not add unwanted files to git before proceeding (git does not handle empty directories same way as svn so you may need to correct this in this branch)
3. Create a feature branch failingTest based on masterForGit. In this branch you create the original failing
test what will be submitted as proof.
4. Create a feature branch bugFix that is branched off failingTest. In this branch you fix the bug and add any subsequent test cases.
5. When you're all done, you typically do diff between failingTest and masterForGit to get the patch file for "proof" bug. Then you diff bugFix and failingTest to get fix-patch. Since you created the "masterForGit" branch initially, none of the patches get polluted with temp-stuff you did locally.
And, if you end up maintaining this patchset, you can just update from svn through github and merge through all of your branches. Easy.
- ▼ October (3)