Re: git-email automatic --to detection?

From: Jeff King <peff@peff.net>
Date: Feb 25, 2008, 18:34 UTC
Message-ID: <20080225183413.GA15131@sigill.intra.peff.net>
In-Reply-To: <slrnfs3rv4.aqm.jgoerzen@katherina.lan.complete.org>

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

Show 5 quoted lines

> 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.

Show 7 quoted lines

> 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

Show 6 quoted lines

> 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