Re: git-email automatic --to detection?

On Sun, Feb 24, 2008 at 04:29:56PM -0600, John Goerzen wrote:

This will look at the repo the local copy was cloned from, find all
local changesets that aren't on the remote, and email off a set of
patches to the remote maintainer.  It finds the email address to send
to by looking at _darcs/prefs/email *on the remote*, which is roughly
the same as setting an option in .git/config.

There is not (currently) a way to read the remote config using the git
protocol. There was some discussion on a protocol extension a few months
back to do so, but I don't recall whether any patches came out of it.

There are a couple of nice things about this:

1) Patch submitters don't have to keep track of where to send patches
for each project they work on

2) Potential submitters don't have to be notified if the submission
address changes

There was some discussion about this a while back for the kernel. Some
relevant points that I recall:

  - there's more than _one_ maintainer for the repo; in fact, who you
    email depends on what part of the code you are touching

  - this information could be shipped as part of the repo (i.e., under
    version control like the rest of the project, as it changes with the
    project)

  - this information can potentially be inferred from git shortlog
    and/or blame; this addresses the problem of data becoming stale

See this thread:

  http://mid.gmane.org/1187110824.32555.76.camel@localhost

As far as I can tell from looking at git-send-email(1),
git-format-patch(1), and git-config(1), git doesn't have this
capability.  Is that correct?  If so, is it possible to add something
like this?  Would it also be possible to unify git-format-patch and
git-send-email into a single command that generates and sends the
patch(es)?

You could make a wrapper script around the two commands that pieces them
together. Though I'm not sure how likely that would be to get accepted
upstream; there are already complaints of too many commands, and this
one would likely be specific to your workflow (many of us have our own
such wrapper scripts already).

-Peff