On 12/17/2018 03:15 PM, Geert Uytterhoeven wrote:
> Hi Marek,
>
> On Mon, Dec 17, 2018 at 2:41 PM Marek Vasut <marek.vasut@xxxxxxxxx> wrote:
>> On 12/17/2018 02:36 PM, Geert Uytterhoeven wrote:
>>> On Mon, Dec 17, 2018 at 2:28 PM Marek Vasut <marek.vasut@xxxxxxxxx> wrote:
>>>> On 12/17/2018 02:26 PM, Geert Uytterhoeven wrote:
>>>>> On Sun, Dec 16, 2018 at 9:50 PM Marek Vasut <marek.vasut@xxxxxxxxx> wrote:
>>>>>> On 12/16/2018 09:08 PM, Geert Uytterhoeven wrote:
>>>>>> [...]
>>>>>>
>>>>>>>>>>> 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 ?
>>>>>>>
>>>>>>> According to git-send-email(1), you can either pass your scrubbed email
>>>>>>> address to --from, or configure it in the sendemail.from config option.
>>>>>>> Does that work for you?
>>>>>>
>>>>>> So sendemail.from != user.email , the later has the +tag while the
>>>>>> former does not ?
>>>>>
>>>>> Right.
>>>>>
>>>>>>>>>>>> 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.
>>>>>>>
>>>>>>>>>> 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 .
>>>>>>>
>>>>>>> In general, you cannot assume the "+foo" part can be ignored. Only the sender
>>>>>>> knows.
>>>>>>
>>>>>> How so ?
>>>>>
>>>>> It depends on the domain.
>>>>>
>>>>> Is Bill.Gates@xxxxxxxxxxxxx the same email address as
>>>>> Bill.Gates+foo@xxxxxxxxxxxxx?
>>>>> Is Bill.Gates+1955@xxxxxxxxxxxxx the same?
>>>>> Is Bill.Gates-1955@xxxxxxxxxxxxx the same?
>>>>>
>>>>> I don't know. Only microsoft.com knows.
>>>>> So that's why you should compare email addresses verbatim (but case
>>>>> insensitive).
>>>>
>>>> Oh, you mean email-domain. In that case, since gmail treats
>>>> foo@xxxxxxxxx the same as foo+bar@xxxxxxxxx , checkpatch should treat
>>>> them equally as well. In which case, your checkpatch patch which now
>>>> generates a warning on this is wrong ?
>>>
>>> So checkpatch should know about all email domains?
>>
>> If correct handling is domain specific knowledge, as you just said,
>> apparently so.
>
> Are you serious?
That's what the discussion would imply.
>> Otherwise checkpatch produces false positives.
>
> Even with gmail, some companies may use a single gmail account for public
> development, and use the +foo to distinguish between individual developers.
> So you cannot ignore it.
Hm, that's a rather warped example, but I guess one can use it like so.
>>> Just fix your setup. All patch statistics operate on the author, incl. +foo, so
>>> your patches will be attributed wrongly.
>>
>> Well your suggestion with sendemail.from doesn't seem to change
>> anything, but I'll keep it in.
>
> Sorry to hear that.
>
> Gr{oetje,eeting}s,
>
> Geert
>
--
Best regards,
Marek Vasut
