{"thread":{"id":"61004","subject":"CR position changed in exported patch file subject section","startedAt":"2024-02-26T05:45:37Z","lastAt":"2024-02-26T08:21:48Z","messageCount":4,"participants":["Chen, Boyang","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"489348","messageId":"IA0PR12MB822711B89738EDA0E2F25150EF5A2@IA0PR12MB8227.namprd12.prod.outlook.com","threadId":"61004","inReplyTo":null,"subject":"CR position changed in exported patch file subject section","fromName":"Chen, Boyang","fromEmail":"boyang.chen@amd.com","sentAt":"2024-02-26T05:45:35Z","receivedAt":"2024-02-26T05:45:37Z","isPatch":false,"sender":{"key":"boyang.chen@amd.com","avatar":null},"body":"[AMD Official Use Only - General]\n\nHi guys,\n\nRecently I faced a question that the CR position in the patch is not in line with the git log.\nBelow are the steps to reproduce.\n\ntouch aaa\ngit add aaa\ngit commit -m \"Add a file to test, make sure that the message is a bit long but in a single line\"\n\nD:\\Source\\CustomerRepoTest\\Platform1>git log -3\ncommit 0c9f8555c55c73fd4e5392c8f8516c389f362d17 (HEAD -> test)\nAuthor: Boyang Chen\nDate:   Mon Feb 26 11:16:00 2024 +0800\n\n    Add a file to test, make make sure that the message is a bit long but in a single line\n\nWe can confirm that the commit message is in a single line in the output of git log command(pls refer to above output).\n\nAnd use below command to generate a patch file.\ngit format-patch -3 --stdout  >  exported_3.patch\nWe can observe that the commit message's CR position is changed in the exported patch, the subject section is split to two lines(pls refer to below output).\n\nFrom 0c9f8555c55c73fd4e5392c8f8516c389f362d17 Mon Sep 17 00:00:00 2001\nFrom: Boyang Chen\nDate: Mon, 26 Feb 2024 11:16:00 +0800\nSubject: [PATCH 3/3] Add a file to test, make make sure that the message is a\nbit long but in a single line\n\n---\naaa | 0\n1 file changed, 0 insertions(+), 0 deletions(-)\n\n\nActually,  we want to keep the commit message format(subject section) in the patch same as the git log output.\nI have tried most of arguments of git format-patch and even upgrade the git version.\nBut no good result is observed.\n\nCould you please help to look at this question? Thanks a lot!\n\nBR\nBoyang\n"},{"id":"489349","messageId":"IA0PR12MB822712F1B3E5205711493D55EF5A2@IA0PR12MB8227.namprd12.prod.outlook.com","threadId":"61004","inReplyTo":"IA0PR12MB822711B89738EDA0E2F25150EF5A2@IA0PR12MB8227.namprd12.prod.outlook.com","subject":"RE: CR position changed in exported patch file subject section","fromName":"Chen, Boyang","fromEmail":"boyang.chen@amd.com","sentAt":"2024-02-26T05:53:19Z","receivedAt":"2024-02-26T05:53:21Z","isPatch":false,"sender":{"key":"boyang.chen@amd.com","avatar":null},"body":"[AMD Official Use Only - General]\n\nHi guys,\nPls ignore the first email as there is some format mistake in it and pick this one.\nRecently I faced a question that the CR position in the patch is not in line with the git log.\nBelow are the steps to reproduce.\n\ntouch aaa\ngit add aaa\ngit commit -m \"Add a file to test, make sure that the message is a bit long but in a single line\"\n\nD:\\Source\\CustomerRepoTest\\Platform1>git log -3 commit 0c9f8555c55c73fd4e5392c8f8516c389f362d17 (HEAD -> test)\nAuthor: Boyang Chen\nDate:   Mon Feb 26 11:16:00 2024 +0800\n\n    Add a file to test, make make sure that the message is a bit long but in a single line\n\nWe can confirm that the commit message is in a single line in the output of git log command(pls refer to above output).\n\nAnd use below command to generate a patch file.\ngit format-patch -3 --stdout  >  exported_3.patch\n\nWe can observe that the commit message's CR position is changed in the exported patch, the subject section is split to two lines(pls refer to below output).\n\nFrom 0c9f8555c55c73fd4e5392c8f8516c389f362d17 Mon Sep 17 00:00:00 2001\nFrom: Boyang Chen\nDate: Mon, 26 Feb 2024 11:16:00 +0800\nSubject: [PATCH 3/3] Add a file to test, make make sure that the message is a\nbit long but in a single line\n\n---\naaa | 0\n1 file changed, 0 insertions(+), 0 deletions(-)\n\n\nActually,  we want to keep the commit message format(subject section) in the patch same as the git log output.\nI have tried most of arguments of git format-patch and even upgrade the git version.\nBut no good result is observed.\n\nCould you please help to look at this question? Thanks a lot!\n\nBR\nBoyang\n"},{"id":"489350","messageId":"20240226070255.GA780982@coredump.intra.peff.net","threadId":"61004","inReplyTo":"IA0PR12MB822712F1B3E5205711493D55EF5A2@IA0PR12MB8227.namprd12.prod.outlook.com","subject":"Re: CR position changed in exported patch file subject section","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2024-02-26T07:02:55Z","receivedAt":"2024-02-26T07:02:58Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 26, 2024 at 05:53:19AM +0000, Chen, Boyang wrote:\n\n> D:\\Source\\CustomerRepoTest\\Platform1>git log -3 commit 0c9f8555c55c73fd4e5392c8f8516c389f362d17 (HEAD -> test)\n> Author: Boyang Chen\n> Date:   Mon Feb 26 11:16:00 2024 +0800\n> \n>     Add a file to test, make make sure that the message is a bit long but in a single line\n> \n> We can confirm that the commit message is in a single line in the output of git log command(pls refer to above output).\n> \n> And use below command to generate a patch file.\n> git format-patch -3 --stdout  >  exported_3.patch\n> \n> We can observe that the commit message's CR position is changed in the\n> exported patch, the subject section is split to two lines(pls refer to\n> below output).\n\nThis is expected. The format-patch command is generating an email, and\nrfc2822 says:\n\n   Each line of characters MUST be no more than 998 characters, and\n   SHOULD be no more than 78 characters, excluding the CRLF.\n\nBut we can make the subject arbitrarily long by using header\ncontinuation; the line after the \"Subject:\" should start with\nwhitespace, which indicates to a parser that it is a continuation of the\nprevious header.\n\nYou don't show that here:\n\n> From 0c9f8555c55c73fd4e5392c8f8516c389f362d17 Mon Sep 17 00:00:00 2001\n> From: Boyang Chen\n> Date: Mon, 26 Feb 2024 11:16:00 +0800\n> Subject: [PATCH 3/3] Add a file to test, make make sure that the message is a\n> bit long but in a single line\n\nbut I'm not sure if it's really missing, or if the whitespace got munged\nas you sent it. Assuming it is, then everything is working as designed.\n\nThat said, I have sometimes been annoyed at this myself, because I want\nto process the mails with tools that are quite capable of handling long\nlines (e.g., mutt). And doing hacky processing with perl, etc, becomes\nharder because you have to actually parse the mail correctly rather than\njust grepping for \"^Subject:\". ;)\n\nSo I have wondered if it would be useful to have a --no-wrap-email\noption. Or perhaps the existing --no-encode-email-headers should be used\nas a hint that the user prefers easy-to-parse output over strict rfc\ncompliance.\n\n-Peff\n"},{"id":"489356","messageId":"IA0PR12MB822787A4CBE319143FD81C86EF5A2@IA0PR12MB8227.namprd12.prod.outlook.com","threadId":"61004","inReplyTo":"20240226070255.GA780982@coredump.intra.peff.net","subject":"RE: CR position changed in exported patch file subject section","fromName":"Chen, Boyang","fromEmail":"boyang.chen@amd.com","sentAt":"2024-02-26T08:21:46Z","receivedAt":"2024-02-26T08:21:48Z","isPatch":false,"sender":{"key":"boyang.chen@amd.com","avatar":null},"body":"[AMD Official Use Only - General]\n\nHi Peff,\n\nThanks for your clarification.\nThe commit message is just a single line, but the subject section is splinted into two lines as the line characters number is more than 78.\nThis is in line with the design.\nThe content you read doesn't have this change, maybe it is caused by the outlook content format.\n\nperhaps the existing --no-encode-email-headers should be used as a hint that the user prefers easy-to-parse output over strict rfc compliance.\n==> I have tried this command,  the generated patch subject section is still splinted into two lines.\n\nI have wondered if it would be useful to have a --no-wrap-email option.\n==> if we add this new option and output the commit message as the way that git log command does, it should be good with usage.\n\nThanks again!\n\nBR\nBoyang\n\n\n-----Original Message-----\nFrom: Jeff King <peff@peff.net>\nSent: Monday, February 26, 2024 3:03 PM\nTo: Chen, Boyang <Boyang.Chen@amd.com>\nCc: git@vger.kernel.org\nSubject: Re: CR position changed in exported patch file subject section\n\nCaution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.\n\n\nOn Mon, Feb 26, 2024 at 05:53:19AM +0000, Chen, Boyang wrote:\n\n> D:\\Source\\CustomerRepoTest\\Platform1>git log -3 commit\n> 0c9f8555c55c73fd4e5392c8f8516c389f362d17 (HEAD -> test)\n> Author: Boyang Chen\n> Date:   Mon Feb 26 11:16:00 2024 +0800\n>\n>     Add a file to test, make make sure that the message is a bit long\n> but in a single line\n>\n> We can confirm that the commit message is in a single line in the output of git log command(pls refer to above output).\n>\n> And use below command to generate a patch file.\n> git format-patch -3 --stdout  >  exported_3.patch\n>\n> We can observe that the commit message's CR position is changed in the\n> exported patch, the subject section is split to two lines(pls refer to\n> below output).\n\nThis is expected. The format-patch command is generating an email, and\nrfc2822 says:\n\n   Each line of characters MUST be no more than 998 characters, and\n   SHOULD be no more than 78 characters, excluding the CRLF.\n\nBut we can make the subject arbitrarily long by using header continuation; the line after the \"Subject:\" should start with whitespace, which indicates to a parser that it is a continuation of the previous header.\n\nYou don't show that here:\n\n> From 0c9f8555c55c73fd4e5392c8f8516c389f362d17 Mon Sep 17 00:00:00 2001\n> From: Boyang Chen\n> Date: Mon, 26 Feb 2024 11:16:00 +0800\n> Subject: [PATCH 3/3] Add a file to test, make make sure that the\n> message is a bit long but in a single line\n\nbut I'm not sure if it's really missing, or if the whitespace got munged as you sent it. Assuming it is, then everything is working as designed.\n\nThat said, I have sometimes been annoyed at this myself, because I want to process the mails with tools that are quite capable of handling long lines (e.g., mutt). And doing hacky processing with perl, etc, becomes harder because you have to actually parse the mail correctly rather than just grepping for \"^Subject:\". ;)\n\nSo I have wondered if it would be useful to have a --no-wrap-email option. Or perhaps the existing --no-encode-email-headers should be used as a hint that the user prefers easy-to-parse output over strict rfc compliance.\n\n-Peff\n"}]}