[Nut-upsdev] [RFC apcsmart V3 00/18] apcsmart driver updates

Michal Soltys soltys at ziu.info
Mon Mar 7 18:00:34 UTC 2011


On 11-03-07 14:54, Charles Lepple wrote:
> On Mar 6, 2011, at 10:31 AM, Arjen de Korte wrote:
>
>> Citeren Michal Soltys <soltys at ziu.info>:
>>
>> 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.



More information about the Nut-upsdev mailing list