git-email automatic --to detection?

One of my favorite features of Darcs is that users can submit patches by typing:

  darcs send -a

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

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)?

Thanks,

-- John

On 2/25/08, John Goerzen > Would it also be possible to unify git-format-patch and

I can't think of how to unify the commands from the ui point of view. What do you suggest?

However, i like the idea of a --send commad line option to git-format-patch that calls git-send-email to create and send the patch series.

Ciao, -- Paolo http://paolo.ciarrocchi.googlepages.com/

On 2008-02-24, Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:

That sounds reasonable to me.

I'm all in favor of less typing, so git-email sounds even better :-)

-- John

On Mon, Feb 25, 2008 at 02:26:03AM +0330, Paolo Ciarrocchi wrote:

I think it makes sense the other way around: have git-send-email invoke git-format-patch.

My reasoning is that git-send-email users almost always use git-format-patch, but git-format-patch users frequently do not use git-send-email.

-Peff

On 2/25/08, Jeff King <peff@peff.net> wrote:

that's correct. I even like the idea of a single git email command. ciao, -- Paolo http://paolo.ciarrocchi.googlepages.com/

On Sun, Feb 24, 2008 at 04:29:56PM -0600, John Goerzen <jgoerzen@complete.org> wrote:

i don't think so. what about git config sendemail.to?

- VMiklos

On Mon February 25 2008 8:39:59 am Miklos Vajna wrote:

<jgoerzen@complete.org> wrote:

But that must be applied locally. It is not pulling that down from the remote repo before the send, which is the point of all this.

On Mon, Feb 25, 2008 at 09:08:20AM -0600, John Goerzen <jgoerzen@complete.org> wrote:

right. this is a pro and a con: you can't run darcs send -a while you're offline but you can do a git format-patch while offline. and of course _once_ you have to configure sendemail.to manually.

- VMiklos

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

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

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

Jeff King <peff@peff.net> writes:

Yes, but a sane default address to send to can be given by the repository you make your original clone from.

The really nice thing with the way darcs does it is that it makes it extremely easy for an occasional contribution. If the maintainer configured his stuff correctly, it's really "darcs get; ... ; darcs record; darcs send". git-send-email is nice, but harder to use for a first-timer.

True, but for the case of multiple maintainers, that would break merging between maintainers on that particular part.

You can have a maintainer A advertizing for A@domain.com, and a "sub-maintainer" B advertizing for B@domain.com. If A merges from B, he doesn't want his advertized adress to become the one of B.

Yes and no. git@vger.kernel.org won't appear anywhere in these for example.

On Mon, Feb 25, 2008 at 07:57:13PM +0100, Matthieu Moy wrote:

I agree that this is useful, especially for smaller projects where it really _is_ just one address.

I think there are advantages and drawbacks to both methods. Version-controlled information is better for a project that has multiple official maintainers, and those maintainers want to submit a patch saying "and here's my contacat information." But it's worse for people who are saying "here's somebody else's repo with my patches, but email me about it".

Worse, you may want to do either in a particular repo, depending on what your patches are. If I publish a repo with patches on top of git.git, then you want to email me for patches specific to my repo, but probably the regular git list and subsystem maintainers for patches that are generally applicable.

So I'm not sure you will be able to write a tool that will always just do the right thing.

Yes, there would need to be some tool that combines:
  - per-repo patch submitting policy (i.e., mail me because I am your
    upstream)
  - per-project patch submitting policy (i.e., mail git@vger for git
    patches)
  - per-patch policy (e.g., this patch touches foo.c: who is
    interested in foo.c?)

-Peff

On 2008-02-25, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:

Right. That's why this would be a per-repo setting. It wouldn't be pulled or cloned, just looked up when needed.

I imagine that in gitese, this would mean that by default this would be looked up in the repo that origin points to.

John Goerzen <jgoerzen@complete.org> writes:

I think it should. Not versionned, but initialized by "clone" based on the cloned repo.

The advantage of a clone-time initialization compared to a submit-time look up is that the local user can very easily change the value manually after a clone.

On 2008-02-26, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:

That would work.

You could always make it work like this:

* If an address is given on the command line, use that.

* Otherwise, if an address is given in config, use that.

* Otherwise, look up the address at the remote repo; if successful,
  use that.

* Otherwise, prompt the user.

The advantage of this is that if the submission address changes (but the remote repo URL hasn't), then patches can automatically go to the right place. Of course the disadvantage is that the config is not initialized for offline mail queuing at clone time.

I have generally found that not being able to queue patches offline isn't a big deal to me. Of course, someone could effectively do that also be using format-patch as it is normally used now.

-- John

On Mon, Feb 25, 2008 at 07:57:13PM +0100, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:

that's true, while the practice can be the opposite. darcs forces you to have an smtpd on localhost, while git allows you to send the patch from your mail client. this _is_ easier for people sometimes. (especially these days when everybody blocks dhcp address ranges and an avarage user doesn't configure a proxy smtpd on localhost usually i think.)

- VMiklos

On 2008-02-25, Miklos Vajna <vmiklos@frugalware.org> wrote:

Actually, both can do both, right? darcs send -o will write the data to send out to a file on disk, and git-send-email will transmit the message. I don't so much care about the default as making it easy for people that do have a local sendmail or smtpd or (ugh) MAPI client to send patches automatically, if I tell them what flags to use.

-- John

On Tue, Feb 26, 2008 at 07:59:55AM -0600, John Goerzen <jgoerzen@complete.org> wrote:

right. afaik no commands read the remote git config atm, but it might be possible.

true. what annoyed me is that i needed net access to generate the file, ie i was not able to do a 'darcs send -o file', copy the file to an usb stick and send it from some other box.

but that's the case for git as well :) you should tell people (for example): use "git format-patch origin"; send the created *.patch files and use "git pull --rebase" to avoid an unnecessary merge.

- VMiklos

Jeff King <peff@peff.net> writes:

That matches my recollection, but I think the most important point to take home from these points are that you cannot blindly say that the tool can figure it out and do that for you. We could probably have an automated way to scan shortlog and whatnot and offer suggestions, but the final determination of the recipient addresses needs to be done by the end user.

Which in short means README or Documentation/SubmittingPatches would be the most appropriate place for that information.