Taking https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.org/thread/ROKGAPNNISSV6NHO5KZEHLCSVNPVE55V/ as an example, I download the emails as .mbox.gz. After unpacking the file, "git am" complained the patch is empty, $ git am kexec@lists.fedoraproject.org-ROKGAPNNISSV6NHO5KZEHLCSVNPVE55V.mbox Patch is empty. When you have resolved this problem, run "git am --continue"
2021/05/01
Seems like a duplicate/related to #9831
Closing as duplicate.
Metadata Update from @mohanboddu: - Issue close_status updated to: Duplicate - Issue status updated to: Closed (was: Open)
No, it's not a duplicate of #9381, - the patches for this bug are download via webui while for #9381 they are emails saved as mbox file in mutt - this bug complains about the patch being empty while #9381 complains about trailing ^M
Metadata Update from @coiby: - Issue status updated to: Open (was: Closed)
So, this seems like expected behavior to me...
git am sees the mailbox file, breaks it out to a bunch of files, one per post, then tries to apply any patches in them.
The first post in that mbox has no patch. So, git am says 'patch is empty' and waits for you to 'git am next' or 'git am abort' or whatever.
If you do 'git am next' it goes to the second post and should apply that patch? Does it not?
What behavior are you expecting here?
So, this seems like expected behavior to me... git am sees the mailbox file, breaks it out to a bunch of files, one per post, then tries to apply any patches in them. The first post in that mbox has no patch. So, git am says 'patch is empty' and waits for you to 'git am next' or 'git am abort' or whatever. If you do 'git am next' it goes to the second post and should apply that patch? Does it not? What behavior are you expecting here?
Thanks for the explanation. You are right about that, the cover letter is empty patch. And I agree this is expected behavior.
I notice another problem after skip the empty patch. The emails in the downloaded .mbox.gz file seems to sorted a bit ramdomly and this causes the failture of "git am" because of patche dependency. It could be reproduced for https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.org/thread/SU3YDRHMJFZZRMXX3GVQBTJ65SEA4ZIS/.
Metadata Update from @kevin: - Issue priority set to: Waiting on Assignee (was: Needs Review) - Issue tagged with: low-gain, low-trouble, ops
So, the best I can think of here is that you can start the git am, but then look under .git/rebase-apply/ where it has all the patches in the order it thinks they should be in. Then you can 'git am --abort' and apply those in the order you wish?
I don't know if git am has any way to sort things, I couldn't find one from a quick search. Might be good to ask in a upstream git forum or perhaps on the fedora devel list?
Anyhow, I don't think there's much we can do to make sure messages are in a specific order. email can be delayed or not arrive for any number of reasons. ;(
Metadata Update from @kevin: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.