git-email automatic --to detection?

git-email automatic --to detection?

[John Goerzen]

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

Re: git-email automatic --to detection?

[Paolo Ciarrocchi]

On 2/25/08, John Goerzen > 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)?

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/

Re: git-email automatic --to detection?

[Miklos Vajna]

[-- Attachment #1: Type: text/plain, Size: 306 bytes --]

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

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

- VMiklos

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: git-email automatic --to detection?

[John Goerzen]

On 2008-02-24, Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:
> On 2/25/08, John Goerzen > 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)?
>
> 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.

That sounds reasonable to me.

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

-- John

Re: git-email automatic --to detection?

[John Goerzen]

On Mon February 25 2008 8:39:59 am Miklos Vajna wrote:
> On Sun, Feb 24, 2008 at 04:29:56PM -0600, John Goerzen 
<jgoerzen@complete.org> wrote:
> > 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?
>
> i don't think so. what about git config sendemail.to?

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.


>
> - VMiklos

Re: git-email automatic --to detection?

[Jeff King]

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

Re: git-email automatic --to detection?

[Jeff King]

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

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

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

Re: git-email automatic --to detection?

[Paolo Ciarrocchi]

On 2/25/08, Jeff King <peff@peff.net> wrote:
> On Mon, Feb 25, 2008 at 02:26:03AM +0330, Paolo Ciarrocchi wrote:
>
> > 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.
>
> 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.


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

Re: git-email automatic --to detection?

[Matthieu Moy]

Jeff King <peff@peff.net> writes:

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

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.

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

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.

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

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

-- 
Matthieu

Re: git-email automatic --to detection?

[Jeff King]

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

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

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

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

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.

> >   - this information can potentially be inferred from git shortlog
> >     and/or blame; this addresses the problem of data becoming stale
> 
> Yes and no. git@vger.kernel.org won't appear anywhere in these for
> example.

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

Re: git-email automatic --to detection?

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> 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

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.

Re: git-email automatic --to detection?

[John Goerzen]

On 2008-02-25, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> 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.

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.

Re: git-email automatic --to detection?

[Miklos Vajna]

[-- Attachment #1: Type: text/plain, Size: 441 bytes --]

On Mon, Feb 25, 2008 at 09:08:20AM -0600, John Goerzen <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.

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: git-email automatic --to detection?

[Miklos Vajna]

[-- Attachment #1: Type: text/plain, Size: 741 bytes --]

On Mon, Feb 25, 2008 at 07:57:13PM +0100, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> 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.

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: git-email automatic --to detection?

[Matthieu Moy]

John Goerzen <jgoerzen@complete.org> writes:

> On 2008-02-25, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
>> 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.
>
> Right.  That's why this would be a per-repo setting.  It wouldn't be
> pulled or cloned, just looked up when needed.

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.

-- 
Matthieu

Re: git-email automatic --to detection?

[John Goerzen]

On 2008-02-25, Miklos Vajna <vmiklos@frugalware.org> wrote:
>> 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.
>
> 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.)

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

Re: git-email automatic --to detection?

[John Goerzen]

On 2008-02-26, 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 think it should. Not versionned, but initialized by "clone" based on
> the cloned repo.

That would work.

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

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

Re: git-email automatic --to detection?

[Miklos Vajna]

[-- Attachment #1: Type: text/plain, Size: 921 bytes --]

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

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

>  darcs send -o will write the data
> to send out to a file on disk, and git-send-email will transmit the
> message.

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.

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

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]