On 12/16/2018 06:42 PM, Geert Uytterhoeven wrote: > Hi Marek, > > On Sun, Dec 16, 2018 at 6:25 PM Marek Vasut <marek.vasut@xxxxxxxxx> wrote: >> On 12/16/2018 09:39 AM, Geert Uytterhoeven wrote: >>> On Sat, Dec 15, 2018 at 9:13 PM Marek Vasut <marek.vasut@xxxxxxxxx> wrote: >>>> On 12/15/2018 09:00 PM, Geert Uytterhoeven wrote: >>>>> On Sat, Dec 15, 2018 at 8:07 PM Marek Vasut <marek.vasut@xxxxxxxxx> wrote: >>>>>> On 12/15/2018 07:54 PM, Geert Uytterhoeven wrote: >>>>>>> On Sat, Dec 15, 2018 at 7:49 PM Marek Vasut <marek.vasut@xxxxxxxxx> wrote: >>>>>>>> On 12/15/2018 07:47 PM, Geert Uytterhoeven wrote: >>>>>>>>> On Sat, Dec 15, 2018 at 7:38 PM Marek Vasut <marek.vasut@xxxxxxxxx> wrote: >>>>>>>>>> On 12/15/2018 06:23 PM, Eduardo Valentin wrote: >>>>>>>>>>> On Wed, Dec 12, 2018 at 02:49:22AM +0100, Marek Vasut wrote: >>>>>>>>>>>> Introduce new thermal_zone_of_sensor_register_params() function, which >>>>>>>>>>>> allows passing struct thermal_zone_params into it and convert original >>>>>>>>>>>> thermal_zone_of_sensor_register() to call it with params set to NULL. >>>>>>>>>>>> >>>>>>>>>>>> Signed-off-by: Marek Vasut <marek.vasut+renesas@xxxxxxxxx> >>>>>>>>>>> >>>>>>>>>>> Git complains about mismatch between From: and this SOB. >>>>>>>>>> >>>>>>>>>> I recall a discussion about gmail stripping the +foo tags from email >>>>>>>>>> addresses. I can add a From: tag into the patch to override this >>>>>>>>>> braindeath, or is there a better solution ? >>>>>>>>> >>>>>>>>> Run the "git format-patch" command from a git repo where user.email >>>>>>>>> is marek.vasut@xxxxxxxxx, so it will retain the original From: tag in the >>>>>>>>> email body, as it is different? >>>>>>>> >>>>>>>> I can also manually patch the From tags or add them, but it's all >>>>>>>> workarounds. >>>>>>> >>>>>>> Use a different outgoing email server? I use my ISP's. >>>>>> >>>>>> Or maybe it'd make sense to fix git to handle the +tags correctly ? >>>>> >>>>> What needs to be fixed? >>>>> If user.email != From, git format-patch generates a From: header, else >>>>> it doesn't. Doesn't that make sense? >>>> >>>> I believe the complaint here is that email address in From does not >>>> match email address in SoB line, because some SMTP servers scrub the >>>> +foo tag from From: and not from SoB-line . And yet, the SoB line is >>> >>> Some SMTP servers (Hi Gmail!) scrub the +foo tag from the From: _header_ >>> in the email. As the SoB is in the _body_ it is not affected. >>> Hence the solution is to include the correct From: in the _body_. >> >> This is basically what I said. >> >>> Git actually does that automatically, assumed your user.email config matches >>> the From: address that is used in your outgoing email delivery path (i.e. the >>> scrubbed one, when using Gmail's SMTP server). >>> If you lie to git in your user.email config, git cannot do the right >>> thing, obviously. >> >> My git user.email obviously matches the From: field , before the >> scrubbing, which I believe is the correct thing to do. > > I disagree, because that is not how the emails are actually going out from the > SMTP server you are using. Can you summarize, clearly, what you believe is the right thing to configure and where ? >>>> from the same person/email address as the email address in From, so they >>>> are equal. >>> >>> If they differ, they are not equal ;-) >> >> Depends on how you define 'equal' . Here I think foo+bar@xxxxxxxxxxx >> should be considered equal to foo@xxxxxxxxxxx . > > That is domain-specific knowledge, which you cannot rely upon. > >>> While many mail servers ignore +foo when delivering email to mailboxes, >>> this is not the case for all of them. So ignoring +foo is not the universal >>> solution. >>> >>>> I think git should just ignore the +foo tag in SoB line. >>> >>> Where should "git" ignore the +foo tag? Is it actually git that complains? >>> Eduardo: Do you mean checkpatch? ;-) >> >> Possibly. I ran checkpatch after git format-patch and it didn't complain. >> >>> I did enhance checkpatch with a check to verify that patches carry SoB tags >>> from their authors, as too many people got that wrong, causing complaints >>> from sfr in linux-next later. As usual, it's better to get things right as early >>> as possible in the process, to avoid rework. >> >> Aha, so maybe that enhancement needs further enhancement to scrub the >> +tags before the check ? > > Again, that is domain-specific knowledge, which you cannot rely upon. How so, please elaborate . >>> So the problem is on the patch sending side, not on the patch verification >>> receiving side. >>> Hence please fix your email setup, thanks! >> >> See above. > > How is any of this different from people making mistakes trying to send > patches through a not-to-be-named corporate email system? I lost you here. -- Best regards, Marek Vasut
