On Tue, Jun 5, 2012 at 1:16 PM, Axel Rau <[email protected]> wrote: > > That would be great. Let me know, if I can assist. > Should I start, porting the patch to 4.80?
I don't know your familiarity with git, so I'm going to describe a quick git work flow to make this easier for anybody else who might want to do similar in the future. If you are already a git expert, please don't take this as condescending, it's mostly for clarity for others. There are other possibly easier ways to do this, but this is just the clear-in-my-mind workflow that I like to use. 1. If you haven't already done it: git clone git://git.exim.org/exim.git 2. If you haven't already done so, read http://wiki.exim.org/EximGit 3. Check out the 4.77 release: git checkout exim-4_77 4. Create a new local branch from this point, giving it a name to indicate it's for your db logging. git checkout -b db_logging 5. Apply your patch with -p1. The code should apply cleanly, the docs will fail. The reason is that the git tree looks different than the tree of the source tarball. cd src/ patch -p1 < ../db_logging.patch 6. Apply the doc portion of the patch: cd ../doc/doc-txt patch -p1 ../../src/doc/*.rej cd ../.. # should put you back in root of exim repo # In the repo, doc/ is valid, but # src/doc is not valid, is a remnant of first failed patch rm -rf src/doc/ find . -name *.orig -exec rm -v {} \; 7. A 'git status' should show something like this: # modified: doc/doc-txt/experimental-spec.txt # modified: src/src/EDITME # modified: src/src/config.h.defaults # modified: src/src/deliver.c # modified: src/src/exim.c # modified: src/src/expand.c # modified: src/src/globals.c # modified: src/src/globals.h # modified: src/src/readconf.c # modified: src/src/transports/smtp.c # modified: src/src/transports/smtp.h 8. Do a 'git add FILE' for each one of those (can do multiple filenames at once on the commandline). Do not do the cheating 'git add .' because that *WILL* inadvertently add things to the repo that shouldn't be added. The .gitignore file has been modified since 4.77 to block most of these inadvertent commits. 9. Run 'git commit', enter a commit message, and save it. Google for "format git commit message" if you have any questions of how the commit message should look. 10. This command does a lot in the background, but basically you'll tell git to un-apply your patch, roll the branch forward to exim 4.80 release, and then reapply your patch: git rebase exim-4_80 11. If it succeeds (and it usually does), then you're finished. However, I tested the above with your patch and it had some merge conflicts (not in the code, but in the doc file, the EDITME file, and the config.h.defaults file. 12. If it has conflicts it can't resolve, it will give you some brief instructions to fix it. It's up to you if you want to try to fix it or not. Basically you edit the 3 files with the merge conflicts. (I just look for the string "======" which puts you right in the middle of the merge conflict. Remove the conflict markers, fix the code, and save them. 13. git add FILE1 FILE2 FILE3 14. git rebase --continue Now is an easy way to present your patch: git format-patch exim-4_80..HEAD which will create a commit patch file for every commit between exim-4_80 branch and your current HEAD. Since HEAD is currently your local branch that you made, there is only one commit, so only one file will be created. Send that file to the list or to bug tracker and it's much easier for the maintainers to work with it. While git and this process may be second nature for Axel, my hope is that this workflow detail can help someone new to git in the future. If there's no objections are changes, I think I might put something similar into the wiki (assuming I have commit access to the wiki). ...Todd -- Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Martin Golding -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
