From: Andreas Ericsson <hidden> Date: 2016-06-15 22:42:13
Finally giving up on git-send-email (I won't install the 6 perl-modules
it requires and I don't know perl enough to remove the need for them), I
hacked up a replacement in sh. It's more aptly named as well. ;)
It tries to be fairly newbie-friendly in what it accepts so that new
developers on a project easily can submit patches upstream in the
desired format.
This is just a draft. If anyone thinks it's a good idea then say so and
I'll write the man-page and re-submit it as a proper patch.
It's better than the perl version because;
1. It doesn't have any requirements other than normal unix-commands and
"mail" being in the path.
2. It can generate the patches on the fly, using git-format-patch.
It's worse than the perl version because;
1. It doesn't thread the patch-series (which I personally prefer anyway
since it's easier to follow a thread on a particular patch that way).
2. The patches sent within the same second arrive in random order.
Sorry about the attachment btw. Thunderbird seems to wrap lines no
matter what I tell it.
Thoughts? Comments?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
From: Nikolai Weibull <hidden> Date: 2016-06-15 22:42:13
Andreas Ericsson wrote:
Finally giving up on git-send-email (I won't install the 6 perl-modules
it requires and I don't know perl enough to remove the need for them), I
hacked up a replacement in sh. It's more aptly named as well. ;)
It's better than the perl version because;
1. It doesn't have any requirements other than normal unix-commands and
"mail" being in the path.
2. It can generate the patches on the fly, using git-format-patch.
Great!
It's worse than the perl version because;
1. It doesn't thread the patch-series (which I personally prefer anyway
since it's easier to follow a thread on a particular patch that way).
Not so great. Why is it so much more difficult to have one more level
of nesting? It's annoying, but it's a lot less annoying than having 19
separate threads that are all, in fact, related to each other.
2. The patches sent within the same second arrive in random order.
Perhaps adding a 'sleep 1' would help? (The delay may be unacceptable
to some people, though.)
nikolai
--
Nikolai Weibull: now available free of charge at http://bitwi.se/!
Born in Chicago, IL USA; currently residing in Gothenburg, Sweden.
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:42:13
Nikolai Weibull wrote:
quoted
It's worse than the perl version because;
1. It doesn't thread the patch-series (which I personally prefer anyway
since it's easier to follow a thread on a particular patch that way).
Not so great. Why is it so much more difficult to have one more level
of nesting? It's annoying, but it's a lot less annoying than having 19
separate threads that are all, in fact, related to each other.
I am of the opinion that nesting is bad because some patches get a few
comments while some others get them in droves. It's easy to miss those
with few if they're all nested. As for finding them, all the threads
should show up next to each other since there's practically no delay
between sending them.
As for implementation, I don't think most "mail" programs have the
functionality necessary to do so (dunno though since I didn't investigate).
quoted
2. The patches sent within the same second arrive in random order.
Perhaps adding a 'sleep 1' would help? (The delay may be unacceptable
to some people, though.)
I thought about that, but decided against it.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:42:13
Hi,
On Fri, 25 Nov 2005, Andreas Ericsson wrote:
It's worse than the perl version because;
1. It doesn't thread the patch-series (which I personally prefer anyway since
it's easier to follow a thread on a particular patch that way).
I think you can do that easily by providing a Message-ID: and a
References: header. The id could be made up by "git-$commit_id" to be
reasonably unique.
2. The patches sent within the same second arrive in random order.
I have that all the time. Sometimes, I send emails to the git list
several minutes apart, and they come out in the wrong order. So it is no
problem.
Sorry about the attachment btw. Thunderbird seems to wrap lines no
matter what I tell it.
The hints in SubmittingPatches did not help?
Thoughts? Comments?
I find it very cool. And easy to read. Just a few nits: You could use
git-sh-setup.sh to ensure that you're in a valid git repository. Also, you
could reuse the "die" function contained therein instead of a new
function, "abort".
Ciao,
Dscho
From: Fernando J. Pereda <hidden> Date: 2016-06-15 22:42:13
On Fri, Nov 25, 2005 at 11:59:07AM +0100, Andreas Ericsson wrote:
| As for implementation, I don't think most "mail" programs have the
| functionality necessary to do so (dunno though since I didn't investigate).
You can always generate a 'valid' mail message and use the sendmail
binary directly. That way you can set proper Message-Id: and proper
References: and/or In-Reply-To: in the following mails.
Cheers,
Ferdy
--
Fernando J. Pereda Garcimartín
Gentoo Developer (Alpha,net-mail,mutt,git)
20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4
From: Junio C Hamano <hidden> Date: 2016-06-15 22:42:13
Andreas Ericsson [off-list ref] writes:
It's better than the perl version because;
Good.
It's worse than the perl version because;
1. It doesn't thread the patch-series (which I personally prefer anyway
since it's easier to follow a thread on a particular patch that way).
I think that is an improvement, actually ;-)
2. The patches sent within the same second arrive in random order.
I think you can fudge the "Date: " yourself. Count the number
of messages you are going to send out, grab the wallclock time
before starting to send the first message, subtract that number
of seconds and give it to the first message, add 1 second and
give it to the second message, and so on.
3. It does not CC signers and authors. Although I personally
consider not doing it "better", some people _might_ want to keep
that behaviour as an option.
# Instead of applying the 8942 chars long RFC-exact regex to
# match recipients email addresses against, we're satisfied with
# a simple @ somewhere inside an argument and just assume that
# people won't try anything obviously stupid
This is probably adequate in practice. I have not seen an
e-mail address other than local-part@domain (RFC2822-speak
"addr-spec") form of mailbox on the kernel list for some time.
I'm old fashioned and tend to omit noise word "function".
The original format-patch parameters are my fault, but I'd
rather see newly written commands done like this:
"git-send-email" <param>+
<param> = <patch> | <addressee> | <commits>
<patch> = <anything that passes "test -f">
<addressee> = <RFC2822 addr-spec>
<commits> = ".." <top> | <bottom> ".." <top> | <commit>
<bottom> = <extended SHA1 expression>
<top> = <extended SHA1 expression>
<commit> = <extended SHA1 expression>
* ..<top> is a shorthand of "origin"..<top> (the choice of
"origin" might be debatable, but probably sane).
* <bottom>..<top> pair is to format changes in <top> but not in
<bottom>; typically <top> is the name of a topic branch, and
<bottom> is typically "origin". This is to encourage the use
of topic branches.
* <commit> is a shorthand for <commit>^1..<commit>; this is to
allow you to quickly pick just one commit and send it out.
function abort() {
echo "Aborting."
exit 0
}
Abort but exit 0? You do not seem to be using it though ;-).
commits=0
if [ "$com1" ]; then
if [ -z "$com2" ]; then
com2="$com1"
com1=HEAD
fi
commits=$(git rev-list $com1 ^$com2 | wc -l)
fi
You do not want to count commits like this. format-patch drops
patches that are already in upstream even if they are recorded
as diffrent commit objects, so the number you get from rev-list
is just an upper bound, and may not match the number of commits
that would be formatted.
[ $commits -eq 0 -a -z "$patches" ] && usage
And I'd probably drop this one as well; you can have the check
before sending things out, right?
Storing the default addressee in the config is a good idea,
since typically e-mail submissions are to a single address.
[ $commits -gt 1 ] && opts=-n
You can always say -n if you want to do this; format-patch -n
with a single patch would not say [PATCH 1/1].
for patch in $(git format-patch $opts $com2 $com1 | sed 's/^* //'); do
patches="$patches $patch"
done
This is the first script I saw that uses the standard output
from format-patch, and I do not think nobody else used it so
far. If the standard output from format-patch is useful like
this, I would like to drop the '* ' prefix from it, so that you
do not have to sed it out.
You would probably want to do "format-patch -o $tmpdir" at least
not to smudge the toplevel directory.
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:42:13
Johannes Schindelin wrote:
quoted
Sorry about the attachment btw. Thunderbird seems to wrap lines no
matter what I tell it.
The hints in SubmittingPatches did not help?
Nopes. Perhaps because I started editing the message before I changed
the settings. I'll investigate further and make amendments if necessary.
quoted
Thoughts? Comments?
I find it very cool. And easy to read. Just a few nits: You could use
git-sh-setup.sh to ensure that you're in a valid git repository. Also, you
could reuse the "die" function contained therein instead of a new
function, "abort".
Will do. Thanks for the feedback.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
From: Ryan Anderson <hidden> Date: 2016-06-15 22:42:13
On Fri, Nov 25, 2005 at 10:45:41AM +0100, Andreas Ericsson wrote:
Finally giving up on git-send-email (I won't install the 6 perl-modules
it requires and I don't know perl enough to remove the need for them), I
hacked up a replacement in sh. It's more aptly named as well. ;)
Scanning the list, 2 are related to option handling (one of which is
builtin), one isn't used (Data::Dumper), and two are related to sending
valid emails. The email address verification is ridiculously hard to get
correct, so using pre-written code for that seemed justified.
It's worse than the perl version because;
1. It doesn't thread the patch-series (which I personally prefer anyway
since it's easier to follow a thread on a particular patch that way).
You can use --no-chain-reply-to in git-send-email.perl, and put a 0/N
message in, and all subsequent replies get attached to that instead of
in order, if you want. This keeps everything in one thread, but all as
responses to the first email, so the people that want everything in one
thread can get that behavior.
--
Ryan Anderson
sometimes Pug Majere
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:42:13
Ryan Anderson wrote:
On Fri, Nov 25, 2005 at 10:45:41AM +0100, Andreas Ericsson wrote:
quoted
Finally giving up on git-send-email (I won't install the 6 perl-modules
it requires and I don't know perl enough to remove the need for them), I
hacked up a replacement in sh. It's more aptly named as well. ;)
Scanning the list, 2 are related to option handling (one of which is
builtin), one isn't used (Data::Dumper), and two are related to sending
valid emails.
When I try to install Email::Valid (using apt) it wants an additional
two modules. Mail::Sendmail wants one other, so that's Data::Dumper, the
two actually used and the three those two use. Six, for short.
The email address verification is ridiculously hard to get
correct, so using pre-written code for that seemed justified.
But it isn't necessary to validate it to such exactness. Nothing worse
will happen than the user chiding himself for his butterfingers if
he/she makes a mistake.
Besides, I think typos are by far the most common error. Those are
usually valid email addresses while still not being correct.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:42:13
Junio C Hamano wrote:
Andreas Ericsson [off-list ref] writes:
quoted
It's worse than the perl version because;
1. It doesn't thread the patch-series (which I personally prefer anyway
since it's easier to follow a thread on a particular patch that way).
I think that is an improvement, actually ;-)
Agreed to that then. Good thing since that was the hardest to solve.
quoted
2. The patches sent within the same second arrive in random order.
I think you can fudge the "Date: " yourself. Count the number
of messages you are going to send out, grab the wallclock time
before starting to send the first message, subtract that number
of seconds and give it to the first message, add 1 second and
give it to the second message, and so on.
3. It does not CC signers and authors. Although I personally
consider not doing it "better", some people _might_ want to keep
that behaviour as an option.
It doesn't CC them, but any number of email-addresses can be specified
on the command line (so long as they don't include spaces, but that can
be taken care of).
These below needs a bit of clarification. It's friday afternoon here, so
I'm a bit slow.
<commits> = ".." <top> | <bottom> ".." <top> | <commit>
<bottom> = <extended SHA1 expression>
<top> = <extended SHA1 expression>
<commit> = <extended SHA1 expression>
* ..<top> is a shorthand of "origin"..<top> (the choice of
"origin" might be debatable, but probably sane).
I'd rather specify the entry-point, as in "get all patches from this
commit to HEAD", if only one commit is specified, so:
git-send-patch git@vger.kernel.org origin
would do just that.
* <bottom>..<top> pair is to format changes in <top> but not in
<bottom>; typically <top> is the name of a topic branch, and
<bottom> is typically "origin". This is to encourage the use
of topic branches.
Would that be
git-send-patch origin..HEAD
to get the changes in the current branch since head?
* <commit> is a shorthand for <commit>^1..<commit>; this is to
allow you to quickly pick just one commit and send it out.
Marvellous the things one learn. I didn't know about that syntax before. :)
Storing the default addressee in the config is a good idea,
since typically e-mail submissions are to a single address.
If values can have spaces there can be any number of email-addresses.
quoted
[ $commits -gt 1 ] && opts=-n
You can always say -n if you want to do this; format-patch -n
with a single patch would not say [PATCH 1/1].
Didn't know that. Good thing though.
This is the first script I saw that uses the standard output
from format-patch, and I do not think nobody else used it so
far. If the standard output from format-patch is useful like
this, I would like to drop the '* ' prefix from it, so that you
do not have to sed it out.
I'll do that then. It doesn't really add any value anyways.
You would probably want to do "format-patch -o $tmpdir" at least
not to smudge the toplevel directory.
Perhaps support the -o flag in git-send-patch?
I'm wondering if it wouldn't be better to move much of
git-format-patch's functionality to git-send-patch and support a
"--todisk" option. After all, how many patches are created but not sent
anywhere?
That way we could rework the syntax to only support that of
git-rev-list. I think it's the most standard-like thing there is in git.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
From: Junio C Hamano <hidden> Date: 2016-06-15 22:42:13
Andreas Ericsson [off-list ref] writes:
It doesn't CC them, but any number of email-addresses can be specified
on the command line (so long as they don't include spaces, but that can
be taken care of).
Again I do not think I'd ever use that feature from the original
send-email myself, but the difference is that this CC list
depends on each commit (sign-offs taken from a commit are
added to CC list for only that commit).
quoted
* <bottom>..<top> pair is to format changes in <top> but not in
<bottom>; typically <top> is the name of a topic branch, and
<bottom> is typically "origin". This is to encourage the use
of topic branches.
Would that be
git-send-patch origin..HEAD
to get the changes in the current branch since head?
Yes, and that could be spelled "git-send-patch ..HEAD" as well,
if we go with my suggestion to default <bottom> to "origin".
quoted
* <commit> is a shorthand for <commit>^1..<commit>; this is to
allow you to quickly pick just one commit and send it out.
Marvellous the things one learn. I didn't know about that syntax before. :)
Just to make sure you did not misunderstand me, I meant: the
proposed program acts as if <commit>^1..<commit> was given when
single <commit> is given.
But you are right. We could make a single <commit> a short-hand
for "origin"..<commit>; if somebody wants to pick just one
commit from a topic branch, he can always say <commit>^1..<commit>.
I'm wondering if it wouldn't be better to move much of
git-format-patch's functionality to git-send-patch and support a
"--todisk" option. After all, how many patches are created but not sent
anywhere?
Manymanymanymanymany. I do all my rebases and cherry-picks via
format-patch piped to git-am, and obviously they are never sent
out.
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:42:13
Junio C Hamano wrote:
Andreas Ericsson [off-list ref] writes:
quoted
It doesn't CC them, but any number of email-addresses can be specified
on the command line (so long as they don't include spaces, but that can
be taken care of).
Again I do not think I'd ever use that feature from the original
send-email myself, but the difference is that this CC list
depends on each commit (sign-offs taken from a commit are
added to CC list for only that commit).
Had a thinko when I wrote that. I've added --cc-signers, --cc-author and
--cc (for both --cc-signers and --cc-author).
But you are right. We could make a single <commit> a short-hand
for "origin"..<commit>;
Actually, I meant that a single <commit> would mean "<commit>..HEAD",
like git-format-patch does it. Doing the other way around in a tool so
closely coupled would be very confusing, I think.
Here's what I have on disk right now. The ${var##*^} syntax was decided
to be portable in some earlier discussion, so I'm sticking with it
(mostly because I don't know how to do it with expr and Junio pokes me
when I do it with sed. Enlightenment welcome).
if [ "$com2" ]; then
range="$com1..$com2"
else
case "$com1" in
?*..?*)
# nicely ranged already
range="$com1"
;;
..)
range=origin..HEAD
;;
?*^)
# single commit
com1="${com1##*^}"
range="$com1^1..$com1"
;;
?*^[0-9]|?*^[0-9][0-9])
# series of commits, ranging back from <commit-ish>
range="$com1..${com1%%^*}"
;;
^[0-9]|^[0-9][0-9])
# series of commits, ranging back from HEAD
range="HEAD$com1..HEAD"
;;
*)
range="$com1..HEAD"
;;
esac
fi
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
From: Ryan Anderson <hidden> Date: 2016-06-15 22:42:13
Andreas Ericsson wrote:
Ryan Anderson wrote:
quoted
On Fri, Nov 25, 2005 at 10:45:41AM +0100, Andreas Ericsson wrote:
quoted
Finally giving up on git-send-email (I won't install the 6
perl-modules it requires and I don't know perl enough to remove the
need for them), I hacked up a replacement in sh. It's more aptly
named as well. ;)
Scanning the list, 2 are related to option handling (one of which is
builtin), one isn't used (Data::Dumper), and two are related to sending
valid emails.
When I try to install Email::Valid (using apt) it wants an additional
two modules. Mail::Sendmail wants one other, so that's Data::Dumper, the
two actually used and the three those two use. Six, for short.
Can I ask why you aren't willing to install packages, such as those? I
can understand a reluctance to install modules directly from CPAN, on an
otherwise package-managed system, but I'm afraid I must confess to
puzzlement over a reluctance to use pre-packaged modules.
The major flaw in git-send-email, from my perspective, was a lack of
support for SMTP AUTH, for situations like Junio's, where the local MTA
(and thus "mail" as well) are not configured to handle SMTP AUTH. Moving
to a purely shell based replacement seems to make this an even harder
feature to support. (Though, admittedly, I haven't even made an attempt
to add it to the Perl version yet.)
quoted
The email address verification is ridiculously hard to get
correct, so using pre-written code for that seemed justified.
But it isn't necessary to validate it to such exactness. Nothing worse
will happen than the user chiding himself for his butterfingers if
he/she makes a mistake.
Besides, I think typos are by far the most common error. Those are
usually valid email addresses while still not being correct.
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:42:13
Ryan Anderson wrote:
Andreas Ericsson wrote:
quoted
When I try to install Email::Valid (using apt) it wants an additional
two modules. Mail::Sendmail wants one other, so that's Data::Dumper, the
two actually used and the three those two use. Six, for short.
Can I ask why you aren't willing to install packages, such as those? I
can understand a reluctance to install modules directly from CPAN, on an
otherwise package-managed system, but I'm afraid I must confess to
puzzlement over a reluctance to use pre-packaged modules.
I don't like having lots of junk installed. Besides, I do a lot of
development work for the Openwall distro which tries fairly hard to get
away without installing lots of cruft. I'd rather not taint it with
packages from other vendors since I do a fair amount of RPM building and
testing on it but I still want to be able to use git on it.
The major flaw in git-send-email, from my perspective, was a lack of
support for SMTP AUTH, for situations like Junio's, where the local MTA
(and thus "mail" as well) are not configured to handle SMTP AUTH. Moving
to a purely shell based replacement seems to make this an even harder
feature to support. (Though, admittedly, I haven't even made an attempt
to add it to the Perl version yet.)
By "local" do you mean "local on Junio's laptop" or "local at cox.net"?
"mail" uses the "local on Junio's laptop" SMTP server so he can
configure it any way he wants.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231