Re: Best practices for indicating what address to send patches to?

[Philip Kaludercic <philipk@posteo.net>]

Junio C Hamano <gitster@pobox.com> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Hi, I was wondering if anyone had a good suggestion on how to indicate
>> where to send a patch to.  Ideally I'd like to have "sendemail.to"
>> configured on cloning, but that isn't possible IIUC.  There also doesn't
>> seem to be a conventional file like ".git-email" that would list where
>> to send a patch, without having to look it up.
>>
>> Is this intentional, has it been discussed in the past or is there the
>> chance that it might be improved upon in the future?
>
> The usual convention is to have the patch submission address (if a
> project uses e-mail based patch as its workflow) together with other
> rules and guidelines the contributors are expected to adhere to in
> documents like README, CONTRIBUTING, etc.  As an e-mailed patch that
> does not follow established conventions is not necessarily useful to
> the receiving projects, it is a good practice to put these pieces of
> information crucial to start contributing in a single place.
>
> It would not be an improvement to add a mechanism to make it easier
> to find "here is the address" to a reader who hasn't even discovered
> where these contributor guide documents are.

But is that an argument to prevent projects with mild or now contributor
guidelines to make the patch-driven workflow more difficult?  I've often
contributed to a project by quickly checking out the source code,
changing something and then sending a patch (this is easier in the
context of Emacs, because we have the a `vc-default-patch-addressee'
variable).  My suggestion is by no means to mandate this kind of an
option, but there are situations where this kind of configurability
would be useful, e.g. for Sourcehut projects.

> Thanks.

-- 
	Philip Kaludercic on peregrine