Best practices for indicating what address to send patches to?

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?

Philip Kaludercic <philipk@posteo.net> writes:

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.

Thanks.

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

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.

Philip Kaludercic <philipk@posteo.net> writes:

Projects can actively refuse to use such a "feature", if it is expected to encourage undesirable behaviour by new contributors. And projects that do not care can use such a "feature". In that sense, I can see a future in which such a "feature" exists but not used by everybody. But introducing such a "feature" that is not necessarily an improvement and can actively harm projects that use it is tricky. You'd have to document the upsides and the downsides to allow projects to make informed decisions if they want to adopt it.

Stepping back to your original question, you asked if this is intentional and if this was discussed in the past.

The answer is this is more organic and not with an explicit intention, but in hindsight, because submission address is just a small piece of information projects want to publish together with other guidelines, not having a mechanism only to give the submission address would *not* have helped projects all that much. With the explanation behind the answer to the first question it should be easy to see why nobody talked about such a "feature" in the past, which is the answer to your second question.