On Fri, Mar 19, 2010 at 4:05 PM, Michael Witten <mfwitten@gmail.com> wrote:
quoted text
> On Fri, Mar 19, 2010 at 08:56, Erik Faye-Lund <kusmabite@googlemail.com> wrote:
>> On Fri, Mar 19, 2010 at 3:40 PM, Michael Witten <mfwitten@gmail.com> wrote:
>>> On Fri, Mar 19, 2010 at 08:08, Jakub Narebski <jnareb@gmail.com> wrote:
>>>> First, the user.name and user.email does not need to be name and email
>>>> from some email account.  It might be some "canonical name" and
>>>> "canonical email".
>>>
>>> The vast majority of patches come in through email; the git tools
>>> expect the user.name and user.email to reflect physical email account
>>> information.
>>
>> What git tools would that be?
>
> Anything involving emailed patches.

Which are...?

quoted text
>
>> The only one I know of that does
>> anything near assuming that is git send-email, and it only uses
>> user.email if neither sendemail.from is configured nor --from option
>> is specified. And even when it does, it prompts the user so it can be
>> changed if called from a terminal. So I wouldn't say that it assumes
>> anything about the "physicalness" of user.email, it just uses it's as
>> the most sane default unless anything else has been specified.
>
> It's useless to spoof the From field because many email services won't
> send it, a point I already covered in the email you quoted.
>
> When a patch is finally emailed, it's the From field that is used for
> Author attribution.

The From-field isn't assumed to be a physical-address, but the
From-header is. If the From-field and the From-header are identical,
the From-field doesn't get emitted. This is the same mechanism that is
used when people forward patches from other authors, and there's no
attempts to validate the From-field, only the From-header.

So no, the author-email shouldn't need to be a physical address as far
as send-email is concerned.

-- 
Erik "kusma" Faye-Lund
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html