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:
1187110824.32555.76.camel@localhost">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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
