monospaced (`GIT_EDITOR` - l.657)
As a first step, this patch changes GIT_* variables that where in
italic style to monospace font. It was obtained with
perl -pi -e "s/\'(GIT_.*?)\'/\`\1\`/g" *.txt
Signed-off-by: Tom Russello
Signed-off-by: Matthieu Moy
---
Hello,
There is n
Hello,
With the current send-email command, you can send a series of patches "in reply
to" an email.
This patch adds a new option to `git send-email`, `--quote-mail=`, to
quote an email in the cover letter in your series of patches.
The "To", "Cc" and "Subject" fields will be filled appropriately
From: Tom Russello
Tests if the "To", "Cc" and "Subject" fields are adequately filled and if the
message is correctly quoted.
Signed-off-by: Tom Russello
Signed-off-by: Samuel Groot
Signed-off-by: Matthieu Moy
---
diff --git a/t/t9001-send-email.sh b/t/t90
From: Tom Russello
This new option takes an email message file, parses it, fills the "To",
"Subject" and "Cc" fields appropriately and quote the message.
This option involves the `--compose` mode to edit the cover letter quoting the
given email.
Signed-off-b
On 05/25/16 00:30, Aaron Schrab wrote:
> At 14:49 +0200 24 May 2016, Matthieu Moy
> wrote:
>> Samuel GROOT writes:
>>
>>> What kind of help text would you want to see?
>>>
>>> Maybe something like this:
>>>
>>> GIT: Quoted message body below.
>>> GIT: Feel free to trim down the quoted text
>>
Hello,
With the current send-email command, you can send a series of patches
"in reply to" an email.
This patch adds a new option to `git send-email`,
`--quote-email=` which does two things:
- set fields appropriately (To, Cc, Subject, In-Reply-To)
- quote the given message
In th
Take an email message file, parse it and quote the message body.
If `--compose` is set, then it will quote the message in the cover letter.
Otherwise, imply `--annotate` option and put the quoted message in the first
patch after the triple-dash.
Signed-off-by: Tom Russello
Signed-off-by: Samuel
Take an email message file, parse it and fill the "To", "Cc" and
"In-Reply-To" fields appropriately.
If `--compose` option is set, it will also fill the subject field with
"Re: ['s subject]".
Signed-off-by: Tom Russello
Signed-off-by: Samuel Groot
S
On 05/28/16 17:01, Matthieu Moy wrote:
>> Currently, `send-email` without `--compose` implies `--annotate`.
>
> I don't get it. Did you mean s/without/with/? Even if so, this is not
> exactly true: "git send-email --compose -1" will open the editor only
> for the cover-letter, while adding --annota
On 05/28/16 16:35, Matthieu Moy wrote:
>> +--quote-email=::
>> +Reply to the given email and automatically populate the "To:",
"Cc:" and
>> +"In-Reply-To:" fields.
>
> I think this is a bit too technical for a user documentation. To: and
> Cc: is OK, but people need not know about "In-Reply
Hello,
as `MAN_BOLD_LITERAL` knob is now turned on by default, it is the right time to
make our documentation more consistent.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majo
s -iP perl -pi -e "s/\'P\'/\`P\`/g" ./*.txt
Signed-off-by: Tom Russello
Signed-off-by: Erwan Mathoniere
Signed-off-by: Samuel Groot
Signed-off-by: Matthieu Moy
---
Currently, in Documentation/git-status.txt, status.relativePaths (l.120) has no
particular style whereas in Docum
Make the guideline text that we want for our documentation clearer.
Signed-off-by: Tom Russello
Signed-off-by: Erwan Mathoniere
Signed-off-by: Samuel Groot
Signed-off-by: Matthieu Moy
---
IMHO, the previous "rule" was not so clear on what we have to do and didn't give
a guide
As a first step, this change GIT_* variables that where in
italic style to monospace font according to the guideline. It was obtained
with
perl -pi -e "s/\'(GIT_.*?)\'/\`\1\`/g" *.txt
Signed-off-by: Tom Russello
Signed-off-by: Erwan Mathoniere
Signed-off-by: Samuel
Hello,
as `MAN_BOLD_LITERAL` knob is just now turned on by default with 5945717
(Documentation: bold literals in man, 2016-05-31), it is the right time to
make our documentation more consistent.
Changes since v2: prefix the email subject lines with "doc:"
--
To unsubscribe from this list: send th
Make the guideline text that we want for our documentation clearer.
Signed-off-by: Tom Russello
Signed-off-by: Erwan Mathoniere
Signed-off-by: Samuel Groot
Signed-off-by: Matthieu Moy
---
IMHO, the previous "rule" was not so clear on what we have to do and didn't give
a guide
As a first step, this change GIT_* variables that where in
italic style to monospace font according to the guideline. It was obtained
with
perl -pi -e "s/\'(GIT_.*?)\'/\`\1\`/g" *.txt
Signed-off-by: Tom Russello
Signed-off-by: Erwan Mathoniere
Signed-off-by: Samuel
s -iP perl -pi -e "s/\'P\'/\`P\`/g" ./*.txt
Signed-off-by: Tom Russello
Signed-off-by: Erwan Mathoniere
Signed-off-by: Samuel Groot
Signed-off-by: Matthieu Moy
---
Currently, in Documentation/git-status.txt, status.relativePaths (l.120) has no
particular style whereas in Docum
On 06/06/16 15:42, Matthieu Moy wrote:
> Matthieu Moy writes:
>
>> Tom Russello writes:
>>> + Literal examples (e.g. use of command-line options, command names,
>>> + configuration and environment variables) must be typeset in monospace
>>
On 06/06/16 16:08, Matthieu Moy wrote:
> I'd add to the commit message that one of the goals of this patch is to
> make the use "mostly consistent" with CodingGuidelines, so that people
> writting new doc by mimicking the existing one later get a good
> probability of getting it right even if they
The purpose of this series of patches is to implement a new
"quote-email" feature integrated in the current `--in-reply-to` option.
* The first 2 patches make the tests less dependent to
`git send-email`'s exact output.
* Third patch makes `git send-email` a bit less verbose.
* Fourth pat
Tests might fail if lines compared in text files don't have the same order.
Signed-off-by: Samuel GROOT
Signed-off-by: Tom RUSSELLO
Signed-off-by: Matthieu MOY
---
t/t9001-send-email.sh | 61 ---
1 file changed, 34 insertions(+), 27 dele
Check if the given utf-8 email address is in the Cc: field.
Signed-off-by: Tom RUSSELLO
Signed-off-by: Samuel GROOT
Signed-off-by: Matthieu MOY
---
t/t9001-send-email.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index
We need a simple and generic way to parse an email file.
Since it would be hard to include and maintain an external library,
create an simple email parser subroutine to parse an email file.
Signed-off-by: Samuel GROOT
Signed-off-by: Tom RUSSELLO
Signed-off-by: Matthieu MOY
---
We chose to
Messages displayed by `send-email` should be shortened to avoid displaying
unnecesseray informations.
Signed-off-by: Samuel GROOT
Signed-off-by: Tom RUSSELLO
Signed-off-by: Matthieu MOY
---
git-send-email.perl | 22 +--
t/t9001-send-email.sh | 58
-by: Tom RUSSELLO
Signed-off-by: Samuel GROOT
Signed-off-by: Matthieu MOY
---
Documentation/git-send-email.txt | 8
git-send-email.perl | 81 ++--
t/t9001-send-email.sh| 32
3 files changed, 117 insertions(+), 4
Take an email message file, parse it and fill the "From", "To", "Cc",
"In-reply-to", "References" fields appropriately.
If `--compose` option is set, it will also fill the subject field with
`Re: ['s subject]` in the introductory message.
S
new documentation by mimicking the existing are more likely
to have it right (even if they didn't read the CodingGuidelines).
Signed-off-by: Tom Russello
Signed-off-by: Erwan Mathoniere
Signed-off-by: Samuel Groot
Signed-off-by: Matthieu Moy
---
Changes since v3:
- More precise commi
Hello,
as `MAN_BOLD_LITERAL` knob is just now turned on by default with 5945717
(Documentation: bold literals in man, 2016-05-31), it is the right time to
make our documentation more consistent.
Documentation/CodingGuidelines| 13 --
Documentation/config.txt | 58 ++
Make the guideline text that we want for our documentation clearer.
Signed-off-by: Tom Russello
Signed-off-by: Erwan Mathoniere
Signed-off-by: Samuel Groot
Signed-off-by: Matthieu Moy
---
Changes since v3:
- Add the rule of when environment variables must be prefixed with
in purposes is to stick to the CodingGuidelines as possible so
that people writting new documentation by mimicking the existing are more likely
to have it right (even if they didn't read the CodingGuidelines).
Signed-off-by: Tom Russello
Signed-off-by: Erwan Mathoniere
Signed-off-by: Samuel
i -e "s/\'P\'/\`P\`/g" ./*.txt
Signed-off-by: Tom Russello
Signed-off-by: Erwan Mathoniere
Signed-off-by: Samuel Groot
Signed-off-by: Matthieu Moy
Reviewed-by: Matthieu Moy
---
I forgot to add this patch to the current series (v4) and there is no change
si
On 06/08/16 08:26, Matthieu Moy wrote:
> Did you drop the "configuration variables" patch on purpose? Or will you
> resend it separately?
I just resend it separately,
thank you.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
On 06/09/16 07:51, Matthieu Moy wrote:
> Junio C Hamano writes:
>
>> Tom Russello writes:
>>
>>> +# Check if two files have the same content, non-order sensitive
>>> +test_cmp_noorder () {
>>> + sort $1 >$1;
>>
>> Here is what I th
Le 09/06/2016 à 13:49, Matthieu Moy a écrit :
> Samuel GROOT writes:
>
>> If used with `in-reply-to=`, cite the message body of the given
>> email file. Otherwise, do nothing.
>
> It should at least warn when --in-reply-to= is not given
> (either no --in-reply-to or --in-reply-to=). I don't see
35 matches
Mail list logo
