[Patchew-devel] [PATCH] rest: POST for message endpoint

[Shubham Jain]

Alright. One more question.
Setting in_reply_to here is the right thing to do for how the code
behaves right now.  However, the real problem is that it's missing in
MessageSerializer!  Can you add it, and here do:

    if 'in_reply_to' not in validated_data:
        msg.in_reply_to = m.get_in_reply_to() or ""

Is this same for every field? msg.stripped_subject ,msg.version,
msg.prefixes, msg.is_series_head ......

On Mon, May 7, 2018 at 4:42 PM Paolo Bonzini <pbonzini at redhat.com> wrote:

> On 07/05/2018 13:03, Shubham Jain wrote:
> >
> >
> > On Mon, May 7, 2018 at 4:25 PM Paolo Bonzini <pbonzini at redhat.com
> > <mailto:pbonzini at redhat.com>> wrote:
> >
> >     On 05/05/2018 09:09, Shubham Jain wrote:
> >     > This commit allows to create/POST message from browser
> >     > - Add "create" method to MessageManager so that it calls
> save_mbox()
> >     > - Add getter and setter for mbox
> >     > - Rename the existing "mbox" field to e.g. "mbox_blob"
> >     > - Fix nested writable serializer issue
> >
> >     This already looks pretty good, but:
> >
> >     - there are no test cases
> >
> > I was thinking of doing this when we have POST for both json and
> > text/plain format.
>
> No, please do it immediately.  Every patch should have testcases if
> applicable.
>
> >     - we should use it as an exercise in posting a series composed of
> >     multiple changes
> >
> > I still don't know how to send the multiple patches in a single patch.
>
> Good, that's what I wanted to know! :)
>
> You can do
>
>     git format-patch -opatches-post --cover-letter origin/master..
>
> "-o" gives the output directory.  "--cover-letter" says that you want to
> include an introductory message.
>
> Now edit "patches-post/0000-cover-letter.patch" to include the
> introductory message, and then
>
>     git send-mbox *whatever options you need* patches-post/*
>
> Do you know how to split a patch in multiple parts?  The idea is
>
>     git add -p
>     ... add changes for the first patch ...
>     git stash --keep-index
>     ... test ...
>     git commit -a
>     git stash pop
>
> and repeat until the last part is missing.  Then just:
>
>     ... test ...
>     git commit -a
>
> to commit the last part.
>
> But again, it's okay (perhaps better for your comfort) if you first do
> the requested changes and then we work on testcases and posting
> splitting the patches.  This way, the mailing list post also acts as a
> sort of backup. :)
>
> Paolo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/patchew-devel/attachments/20180507/69747470/attachment.htm>