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?
> 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.
> > 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
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
