From: John Goerzen <hidden> Date: 2016-06-15 22:44:16
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
From: Paolo Ciarrocchi <hidden> Date: 2016-06-15 22:44:16
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/
From: John Goerzen <hidden> Date: 2016-06-15 22:44:17
On 2008-02-24, Paolo Ciarrocchi [off-list ref] wrote:
On 2/25/08, John Goerzen > Would it also be possible to unify
git-format-patch and
quoted
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
From: Jeff King <hidden> Date: 2016-06-15 22:44:17
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
From: Jeff King <hidden> Date: 2016-06-15 22:44:17
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
From: Paolo Ciarrocchi <hidden> Date: 2016-06-15 22:44:17
On 2/25/08, Jeff King [off-list ref] wrote:
On Mon, Feb 25, 2008 at 02:26:03AM +0330, Paolo Ciarrocchi wrote:
quoted
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.
On Mon, Feb 25, 2008 at 09:08:20AM -0600, John Goerzen [off-list ref] 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