On Tue, Jun 5, 2012 at 1:16 PM, Axel Rau <axel.rau@???> 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
