On 11-03-07 14:54, Charles Lepple wrote:
On Mar 6, 2011, at 10:31 AM, Arjen de Korte wrote:
Citeren Michal Soltys <[email protected]>:
Thanks for these patches. One remark though, is that we prefer if you
send patches as attachments rather than inline them. Inlining them
means we have to painstakingly extract them from the messages (making
sure the formatting is not changed along the way) and applying them in
the hope we didn't miss a part. Attaching them means that we can
simply save the attachment and apply that to the trunk immediately.
Arjen,
I assume from the format that Michal sent these from git's patch
generation tool. The idea there is that the patch is sent in plain text
format, such that you can pipe the raw message to patch. (Patch will
look for the "diff ..." header and start operating there.)
While I usually would agree that attachments are better (if a mail
client folds the lines), I think that automatically generated patches
can be a little easier to apply. I basically saved each of the messages
in mbox format, and my mail client named them after the subject lines
(which are designed so that a lexicographical sort is also chronological).
Yes, git format-patch + git send-email . They should be applicable by
any usual method - patch, git apply, git am .
In this case, you should be able to just:
git am [<mbox> | <Maildir>...]
the whole set with 1 command.
Still, I don't know how such methods are really applicable at svn front,
so of course I'll send stuff as attachments next time.
I tried rebasing the patches onto my local Git branch of the SVN trunk
after Arjen committed them, and ran into a few conflicts. Do you have a
place where you can upload your Git branch (assuming this is indeed git
patch output)?
Most by not all (8,9,16,18) of those were applied, and there were few
minor modifications (like in 13). Possibly the source of errors.
I've been thinking about trying to mirror our SVN tree on GitHub or
something similar so that it is easier for people to fork, but it looks
like you already have this in some DSCM system. Also, for a long patch
sequence, sometimes it's easier to browse it online, or to pull the
branches to a local repository.
Sure I could quickly do a local branch, but most of the stuff is already
applied - only a few things left - test icanon approach, update manual
page, some minor stuff perhaps.
_______________________________________________
Nut-upsdev mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev