Re: git-email automatic --to detection?

[Jeff King <peff@peff.net>]

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