* [RFC-PATCH 0/2] send-email: new --quote-mail option
@ 2016-05-23 19:30 Tom Russello
2016-05-23 19:30 ` [RFC-PATCH 1/2] send-email: new option to quote an email and reply to Tom Russello
` (3 more replies)
0 siblings, 4 replies; 256+ messages in thread
From: Tom Russello @ 2016-05-23 19:30 UTC (permalink / raw)
To: git; +Cc: samuel.groot, matthieu.moy, erwan.mathoniere, jordan.de-gea
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=<file>`, to
quote an email in the cover letter in your series of patches.
The "To", "Cc" and "Subject" fields will be filled appropriately and the message
given quoted in the cover letter for the series of patches.
In this first patch, the new option `--quote-mail=<file>` needs an
email file and does not manage accents.
There is still work in progress, including:
1. An option `--quote-mail-id=<message-id>` to download the message
from any source, e.g. http://mid.gmane.org/<message-id>/raw.
The server's address could be set in the repo's config file.
2. The proper documentation for `--quote-mail=<file>` and
`--quote-mail-id=<message-id>` as soon as their definitive
behavior is approved by the community.
3. The code to parse the email headers is currently duplicated several
times, we should refactor it to help maintaining the code.
4. More tests on the features described above.
git-send-email.perl | 99 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
t/t9001-send-email.sh | 43 +++++++++++++++++++++++++++++++++++++++++++
2 files changed, 141 insertions(+), 1 deletion(-)
^ permalink raw reply [flat|nested] 256+ messages in thread
* [RFC-PATCH 1/2] send-email: new option to quote an email and reply to
2016-05-23 19:30 [RFC-PATCH 0/2] send-email: new --quote-mail option Tom Russello
@ 2016-05-23 19:30 ` Tom Russello
2016-05-23 19:55 ` Eric Wong
2016-05-23 20:00 ` Matthieu Moy
2016-05-23 19:30 ` [RFC-PATCH 2/2] t9001: adding --quote-mail option test Tom Russello
` (2 subsequent siblings)
3 siblings, 2 replies; 256+ messages in thread
From: Tom Russello @ 2016-05-23 19:30 UTC (permalink / raw)
To: git
Cc: samuel.groot, matthieu.moy, erwan.mathoniere, jordan.de-gea,
Tom Russello, Tom Russello
From: Tom Russello <tom.russello@ensimag.grenoble-inp.fr>
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-by: Tom Russello <tom.russello@grenoble-inp.org>
Signed-off-by: Samuel Groot <samuel.groot@grenoble-inp.org>
Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
---
diff --git a/git-send-email.perl b/git-send-email.perl
index 6958785..784b8a6 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -55,6 +55,7 @@ git send-email --dump-aliases
--[no-]bcc <str> * Email Bcc:
--subject <str> * Email "Subject:"
--in-reply-to <str> * Email "In-Reply-To:"
+ --quote-mail <str> * Email To, Cc and quote the message.
--[no-]xmailer * Add "X-Mailer:" header (default).
--[no-]annotate * Review each patch that will be sent in an editor.
--compose * Open an editor for introduction.
@@ -160,7 +161,7 @@ my $re_encoded_word = qr/=\?($re_token)\?($re_token)\?($re_encoded_text)\?=/;
# Variables we fill in automatically, or via prompting:
my (@to,$no_to,@initial_to,@cc,$no_cc,@initial_cc,@bcclist,$no_bcc,@xh,
- $initial_reply_to,$initial_subject,@files,
+ $initial_reply_to,$quote_mail,$initial_subject,@files,
$author,$sender,$smtp_authpass,$annotate,$use_xmailer,$compose,$time);
my $envelope_sender;
@@ -304,6 +305,7 @@ $rc = GetOptions(
"sender|from=s" => \$sender,
"in-reply-to=s" => \$initial_reply_to,
"subject=s" => \$initial_subject,
+ "quote-mail=s" => \$quote_mail,
"to=s" => \@initial_to,
"to-cmd=s" => \$to_cmd,
"no-to" => \$no_to,
@@ -638,6 +640,98 @@ if (@files) {
print STDERR "\nNo patch files specified!\n\n";
usage();
}
+my $message_quoted;
+if ($quote_mail) {
+ $message_quoted = "";
+ my $error = validate_patch($quote_mail);
+ $error and die "fatal: $quote_mail: $error\nwarning: no patches were sent\n";
+ $compose = 1;
+ my @header = ();
+ open my $fh, "<", $quote_mail or die "can't open file $quote_mail";
+ while(<$fh>) {
+ #for files containing crlf line endings
+ $_=~ s/\r//g;
+ last if /^\s*$/;
+ if (/^\s+\S/ and @header) {
+ chomp($header[$#header]);
+ s/^\s+/ /;
+ $header[$#header] .= $_;
+ } else {
+ push(@header, $_);
+ }
+ }
+
+ foreach(@header) {
+ my $input_format;
+ my $initial_sender = $sender || $repoauthor || $repocommitter || '';
+ if (/^From /) {
+ $input_format = 'mbox';
+ next;
+ }
+ chomp;
+ if (!defined $input_format && /^[-A-Za-z]+:\s/) {
+ $input_format = 'mbox';
+ }
+
+ if (defined $input_format && $input_format eq 'mbox') {
+ if (/^Subject:\s+(.*)$/i) {
+ my $prefix_re = "";
+ my $subject_re = $1;
+ if ($1=~/^[^Re:]/) {
+ $prefix_re = "Re: ";
+ }
+ $initial_subject = $prefix_re.$subject_re;
+ }
+ elsif (/^From:\s+(.*)$/i) {
+ push @initial_to, $1;
+ }
+ elsif (/^To:\s+(.*)$/i) {
+ foreach my $addr (parse_address_line($1)) {
+ if (!($addr eq $initial_sender)) {
+ push @initial_to, $addr;
+ }
+ }
+ } elsif (/^Cc:\s+(.*)$/i) {
+ foreach my $addr (parse_address_line($1)) {
+ my $qaddr = unquote_rfc2047($addr);
+ my $saddr = sanitize_address($qaddr);
+ if ($saddr eq $initial_sender) {
+ next if ($suppress_cc{'self'});
+ } else {
+ next if ($suppress_cc{'cc'});
+ }
+ push @initial_cc, $addr;
+ }
+ } elsif (/^Message-Id: (.*)/i) {
+ $initial_reply_to = $1;
+ }
+ } else {
+ # In the traditional
+ # "send lots of email" format,
+ # line 1 = cc
+ # line 2 = subject
+ # So let's support that, too.
+ $input_format = 'lots';
+ if (@cc == 0 && !$suppress_cc{'cc'}) {
+ push @cc, $_;
+ } elsif (!defined $initial_subject) {
+ $initial_subject = $_;
+ }
+ }
+ }
+
+ #Message body
+ while (<$fh>) {
+ #for files containing crlf line endings
+ $_=~ s/\r//g;
+ my $space="";
+ if (/^[^>]/) {
+ $space = " ";
+ }
+ $message_quoted .= ">".$space.$_;
+ }
+
+}
sub get_patch_subject {
my $fn = shift;
@@ -664,6 +758,7 @@ if ($compose) {
my $tpl_sender = $sender || $repoauthor || $repocommitter || '';
my $tpl_subject = $initial_subject || '';
my $tpl_reply_to = $initial_reply_to || '';
+ my $tpl_quote = $message_quoted || '';
print $c <<EOT;
From $tpl_sender # This line is ignored.
@@ -676,6 +771,8 @@ From: $tpl_sender
Subject: $tpl_subject
In-Reply-To: $tpl_reply_to
+$tpl_quote
+
EOT
for my $f (@files) {
print $c get_patch_subject($f);
--
2.8.2
^ permalink raw reply related [flat|nested] 256+ messages in thread
* Re: [RFC-PATCH 1/2] send-email: new option to quote an email and reply to
2016-05-23 19:30 ` [RFC-PATCH 1/2] send-email: new option to quote an email and reply to Tom Russello
@ 2016-05-23 19:55 ` Eric Wong
2016-05-23 20:07 ` Matthieu Moy
2016-05-24 12:43 ` Samuel GROOT
2016-05-23 20:00 ` Matthieu Moy
1 sibling, 2 replies; 256+ messages in thread
From: Eric Wong @ 2016-05-23 19:55 UTC (permalink / raw)
To: Tom Russello
Cc: git, samuel.groot, matthieu.moy, erwan.mathoniere, jordan.de-gea,
Tom Russello
Tom Russello <tom.russello@grenoble-inp.org> wrote:
> 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.
Cool! There should probably be some help text to encourage
trimming down the quoted text to only relevant portions.
> + #Message body
> + while (<$fh>) {
> + #for files containing crlf line endings
> + $_=~ s/\r//g;
> + my $space="";
> + if (/^[^>]/) {
> + $space = " ";
> + }
> + $message_quoted .= ">".$space.$_;
Is this really necessary to switch between "> " and ">" prefix?
AFAIK, MUAs prefix unconditionally with "> ".
At least that's how mutt does it...
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [RFC-PATCH 1/2] send-email: new option to quote an email and reply to
2016-05-23 19:55 ` Eric Wong
@ 2016-05-23 20:07 ` Matthieu Moy
2016-05-23 22:10 ` Samuel GROOT
2016-05-24 12:43 ` Samuel GROOT
1 sibling, 1 reply; 256+ messages in thread
From: Matthieu Moy @ 2016-05-23 20:07 UTC (permalink / raw)
To: Eric Wong
Cc: Tom Russello, git, samuel.groot, erwan.mathoniere, jordan.de-gea,
Tom Russello
Eric Wong <e@80x24.org> writes:
> Tom Russello <tom.russello@grenoble-inp.org> wrote:
>
>> + #Message body
>> + while (<$fh>) {
>> + #for files containing crlf line endings
>> + $_=~ s/\r//g;
>> + my $space="";
>> + if (/^[^>]/) {
>> + $space = " ";
>> + }
>> + $message_quoted .= ">".$space.$_;
>
> Is this really necessary to switch between "> " and ">" prefix?
> AFAIK, MUAs prefix unconditionally with "> ".
I had the same question, but at least my mailer (Gnus) has the same
special-case it seems.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [RFC-PATCH 1/2] send-email: new option to quote an email and reply to
2016-05-23 20:07 ` Matthieu Moy
@ 2016-05-23 22:10 ` Samuel GROOT
0 siblings, 0 replies; 256+ messages in thread
From: Samuel GROOT @ 2016-05-23 22:10 UTC (permalink / raw)
To: Matthieu Moy, Eric Wong
Cc: Tom Russello, git, erwan.mathoniere, jordan.de-gea, Tom Russello
On 05/23/2016 10:07 PM, Matthieu Moy wrote:
> Eric Wong <e@80x24.org> writes:
>
>> Tom Russello <tom.russello@grenoble-inp.org> wrote:
>>
>>> + #Message body
>>> + while (<$fh>) {
>>> + #for files containing crlf line endings
>>> + $_=~ s/\r//g;
>>> + my $space="";
>>> + if (/^[^>]/) {
>>> + $space = " ";
>>> + }
>>> + $message_quoted .= ">".$space.$_;
>>
>> Is this really necessary to switch between "> " and ">" prefix?
>> AFAIK, MUAs prefix unconditionally with "> ".
>
> I had the same question, but at least my mailer (Gnus) has the same
> special-case it seems.
Thunderbird behaves the same way, so we decided to mimic that behavior.
It is specified neither in RFC 2822 [1] nor in RFC 5322 [2].
When we write an email, we write it with a maximum width of 72 columns.
If we insert "> " with each reply, the 80-columns limit will be reached
with only 4 replies.
So IMHO we should trim the extra space to allow up to 7 replies before
reaching the 80-columns limit.
[1] https://www.ietf.org/rfc/rfc2822.txt
[2] https://www.ietf.org/rfc/rfc5322.txt
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [RFC-PATCH 1/2] send-email: new option to quote an email and reply to
2016-05-23 19:55 ` Eric Wong
2016-05-23 20:07 ` Matthieu Moy
@ 2016-05-24 12:43 ` Samuel GROOT
2016-05-24 12:49 ` Matthieu Moy
2016-05-24 21:23 ` Eric Wong
1 sibling, 2 replies; 256+ messages in thread
From: Samuel GROOT @ 2016-05-24 12:43 UTC (permalink / raw)
To: Eric Wong, Tom Russello
Cc: git, matthieu.moy, erwan.mathoniere, Jordan DE GEA
On 05/23/2016 09:55 PM, Eric Wong wrote:
> Tom Russello <tom.russello@grenoble-inp.org> wrote:
>> 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.
>
> Cool! There should probably be some help text to encourage
> trimming down the quoted text to only relevant portions.
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
GIT: to only relevant portions.
As "GIT:" portions are ignored when parsed by `git send-email`.
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [RFC-PATCH 1/2] send-email: new option to quote an email and reply to
2016-05-24 12:43 ` Samuel GROOT
@ 2016-05-24 12:49 ` Matthieu Moy
2016-05-24 22:30 ` Aaron Schrab
2016-05-24 21:23 ` Eric Wong
1 sibling, 1 reply; 256+ messages in thread
From: Matthieu Moy @ 2016-05-24 12:49 UTC (permalink / raw)
To: Samuel GROOT
Cc: Eric Wong, Tom Russello, git, erwan.mathoniere, Jordan DE GEA
Samuel GROOT <samuel.groot@grenoble-inp.org> writes:
> On 05/23/2016 09:55 PM, Eric Wong wrote:
>> Tom Russello <tom.russello@grenoble-inp.org> wrote:
>>> 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.
>>
>> Cool! There should probably be some help text to encourage
>> trimming down the quoted text to only relevant portions.
>
> 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
> GIT: to only relevant portions.
>
> As "GIT:" portions are ignored when parsed by `git send-email`.
That's an option, but in the context of email, I think these
instructions are not necessary.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [RFC-PATCH 1/2] send-email: new option to quote an email and reply to
2016-05-24 12:49 ` Matthieu Moy
@ 2016-05-24 22:30 ` Aaron Schrab
2016-05-25 0:04 ` Tom Russello
0 siblings, 1 reply; 256+ messages in thread
From: Aaron Schrab @ 2016-05-24 22:30 UTC (permalink / raw)
To: Matthieu Moy
Cc: Samuel GROOT, Eric Wong, Tom Russello, git, erwan.mathoniere,
Jordan DE GEA
At 14:49 +0200 24 May 2016, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:
>Samuel GROOT <samuel.groot@grenoble-inp.org> 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
>> GIT: to only relevant portions.
>>
>> As "GIT:" portions are ignored when parsed by `git send-email`.
>
>That's an option, but in the context of email, I think these
>instructions are not necessary.
In an ideal world that would be true. But in the real world I think
evidence of many messages to this mailing list containing full quotes
suggests it might be helpful. I'd actually argue that the message be
more forceful, making it a suggestion/request to trim rather than simply
telling the user that it's allowed.
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [RFC-PATCH 1/2] send-email: new option to quote an email and reply to
2016-05-24 22:30 ` Aaron Schrab
@ 2016-05-25 0:04 ` Tom Russello
0 siblings, 0 replies; 256+ messages in thread
From: Tom Russello @ 2016-05-25 0:04 UTC (permalink / raw)
To: Eric Wong, git, erwan.mathoniere, Jordan DE GEA
Cc: Matthieu Moy, Samuel GROOT
On 05/25/16 00:30, Aaron Schrab wrote:
> At 14:49 +0200 24 May 2016, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
> wrote:
>> Samuel GROOT <samuel.groot@grenoble-inp.org> 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
>>> GIT: to only relevant portions.
>>>
>>> As "GIT:" portions are ignored when parsed by `git send-email`.
>>
>> That's an option, but in the context of email, I think these
>> instructions are not necessary.
>
> In an ideal world that would be true. But in the real world I think
> evidence of many messages to this mailing list containing full quotes
> suggests it might be helpful. I'd actually argue that the message be
> more forceful, making it a suggestion/request to trim rather than simply
> telling the user that it's allowed.
Furthermore, it is a good way to avoid very long messages due to
unnecessary parts quoted.
Therefore, we thought about a request like "Please, trim down irrelevant
sections in the quoted message to keep your email concise"
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [RFC-PATCH 1/2] send-email: new option to quote an email and reply to
2016-05-24 12:43 ` Samuel GROOT
2016-05-24 12:49 ` Matthieu Moy
@ 2016-05-24 21:23 ` Eric Wong
1 sibling, 0 replies; 256+ messages in thread
From: Eric Wong @ 2016-05-24 21:23 UTC (permalink / raw)
To: Samuel GROOT
Cc: Tom Russello, git, matthieu.moy, erwan.mathoniere, Jordan DE GEA
Samuel GROOT <samuel.groot@grenoble-inp.org> wrote:
> On 05/23/2016 09:55 PM, Eric Wong wrote:
> >Cool! There should probably be some help text to encourage
> >trimming down the quoted text to only relevant portions.
>
> 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
> GIT: to only relevant portions.
>
> As "GIT:" portions are ignored when parsed by `git send-email`.
Yes, given we have instructions for diffstat and table of contents;
I think it'd be useful to discourage quoting irrelevant parts of
the message (especially signatures and like).
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [RFC-PATCH 1/2] send-email: new option to quote an email and reply to
2016-05-23 19:30 ` [RFC-PATCH 1/2] send-email: new option to quote an email and reply to Tom Russello
2016-05-23 19:55 ` Eric Wong
@ 2016-05-23 20:00 ` Matthieu Moy
2016-05-24 23:31 ` Samuel GROOT
1 sibling, 1 reply; 256+ messages in thread
From: Matthieu Moy @ 2016-05-23 20:00 UTC (permalink / raw)
To: Tom Russello
Cc: git, samuel.groot, erwan.mathoniere, jordan.de-gea, Tom Russello
Tom Russello <tom.russello@grenoble-inp.org> writes:
> This option involves the `--compose` mode to edit the cover letter quoting the
s/involves/implies/
?
I don't think this is right: I often reply to an email with a single
patch, for which it would clearly be overkill to have a cover-letter.
Your --quote-mail does two things:
1) Populate the To and Cc field
2) Include the original message body with quotation prefix.
When not using --compose, 1) clearly makes sense already, and there's no
reason to prevent this use-case. When sending a single patch, 2) also
makes sense as "below-tripple-dash comment", like
This is the commit message for feature A.
---
John Smith wrote:
> You should implement feature A.
Indeed, here's a patch.
modified-file.c | 99 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
When sending multiple patches without --compose, 2) may not make sense,
but I think a sane behavior would be:
* If --compose is given, cite the message there.
* If --compose is not given, don't send a cover-letter but cite the body
as comment in the first patch.
As a first step, the second point can be changed to "if --compose is not
given, don't cite the message, just populate the To: and Cc: fields".
> ---
>
> diff --git a/git-send-email.perl b/git-send-email.perl
No diffstat?
> @@ -638,6 +640,98 @@ if (@files) {
> print STDERR "\nNo patch files specified!\n\n";
> usage();
> }
> +my $message_quoted;
> +if ($quote_mail) {
Style: The code you're adding doesn't look related to the code right
before => separate them with a blank line.
> + while(<$fh>) {
Style: space before (.
> + push(@header, $_);
I think the code would be clearer if @header was a list of pairs
(header-name, header-content). Then you'd need much less regex magic
when going through it.
> + #for files containing crlf line endings
Sytle: space after #.
> + foreach(@header) {
Space before (.
> + elsif (/^From:\s+(.*)$/i) {
> + push @initial_to, $1;
> + }
> + elsif (/^To:\s+(.*)$/i) {
> + foreach my $addr (parse_address_line($1)) {
> + if (!($addr eq $initial_sender)) {
> + push @initial_to, $addr;
> + }
> + }
This adds the content of the To: field in the original email to the Cc:
field in the new message, right? If so, this is a weird behavior: when
following up to an email, one usually addresses to the person s/he's
replying, keeping the others Cc-ed, hence the original From: becomes the
To header, and the original To: and Cc: become Cc:.
> + } elsif (/^Cc:\s+(.*)$/i) {
Style: IIRC, there's no consensus on whether "elsif" should be on the
same line as the closing }, but please follow the same convention inside
a single if/elsif/ chain.
> + #Message body
Style: space after # (more below). And while you're there, the comment
could be "Quote the message body" or so, to give a hint to the user
about what's going on.
> + while (<$fh>) {
> + #for files containing crlf line endings
> + $_=~ s/\r//g;
> + my $space="";
Style: spaces around =.
> @@ -676,6 +771,8 @@ From: $tpl_sender
> Subject: $tpl_subject
> In-Reply-To: $tpl_reply_to
>
> +$tpl_quote
> +
> EOT
Doesn't this add two extra useless blank lines if $tpl_quote is empty?
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [RFC-PATCH 1/2] send-email: new option to quote an email and reply to
2016-05-23 20:00 ` Matthieu Moy
@ 2016-05-24 23:31 ` Samuel GROOT
2016-05-25 6:29 ` Matthieu Moy
0 siblings, 1 reply; 256+ messages in thread
From: Samuel GROOT @ 2016-05-24 23:31 UTC (permalink / raw)
To: Matthieu Moy, Tom Russello
Cc: git, erwan.mathoniere, jordan.de-gea, Tom Russello
On 05/23/2016 10:00 PM, Matthieu Moy wrote:
> I don't think this is right: I often reply to an email with a single
> patch, for which it would clearly be overkill to have a cover-letter.
Yes indeed, we are working on inserting the quoted message body in the
patch's "below-triple-dash" section.
> Your --quote-mail does two things:
>
> 1) Populate the To and Cc field
>
> 2) Include the original message body with quotation prefix.
>
> When not using --compose, 1) clearly makes sense already, and there's no
> reason to prevent this use-case. When sending a single patch, 2) also
> makes sense as "below-tripple-dash comment", like
>
> This is the commit message for feature A.
> ---
> John Smith wrote:
> > You should implement feature A.
>
> Indeed, here's a patch.
>
> modified-file.c | 99 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
>
> When sending multiple patches without --compose, 2) may not make sense,
> but I think a sane behavior would be:
>
> * If --compose is given, cite the message there.
>
> * If --compose is not given, don't send a cover-letter but cite the body
> as comment in the first patch.
>
> As a first step, the second point can be changed to "if --compose is not
> given, don't cite the message, just populate the To: and Cc: fields".
It seems a good behavior to me too.
> * If --compose is not given, don't send a cover-letter but cite the body
> as comment in the first patch.
Then should the option imply `--annotate`, to let the user edit the
patch containing the quoted email?
>> + push(@header, $_);
>
> I think the code would be clearer if @header was a list of pairs
> (header-name, header-content). Then you'd need much less regex magic
> when going through it.
The next series of patches may include (if the code is clean enough by
then) a cleaner subroutine to parse the email, probably returning
something like:
return (
"from" => $from,
"subject" => $subject,
"date" => $date,
"message_id" => $message_id,
"to" => [@to],
"cc" => [@cc],
"xh" => [@xh],
"config" => {%config}
);
>> + elsif (/^From:\s+(.*)$/i) {
>> + push @initial_to, $1;
>> + }
>> + elsif (/^To:\s+(.*)$/i) {
>> + foreach my $addr (parse_address_line($1)) {
>> + if (!($addr eq $initial_sender)) {
>> + push @initial_to, $addr;
>> + }
>> + }
>
> This adds the content of the To: field in the original email to the Cc:
> field in the new message, right? If so, this is a weird behavior: when
> following up to an email, one usually addresses to the person s/he's
> replying, keeping the others Cc-ed, hence the original From: becomes the
> To header, and the original To: and Cc: become Cc:.
We made the option behave like Thunderbird does, but indeed RFC 2822 [1]
sees it the same you do, it will be fixed in next iteration.
>> @@ -676,6 +771,8 @@ From: $tpl_sender
>> Subject: $tpl_subject
>> In-Reply-To: $tpl_reply_to
>>
>> +$tpl_quote
>> +
>> EOT
>
> Doesn't this add two extra useless blank lines if $tpl_quote is empty?
Yes it does, it will be fixed in the next series of patches.
Thank you for your time!
[1] https://www.ietf.org/rfc/rfc2822.txt
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [RFC-PATCH 1/2] send-email: new option to quote an email and reply to
2016-05-24 23:31 ` Samuel GROOT
@ 2016-05-25 6:29 ` Matthieu Moy
2016-05-25 15:40 ` Junio C Hamano
0 siblings, 1 reply; 256+ messages in thread
From: Matthieu Moy @ 2016-05-25 6:29 UTC (permalink / raw)
To: Samuel GROOT
Cc: Tom Russello, git, erwan.mathoniere, jordan.de-gea, Tom Russello
Samuel GROOT <samuel.groot@grenoble-inp.org> writes:
> On 05/23/2016 10:00 PM, Matthieu Moy wrote:
>
>> Your --quote-mail does two things:
>>
>> 1) Populate the To and Cc field
>>
>> 2) Include the original message body with quotation prefix.
>>
[...]
>> * If --compose is not given, don't send a cover-letter but cite the body
>> as comment in the first patch.
>
> Then should the option imply `--annotate`, to let the user edit the
> patch containing the quoted email?
Actually, I'm not sure what the ideal behavior should be. Perhaps it's
better to distinguish 1) and 2) above, and have two options
--reply-to-email=<file> doing 1), and --quote doing 2), implying
--compose and requiring --reply-to-email.
That would be more flexible, but that would require two new options, and
I also like to keep things simple.
In any case, quoting the message without replying to it does not make
sense (especially if you add instructions to trim it: the user would not
even see it). So it its current form, I'd say --quote-email should imply
--annotate.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [RFC-PATCH 1/2] send-email: new option to quote an email and reply to
2016-05-25 6:29 ` Matthieu Moy
@ 2016-05-25 15:40 ` Junio C Hamano
2016-05-25 16:56 ` Matthieu Moy
0 siblings, 1 reply; 256+ messages in thread
From: Junio C Hamano @ 2016-05-25 15:40 UTC (permalink / raw)
To: Matthieu Moy
Cc: Samuel GROOT, Tom Russello, git, erwan.mathoniere, jordan.de-gea,
Tom Russello
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> Actually, I'm not sure what the ideal behavior should be. Perhaps it's
> better to distinguish 1) and 2) above, and have two options
> --reply-to-email=<file> doing 1), and --quote doing 2), implying
> --compose and requiring --reply-to-email.
I tend to agree that sounds like a better way to structure these
features.
I wonder if we can safely repurpose existing --in-reply-to option?
That is, if the value of --in-reply-to can be reliably determined as
a filename that has the message (as opposed to a message-id), we
read the "Message-Id:" from that file to figuire out what message-id
to use, and figure out To/Cc: to use for the purpose of your (1) at
the same time. In the future, you might even teach send-email,
perhaps via a user configurable hook, a way to get to the message
header and text given a message-id, and when it happens, the same
logic can be used when --in-reply-to is given a message-id (i.e. you
go from the id to the message and find the addresses you would
To/Cc: your message).
> In any case, quoting the message without replying to it does not make
> sense (especially if you add instructions to trim it: the user would not
> even see it). So it its current form, I'd say --quote-email should imply
> --annotate.
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [RFC-PATCH 1/2] send-email: new option to quote an email and reply to
2016-05-25 15:40 ` Junio C Hamano
@ 2016-05-25 16:56 ` Matthieu Moy
2016-05-25 18:15 ` Junio C Hamano
0 siblings, 1 reply; 256+ messages in thread
From: Matthieu Moy @ 2016-05-25 16:56 UTC (permalink / raw)
To: Junio C Hamano
Cc: Samuel GROOT, Tom Russello, git, erwan.mathoniere, jordan.de-gea,
Tom Russello
Junio C Hamano <gitster@pobox.com> writes:
> I wonder if we can safely repurpose existing --in-reply-to option?
In theory, obviously no as there can be a file with this name _and_ it
can be a valid message-id. In practice, it is clearly unlikely. The only
use-case I can think of where both would be valid is if the user happens
to have saved the message using the message-id as filename. But then,
the ambiguity would not harm, as the message-id contained in the file
would be the same as the filename.
> That is, if the value of --in-reply-to can be reliably determined as
> a filename that has the message (as opposed to a message-id), we
> read the "Message-Id:" from that file to figuire out what message-id
> to use, and figure out To/Cc: to use for the purpose of your (1) at
> the same time.
This should work, but sounds like too much of overloading of
--in-reply-to IMHO: if given a message id, it would only add a reference
to this message-id, but if given a file, it would also modify the To:
and Cc: list.
Not a strong objection, though.
> In the future, you might even teach send-email, perhaps via a user
> configurable hook, a way to get to the message header and text given a
> message-id, and when it happens, the same logic can be used when
> --in-reply-to is given a message-id (i.e. you go from the id to the
> message and find the addresses you would To/Cc: your message).
That is the plan indeed. Fetching from gmane for example should be
rather easy in perl, and would be really convenient!
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [RFC-PATCH 1/2] send-email: new option to quote an email and reply to
2016-05-25 16:56 ` Matthieu Moy
@ 2016-05-25 18:15 ` Junio C Hamano
2016-05-25 18:31 ` Matthieu Moy
0 siblings, 1 reply; 256+ messages in thread
From: Junio C Hamano @ 2016-05-25 18:15 UTC (permalink / raw)
To: Matthieu Moy
Cc: Samuel GROOT, Tom Russello, git, erwan.mathoniere, jordan.de-gea,
Tom Russello
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> This should work, but sounds like too much of overloading of
> --in-reply-to IMHO: if given a message id, it would only add a reference
> to this message-id, but if given a file, it would also modify the To:
> and Cc: list.
>
> Not a strong objection, though.
Well, with your "that is the plan indeed", the option would behave
the same whether given a message ID or a filename, no?
But I do agree that those who have accustomed to the behaviour of
--in-reply-to that does not mess with To/Cc:, such a behaviour
change is not desirable.
If we are adding a new --reply-to-email=<file|id>, it should behave
as a superset of --in-reply-to (i.e. it should set In-Reply-to:
using the message ID of the e-mail we are replying to), though.
>> In the future, you might even teach send-email, perhaps via a user
>> configurable hook, a way to get to the message header and text given a
>> message-id, and when it happens, the same logic can be used when
>> --in-reply-to is given a message-id (i.e. you go from the id to the
>> message and find the addresses you would To/Cc: your message).
>
> That is the plan indeed. Fetching from gmane for example should be
> rather easy in perl, and would be really convenient!
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [RFC-PATCH 1/2] send-email: new option to quote an email and reply to
2016-05-25 18:15 ` Junio C Hamano
@ 2016-05-25 18:31 ` Matthieu Moy
2016-05-26 0:08 ` Samuel GROOT
0 siblings, 1 reply; 256+ messages in thread
From: Matthieu Moy @ 2016-05-25 18:31 UTC (permalink / raw)
To: Junio C Hamano
Cc: Samuel GROOT, Tom Russello, git, erwan.mathoniere, jordan.de-gea,
Tom Russello
Junio C Hamano <gitster@pobox.com> writes:
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
>> This should work, but sounds like too much of overloading of
>> --in-reply-to IMHO: if given a message id, it would only add a reference
>> to this message-id, but if given a file, it would also modify the To:
>> and Cc: list.
>>
>> Not a strong objection, though.
>
> Well, with your "that is the plan indeed", the option would behave
> the same whether given a message ID or a filename, no?
The "fetch message from ID" feature should not be unconditional IMHO. So
it would probably be stg like:
git send-email --in-reply-to=<id> --fetch
What's a bit counter-intuitive is that --fetch would not only trigger
fetching the complete message, but also populate To/Cc. But thinking
about it, it's not _that_ counter-intuitive, as fetching the message
should be done for a reason, so the user can guess that the message is
going to be used for something.
So, a possible UI would be:
git send-email --in-reply-to=<id> => just set In-Reply-To: field.
git send-email --in-reply-to=<file> => set In-Reply-To, To and Cc.
git send-email --in-reply-to=<file> --cite => in addition, add the
body of the message quoted with '> '.
git send-email --in-reply-to=<id> --fetch => fetch and do like <file>
using the default configuration for fetch.
This leaves room for:
git send-email --in-reply-to=<id> --fetch=gmane => fetch from gmane
(details on how to fetch would be in the config file)
This UI wouldn't allow using a file to get only the message-id. But I'm
not sure this is an interesting use-case.
So, I guess you convinced me.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [RFC-PATCH 1/2] send-email: new option to quote an email and reply to
2016-05-25 18:31 ` Matthieu Moy
@ 2016-05-26 0:08 ` Samuel GROOT
2016-05-27 9:06 ` Matthieu Moy
0 siblings, 1 reply; 256+ messages in thread
From: Samuel GROOT @ 2016-05-26 0:08 UTC (permalink / raw)
To: Matthieu Moy, Junio C Hamano
Cc: Tom Russello, git, erwan.mathoniere, jordan.de-gea, Tom Russello
On 05/25/2016 08:31 PM, Matthieu Moy wrote:
> So, a possible UI would be:
>
> git send-email --in-reply-to=<id> => just set In-Reply-To: field.
>
> git send-email --in-reply-to=<file> => set In-Reply-To, To and Cc.
>
> git send-email --in-reply-to=<file> --cite => in addition, add the
> body of the message quoted with '> '.
>
> git send-email --in-reply-to=<id> --fetch => fetch and do like <file>
> using the default configuration for fetch.
We designed a similar UI, except for the --fetch option:
We wanted to try to fetch the email from a distant server (e.g. gmane)
if that server address was set in the config file, and populate the
To:/Cc: fields.
If the file cannot be downloaded, or server address not set, just fill
the Reply-to header.
Either way, display what was done with the message-id given (unless
--quiet is set, of course).
> This leaves room for:
>
> git send-email --in-reply-to=<id> --fetch=gmane => fetch from gmane
> (details on how to fetch would be in the config file)
>
> This UI wouldn't allow using a file to get only the message-id. But I'm
> not sure this is an interesting use-case.
IMHO when you reply to a thread with a patch, it seems
counter-productive to reply without notifying (putting in To:/Cc:) the
original author and people involved in the thread.
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [RFC-PATCH 1/2] send-email: new option to quote an email and reply to
2016-05-26 0:08 ` Samuel GROOT
@ 2016-05-27 9:06 ` Matthieu Moy
0 siblings, 0 replies; 256+ messages in thread
From: Matthieu Moy @ 2016-05-27 9:06 UTC (permalink / raw)
To: Samuel GROOT
Cc: Junio C Hamano, Tom Russello, git, erwan.mathoniere,
jordan.de-gea, Tom Russello
Samuel GROOT <samuel.groot@grenoble-inp.org> writes:
> On 05/25/2016 08:31 PM, Matthieu Moy wrote:
>> So, a possible UI would be:
>>
>> git send-email --in-reply-to=<id> => just set In-Reply-To: field.
>>
>> git send-email --in-reply-to=<file> => set In-Reply-To, To and Cc.
>>
>> git send-email --in-reply-to=<file> --cite => in addition, add the
>> body of the message quoted with '> '.
>>
>> git send-email --in-reply-to=<id> --fetch => fetch and do like <file>
>> using the default configuration for fetch.
>
> We designed a similar UI, except for the --fetch option:
>
> We wanted to try to fetch the email from a distant server (e.g. gmane)
> if that server address was set in the config file, and populate the
> To:/Cc: fields.
>
> If the file cannot be downloaded, or server address not set, just fill
> the Reply-to header.
I'm not sure this is right. I'd typically configure gmane in my
user-wide config file, so I'd have it configured all the time, but I may
not always want to fetch from it (e.g. replying to a message which is
not on a mailing-list, or if gmane is down, or ...).
Fetching by default would clearly work in most cases, but for the few
remaning cases it may be painful for the user if the only way to disable
fetching is to remove the configuration from the config file.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply [flat|nested] 256+ messages in thread
* [RFC-PATCH 2/2] t9001: adding --quote-mail option test
2016-05-23 19:30 [RFC-PATCH 0/2] send-email: new --quote-mail option Tom Russello
2016-05-23 19:30 ` [RFC-PATCH 1/2] send-email: new option to quote an email and reply to Tom Russello
@ 2016-05-23 19:30 ` Tom Russello
2016-05-23 20:05 ` Matthieu Moy
2016-05-23 19:38 ` [RFC-PATCH 0/2] send-email: new --quote-mail option Matthieu Moy
2016-05-27 17:11 ` [RFC-PATCH v2 0/2] send-email: new --quote-email option Tom Russello
3 siblings, 1 reply; 256+ messages in thread
From: Tom Russello @ 2016-05-23 19:30 UTC (permalink / raw)
To: git
Cc: samuel.groot, matthieu.moy, erwan.mathoniere, jordan.de-gea,
Tom Russello, Tom Russello
From: Tom Russello <tom.russello@ensimag.grenoble-inp.fr>
Tests if the "To", "Cc" and "Subject" fields are adequately filled and if the
message is correctly quoted.
Signed-off-by: Tom Russello <tom.russello@grenoble-inp.org>
Signed-off-by: Samuel Groot <samuel.groot@grenoble-inp.org>
Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
---
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index b3355d2..bda4018 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -1885,4 +1885,47 @@ test_expect_success $PREREQ 'leading and trailing whitespaces are removed' '
test_cmp expected-list actual-list
'
+test_expect_success $PREREQ 'setup expect' '
+ cat >email <<-\EOF
+ Message-Id: <author_123456@example.com>
+ From: author@example.com
+ To: to1@example.com
+ Cc: cc1@example.com
+ Date: Sat, 12 Jun 2010 15:53:58 +0200
+ Subject: subject goes here
+
+ Have you seen my previous email?
+ > Previous content
+ EOF
+'
+
+test_expect_success $PREREQ 'From, To, Cc, Subject with --quote-mail are correct' '
+ clean_fake_sendmail &&
+ git send-email \
+ --quote-mail=email \
+ --from="Example <nobody@example.com>" \
+ --smtp-server="$(pwd)/fake.sendmail" \
+ -1 \
+ 2>errors &&
+ grep "From: Example <nobody@example.com>" msgtxt1 &&
+ to_adr=$(awk "/^To: /,/^Cc: /" msgtxt1) &&
+ echo "$to_adr" | grep author@example.com &&
+ echo "$to_adr" | grep to1@example.com &&
+ grep "Cc: cc1@example.com" msgtxt1
+'
+test_expect_success $PREREQ 'the message given is quoted with --quote-mail' '
+ grep "> Have you seen my previous email?" msgtxt1 &&
+ grep ">> Previous content" msgtxt1
+'
+test_expect_success $PREREQ 'Check if Re is written, only once with --quote-mail' '
+ grep "Subject: Re: subject goes here" msgtxt1 &&
+ git send-email \
+ --quote-mail=msgtxt1 \
+ --from="Example <nobody@example.com>" \
+ --smtp-server="$(pwd)/fake.sendmail" \
+ -1 \
+ 2>errors &&
+ grep "Subject: Re: subject goes here" msgtxt3
+'
+
test_done
--
2.8.2
^ permalink raw reply related [flat|nested] 256+ messages in thread
* Re: [RFC-PATCH 2/2] t9001: adding --quote-mail option test
2016-05-23 19:30 ` [RFC-PATCH 2/2] t9001: adding --quote-mail option test Tom Russello
@ 2016-05-23 20:05 ` Matthieu Moy
0 siblings, 0 replies; 256+ messages in thread
From: Matthieu Moy @ 2016-05-23 20:05 UTC (permalink / raw)
To: Tom Russello
Cc: git, samuel.groot, erwan.mathoniere, jordan.de-gea, Tom Russello
> Subject: [RFC-PATCH 2/2] t9001: adding --quote-mail option test
We write messages at imperative tone, hence s/adding/add/
Tom Russello <tom.russello@grenoble-inp.org> writes:
> From: Tom Russello <tom.russello@ensimag.grenoble-inp.fr>
Please use the same identity for email and commit to avoid this line.
> ---
>
>
> diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
No diffstat again?
Splitting a patch series as "code first; tests after" is not a good idea
IMHO. When questionning the behavior of To: Vs Cc: in the previous
patch, I would have appreciated having tests in the same message, to
check that the tested behavior was indeed the one I was reading in the
code.
OTOH, having one patch to introduce "--quote-email populates To: and Cc:
headers", and then another one for "--quote-email quotes the message
body" would make the review much easier.
Oh, BTW, this obviously lacks documentation
(Documentation/git-send-email.txt).
And that's one reason why the diffstat is useful: one can reply "this
lacks tests and doc" before even reviewing the patch.
Regards,
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [RFC-PATCH 0/2] send-email: new --quote-mail option
2016-05-23 19:30 [RFC-PATCH 0/2] send-email: new --quote-mail option Tom Russello
2016-05-23 19:30 ` [RFC-PATCH 1/2] send-email: new option to quote an email and reply to Tom Russello
2016-05-23 19:30 ` [RFC-PATCH 2/2] t9001: adding --quote-mail option test Tom Russello
@ 2016-05-23 19:38 ` Matthieu Moy
2016-05-23 19:56 ` Samuel GROOT
2016-05-27 17:11 ` [RFC-PATCH v2 0/2] send-email: new --quote-email option Tom Russello
3 siblings, 1 reply; 256+ messages in thread
From: Matthieu Moy @ 2016-05-23 19:38 UTC (permalink / raw)
To: Tom Russello; +Cc: git, samuel.groot, erwan.mathoniere, jordan.de-gea
Tom Russello <tom.russello@grenoble-inp.org> writes:
> 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=<file>`, to
I think the option name should be --quote-email. Even though "mail"
usually means "email" for French people, there's still non-electronic
mail for english-speaking ones.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [RFC-PATCH 0/2] send-email: new --quote-mail option
2016-05-23 19:38 ` [RFC-PATCH 0/2] send-email: new --quote-mail option Matthieu Moy
@ 2016-05-23 19:56 ` Samuel GROOT
0 siblings, 0 replies; 256+ messages in thread
From: Samuel GROOT @ 2016-05-23 19:56 UTC (permalink / raw)
To: Matthieu Moy, Tom Russello; +Cc: git, erwan.mathoniere, jordan.de-gea
On 05/23/2016 09:38 PM, Matthieu Moy wrote:
> Tom Russello <tom.russello@grenoble-inp.org> writes:
>
>> 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=<file>`, to
>
> I think the option name should be --quote-email. Even though "mail"
> usually means "email" for French people, there's still non-electronic
> mail for english-speaking ones.
That makes sense, all occurrences of "mail" will be changed into "email"
for v2.
Thanks for your feedback !
^ permalink raw reply [flat|nested] 256+ messages in thread
* [RFC-PATCH v2 0/2] send-email: new --quote-email option
2016-05-23 19:30 [RFC-PATCH 0/2] send-email: new --quote-mail option Tom Russello
` (2 preceding siblings ...)
2016-05-23 19:38 ` [RFC-PATCH 0/2] send-email: new --quote-mail option Matthieu Moy
@ 2016-05-27 17:11 ` Tom Russello
2016-05-27 17:11 ` [RFC-PATCH v2 1/2] send-email: quote-email populates the fields Tom Russello
` (2 more replies)
3 siblings, 3 replies; 256+ messages in thread
From: Tom Russello @ 2016-05-27 17:11 UTC (permalink / raw)
To: git
Cc: jordan.de-gea, erwan.mathoniere, matthieu.moy, samuel.groot, e,
aaron, gitster
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=<file>` which does two things:
- set fields appropriately (To, Cc, Subject, In-Reply-To)
- quote the given message
In this second patch, the new option `--quote-email=<file>` needs an
email file and does not manage non ascii characters.
There is still work in progress, including:
1. An option `--quote-email-id=<message-id>` to download the message
from any source, e.g. http://mid.gmane.org/<message-id>/raw.
The server's address could be set in the repo's config file.
2. There's also a discussion about whether this option should be
integrated in the current `--in-reply-to` option or not
* http://news.gmane.org/find-root.php?message_id=vpqh9dmfy5k.fsf@anie.imag.fr
3. The code to parse the email headers is currently duplicated
several times, we are refactoring it to help maintaining the
code.
4. Manage non ascii characters
Documentation/git-send-email.txt | 8 +++++++
git-send-email.perl | 160 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---
t/t9001-send-email.sh | 67 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 232 insertions(+), 3 deletions(-)
^ permalink raw reply [flat|nested] 256+ messages in thread
* [RFC-PATCH v2 1/2] send-email: quote-email populates the fields
2016-05-27 17:11 ` [RFC-PATCH v2 0/2] send-email: new --quote-email option Tom Russello
@ 2016-05-27 17:11 ` Tom Russello
2016-05-28 14:35 ` Matthieu Moy
2016-05-27 17:11 ` [RFC-PATCH v2 2/2] send-email: quote-email quotes the message body Tom Russello
2016-06-07 14:01 ` [PATCH v3 0/6] send-email: cleaner tests and quote email Tom Russello
2 siblings, 1 reply; 256+ messages in thread
From: Tom Russello @ 2016-05-27 17:11 UTC (permalink / raw)
To: git
Cc: jordan.de-gea, erwan.mathoniere, matthieu.moy, samuel.groot, e,
aaron, gitster, Tom Russello
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: [<email_file>'s subject]".
Signed-off-by: Tom Russello <tom.russello@grenoble-inp.org>
Signed-off-by: Samuel Groot <samuel.groot@grenoble-inp.org>
Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
---
As it is said in the cover letter, the file git-send-email.perl is being
refactored therefore the parsing section with nested if's is ought to
change.
changes since v1:
- option's name changed and is now --quote-email
- original From: becomes To:, original To:'s become Cc: and original
Cc:'s stay Cc:
- coding style improved
- documentation for the option
- more tests
Documentation/git-send-email.txt | 5 +++
git-send-email.perl | 87 +++++++++++++++++++++++++++++++++++++++-
t/t9001-send-email.sh | 61 ++++++++++++++++++++++++++++
3 files changed, 152 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 771a7b5..2334d69 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -106,6 +106,11 @@ illustration below where `[PATCH v2 0/3]` is in reply to `[PATCH 0/2]`:
Only necessary if --compose is also set. If --compose
is not set, this will be prompted for.
+--quote-email=<email_file>::
+ Reply to the given email and automatically populate the "To:", "Cc:" and
+ "In-Reply-To:" fields. If `--compose` is set, this will also fill the
+ subject field with "Re: [<email_file>'s subject]".
+
--subject=<string>::
Specify the initial subject of the email thread.
Only necessary if --compose is also set. If --compose
diff --git a/git-send-email.perl b/git-send-email.perl
index 6958785..9df3dee 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -55,6 +55,8 @@ git send-email --dump-aliases
--[no-]bcc <str> * Email Bcc:
--subject <str> * Email "Subject:"
--in-reply-to <str> * Email "In-Reply-To:"
+ --quote-email <file> * Fill the fields "To:", "Cc:", "Subject:",
+ "In-Reply-To" appropriately.
--[no-]xmailer * Add "X-Mailer:" header (default).
--[no-]annotate * Review each patch that will be sent in an editor.
--compose * Open an editor for introduction.
@@ -160,7 +162,7 @@ my $re_encoded_word = qr/=\?($re_token)\?($re_token)\?($re_encoded_text)\?=/;
# Variables we fill in automatically, or via prompting:
my (@to,$no_to,@initial_to,@cc,$no_cc,@initial_cc,@bcclist,$no_bcc,@xh,
- $initial_reply_to,$initial_subject,@files,
+ $initial_reply_to,$quote_email,$initial_subject,@files,
$author,$sender,$smtp_authpass,$annotate,$use_xmailer,$compose,$time);
my $envelope_sender;
@@ -304,6 +306,7 @@ $rc = GetOptions(
"sender|from=s" => \$sender,
"in-reply-to=s" => \$initial_reply_to,
"subject=s" => \$initial_subject,
+ "quote-email=s" => \$quote_email,
"to=s" => \@initial_to,
"to-cmd=s" => \$to_cmd,
"no-to" => \$no_to,
@@ -639,6 +642,88 @@ if (@files) {
usage();
}
+if ($quote_email) {
+ my $error = validate_patch($quote_email);
+ $error and die "fatal: $quote_email: $error\nwarning: no patches were sent\n";
+
+ my @header = ();
+
+ open my $fh, "<", $quote_email or die "can't open file $quote_email";
+
+ # Get the email header
+ while (<$fh>) {
+ # For files containing crlf line endings
+ s/\r//g;
+ last if /^\s*$/;
+ if (/^\s+\S/ and @header) {
+ chomp($header[$#header]);
+ s/^\s+/ /;
+ $header[$#header] .= $_;
+ } else {
+ push(@header, $_);
+ }
+ }
+
+ # Parse the header
+ foreach (@header) {
+ my $input_format;
+ my $initial_sender = $sender || $repoauthor || $repocommitter || '';
+
+ if (/^From /) {
+ $input_format = 'mbox';
+ next;
+ }
+ chomp;
+ if (!defined $input_format && /^[-A-Za-z]+:\s/) {
+ $input_format = 'mbox';
+ }
+
+ if (defined $input_format && $input_format eq 'mbox') {
+ if (/^Subject:\s+(.*)$/i) {
+ my $prefix_re = "";
+ my $subject_re = $1;
+ if ($1 =~ /^[^Re:]/) {
+ $prefix_re = "Re: ";
+ }
+ $initial_subject = $prefix_re . $subject_re;
+ } elsif (/^From:\s+(.*)$/i) {
+ push @initial_to, $1;
+ } elsif (/^To:\s+(.*)$/i) {
+ foreach my $addr (parse_address_line($1)) {
+ if (!($addr eq $initial_sender)) {
+ push @initial_cc, $addr;
+ }
+ }
+ } elsif (/^Cc:\s+(.*)$/i) {
+ foreach my $addr (parse_address_line($1)) {
+ my $qaddr = unquote_rfc2047($addr);
+ my $saddr = sanitize_address($qaddr);
+ if ($saddr eq $initial_sender) {
+ next if ($suppress_cc{'self'});
+ } else {
+ next if ($suppress_cc{'cc'});
+ }
+ push @initial_cc, $addr;
+ }
+ } elsif (/^Message-Id: (.*)/i) {
+ $initial_reply_to = $1;
+ }
+ } else {
+ # In the traditional
+ # "send lots of email" format,
+ # line 1 = cc
+ # line 2 = subject
+ # So let's support that, too.
+ $input_format = 'lots';
+ if (@cc == 0 && !$suppress_cc{'cc'}) {
+ push @cc, $_;
+ } elsif (!defined $initial_subject) {
+ $initial_subject = $_;
+ }
+ }
+ }
+}
+
sub get_patch_subject {
my $fn = shift;
open (my $fh, '<', $fn);
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index b3355d2..389a54c 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -1885,4 +1885,65 @@ test_expect_success $PREREQ 'leading and trailing whitespaces are removed' '
test_cmp expected-list actual-list
'
+test_expect_success $PREREQ 'setup expect' '
+ cat >email <<-\EOF
+ Message-Id: <author_123456@example.com>
+ From: author@example.com
+ To: to1@example.com
+ Cc: cc1@example.com
+ Date: Sat, 12 Jun 2010 15:53:58 +0200
+ Subject: subject goes here
+
+ Have you seen my previous email?
+ > Previous content
+ EOF
+'
+
+test_expect_success $PREREQ 'Fields with --quote-email are correct' '
+ clean_fake_sendmail &&
+ git send-email \
+ --quote-email=email \
+ --from="Example <nobody@example.com>" \
+ --smtp-server="$(pwd)/fake.sendmail" \
+ -1 \
+ 2>errors &&
+ grep "From: Example <nobody@example.com>" msgtxt1 &&
+ grep "In-Reply-To: <author_123456@example.com>" msgtxt1 &&
+ to_adr=$(awk "/^To: /,/^Cc: /" msgtxt1) &&
+ cc_adr=$(awk "/^Cc: /,/^Date /" msgtxt1) &&
+ echo "$to_adr" | grep author@example.com &&
+ echo "$cc_adr" | grep to1@example.com &&
+ echo "$cc_adr" | grep cc1@example.com
+'
+
+test_expect_success $PREREQ 'Fields with --quote-email and --compose are correct' '
+ clean_fake_sendmail &&
+ git send-email \
+ --quote-email=email \
+ --compose \
+ --from="Example <nobody@example.com>" \
+ --smtp-server="$(pwd)/fake.sendmail" \
+ -1 \
+ 2>errors &&
+ grep "From: Example <nobody@example.com>" msgtxt1 &&
+ grep "In-Reply-To: <author_123456@example.com>" msgtxt1 &&
+ grep "Subject: Re: subject goes here" msgtxt1 &&
+ to_adr=$(awk "/^To: /,/^Cc: /" msgtxt1) &&
+ cc_adr=$(awk "/^Cc: /,/^Date /" msgtxt1) &&
+ echo "$to_adr" | grep author@example.com &&
+ echo "$cc_adr" | grep to1@example.com &&
+ echo "$cc_adr" | grep cc1@example.com
+'
+
+test_expect_success $PREREQ 'Re: written only once with --quote-email and --compose ' '
+ git send-email \
+ --quote-email=msgtxt1 \
+ --compose \
+ --from="Example <nobody@example.com>" \
+ --smtp-server="$(pwd)/fake.sendmail" \
+ -1 \
+ 2>errors &&
+ grep "Subject: Re: subject goes here" msgtxt3
+'
+
test_done
--
2.8.2
^ permalink raw reply related [flat|nested] 256+ messages in thread
* Re: [RFC-PATCH v2 1/2] send-email: quote-email populates the fields
2016-05-27 17:11 ` [RFC-PATCH v2 1/2] send-email: quote-email populates the fields Tom Russello
@ 2016-05-28 14:35 ` Matthieu Moy
2016-05-29 23:38 ` Tom Russello
0 siblings, 1 reply; 256+ messages in thread
From: Matthieu Moy @ 2016-05-28 14:35 UTC (permalink / raw)
To: Tom Russello
Cc: git, jordan.de-gea, erwan.mathoniere, samuel.groot, e, aaron, gitster
Tom Russello <tom.russello@grenoble-inp.org> writes:
> --- a/Documentation/git-send-email.txt
> +++ b/Documentation/git-send-email.txt
> @@ -106,6 +106,11 @@ illustration below where `[PATCH v2 0/3]` is in reply to `[PATCH 0/2]`:
> Only necessary if --compose is also set. If --compose
> is not set, this will be prompted for.
>
> +--quote-email=<email_file>::
> + 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-To:" to understand
this. See what the doc of --in-reply-to says. If you want to be
technical, you'd need to mention the References: field too.
Talking about Reference: field, something your patch could do is to add
all references in <email_file> to the references of the new email (see
what a mailer is doing when replying). This way, the recipient can still
get threading if the last message being replied-to is missing.
> +"Re: [<email_file>'s subject]".
Perhaps `Re: ...` instead of double-quotes.
> +if ($quote_email) {
> + my $error = validate_patch($quote_email);
> + $error and die "fatal: $quote_email: $error\nwarning: no patches were sent\n";
I know it's done this way elsewhere, but I don't like this "$error and
die", I'd rather see a proper if here.
> + if (defined $input_format && $input_format eq 'mbox') {
To me, the input format refers to patch files, not the <email_file>.
I'm not sure anyone still use the "lots of email" format, and you are
not testing it. So, this is claiming that we have a feature without
being sure we have it nor that anyone's ever going to use it.
I'd just drop this "if" and the "else" branch, and just assume the email
file is a normal email file.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [RFC-PATCH v2 1/2] send-email: quote-email populates the fields
2016-05-28 14:35 ` Matthieu Moy
@ 2016-05-29 23:38 ` Tom Russello
0 siblings, 0 replies; 256+ messages in thread
From: Tom Russello @ 2016-05-29 23:38 UTC (permalink / raw)
To: Matthieu Moy
Cc: git, jordan.de-gea, erwan.mathoniere, samuel.groot, e, aaron, gitster
On 05/28/16 16:35, Matthieu Moy wrote:
>> +--quote-email=<email_file>::
>> + 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-To:" to understand
> this. See what the doc of --in-reply-to says. If you want to be
> technical, you'd need to mention the References: field too.
You have a point here. Maybe, we can explain that the `--quote-email`
option behaves like a mailer when replying to someone without getting
into details.
> Talking about Reference: field, something your patch could do is to add
> all references in <email_file> to the references of the new email (see
> what a mailer is doing when replying). This way, the recipient can still
> get threading if the last message being replied-to is missing.
I didn't know about this field, it looks like it appends all the
parent message ID's.
>> +"Re: [<email_file>'s subject]".
>
> Perhaps `Re: ...` instead of double-quotes.
Agreed.
>> +if ($quote_email) {
>> + my $error = validate_patch($quote_email);
>> + $error and die "fatal: $quote_email: $error\nwarning: no patches
were sent\n";
>
> I know it's done this way elsewhere, but I don't like this "$error and
> die", I'd rather see a proper if here.
You're right, I'll change that in the next version.
>> + if (defined $input_format && $input_format eq 'mbox') {
>
> To me, the input format refers to patch files, not the <email_file>.
>
> I'm not sure anyone still use the "lots of email" format, and you are
> not testing it. So, this is claiming that we have a feature without
> being sure we have it nor that anyone's ever going to use it.
You summed up the situation well.
> I'd just drop this "if" and the "else" branch, and just assume the email
> file is a normal email file.
I'll do that.
Thank you for the review.
^ permalink raw reply [flat|nested] 256+ messages in thread
* [RFC-PATCH v2 2/2] send-email: quote-email quotes the message body
2016-05-27 17:11 ` [RFC-PATCH v2 0/2] send-email: new --quote-email option Tom Russello
2016-05-27 17:11 ` [RFC-PATCH v2 1/2] send-email: quote-email populates the fields Tom Russello
@ 2016-05-27 17:11 ` Tom Russello
2016-05-28 15:01 ` Matthieu Moy
2016-06-07 14:01 ` [PATCH v3 0/6] send-email: cleaner tests and quote email Tom Russello
2 siblings, 1 reply; 256+ messages in thread
From: Tom Russello @ 2016-05-27 17:11 UTC (permalink / raw)
To: git
Cc: jordan.de-gea, erwan.mathoniere, matthieu.moy, samuel.groot, e,
aaron, gitster, Tom Russello
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 <tom.russello@grenoble-inp.org>
Signed-off-by: Samuel Groot <samuel.groot@grenoble-inp.org>
Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
---
Currently, `send-email` without `--compose` implies `--annotate`. The
current behavior of `--annotate` is that changes made during edition are saved
in patch files.
Keeping that behavior when using `--quote-email` populates the patch file with
the quoted message body, and the patch is saved no matter what. If the user
closes his editor and then exits `send-email`, changes will be saved.
Should we keep the current behavior for the user, keeping the changes (including
the quoted message body) in the patch, or should we discard them?
changes since v1:
- default behaviour of the option: it is now --annotate as one may not want
to send a cover letter for a single patch
- "On [date], [original author] wrote:" is added before the quoted message
- request to trim useless parts of the cited message when `--compose` is set
- extra blank removed when the message quoted is empty
Documentation/git-send-email.txt | 5 ++-
git-send-email.perl | 79 +++++++++++++++++++++++++++++++++++++---
t/t9001-send-email.sh | 6 +++
3 files changed, 84 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 2334d69..68bbb6c 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -109,7 +109,10 @@ is not set, this will be prompted for.
--quote-email=<email_file>::
Reply to the given email and automatically populate the "To:", "Cc:" and
"In-Reply-To:" fields. If `--compose` is set, this will also fill the
- subject field with "Re: [<email_file>'s subject]".
+ subject field with "Re: [<email_file>'s subject]" and quote the message body
+ of <email_file>. If `--compose` is not set, this will imply `--annotate`
+ option and will quote the message body of <email_file> after the triple-dash
+ in the first patch.
--subject=<string>::
Specify the initial subject of the email thread.
diff --git a/git-send-email.perl b/git-send-email.perl
index 9df3dee..e73aa25 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -26,6 +26,7 @@ use Text::ParseWords;
use Term::ANSIColor;
use File::Temp qw/ tempdir tempfile /;
use File::Spec::Functions qw(catfile);
+use File::Copy;
use Error qw(:try);
use Git;
@@ -55,8 +56,8 @@ git send-email --dump-aliases
--[no-]bcc <str> * Email Bcc:
--subject <str> * Email "Subject:"
--in-reply-to <str> * Email "In-Reply-To:"
- --quote-email <file> * Fill the fields "To:", "Cc:", "Subject:",
- "In-Reply-To" appropriately.
+ --quote-email <file> * Fill To:, Cc:, Subject:, In-Reply-To:
+ appropriately and quote the message body.
--[no-]xmailer * Add "X-Mailer:" header (default).
--[no-]annotate * Review each patch that will be sent in an editor.
--compose * Open an editor for introduction.
@@ -642,11 +643,14 @@ if (@files) {
usage();
}
+my $message_quoted;
if ($quote_email) {
my $error = validate_patch($quote_email);
$error and die "fatal: $quote_email: $error\nwarning: no patches were sent\n";
my @header = ();
+ my $date;
+ my $recipient;
open my $fh, "<", $quote_email or die "can't open file $quote_email";
@@ -687,7 +691,8 @@ if ($quote_email) {
}
$initial_subject = $prefix_re . $subject_re;
} elsif (/^From:\s+(.*)$/i) {
- push @initial_to, $1;
+ $recipient = $1;
+ push @initial_to, $recipient;
} elsif (/^To:\s+(.*)$/i) {
foreach my $addr (parse_address_line($1)) {
if (!($addr eq $initial_sender)) {
@@ -707,6 +712,8 @@ if ($quote_email) {
}
} elsif (/^Message-Id: (.*)/i) {
$initial_reply_to = $1;
+ } elsif (/^Date: (.*)/i) {
+ $date = $1;
}
} else {
# In the traditional
@@ -722,6 +729,23 @@ if ($quote_email) {
}
}
}
+
+ my $tpl_date = $date && "On $date, " || '';
+ $message_quoted = $tpl_date . $recipient . " wrote:\n";
+
+ # Quote the message body
+ while (<$fh>) {
+ # Only for files containing crlf line endings
+ s/\r//g;
+ my $space = "";
+ if (/^[^>]/) {
+ $space = " ";
+ }
+ $message_quoted .= ">" . $space . $_;
+ }
+ if (!$compose) {
+ $annotate = 1;
+ }
}
sub get_patch_subject {
@@ -749,6 +773,9 @@ if ($compose) {
my $tpl_sender = $sender || $repoauthor || $repocommitter || '';
my $tpl_subject = $initial_subject || '';
my $tpl_reply_to = $initial_reply_to || '';
+ my $tpl_quote = $message_quoted &&
+ "\nGIT: Please, trim down irrelevant sections in the quoted message\n".
+ "GIT: to keep your email concise\n" . $message_quoted || '';
print $c <<EOT;
From $tpl_sender # This line is ignored.
@@ -760,7 +787,7 @@ GIT: Clear the body content if you don't wish to send a summary.
From: $tpl_sender
Subject: $tpl_subject
In-Reply-To: $tpl_reply_to
-
+$tpl_quote
EOT
for my $f (@files) {
print $c get_patch_subject($f);
@@ -825,9 +852,51 @@ EOT
$compose = -1;
}
} elsif ($annotate) {
- do_edit(@files);
+ if ($quote_email) {
+ my $quote_email_filename = ($repo ?
+ tempfile(".gitsendemail.msg.XXXXXX",
+ DIR => $repo->repo_path()) :
+ tempfile(".gitsendemail.msg.XXXXXX",
+ DIR => "."))[1];
+
+ do_insert_quoted_message($quote_email_filename, $files[0]);
+
+ my $tmp = $files[0];
+ $files[0] = $quote_email_filename;
+
+ do_edit(@files);
+
+ # Erase the original patch
+ move($quote_email_filename, $tmp);
+ $files[0] = $tmp;
+ } else {
+ do_edit(@files);
+ }
}
+sub do_insert_quoted_message {
+ my $tmp_file = shift;
+ my $original_file = shift;
+
+ open my $c, "<", $original_file
+ or die "Failed to open $original_file : " . $!;
+
+ open my $c2, ">", $tmp_file
+ or die "Failed to open $tmp_file : " . $!;
+
+ # Insertion after the triple-dash
+ while (<$c>) {
+ print $c2 $_;
+ last if (/^---$/);
+ }
+ print $c2 $message_quoted;
+ while (<$c>) {
+ print $c2 $_;
+ }
+
+ close $c;
+ close $c2;
+}
sub ask {
my ($prompt, %arg) = @_;
my $valid_re = $arg{valid_re};
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 389a54c..5ab7533 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -1916,6 +1916,12 @@ test_expect_success $PREREQ 'Fields with --quote-email are correct' '
echo "$cc_adr" | grep cc1@example.com
'
+test_expect_success $PREREQ 'correct quoted message with --quote-email' '
+ grep "On Sat, 12 Jun 2010 15:53:58 +0200, author@example.com wrote:" msgtxt1 &&
+ grep "> Have you seen my previous email?" msgtxt1 &&
+ grep ">> Previous content" msgtxt1
+'
+
test_expect_success $PREREQ 'Fields with --quote-email and --compose are correct' '
clean_fake_sendmail &&
git send-email \
--
2.8.2
^ permalink raw reply related [flat|nested] 256+ messages in thread
* Re: [RFC-PATCH v2 2/2] send-email: quote-email quotes the message body
2016-05-27 17:11 ` [RFC-PATCH v2 2/2] send-email: quote-email quotes the message body Tom Russello
@ 2016-05-28 15:01 ` Matthieu Moy
2016-05-29 11:41 ` Tom Russello
0 siblings, 1 reply; 256+ messages in thread
From: Matthieu Moy @ 2016-05-28 15:01 UTC (permalink / raw)
To: Tom Russello
Cc: git, jordan.de-gea, erwan.mathoniere, samuel.groot, e, aaron, gitster
Tom Russello <tom.russello@grenoble-inp.org> writes:
> 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 --annotate will also open it for the
patch.
> Keeping that behavior when using `--quote-email` populates the patch file with
> the quoted message body, and the patch is saved no matter what. If the user
> closes his editor and then exits `send-email`, changes will be saved.
>
> Should we keep the current behavior for the user, keeping the changes (including
> the quoted message body) in the patch, or should we discard them?
(Note: we discussed this off-list already, but I'll try to summarize my
thoughts here)
I don't have strong opinion on this, but I think there's a difference
between launching the editor directly on the input patch files
(resulting in _user_'s edit being done directly on them) and having the
script modify it in-place (resulting in automatic changes done directly
on the user's files).
I usually use "git send-email" directly without using "git
format-patch", so I'm not the best juge. But I can imagine a flow like
1) run "git send-email *.patch"
2) start editting
3) notice there's something wrong, give up for now (answer 'q' when git
send-email prompts for confirmation, or kill it via Control-C in a
terminal)
4) run "git send-email *.patch" again
5) be happy that changes done at 2) are still there.
With --quote-email, it's different. The scenario above would result in
5') WTF, why is the email quoted twice?
Unfortunately, I don't really have a solution for this. My first thought
was that we should copy the files to a temporary location before
starting the editor (that what I'm used to when using "git send-email"
without "git format-patch"), but that would prevent 5) above.
> @@ -109,7 +109,10 @@ is not set, this will be prompted for.
> --quote-email=<email_file>::
> Reply to the given email and automatically populate the "To:", "Cc:" and
> "In-Reply-To:" fields. If `--compose` is set, this will also fill the
> - subject field with "Re: [<email_file>'s subject]".
> + subject field with "Re: [<email_file>'s subject]" and quote the message body
> + of <email_file>.
I'd add "in the introductory message".
> + while (<$fh>) {
> + # Only for files containing crlf line endings
> + s/\r//g;
The comment doesn't really say what it does.
What about "turn crlf line endings into lf-only"?
> } elsif ($annotate) {
> - do_edit(@files);
> + if ($quote_email) {
> + my $quote_email_filename = ($repo ?
> + tempfile(".gitsendemail.msg.XXXXXX",
> + DIR => $repo->repo_path()) :
> + tempfile(".gitsendemail.msg.XXXXXX",
> + DIR => "."))[1];
> +
> + do_insert_quoted_message($quote_email_filename, $files[0]);
> +
> + my $tmp = $files[0];
> + $files[0] = $quote_email_filename;
> +
> + do_edit(@files);
> +
> + # Erase the original patch
> + move($quote_email_filename, $tmp);
> + $files[0] = $tmp;
When writing comment, always try to ask the question "why?" more than
"what?". This part is possibly controversial, think about a contributor
finding this piece of code later without having followed the current
conversation. He'd probably expect an explanation about why you need a
temp file here and not elsewhere.
> + open my $c, "<", $original_file
> + or die "Failed to open $original_file : " . $!;
> +
> + open my $c2, ">", $tmp_file
> + or die "Failed to open $tmp_file : " . $!;
No space before :.
> --- a/t/t9001-send-email.sh
> +++ b/t/t9001-send-email.sh
> @@ -1916,6 +1916,12 @@ test_expect_success $PREREQ 'Fields with --quote-email are correct' '
> echo "$cc_adr" | grep cc1@example.com
> '
>
> +test_expect_success $PREREQ 'correct quoted message with --quote-email' '
> + grep "On Sat, 12 Jun 2010 15:53:58 +0200, author@example.com wrote:" msgtxt1 &&
> + grep "> Have you seen my previous email?" msgtxt1 &&
> + grep ">> Previous content" msgtxt1
> +'
When the spec says "if --compose ... then ...", "after the triple-dash",
and "in the first patch", one would expect at least one test with
--compose and one without, something to check that the insertion was
done below the triple-dash, and one test with two patches, checking that
the second patch is not altered by --quote-email.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [RFC-PATCH v2 2/2] send-email: quote-email quotes the message body
2016-05-28 15:01 ` Matthieu Moy
@ 2016-05-29 11:41 ` Tom Russello
0 siblings, 0 replies; 256+ messages in thread
From: Tom Russello @ 2016-05-29 11:41 UTC (permalink / raw)
To: Matthieu Moy
Cc: git, jordan.de-gea, erwan.mathoniere, samuel.groot, e, aaron, gitster
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 --annotate will also open it for the
> patch.
We meant that the default behavior of `--quote-email` (i.e. without
--compose enabled) will open the editor with the given patches in
argument and will quote the message body in the first one.
> (Note: we discussed this off-list already, but I'll try to summarize my
> thoughts here)
>
> I don't have strong opinion on this, but I think there's a difference
> between launching the editor directly on the input patch files
> (resulting in _user_'s edit being done directly on them) and having the
> script modify it in-place (resulting in automatic changes done directly
> on the user's files).
>
> I usually use "git send-email" directly without using "git
> format-patch", so I'm not the best juge. But I can imagine a flow like
>
> 1) run "git send-email *.patch"
>
> 2) start editting
>
> 3) notice there's something wrong, give up for now (answer 'q' when git
> send-email prompts for confirmation, or kill it via Control-C in a
> terminal)
>
> 4) run "git send-email *.patch" again
>
> 5) be happy that changes done at 2) are still there.
>
> With --quote-email, it's different. The scenario above would result in
>
> 5') WTF, why is the email quoted twice?
Actually the Control-C during the edition will cancel all the
annotations written (including the cited email).
> Unfortunately, I don't really have a solution for this. My first thought
> was that we should copy the files to a temporary location before
> starting the editor (that what I'm used to when using "git send-email"
> without "git format-patch"), but that would prevent 5) above.
It's already what we did: the first original patch is copied in a
temporary file. However, if the edition went well (i.e. the editor
closed by the user), the temporary file will erase the original one.
>> @@ -109,7 +109,10 @@ is not set, this will be prompted for.
>> --quote-email=<email_file>::
>> Reply to the given email and automatically populate the "To:",
"Cc:" and
>> "In-Reply-To:" fields. If `--compose` is set, this will also fill the
>> - subject field with "Re: [<email_file>'s subject]".
>> + subject field with "Re: [<email_file>'s subject]" and quote the
message body
>> + of <email_file>.
>
> I'd add "in the introductory message".
Agreed.
>> + while (<$fh>) {
>> + # Only for files containing crlf line endings
>> + s/\r//g;
>
> The comment doesn't really say what it does.
>
> What about "turn crlf line endings into lf-only"?
Yes, I completely agree this suggestion.
> When writing comment, always try to ask the question "why?" more than
> "what?". This part is possibly controversial, think about a contributor
> finding this piece of code later without having followed the current
> conversation. He'd probably expect an explanation about why you need a
> temp file here and not elsewhere.
Thank you for the advice, I'll keep it in mind.
>> + open my $c, "<", $original_file
>> + or die "Failed to open $original_file : " . $!;
>> +
>> + open my $c2, ">", $tmp_file
>> + or die "Failed to open $tmp_file : " . $!;
>
> No space before :.
Sorry, I copied the previous error messages.
> When the spec says "if --compose ... then ...", "after the triple-dash",
> and "in the first patch", one would expect at least one test with
> --compose and one without, something to check that the insertion was
> done below the triple-dash, and one test with two patches, checking that
> the second patch is not altered by --quote-email.
Yes, indeed. I'll add these tests in the next version.
Thank you for the review.
^ permalink raw reply [flat|nested] 256+ messages in thread
* [PATCH v3 0/6] send-email: cleaner tests and quote email
2016-05-27 17:11 ` [RFC-PATCH v2 0/2] send-email: new --quote-email option Tom Russello
2016-05-27 17:11 ` [RFC-PATCH v2 1/2] send-email: quote-email populates the fields Tom Russello
2016-05-27 17:11 ` [RFC-PATCH v2 2/2] send-email: quote-email quotes the message body Tom Russello
@ 2016-06-07 14:01 ` Tom Russello
2016-06-07 14:01 ` [PATCH v3 1/6] t9001: non order-sensitive file comparison Tom Russello
` (4 more replies)
2 siblings, 5 replies; 256+ messages in thread
From: Tom Russello @ 2016-06-07 14:01 UTC (permalink / raw)
To: git
Cc: erwan.mathoniere, samuel.groot, jordan.de-gea, matthieu.moy, e,
aaron, gitster
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 patch introduces our email parser subroutine.
* Fifth patch makes the `--in-reply-to` open a email file (if it
exists) and populates From:, To:, Cc:, In-reply-to and
References: fields.
* Sixth patch quotes the message body in the cover letter if
`--compose` is set. Else, imply `--annotate` and insert quoted
message body below triple-dash in the first patch.
General changes since v2:
- Modify tests to be less dependent on `git send-email`'s exact
output.
- New email parser subroutine.
- `--quote-email` option is now merged with `--in-reply-to`.
- Add `--cite` option to quote the message body.
- `git send-email` is less verbose.
Documentation/git-send-email.txt | 17 +++++--
git-send-email.perl | 178 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++------
t/t9001-send-email.sh | 238 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++----------------------
3 files changed, 356 insertions(+), 77 deletions(-)
^ permalink raw reply [flat|nested] 256+ messages in thread
* [PATCH v3 1/6] t9001: non order-sensitive file comparison
2016-06-07 14:01 ` [PATCH v3 0/6] send-email: cleaner tests and quote email Tom Russello
@ 2016-06-07 14:01 ` Tom Russello
2016-06-08 1:07 ` Junio C Hamano
2016-06-07 14:01 ` [PATCH v3 2/6] t9001: check email address is in Cc: field Tom Russello
` (3 subsequent siblings)
4 siblings, 1 reply; 256+ messages in thread
From: Tom Russello @ 2016-06-07 14:01 UTC (permalink / raw)
To: git
Cc: erwan.mathoniere, samuel.groot, jordan.de-gea, matthieu.moy, e,
aaron, gitster, Tom RUSSELLO
Tests might fail if lines compared in text files don't have the same order.
Signed-off-by: Samuel GROOT <samuel.groot@grenoble-inp.org>
Signed-off-by: Tom RUSSELLO <tom.russello@grenoble-inp.org>
Signed-off-by: Matthieu MOY <matthieu.moy@grenoble-inp.fr>
---
t/t9001-send-email.sh | 61 ++++++++++++++++++++++++++++-----------------------
1 file changed, 34 insertions(+), 27 deletions(-)
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index b3355d2..4558e0f 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -54,6 +54,13 @@ test_no_confirm () {
>no_confirm_okay
}
+# Check if two files have the same content, non-order sensitive
+test_cmp_noorder () {
+ sort $1 >$1;
+ sort $2 >$2;
+ return $(test_cmp $1 $2)
+}
+
# Exit immediately to prevent hang if a no-confirm test fails
check_no_confirm () {
if ! test -f no_confirm_okay
@@ -97,7 +104,7 @@ test_expect_success $PREREQ 'setup expect' '
'
test_expect_success $PREREQ 'Verify commandline' '
- test_cmp expected commandline1
+ test_cmp_noorder expected commandline1
'
test_expect_success $PREREQ 'Send patches with --envelope-sender' '
@@ -117,7 +124,7 @@ test_expect_success $PREREQ 'setup expect' '
'
test_expect_success $PREREQ 'Verify commandline' '
- test_cmp expected commandline1
+ test_cmp_noorder expected commandline1
'
test_expect_success $PREREQ 'Send patches with --envelope-sender=auto' '
@@ -137,7 +144,7 @@ test_expect_success $PREREQ 'setup expect' '
'
test_expect_success $PREREQ 'Verify commandline' '
- test_cmp expected commandline1
+ test_cmp_noorder expected commandline1
'
test_expect_success $PREREQ 'setup expect' "
@@ -196,7 +203,7 @@ test_suppress_self () {
>"expected-no-cc-$3" &&
(grep '^Cc:' msghdr1-$3 >"actual-no-cc-$3";
- test_cmp expected-no-cc-$3 actual-no-cc-$3)
+ test_cmp_noorder expected-no-cc-$3 actual-no-cc-$3)
}
test_suppress_self_unquoted () {
@@ -269,7 +276,7 @@ test_expect_success $PREREQ 'Show all headers' '
-e "s/^\(Message-Id:\).*/\1 MESSAGE-ID-STRING/" \
-e "s/^\(X-Mailer:\).*/\1 X-MAILER-STRING/" \
>actual-show-all-headers &&
- test_cmp expected-show-all-headers actual-show-all-headers
+ test_cmp_noorder expected-show-all-headers actual-show-all-headers
'
test_expect_success $PREREQ 'Prompting works' '
@@ -436,13 +443,13 @@ test_expect_success $PREREQ 'In-Reply-To without --chain-reply-to' '
2>errors &&
# The first message is a reply to --in-reply-to
sed -n -e "s/^In-Reply-To: *\(.*\)/\1/p" msgtxt1 >actual &&
- test_cmp expect actual &&
+ test_cmp_noorder expect actual &&
# Second and subsequent messages are replies to the first one
sed -n -e "s/^Message-Id: *\(.*\)/\1/p" msgtxt1 >expect &&
sed -n -e "s/^In-Reply-To: *\(.*\)/\1/p" msgtxt2 >actual &&
- test_cmp expect actual &&
+ test_cmp_noorder expect actual &&
sed -n -e "s/^In-Reply-To: *\(.*\)/\1/p" msgtxt3 >actual &&
- test_cmp expect actual
+ test_cmp_noorder expect actual
'
test_expect_success $PREREQ 'In-Reply-To with --chain-reply-to' '
@@ -457,13 +464,13 @@ test_expect_success $PREREQ 'In-Reply-To with --chain-reply-to' '
$patches $patches $patches \
2>errors &&
sed -n -e "s/^In-Reply-To: *\(.*\)/\1/p" msgtxt1 >actual &&
- test_cmp expect actual &&
+ test_cmp_noorder expect actual &&
sed -n -e "s/^Message-Id: *\(.*\)/\1/p" msgtxt1 >expect &&
sed -n -e "s/^In-Reply-To: *\(.*\)/\1/p" msgtxt2 >actual &&
- test_cmp expect actual &&
+ test_cmp_noorder expect actual &&
sed -n -e "s/^Message-Id: *\(.*\)/\1/p" msgtxt2 >expect &&
sed -n -e "s/^In-Reply-To: *\(.*\)/\1/p" msgtxt3 >actual &&
- test_cmp expect actual
+ test_cmp_noorder expect actual
'
test_expect_success $PREREQ 'setup fake editor' '
@@ -537,7 +544,7 @@ test_suppression () {
--smtp-server relay.example.com \
$patches | replace_variable_fields \
>actual-suppress-$1${2+"-$2"} &&
- test_cmp expected-suppress-$1${2+"-$2"} actual-suppress-$1${2+"-$2"}
+ test_cmp_noorder expected-suppress-$1${2+"-$2"} actual-suppress-$1${2+"-$2"}
}
test_expect_success $PREREQ 'sendemail.cc set' '
@@ -1213,7 +1220,7 @@ test_expect_success $PREREQ 'ASCII subject is not RFC2047 quoted' '
--8bit-encoding=UTF-8 \
email-using-8bit >stdout &&
grep "Subject" msgtxt1 >actual &&
- test_cmp expected actual
+ test_cmp_noorder expected actual
'
test_expect_success $PREREQ 'setup expect' '
@@ -1234,7 +1241,7 @@ test_expect_success $PREREQ 'asks about and fixes 8bit encodings' '
grep email-using-8bit stdout &&
grep "Which 8bit encoding" stdout &&
egrep "Content|MIME" msgtxt1 >actual &&
- test_cmp actual content-type-decl
+ test_cmp_noorder actual content-type-decl
'
test_expect_success $PREREQ 'sendemail.8bitEncoding works' '
@@ -1245,7 +1252,7 @@ test_expect_success $PREREQ 'sendemail.8bitEncoding works' '
--smtp-server="$(pwd)/fake.sendmail" \
email-using-8bit >stdout &&
egrep "Content|MIME" msgtxt1 >actual &&
- test_cmp actual content-type-decl
+ test_cmp_noorder actual content-type-decl
'
test_expect_success $PREREQ '--8bit-encoding overrides sendemail.8bitEncoding' '
@@ -1257,7 +1264,7 @@ test_expect_success $PREREQ '--8bit-encoding overrides sendemail.8bitEncoding' '
--8bit-encoding=UTF-8 \
email-using-8bit >stdout &&
egrep "Content|MIME" msgtxt1 >actual &&
- test_cmp actual content-type-decl
+ test_cmp_noorder actual content-type-decl
'
test_expect_success $PREREQ 'setup expect' '
@@ -1286,7 +1293,7 @@ test_expect_success $PREREQ '--8bit-encoding also treats subject' '
--8bit-encoding=UTF-8 \
email-using-8bit >stdout &&
grep "Subject" msgtxt1 >actual &&
- test_cmp expected actual
+ test_cmp_noorder expected actual
'
test_expect_success $PREREQ 'setup expect' '
@@ -1335,7 +1342,7 @@ test_expect_success $PREREQ 'sendemail.transferencoding=8bit' '
2>errors >out &&
sed '1,/^$/d' msgtxt1 >actual &&
sed '1,/^$/d' email-using-8bit >expected &&
- test_cmp expected actual
+ test_cmp_noorder expected actual
'
test_expect_success $PREREQ 'setup expect' '
@@ -1352,7 +1359,7 @@ test_expect_success $PREREQ '8-bit and sendemail.transferencoding=quoted-printab
email-using-8bit \
2>errors >out &&
sed '1,/^$/d' msgtxt1 >actual &&
- test_cmp expected actual
+ test_cmp_noorder expected actual
'
test_expect_success $PREREQ 'setup expect' '
@@ -1369,7 +1376,7 @@ test_expect_success $PREREQ '8-bit and sendemail.transferencoding=base64' '
email-using-8bit \
2>errors >out &&
sed '1,/^$/d' msgtxt1 >actual &&
- test_cmp expected actual
+ test_cmp_noorder expected actual
'
test_expect_success $PREREQ 'setup expect' '
@@ -1395,7 +1402,7 @@ test_expect_success $PREREQ 'convert from quoted-printable to base64' '
email-using-qp \
2>errors >out &&
sed '1,/^$/d' msgtxt1 >actual &&
- test_cmp expected actual
+ test_cmp_noorder expected actual
'
test_expect_success $PREREQ 'setup expect' "
@@ -1425,7 +1432,7 @@ test_expect_success $PREREQ 'CRLF and sendemail.transferencoding=quoted-printabl
email-using-crlf \
2>errors >out &&
sed '1,/^$/d' msgtxt1 >actual &&
- test_cmp expected actual
+ test_cmp_noorder expected actual
'
test_expect_success $PREREQ 'setup expect' '
@@ -1442,7 +1449,7 @@ test_expect_success $PREREQ 'CRLF and sendemail.transferencoding=base64' '
email-using-crlf \
2>errors >out &&
sed '1,/^$/d' msgtxt1 >actual &&
- test_cmp expected actual
+ test_cmp_noorder expected actual
'
@@ -1582,7 +1589,7 @@ test_dump_aliases () {
"$(pwd)/.tmp-email-aliases" &&
git config sendemail.aliasfiletype "$filetype" &&
git send-email --dump-aliases 2>errors >actual &&
- test_cmp expect actual
+ test_cmp_noorder expect actual
'
}
@@ -1842,7 +1849,7 @@ test_expect_success $PREREQ 'use email list in --cc --to and --bcc' '
--bcc="bcc1@example.com, bcc2@example.com" \
0001-add-master.patch | replace_variable_fields \
>actual-list &&
- test_cmp expected-list actual-list
+ test_cmp_noorder expected-list actual-list
'
test_expect_success $PREREQ 'aliases work with email list' '
@@ -1858,7 +1865,7 @@ test_expect_success $PREREQ 'aliases work with email list' '
--bcc="bcc1@example.com, bcc2@example.com" \
0001-add-master.patch | replace_variable_fields \
>actual-list &&
- test_cmp expected-list actual-list
+ test_cmp_noorder expected-list actual-list
'
test_expect_success $PREREQ 'leading and trailing whitespaces are removed' '
@@ -1882,7 +1889,7 @@ test_expect_success $PREREQ 'leading and trailing whitespaces are removed' '
--bcc="bcc2@example.com" \
0001-add-master.patch | replace_variable_fields \
>actual-list &&
- test_cmp expected-list actual-list
+ test_cmp_noorder expected-list actual-list
'
test_done
--
2.8.3
^ permalink raw reply related [flat|nested] 256+ messages in thread
* Re: [PATCH v3 1/6] t9001: non order-sensitive file comparison
2016-06-07 14:01 ` [PATCH v3 1/6] t9001: non order-sensitive file comparison Tom Russello
@ 2016-06-08 1:07 ` Junio C Hamano
2016-06-08 8:23 ` Samuel GROOT
2016-06-09 5:51 ` Matthieu Moy
0 siblings, 2 replies; 256+ messages in thread
From: Junio C Hamano @ 2016-06-08 1:07 UTC (permalink / raw)
To: Tom Russello
Cc: git, erwan.mathoniere, samuel.groot, jordan.de-gea, matthieu.moy,
e, aaron
Tom Russello <tom.russello@grenoble-inp.org> writes:
> +# Check if two files have the same content, non-order sensitive
> +test_cmp_noorder () {
> + sort $1 >$1;
Here is what I think happens:
0) the shell parses this command line;
1) the shell notices that the output has to go to $1;
2) the shell does open(2) of $1,
3) the shell spawns "sort" with a single argument, with its
output connected to the file descriptor obtained in 2).
Because "$1" becomes an empty file at 2), "sort" reads nothing and
writes nothing.
> + sort $2 >$2;
> + return $(test_cmp $1 $2)
What is this return doing? I would understand if it were just
test_cmp $1 $2
Of course, all the places you use test_cmp_noorder are happy when
this function returns 0/success, and because $1 and $2 at this point
are both empty files and test_cmp will not say anything to its
standard output, the return will just yield 0/success to the caller
of the function, so it is likely that with this patch t9001 would
have passed for you, but that is not necessarily a good thing X-<.
> @@ -269,7 +276,7 @@ test_expect_success $PREREQ 'Show all headers' '
> -e "s/^\(Message-Id:\).*/\1 MESSAGE-ID-STRING/" \
> -e "s/^\(X-Mailer:\).*/\1 X-MAILER-STRING/" \
> >actual-show-all-headers &&
> - test_cmp expected-show-all-headers actual-show-all-headers
> + test_cmp_noorder expected-show-all-headers actual-show-all-headers
> '
It is dubious that it is a good idea to blindly sort two files and
compare, especially because expected-show-all-headers is actually
something like this:
cat >expected-show-all-headers <<\EOF
0001-Second.patch
(mbox) Adding cc: A <author@example.com> from line 'From: A <author@example.com>'
(mbox) Adding cc: One <one@example.com> from line 'Cc: One <one@example.com>, two@example.com'
(mbox) Adding cc: two@example.com from line 'Cc: One <one@example.com>, two@example.com'
Dry-OK. Log says:
Server: relay.example.com
MAIL FROM:<from@example.com>
RCPT TO:<to@example.com>
RCPT TO:<cc@example.com>
...
To: to@example.com
Cc: cc@example.com,
A <author@example.com>,
One <one@example.com>,
two@example.com
Subject: [PATCH 1/1] Second.
Date: DATE-STRING
Message-Id: MESSAGE-ID-STRING
X-Mailer: X-MAILER-STRING
In-Reply-To: <unique-message-id@example.com>
References: <unique-message-id@example.com>
Result: OK
EOF
We do want to see MAIL FROM: as the first thing we give to the
server, followed by RCPT TO:, followed by the headers.
I am having a hard time guessing what prompted you to sort the
output, i.e. what problem you were trying to solve. It cannot be
because addresses on a list (e.g. Cc:) could come out in an
indeterministic order, because the address that a test expects to be
the first (cc@example.com in the above example) may not appear as
the first one, but in the textual output it _is_ shown differently
from the remainder (i.e. even if you sort, from "Cc:
cc@example.com," it is clear it was the first one output for Cc: and
diferent from "A <author@example.com>".
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [PATCH v3 1/6] t9001: non order-sensitive file comparison
2016-06-08 1:07 ` Junio C Hamano
@ 2016-06-08 8:23 ` Samuel GROOT
2016-06-08 16:09 ` Junio C Hamano
2016-06-09 5:51 ` Matthieu Moy
1 sibling, 1 reply; 256+ messages in thread
From: Samuel GROOT @ 2016-06-08 8:23 UTC (permalink / raw)
To: Junio C Hamano, Tom Russello
Cc: git, erwan.mathoniere, jordan.de-gea, matthieu.moy, e, aaron
On 06/08/2016 03:07 AM, Junio C Hamano wrote:
> I am having a hard time guessing what prompted you to sort the
> output, i.e. what problem you were trying to solve. It cannot be
> because addresses on a list (e.g. Cc:) could come out in an
> indeterministic order, because the address that a test expects to be
> the first (cc@example.com in the above example) may not appear as
> the first one, but in the textual output it _is_ shown differently
> from the remainder (i.e. even if you sort, from "Cc:
> cc@example.com," it is clear it was the first one output for Cc: and
> diferent from "A <author@example.com>".
Actually we had issues when trying to refactor send-email's email
parsing loop [1]. Email addresses in output file `commandeline1` in
tests weren't sorted the same way as the reference file it was compared
to. E.g.:
!nobody@example.com!
!author@example.com!
!one@example.com!
!two@example.com!
I agree replacing test_cmp with test_cmp_noorder is pointless, I will
fix it and re-roll.
Thanks.
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [PATCH v3 1/6] t9001: non order-sensitive file comparison
2016-06-08 8:23 ` Samuel GROOT
@ 2016-06-08 16:09 ` Junio C Hamano
2016-06-08 16:46 ` Samuel GROOT
0 siblings, 1 reply; 256+ messages in thread
From: Junio C Hamano @ 2016-06-08 16:09 UTC (permalink / raw)
To: Samuel GROOT
Cc: Tom Russello, git, erwan.mathoniere, jordan.de-gea, matthieu.moy,
e, aaron
Samuel GROOT <samuel.groot@grenoble-inp.org> writes:
> Actually we had issues when trying to refactor send-email's email
> parsing loop [1]. Email addresses in output file `commandeline1` in
> tests weren't sorted the same way as the reference file it was
> compared to. E.g.:
>
> !nobody@example.com!
> !author@example.com!
> !one@example.com!
> !two@example.com!
And the reason why these addresses that are collected from the same
input (i.e. command line, existing e-mail fields, footers, etc.) are
shown in different order in your implementation is...?
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [PATCH v3 1/6] t9001: non order-sensitive file comparison
2016-06-08 16:09 ` Junio C Hamano
@ 2016-06-08 16:46 ` Samuel GROOT
2016-06-09 6:01 ` Matthieu Moy
0 siblings, 1 reply; 256+ messages in thread
From: Samuel GROOT @ 2016-06-08 16:46 UTC (permalink / raw)
To: Junio C Hamano
Cc: Tom Russello, git, erwan.mathoniere, jordan.de-gea, matthieu.moy,
e, aaron
On 06/08/2016 06:09 PM, Junio C Hamano wrote:
> Samuel GROOT <samuel.groot@grenoble-inp.org> writes:
>
>> Actually we had issues when trying to refactor send-email's email
>> parsing loop [1]. Email addresses in output file `commandeline1` in
>> tests weren't sorted the same way as the reference file it was
>> compared to. E.g.:
>>
>> !nobody@example.com!
>> !author@example.com!
>> !one@example.com!
>> !two@example.com!
>
> And the reason why these addresses that are collected from the same
> input (i.e. command line, existing e-mail fields, footers, etc.) are
> shown in different order in your implementation is...?
It's not shown in different order in our implementation, it's just a
leftover of my refactor attempt [1].
Maybe it's a bad idea to increase tests' complexity, but IMHO tests
should be independent to the addresses' order.
Plus, it would help refactor in the future, the data being processed
differently: parsing and processing in different subroutines rather than
doing everything in one gigantic loop.
We can drop it if necessary, but it may be useful to make
git-send-email.perl easier to maintain.
[1] * http://article.gmane.org/gmane.comp.version-control.git/295753
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [PATCH v3 1/6] t9001: non order-sensitive file comparison
2016-06-08 16:46 ` Samuel GROOT
@ 2016-06-09 6:01 ` Matthieu Moy
2016-06-13 22:21 ` Samuel GROOT
0 siblings, 1 reply; 256+ messages in thread
From: Matthieu Moy @ 2016-06-09 6:01 UTC (permalink / raw)
To: Samuel GROOT
Cc: Junio C Hamano, Tom Russello, git, erwan.mathoniere,
jordan.de-gea, e, aaron
Samuel GROOT <samuel.groot@grenoble-inp.org> writes:
> On 06/08/2016 06:09 PM, Junio C Hamano wrote:
>> Samuel GROOT <samuel.groot@grenoble-inp.org> writes:
>>
>>> Actually we had issues when trying to refactor send-email's email
>>> parsing loop [1]. Email addresses in output file `commandeline1` in
>>> tests weren't sorted the same way as the reference file it was
>>> compared to. E.g.:
>>>
>>> !nobody@example.com!
>>> !author@example.com!
>>> !one@example.com!
>>> !two@example.com!
>>
>> And the reason why these addresses that are collected from the same
>> input (i.e. command line, existing e-mail fields, footers, etc.) are
>> shown in different order in your implementation is...?
>
> It's not shown in different order in our implementation, it's just a
> leftover of my refactor attempt [1].
I think the refactoring makes sense, but having this patch as PATCH 1/6
in a series about --in-reply-to confuses reviewers: they would expect
this patch to be useful to the others in the series.
If you have "reply to a message in a file" ready without the
refactoring, and a mostly ready refactoring, then I think it makes sense
to have two patch series, the first being only "reply to a message in a
file". If the refactoring itself is not ready, you may send a separate
series "tests clean up" and explain on the cover-letter that it's, well,
only a test clean up.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [PATCH v3 1/6] t9001: non order-sensitive file comparison
2016-06-09 6:01 ` Matthieu Moy
@ 2016-06-13 22:21 ` Samuel GROOT
0 siblings, 0 replies; 256+ messages in thread
From: Samuel GROOT @ 2016-06-13 22:21 UTC (permalink / raw)
To: Matthieu Moy
Cc: Junio C Hamano, Tom Russello, git, erwan.mathoniere,
jordan.de-gea, e, aaron
On 06/09/2016 08:01 AM, Matthieu Moy wrote:
> Samuel GROOT <samuel.groot@grenoble-inp.org> writes:
>
>> On 06/08/2016 06:09 PM, Junio C Hamano wrote:
>>> Samuel GROOT <samuel.groot@grenoble-inp.org> writes:
>>>
>>>> Actually we had issues when trying to refactor send-email's email
>>>> parsing loop [1]. Email addresses in output file `commandeline1` in
>>>> tests weren't sorted the same way as the reference file it was
>>>> compared to. E.g.:
>>>>
>>>> !nobody@example.com!
>>>> !author@example.com!
>>>> !one@example.com!
>>>> !two@example.com!
>>>
>>> And the reason why these addresses that are collected from the same
>>> input (i.e. command line, existing e-mail fields, footers, etc.) are
>>> shown in different order in your implementation is...?
>>
>> It's not shown in different order in our implementation, it's just a
>> leftover of my refactor attempt [1].
>
> I think the refactoring makes sense, but having this patch as PATCH 1/6
> in a series about --in-reply-to confuses reviewers: they would expect
> this patch to be useful to the others in the series.
>
> If you have "reply to a message in a file" ready without the
> refactoring, and a mostly ready refactoring, then I think it makes sense
> to have two patch series, the first being only "reply to a message in a
> file". If the refactoring itself is not ready, you may send a separate
> series "tests clean up" and explain on the cover-letter that it's, well,
> only a test clean up.
I think I will split the patch series into 3 smaller series:
- "quote-email" feature
- tests clean up
- send-email code cleanup (including send-email's output)
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [PATCH v3 1/6] t9001: non order-sensitive file comparison
2016-06-08 1:07 ` Junio C Hamano
2016-06-08 8:23 ` Samuel GROOT
@ 2016-06-09 5:51 ` Matthieu Moy
2016-06-09 8:15 ` Tom Russello
1 sibling, 1 reply; 256+ messages in thread
From: Matthieu Moy @ 2016-06-09 5:51 UTC (permalink / raw)
To: Junio C Hamano
Cc: Tom Russello, git, erwan.mathoniere, samuel.groot, jordan.de-gea,
e, aaron
Junio C Hamano <gitster@pobox.com> writes:
> Tom Russello <tom.russello@grenoble-inp.org> writes:
>
>> +# Check if two files have the same content, non-order sensitive
>> +test_cmp_noorder () {
>> + sort $1 >$1;
>
> Here is what I think happens:
>
> 0) the shell parses this command line;
> 1) the shell notices that the output has to go to $1;
> 2) the shell does open(2) of $1,
> 3) the shell spawns "sort" with a single argument, with its
> output connected to the file descriptor obtained in 2).
>
> Because "$1" becomes an empty file at 2), "sort" reads nothing and
> writes nothing.
Tom: in case you're not convinced, try this:
$ (echo b; echo a) >f
$ sort f
a
b
$ sort f >f
$ cat f
$
Also, useless ';' and missing double-quotes around "$1" to avoid bad
surprises ifever test_cmp_noorder is called on file names with special
characters.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [PATCH v3 1/6] t9001: non order-sensitive file comparison
2016-06-09 5:51 ` Matthieu Moy
@ 2016-06-09 8:15 ` Tom Russello
0 siblings, 0 replies; 256+ messages in thread
From: Tom Russello @ 2016-06-09 8:15 UTC (permalink / raw)
To: Matthieu Moy, Junio C Hamano
Cc: git, erwan.mathoniere, samuel.groot, jordan.de-gea, e, aaron
On 06/09/16 07:51, Matthieu Moy wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Tom Russello <tom.russello@grenoble-inp.org> writes:
>>
>>> +# Check if two files have the same content, non-order sensitive
>>> +test_cmp_noorder () {
>>> + sort $1 >$1;
>>
>> Here is what I think happens:
>>
>> 0) the shell parses this command line;
>> 1) the shell notices that the output has to go to $1;
>> 2) the shell does open(2) of $1,
>> 3) the shell spawns "sort" with a single argument, with its
>> output connected to the file descriptor obtained in 2).
>>
>> Because "$1" becomes an empty file at 2), "sort" reads nothing and
>> writes nothing.
>
> Tom: in case you're not convinced, try this:
>
> $ (echo b; echo a) >f
> $ sort f
> a
> b
> $ sort f >f
> $ cat f
> $
>
> Also, useless ';' and missing double-quotes around "$1" to avoid bad
> surprises ifever test_cmp_noorder is called on file names with special
> characters.
I was totally convinced by Junio's explanation, it is partially fixed in
v4 and will be entirely fixed in v5.
Thanks.
^ permalink raw reply [flat|nested] 256+ messages in thread
* [PATCH v3 2/6] t9001: check email address is in Cc: field
2016-06-07 14:01 ` [PATCH v3 0/6] send-email: cleaner tests and quote email Tom Russello
2016-06-07 14:01 ` [PATCH v3 1/6] t9001: non order-sensitive file comparison Tom Russello
@ 2016-06-07 14:01 ` Tom Russello
2016-06-09 5:55 ` Matthieu Moy
2016-06-07 14:01 ` [PATCH v3 3/6] t9001: shorten send-email's output Tom Russello
` (2 subsequent siblings)
4 siblings, 1 reply; 256+ messages in thread
From: Tom Russello @ 2016-06-07 14:01 UTC (permalink / raw)
To: git
Cc: erwan.mathoniere, samuel.groot, jordan.de-gea, matthieu.moy, e,
aaron, gitster, Tom Russello, Tom RUSSELLO
Check if the given utf-8 email address is in the Cc: field.
Signed-off-by: Tom RUSSELLO <tom.ressullo@grenoble-inp.org>
Signed-off-by: Samuel GROOT <samuel.groot@grenoble-inp.org>
Signed-off-by: Matthieu MOY <matthieu.moy@grenoble-inp.fr>
---
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 4558e0f..7fdc876 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -888,8 +888,8 @@ test_expect_success $PREREQ 'utf8 Cc is rfc2047 encoded' '
--to=nobody@example.com \
--smtp-server="$(pwd)/fake.sendmail" \
outdir/*.patch &&
- grep "^ " msgtxt1 |
- grep "=?UTF-8?q?=C3=A0=C3=A9=C3=AC=C3=B6=C3=BA?= <utf8@example.com>"
+ cc_adr=$(awk "/^Cc: /{flag=1}/^Subject: /{flag=0} flag {print}" msgtxt1) &&
+ echo "$cc_adr" | grep "=?UTF-8?q?=C3=A0=C3=A9=C3=AC=C3=B6=C3=BA?= <utf8@example.com>"
'
test_expect_success $PREREQ '--compose adds MIME for utf8 body' '
--
2.8.3
^ permalink raw reply related [flat|nested] 256+ messages in thread
* Re: [PATCH v3 2/6] t9001: check email address is in Cc: field
2016-06-07 14:01 ` [PATCH v3 2/6] t9001: check email address is in Cc: field Tom Russello
@ 2016-06-09 5:55 ` Matthieu Moy
2016-06-13 22:23 ` Samuel GROOT
0 siblings, 1 reply; 256+ messages in thread
From: Matthieu Moy @ 2016-06-09 5:55 UTC (permalink / raw)
To: Tom Russello
Cc: git, erwan.mathoniere, samuel.groot, jordan.de-gea, e, aaron,
gitster, Tom RUSSELLO
Tom Russello <tom.russello@grenoble-inp.org> writes:
> Check if the given utf-8 email address is in the Cc: field.
I wouldn't harm to explain what was the problem with existing code here.
If I understand correctly, that would be:
Existing code just checked that the address appeared in a line starting
with a space, but not to which field the address belonged.
But probably the real motivation for this was that you want to introduce
code that changes the layout and breaks this "address appears on a line
starting with space"?
> --- a/t/t9001-send-email.sh
> +++ b/t/t9001-send-email.sh
> @@ -888,8 +888,8 @@ test_expect_success $PREREQ 'utf8 Cc is rfc2047 encoded' '
> --to=nobody@example.com \
> --smtp-server="$(pwd)/fake.sendmail" \
> outdir/*.patch &&
> - grep "^ " msgtxt1 |
> - grep "=?UTF-8?q?=C3=A0=C3=A9=C3=AC=C3=B6=C3=BA?= <utf8@example.com>"
> + cc_adr=$(awk "/^Cc: /{flag=1}/^Subject: /{flag=0} flag {print}" msgtxt1) &&
> + echo "$cc_adr" | grep "=?UTF-8?q?=C3=A0=C3=A9=C3=AC=C3=B6=C3=BA?= <utf8@example.com>"
> '
>
> test_expect_success $PREREQ '--compose adds MIME for utf8 body' '
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [PATCH v3 2/6] t9001: check email address is in Cc: field
2016-06-09 5:55 ` Matthieu Moy
@ 2016-06-13 22:23 ` Samuel GROOT
0 siblings, 0 replies; 256+ messages in thread
From: Samuel GROOT @ 2016-06-13 22:23 UTC (permalink / raw)
To: Matthieu Moy, Tom Russello
Cc: git, erwan.mathoniere, jordan.de-gea, e, aaron, gitster, Tom RUSSELLO
On 06/09/2016 07:55 AM, Matthieu Moy wrote:
> Tom Russello <tom.russello@grenoble-inp.org> writes:
>
>> Check if the given utf-8 email address is in the Cc: field.
>
> I wouldn't harm to explain what was the problem with existing code here.
> If I understand correctly, that would be:
>
> Existing code just checked that the address appeared in a line starting
> with a space, but not to which field the address belonged.
>
> But probably the real motivation for this was that you want to introduce
> code that changes the layout and breaks this "address appears on a line
> starting with space"?
Actually it was both, we wanted to make the tests less dependent to how
data was displayed.
^ permalink raw reply [flat|nested] 256+ messages in thread
* [PATCH v3 3/6] t9001: shorten send-email's output
2016-06-07 14:01 ` [PATCH v3 0/6] send-email: cleaner tests and quote email Tom Russello
2016-06-07 14:01 ` [PATCH v3 1/6] t9001: non order-sensitive file comparison Tom Russello
2016-06-07 14:01 ` [PATCH v3 2/6] t9001: check email address is in Cc: field Tom Russello
@ 2016-06-07 14:01 ` Tom Russello
2016-06-08 8:36 ` Eric Wong
2016-06-09 6:03 ` Matthieu Moy
2016-06-07 14:01 ` [PATCH v3 4/6] send-email: create email parser subroutine Tom Russello
2016-06-08 13:01 ` (unknown), Samuel GROOT
4 siblings, 2 replies; 256+ messages in thread
From: Tom Russello @ 2016-06-07 14:01 UTC (permalink / raw)
To: git
Cc: erwan.mathoniere, samuel.groot, jordan.de-gea, matthieu.moy, e,
aaron, gitster, Tom RUSSELLO
Messages displayed by `send-email` should be shortened to avoid displaying
unnecesseray informations.
Signed-off-by: Samuel GROOT <samuel.groot@grenoble-inp.org>
Signed-off-by: Tom RUSSELLO <tom.russello@grenoble-inp.org>
Signed-off-by: Matthieu MOY <matthieu.moy@grenoble-inp.fr>
---
git-send-email.perl | 22 +++++++++----------
t/t9001-send-email.sh | 58 +++++++++++++++++++++++++--------------------------
2 files changed, 40 insertions(+), 40 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 6958785..4822f41 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -1478,14 +1478,14 @@ foreach my $t (@files) {
$sauthor = sanitize_address($author);
next if $suppress_cc{'author'};
next if $suppress_cc{'self'} and $sauthor eq $sender;
- printf("(mbox) Adding cc: %s from line '%s'\n",
- $1, $_) unless $quiet;
+ printf("Adding cc: %s from From: header\n",
+ $1) unless $quiet;
push @cc, $1;
}
elsif (/^To:\s+(.*)$/i) {
foreach my $addr (parse_address_line($1)) {
- printf("(mbox) Adding to: %s from line '%s'\n",
- $addr, $_) unless $quiet;
+ printf("Adding to: %s from To: header\n",
+ $addr) unless $quiet;
push @to, $addr;
}
}
@@ -1498,8 +1498,8 @@ foreach my $t (@files) {
} else {
next if ($suppress_cc{'cc'});
}
- printf("(mbox) Adding cc: %s from line '%s'\n",
- $addr, $_) unless $quiet;
+ printf("Adding cc: %s from Cc: header\n",
+ $addr) unless $quiet;
push @cc, $addr;
}
}
@@ -1532,8 +1532,8 @@ foreach my $t (@files) {
# So let's support that, too.
$input_format = 'lots';
if (@cc == 0 && !$suppress_cc{'cc'}) {
- printf("(non-mbox) Adding cc: %s from line '%s'\n",
- $_, $_) unless $quiet;
+ printf("Adding cc: %s from Cc: header\n",
+ $_) unless $quiet;
push @cc, $_;
} elsif (!defined $subject) {
$subject = $_;
@@ -1555,8 +1555,8 @@ foreach my $t (@files) {
next if $suppress_cc{'bodycc'} and $what =~ /Cc/i;
}
push @cc, $c;
- printf("(body) Adding cc: %s from line '%s'\n",
- $c, $_) unless $quiet;
+ printf("Adding cc: %s from Signed-off-by trailer\n",
+ $c) unless $quiet;
}
}
close $fh;
@@ -1660,7 +1660,7 @@ sub recipients_cmd {
$address = sanitize_address($address);
next if ($address eq $sender and $suppress_cc{'self'});
push @addresses, $address;
- printf("($prefix) Adding %s: %s from: '%s'\n",
+ printf("Adding %s: %s from: '%s'\n",
$what, $address, $cmd) unless $quiet;
}
close $fh
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 7fdc876..9b1e56f 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -150,9 +150,9 @@ test_expect_success $PREREQ 'Verify commandline' '
test_expect_success $PREREQ 'setup expect' "
cat >expected-show-all-headers <<\EOF
0001-Second.patch
-(mbox) Adding cc: A <author@example.com> from line 'From: A <author@example.com>'
-(mbox) Adding cc: One <one@example.com> from line 'Cc: One <one@example.com>, two@example.com'
-(mbox) Adding cc: two@example.com from line 'Cc: One <one@example.com>, two@example.com'
+Adding cc: A <author@example.com> from From: header
+Adding cc: One <one@example.com> from Cc: header
+Adding cc: two@example.com from Cc: header
Dry-OK. Log says:
Server: relay.example.com
MAIL FROM:<from@example.com>
@@ -503,9 +503,9 @@ test_expect_success $PREREQ 'second message is patch' '
test_expect_success $PREREQ 'setup expect' "
cat >expected-suppress-sob <<\EOF
0001-Second.patch
-(mbox) Adding cc: A <author@example.com> from line 'From: A <author@example.com>'
-(mbox) Adding cc: One <one@example.com> from line 'Cc: One <one@example.com>, two@example.com'
-(mbox) Adding cc: two@example.com from line 'Cc: One <one@example.com>, two@example.com'
+Adding cc: A <author@example.com> from From: header
+Adding cc: One <one@example.com> from Cc: header
+Adding cc: two@example.com from Cc: header
Dry-OK. Log says:
Server: relay.example.com
MAIL FROM:<from@example.com>
@@ -555,9 +555,9 @@ test_expect_success $PREREQ 'sendemail.cc set' '
test_expect_success $PREREQ 'setup expect' "
cat >expected-suppress-sob <<\EOF
0001-Second.patch
-(mbox) Adding cc: A <author@example.com> from line 'From: A <author@example.com>'
-(mbox) Adding cc: One <one@example.com> from line 'Cc: One <one@example.com>, two@example.com'
-(mbox) Adding cc: two@example.com from line 'Cc: One <one@example.com>, two@example.com'
+Adding cc: A <author@example.com> from From: header
+Adding cc: One <one@example.com> from Cc: header
+Adding cc: two@example.com from Cc: header
Dry-OK. Log says:
Server: relay.example.com
MAIL FROM:<from@example.com>
@@ -587,10 +587,10 @@ test_expect_success $PREREQ 'sendemail.cc unset' '
test_expect_success $PREREQ 'setup expect' "
cat >expected-suppress-cccmd <<\EOF
0001-Second.patch
-(mbox) Adding cc: A <author@example.com> from line 'From: A <author@example.com>'
-(mbox) Adding cc: One <one@example.com> from line 'Cc: One <one@example.com>, two@example.com'
-(mbox) Adding cc: two@example.com from line 'Cc: One <one@example.com>, two@example.com'
-(body) Adding cc: C O Mitter <committer@example.com> from line 'Signed-off-by: C O Mitter <committer@example.com>'
+Adding cc: A <author@example.com> from From: header
+Adding cc: One <one@example.com> from Cc: header
+Adding cc: two@example.com from Cc: header
+Adding cc: C O Mitter <committer@example.com> from Signed-off-by: trailer
Dry-OK. Log says:
Server: relay.example.com
MAIL FROM:<from@example.com>
@@ -647,10 +647,10 @@ test_expect_success $PREREQ '--suppress-cc=all' '
test_expect_success $PREREQ 'setup expect' "
cat >expected-suppress-body <<\EOF
0001-Second.patch
-(mbox) Adding cc: A <author@example.com> from line 'From: A <author@example.com>'
-(mbox) Adding cc: One <one@example.com> from line 'Cc: One <one@example.com>, two@example.com'
-(mbox) Adding cc: two@example.com from line 'Cc: One <one@example.com>, two@example.com'
-(cc-cmd) Adding cc: cc-cmd@example.com from: './cccmd'
+Adding cc: A <author@example.com> from From: header
+Adding cc: One <one@example.com> from Cc: header
+Adding cc: two@example.com from Cc: header
+Adding cc: cc-cmd@example.com from: './cccmd'
Dry-OK. Log says:
Server: relay.example.com
MAIL FROM:<from@example.com>
@@ -681,9 +681,9 @@ test_expect_success $PREREQ '--suppress-cc=body' '
test_expect_success $PREREQ 'setup expect' "
cat >expected-suppress-body-cccmd <<\EOF
0001-Second.patch
-(mbox) Adding cc: A <author@example.com> from line 'From: A <author@example.com>'
-(mbox) Adding cc: One <one@example.com> from line 'Cc: One <one@example.com>, two@example.com'
-(mbox) Adding cc: two@example.com from line 'Cc: One <one@example.com>, two@example.com'
+Adding cc: A <author@example.com> from From: header
+Adding cc: One <one@example.com> from Cc: header
+Adding cc: two@example.com from Cc: header
Dry-OK. Log says:
Server: relay.example.com
MAIL FROM:<from@example.com>
@@ -712,9 +712,9 @@ test_expect_success $PREREQ '--suppress-cc=body --suppress-cc=cccmd' '
test_expect_success $PREREQ 'setup expect' "
cat >expected-suppress-sob <<\EOF
0001-Second.patch
-(mbox) Adding cc: A <author@example.com> from line 'From: A <author@example.com>'
-(mbox) Adding cc: One <one@example.com> from line 'Cc: One <one@example.com>, two@example.com'
-(mbox) Adding cc: two@example.com from line 'Cc: One <one@example.com>, two@example.com'
+Adding cc: A <author@example.com> from From: header
+Adding cc: One <one@example.com> from Cc: header
+Adding cc: two@example.com from Cc: header
Dry-OK. Log says:
Server: relay.example.com
MAIL FROM:<from@example.com>
@@ -744,10 +744,10 @@ test_expect_success $PREREQ '--suppress-cc=sob' '
test_expect_success $PREREQ 'setup expect' "
cat >expected-suppress-bodycc <<\EOF
0001-Second.patch
-(mbox) Adding cc: A <author@example.com> from line 'From: A <author@example.com>'
-(mbox) Adding cc: One <one@example.com> from line 'Cc: One <one@example.com>, two@example.com'
-(mbox) Adding cc: two@example.com from line 'Cc: One <one@example.com>, two@example.com'
-(body) Adding cc: C O Mitter <committer@example.com> from line 'Signed-off-by: C O Mitter <committer@example.com>'
+Adding cc: A <author@example.com> from From: header
+Adding cc: One <one@example.com> from Cc: header
+Adding cc: two@example.com from Cc: header
+Adding cc: C O Mitter <committer@example.com> from Signed-off-by: trailer
Dry-OK. Log says:
Server: relay.example.com
MAIL FROM:<from@example.com>
@@ -778,8 +778,8 @@ test_expect_success $PREREQ '--suppress-cc=bodycc' '
test_expect_success $PREREQ 'setup expect' "
cat >expected-suppress-cc <<\EOF
0001-Second.patch
-(mbox) Adding cc: A <author@example.com> from line 'From: A <author@example.com>'
-(body) Adding cc: C O Mitter <committer@example.com> from line 'Signed-off-by: C O Mitter <committer@example.com>'
+Adding cc: A <author@example.com> from From: header
+Adding cc: C O Mitter <committer@example.com> from Signed-off-by: trailer
Dry-OK. Log says:
Server: relay.example.com
MAIL FROM:<from@example.com>
--
2.8.3
^ permalink raw reply related [flat|nested] 256+ messages in thread
* Re: [PATCH v3 3/6] t9001: shorten send-email's output
2016-06-07 14:01 ` [PATCH v3 3/6] t9001: shorten send-email's output Tom Russello
@ 2016-06-08 8:36 ` Eric Wong
2016-06-08 9:30 ` Samuel GROOT
2016-06-09 6:03 ` Matthieu Moy
1 sibling, 1 reply; 256+ messages in thread
From: Eric Wong @ 2016-06-08 8:36 UTC (permalink / raw)
To: Tom Russello
Cc: git, erwan.mathoniere, samuel.groot, jordan.de-gea, matthieu.moy,
aaron, gitster
Tom Russello <tom.russello@grenoble-inp.org> wrote:
> Messages displayed by `send-email` should be shortened to avoid displaying
> unnecesseray informations.
unnecessary information.
In some of your other patches, the 'grep' can probably
be better replaced by 'fgrep' for fixed strings.
Otherwise, the '.' in the 'example.com' would match any
character instead of the intended dot.
Thanks.
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [PATCH v3 3/6] t9001: shorten send-email's output
2016-06-08 8:36 ` Eric Wong
@ 2016-06-08 9:30 ` Samuel GROOT
0 siblings, 0 replies; 256+ messages in thread
From: Samuel GROOT @ 2016-06-08 9:30 UTC (permalink / raw)
To: Eric Wong, Tom Russello
Cc: git, erwan.mathoniere, jordan.de-gea, matthieu.moy, aaron, gitster
On 06/08/2016 10:36 AM, Eric Wong wrote:
> Tom Russello <tom.russello@grenoble-inp.org> wrote:
>> Messages displayed by `send-email` should be shortened to avoid displaying
>> unnecesseray informations.
>
> unnecessary information.
>
> In some of your other patches, the 'grep' can probably
> be better replaced by 'fgrep' for fixed strings.
> Otherwise, the '.' in the 'example.com' would match any
> character instead of the intended dot.
Thanks, will re-roll
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [PATCH v3 3/6] t9001: shorten send-email's output
2016-06-07 14:01 ` [PATCH v3 3/6] t9001: shorten send-email's output Tom Russello
2016-06-08 8:36 ` Eric Wong
@ 2016-06-09 6:03 ` Matthieu Moy
1 sibling, 0 replies; 256+ messages in thread
From: Matthieu Moy @ 2016-06-09 6:03 UTC (permalink / raw)
To: Tom Russello
Cc: git, erwan.mathoniere, samuel.groot, jordan.de-gea, e, aaron, gitster
Tom Russello <tom.russello@grenoble-inp.org> writes:
> Messages displayed by `send-email` should be shortened to avoid displaying
> unnecesseray informations.
We usually use imperative tone in commit messages:
Shorten messages displayed by `send-email` to avoid displaying
unnecessary information.
Actually, I'd rather have a bit more explanation about why this info is
"unnecessary".
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply [flat|nested] 256+ messages in thread
* [PATCH v3 4/6] send-email: create email parser subroutine
2016-06-07 14:01 ` [PATCH v3 0/6] send-email: cleaner tests and quote email Tom Russello
` (2 preceding siblings ...)
2016-06-07 14:01 ` [PATCH v3 3/6] t9001: shorten send-email's output Tom Russello
@ 2016-06-07 14:01 ` Tom Russello
2016-06-07 14:05 ` [PATCH v3 5/6] send-email: --in-reply-to=<file> populates the fields Tom Russello
2016-06-08 13:01 ` (unknown), Samuel GROOT
4 siblings, 1 reply; 256+ messages in thread
From: Tom Russello @ 2016-06-07 14:01 UTC (permalink / raw)
To: git
Cc: erwan.mathoniere, samuel.groot, jordan.de-gea, matthieu.moy, e,
aaron, gitster, Tom RUSSELLO
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 <samuel.groot@grenoble-inp.org>
Signed-off-by: Tom RUSSELLO <tom.russello@grenoble-inp.org>
Signed-off-by: Matthieu MOY <matthieu.moy@grenoble-inp.fr>
---
We chose to create our own simple email parser and only use it for the
"quote email" feature to pave the way for the refactorization of the patch
parser [0] that may come after our current school project.
[0] * http://thread.gmane.org/gmane.comp.version-control.git/295752
git-send-email.perl | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/git-send-email.perl b/git-send-email.perl
index 4822f41..db114ae 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -1750,3 +1750,31 @@ sub body_or_subject_has_nonascii {
}
return 0;
}
+
+sub parse_email {
+ my %mail = ();
+ my $fh = shift;
+ my $last_header;
+
+ # Unfold and parse multiline header fields
+ while (<$fh>) {
+ last if /^\s*$/;
+ s/\r\n|\n|\r//;
+ if (/^([^\s:]+):[\s]+(.*)$/) {
+ $last_header = lc($1);
+ @{$mail{$last_header}} = ()
+ unless defined $mail{$last_header};
+ push @{$mail{$last_header}}, $2;
+ } elsif (/^\s+\S/ and defined $last_header) {
+ s/^\s+/ /;
+ push @{$mail{$last_header}}, $_;
+ } else {
+ die("Mail format undefined !\n");
+ }
+ }
+
+ # Separate body from header
+ $mail{"body"} = [(<$fh>)];
+
+ return \%mail;
+}
--
2.8.3
^ permalink raw reply related [flat|nested] 256+ messages in thread
* [PATCH v3 5/6] send-email: --in-reply-to=<file> populates the fields
2016-06-07 14:01 ` [PATCH v3 4/6] send-email: create email parser subroutine Tom Russello
@ 2016-06-07 14:05 ` Tom Russello
2016-06-07 14:05 ` [PATCH v3 6/6] send-email: add option --cite to quote the message body Tom Russello
0 siblings, 1 reply; 256+ messages in thread
From: Tom Russello @ 2016-06-07 14:05 UTC (permalink / raw)
To: git
Cc: erwan.mathoniere, samuel.groot, jordan.de-gea, matthieu.moy, e,
aaron, gitster, Tom Russello
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: [<email_file>'s subject]` in the introductory message.
Signed-off-by: Tom RUSSELLO <tom.russello@grenoble-inp.org>
Signed-off-by: Samuel GROOT <samuel.groot@grenoble-inp.org>
Signed-off-by: Matthieu MOY <matthieu.moy@grenoble-inp.fr>
---
Check if the string given by argument with `--in-reply-to` leads to
an existing plain text file. If not, consider it as a message-id.
Changes sinces v2:
- Fill the References: field to keep the thread even if some
emails have been removed
- Explicit error with a proper "if" when an error occured during
email file opening
- More precise comments
- More tests
Documentation/git-send-email.txt | 9 +++--
git-send-email.perl | 49 +++++++++++++++++++++++-
t/t9001-send-email.sh | 83 ++++++++++++++++++++++++++++++++++++++++
3 files changed, 136 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index edbba3a..21776f0 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -84,13 +84,16 @@ See the CONFIGURATION section for 'sendemail.multiEdit'.
the value of GIT_AUTHOR_IDENT, or GIT_COMMITTER_IDENT if that is not
set, as returned by "git var -l".
---in-reply-to=<identifier>::
+--in-reply-to=<Message-Id|email_file>::
Make the first mail (or all the mails with `--no-thread`) appear as a
- reply to the given Message-Id, which avoids breaking threads to
- provide a new patch series.
+ reply to the given Message-Id (given directly by argument or via the email
+ file), which avoids breaking threads to provide a new patch series.
The second and subsequent emails will be sent as replies according to
the `--[no]-chain-reply-to` setting.
+
+Furthermore, if the argument is an email file, parse it and populate header
+fields appropriately for the reply.
++
So for example when `--thread` and `--no-chain-reply-to` are specified, the
second and subsequent patches will be replies to the first one like in the
illustration below where `[PATCH v2 0/3]` is in reply to `[PATCH 0/2]`:
diff --git a/git-send-email.perl b/git-send-email.perl
index db114ae..66aa2cd 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -55,6 +55,7 @@ git send-email --dump-aliases
--[no-]bcc <str> * Email Bcc:
--subject <str> * Email "Subject:"
--in-reply-to <str> * Email "In-Reply-To:"
+ --in-reply-to <file> * Populate header fields appropriately.
--[no-]xmailer * Add "X-Mailer:" header (default).
--[no-]annotate * Review each patch that will be sent in an editor.
--compose * Open an editor for introduction.
@@ -160,7 +161,7 @@ my $re_encoded_word = qr/=\?($re_token)\?($re_token)\?($re_encoded_text)\?=/;
# Variables we fill in automatically, or via prompting:
my (@to,$no_to,@initial_to,@cc,$no_cc,@initial_cc,@bcclist,$no_bcc,@xh,
- $initial_reply_to,$initial_subject,@files,
+ $initial_reply_to,$initial_references,$initial_subject,@files,
$author,$sender,$smtp_authpass,$annotate,$use_xmailer,$compose,$time);
my $envelope_sender;
@@ -639,6 +640,50 @@ if (@files) {
usage();
}
+if ($initial_reply_to && -f $initial_reply_to) {
+ my $error = validate_patch($initial_reply_to);
+ die "fatal: $initial_reply_to: $error\nwarning: no patches were sent\n"
+ if $error;
+
+ open my $fh, "<", $initial_reply_to or die "can't open file $initial_reply_to";
+ my $mail = parse_email($fh);
+ close $fh;
+
+ my $initial_sender = $sender || $repoauthor || $repocommitter || '';
+
+ my $prefix_re = "";
+ my $subject_re = $mail->{"subject"}[0];
+ if ($subject_re =~ /^[^Re:]/) {
+ $prefix_re = "Re: ";
+ }
+ $initial_subject = $prefix_re . $subject_re;
+
+ push @initial_to, $mail->{"from"}[0];
+
+ foreach my $to_addr (parse_address_line(join ",", @{$mail->{"to"}})) {
+ if (!($to_addr eq $initial_sender)) {
+ push @initial_cc, $to_addr;
+ }
+ }
+
+ foreach my $cc_addr (parse_address_line(join ",", @{$mail->{"cc"}})) {
+ my $qaddr = unquote_rfc2047($cc_addr);
+ my $saddr = sanitize_address($qaddr);
+ if ($saddr eq $initial_sender) {
+ next if ($suppress_cc{'self'});
+ } else {
+ next if ($suppress_cc{'cc'});
+ }
+ push @initial_cc, $cc_addr;
+ }
+
+ $initial_reply_to = $mail->{"message-id"}[0];
+ if ($mail->{"references"}) {
+ $initial_references = join("", @{$mail->{"references"}}) .
+ " " . $initial_reply_to;
+ }
+}
+
sub get_patch_subject {
my $fn = shift;
open (my $fh, '<', $fn);
@@ -1426,7 +1471,7 @@ Message-Id: $message_id
}
$reply_to = $initial_reply_to;
-$references = $initial_reply_to || '';
+$references = $initial_references || $initial_reply_to || '';
$subject = $initial_subject;
$message_num = 0;
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 9b1e56f..2d67f6d 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -1892,4 +1892,87 @@ test_expect_success $PREREQ 'leading and trailing whitespaces are removed' '
test_cmp_noorder expected-list actual-list
'
+test_expect_success $PREREQ 'setup expect' '
+ cat >email <<-\EOF
+ Subject: subject goes here
+ From: author@example.com
+ To: to1@example.com
+ Cc: cc1@example.com, cc2@example.com,
+ cc3@example.com
+ Date: Sat, 12 Jun 2010 15:53:58 +0200
+ Message-Id: <author_123456@example.com>
+ References: <firstauthor_654321@example.com>
+ <secondauthor_01546567@example.com>
+ <thirdauthor_1395838@example.com>
+
+ Have you seen my previous email?
+ > Previous content
+ EOF
+'
+
+test_expect_success $PREREQ 'Fields with --in-reply-to are correct' '
+ clean_fake_sendmail &&
+ git send-email \
+ --in-reply-to=email \
+ --from="Example <nobody@example.com>" \
+ --smtp-server="$(pwd)/fake.sendmail" \
+ -2 \
+ 2>errors &&
+ grep "From: Example <nobody@example.com>" msgtxt1 &&
+ grep "In-Reply-To: <author_123456@example.com>" msgtxt1 &&
+ to_adr=$(awk "/^To: /{flag=1}/^Cc: /{flag=0} flag {print}" msgtxt1) &&
+ cc_adr=$(awk "/^Cc: /{flag=1}/^Subject: /{flag=0} flag {print}" msgtxt1) &&
+ ref_adr=$(awk "/^References: /{flag=1}/^MIME-Version: /{flag=0} flag {print}" \
+ msgtxt1) &&
+ echo "$to_adr" | grep author@example.com &&
+ echo "$cc_adr" | grep to1@example.com &&
+ echo "$cc_adr" | grep cc1@example.com &&
+ echo "$cc_adr" | grep cc2@example.com &&
+ echo "$cc_adr" | grep cc3@example.com &&
+ echo "$ref_adr" | grep "<firstauthor_654321@example.com>" &&
+ echo "$ref_adr" | grep "<secondauthor_01546567@example.com>" &&
+ echo "$ref_adr" | grep "<thirdauthor_1395838@example.com>" &&
+ echo "$ref_adr" | grep "<author_123456@example.com>" &&
+ echo "$ref_adr" | grep -v "References: <author_123456@example.com>"
+'
+
+test_expect_success $PREREQ 'Fields with --in-reply-to and --compose are correct' '
+ clean_fake_sendmail &&
+ git send-email \
+ --in-reply-to=email \
+ --compose \
+ --from="Example <nobody@example.com>" \
+ --smtp-server="$(pwd)/fake.sendmail" \
+ -1 \
+ 2>errors &&
+ grep "From: Example <nobody@example.com>" msgtxt1 &&
+ grep "In-Reply-To: <author_123456@example.com>" msgtxt1 &&
+ grep "Subject: Re: subject goes here" msgtxt1 &&
+ to_adr=$(awk "/^To: /{flag=1}/^Cc: /{flag=0} flag {print}" msgtxt1) &&
+ cc_adr=$(awk "/^Cc: /{flag=1}/^Subject: /{flag=0} flag {print}" msgtxt1) &&
+ ref_adr=$(awk "/^References: /{flag=1}/^MIME-Version: /{flag=0} flag {print}" \
+ msgtxt1) &&
+ echo "$to_adr" | grep author@example.com &&
+ echo "$cc_adr" | grep to1@example.com &&
+ echo "$cc_adr" | grep cc1@example.com &&
+ echo "$cc_adr" | grep cc2@example.com &&
+ echo "$cc_adr" | grep cc3@example.com &&
+ echo "$ref_adr" | grep "<firstauthor_654321@example.com>" &&
+ echo "$ref_adr" | grep "<secondauthor_01546567@example.com>" &&
+ echo "$ref_adr" | grep "<thirdauthor_1395838@example.com>" &&
+ echo "$ref_adr" | grep "<author_123456@example.com>" &&
+ echo "$ref_adr" | grep -v "References: <author_123456@example.com>"
+'
+
+test_expect_success $PREREQ 'Re: written only once with --in-reply-to and --compose ' '
+ git send-email \
+ --in-reply-to=msgtxt1 \
+ --compose \
+ --from="Example <nobody@example.com>" \
+ --smtp-server="$(pwd)/fake.sendmail" \
+ -1 \
+ 2>errors &&
+ grep "Subject: Re: subject goes here" msgtxt3
+'
+
test_done
--
2.8.3
^ permalink raw reply related [flat|nested] 256+ messages in thread
* [PATCH v3 6/6] send-email: add option --cite to quote the message body
2016-06-07 14:05 ` [PATCH v3 5/6] send-email: --in-reply-to=<file> populates the fields Tom Russello
@ 2016-06-07 14:05 ` Tom Russello
0 siblings, 0 replies; 256+ messages in thread
From: Tom Russello @ 2016-06-07 14:05 UTC (permalink / raw)
To: git
Cc: erwan.mathoniere, samuel.groot, jordan.de-gea, matthieu.moy, e,
aaron, gitster, Tom Russello
If used with `in-reply-to=<email_file>`, cite the message body of the given
email file. Otherwise, do nothing.
If `--compose` is set, quote the message body in the cover letter. Else,
imply `--annotate` by default and quote the message body below the triple-dash
section in the first patch only.
Signed-off-by: Tom RUSSELLO <tom.russello@grenoble-inp.org>
Signed-off-by: Samuel GROOT <samuel.groot@grenoble-inp.org>
Signed-off-by: Matthieu MOY <matthieu.moy@grenoble-inp.fr>
---
Documentation/git-send-email.txt | 8 ++++
git-send-email.perl | 81 ++++++++++++++++++++++++++++++++++++++--
t/t9001-send-email.sh | 32 ++++++++++++++++
3 files changed, 117 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 21776f0..23cbd17 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -109,6 +109,14 @@ illustration below where `[PATCH v2 0/3]` is in reply to `[PATCH 0/2]`:
Only necessary if --compose is also set. If --compose
is not set, this will be prompted for.
+--cite::
+ When used with `--in-reply-to=<email_file>`, quote the message body of the
+ given email file.
++
+If `--compose` is also set, the message cited will be in the cover letter. If
+`--compose` is not set, `--annotate` option is implied by default and the
+message body will be cited in the "below-triple-dash" section.
+
--subject=<string>::
Specify the initial subject of the email thread.
Only necessary if --compose is also set. If --compose
diff --git a/git-send-email.perl b/git-send-email.perl
index 66aa2cd..03483f5 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -26,6 +26,7 @@ use Text::ParseWords;
use Term::ANSIColor;
use File::Temp qw/ tempdir tempfile /;
use File::Spec::Functions qw(catfile);
+use File::Copy;
use Error qw(:try);
use Git;
@@ -56,6 +57,8 @@ git send-email --dump-aliases
--subject <str> * Email "Subject:"
--in-reply-to <str> * Email "In-Reply-To:"
--in-reply-to <file> * Populate header fields appropriately.
+ --cite * Quote the message body in the cover if
+ --compose is set, else in the first patch.
--[no-]xmailer * Add "X-Mailer:" header (default).
--[no-]annotate * Review each patch that will be sent in an editor.
--compose * Open an editor for introduction.
@@ -161,7 +164,7 @@ my $re_encoded_word = qr/=\?($re_token)\?($re_token)\?($re_encoded_text)\?=/;
# Variables we fill in automatically, or via prompting:
my (@to,$no_to,@initial_to,@cc,$no_cc,@initial_cc,@bcclist,$no_bcc,@xh,
- $initial_reply_to,$initial_references,$initial_subject,@files,
+ $initial_reply_to,$initial_references,$cite,$initial_subject,@files,
$author,$sender,$smtp_authpass,$annotate,$use_xmailer,$compose,$time);
my $envelope_sender;
@@ -305,6 +308,7 @@ $rc = GetOptions(
"sender|from=s" => \$sender,
"in-reply-to=s" => \$initial_reply_to,
"subject=s" => \$initial_subject,
+ "cite" => \$cite,
"to=s" => \@initial_to,
"to-cmd=s" => \$to_cmd,
"no-to" => \$no_to,
@@ -640,6 +644,7 @@ if (@files) {
usage();
}
+my $message_cited;
if ($initial_reply_to && -f $initial_reply_to) {
my $error = validate_patch($initial_reply_to);
die "fatal: $initial_reply_to: $error\nwarning: no patches were sent\n"
@@ -658,7 +663,8 @@ if ($initial_reply_to && -f $initial_reply_to) {
}
$initial_subject = $prefix_re . $subject_re;
- push @initial_to, $mail->{"from"}[0];
+ my $recipient = $mail->{"from"}[0];
+ push @initial_to, $recipient;
foreach my $to_addr (parse_address_line(join ",", @{$mail->{"to"}})) {
if (!($to_addr eq $initial_sender)) {
@@ -682,6 +688,25 @@ if ($initial_reply_to && -f $initial_reply_to) {
$initial_references = join("", @{$mail->{"references"}}) .
" " . $initial_reply_to;
}
+
+ if ($cite) {
+ my $date = $mail->{"date"}[0];
+ my $tpl_date = $date && "On $date, " || '';
+ $message_cited = $tpl_date . $recipient . " wrote:\n";
+
+ # Quote the message body
+ foreach (@{$mail->{"body"}}) {
+ my $space = "";
+ if (/^[^>]/) {
+ $space = " ";
+ }
+ $message_cited .= ">" . $space . $_;
+ }
+
+ if (!$compose) {
+ $annotate = 1;
+ }
+ }
}
sub get_patch_subject {
@@ -709,6 +734,9 @@ if ($compose) {
my $tpl_sender = $sender || $repoauthor || $repocommitter || '';
my $tpl_subject = $initial_subject || '';
my $tpl_reply_to = $initial_reply_to || '';
+ my $tpl_quote = $message_cited &&
+ "\nGIT: Please, trim down irrelevant sections in the cited message\n".
+ "GIT: to keep your email concise.\n" . $message_cited || '';
print $c <<EOT;
From $tpl_sender # This line is ignored.
@@ -720,7 +748,7 @@ GIT: Clear the body content if you don't wish to send a summary.
From: $tpl_sender
Subject: $tpl_subject
In-Reply-To: $tpl_reply_to
-
+$tpl_quote
EOT
for my $f (@files) {
print $c get_patch_subject($f);
@@ -785,7 +813,52 @@ EOT
$compose = -1;
}
} elsif ($annotate) {
- do_edit(@files);
+ if ($message_cited) {
+ my $cite_email_filename = ($repo ?
+ tempfile(".gitsendemail.msg.XXXXXX",
+ DIR => $repo->repo_path()) :
+ tempfile(".gitsendemail.msg.XXXXXX",
+ DIR => "."))[1];
+
+ # Insertion in a temporary file to keep the original file clean
+ # in case of cancellation/error.
+ do_insert_cited_message($cite_email_filename, $files[0]);
+
+ my $tmp = $files[0];
+ $files[0] = $cite_email_filename;
+
+ do_edit(@files);
+
+ # Erase the original patch if the edition went well
+ move($cite_email_filename, $tmp);
+ $files[0] = $tmp;
+ } else {
+ do_edit(@files);
+ }
+}
+
+sub do_insert_cited_message {
+ my $tmp_file = shift;
+ my $original_file = shift;
+
+ open my $c, "<", $original_file
+ or die "Failed to open $original_file: " . $!;
+
+ open my $c2, ">", $tmp_file
+ or die "Failed to open $tmp_file: " . $!;
+
+ # Insertion after the triple-dash
+ while (<$c>) {
+ print $c2 $_;
+ last if (/^---$/);
+ }
+ print $c2 $message_cited;
+ while (<$c>) {
+ print $c2 $_;
+ }
+
+ close $c;
+ close $c2;
}
sub ask {
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 2d67f6d..a107bde 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -1915,6 +1915,7 @@ test_expect_success $PREREQ 'Fields with --in-reply-to are correct' '
git send-email \
--in-reply-to=email \
--from="Example <nobody@example.com>" \
+ --cite \
--smtp-server="$(pwd)/fake.sendmail" \
-2 \
2>errors &&
@@ -1936,10 +1937,22 @@ test_expect_success $PREREQ 'Fields with --in-reply-to are correct' '
echo "$ref_adr" | grep -v "References: <author_123456@example.com>"
'
+test_expect_success $PREREQ 'correct cited message with --in-reply-to' '
+ msg_cited=$(grep -A 3 "^---$" msgtxt1) &&
+ echo "$msg_cited" | grep "On Sat, 12 Jun 2010 15:53:58 +0200, author@example.com wrote:" &&
+ echo "$msg_cited" | grep "> Have you seen my previous email?" &&
+ echo "$msg_cited" | grep ">> Previous content"
+'
+
+test_expect_success $PREREQ 'second patch body is not modified by --in-reply-to' '
+ ! grep "Have you seen my previous email?" msgtxt2
+'
+
test_expect_success $PREREQ 'Fields with --in-reply-to and --compose are correct' '
clean_fake_sendmail &&
git send-email \
--in-reply-to=email \
+ --cite \
--compose \
--from="Example <nobody@example.com>" \
--smtp-server="$(pwd)/fake.sendmail" \
@@ -1967,6 +1980,7 @@ test_expect_success $PREREQ 'Fields with --in-reply-to and --compose are correct
test_expect_success $PREREQ 'Re: written only once with --in-reply-to and --compose ' '
git send-email \
--in-reply-to=msgtxt1 \
+ --cite \
--compose \
--from="Example <nobody@example.com>" \
--smtp-server="$(pwd)/fake.sendmail" \
@@ -1975,4 +1989,22 @@ test_expect_success $PREREQ 'Re: written only once with --in-reply-to and --comp
grep "Subject: Re: subject goes here" msgtxt3
'
+test_expect_success $PREREQ 'correct cited message with --in-reply-to and --compose' '
+ grep "> On Sat, 12 Jun 2010 15:53:58 +0200, author@example.com wrote:" msgtxt3 &&
+ grep ">> Have you seen my previous email?" msgtxt3 &&
+ grep ">>> Previous content" msgtxt3
+'
+
+test_expect_success $PREREQ 'Message is not cited with only --in-reply-to' '
+ clean_fake_sendmail &&
+ git send-email \
+ --in-reply-to=email \
+ --compose \
+ --from="Example <nobody@example.com>" \
+ --smtp-server="$(pwd)/fake.sendmail" \
+ -1 \
+ 2>errors &&
+ ! grep "Have you seen my previous email?" msgtxt1
+'
+
test_done
--
2.8.3
^ permalink raw reply related [flat|nested] 256+ messages in thread
* (unknown),
2016-06-07 14:01 ` [PATCH v3 0/6] send-email: cleaner tests and quote email Tom Russello
` (3 preceding siblings ...)
2016-06-07 14:01 ` [PATCH v3 4/6] send-email: create email parser subroutine Tom Russello
@ 2016-06-08 13:01 ` Samuel GROOT
2016-06-08 13:01 ` [PATCH v4 1/6] t9001: non order-sensitive file comparison Samuel GROOT
` (5 more replies)
4 siblings, 6 replies; 256+ messages in thread
From: Samuel GROOT @ 2016-06-08 13:01 UTC (permalink / raw)
To: git
Cc: samuel.groot, tom.russello, erwan.mathoniere, jordan.de-gea,
matthieu.moy, gitster, aaron, e
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 patch introduces our email parser subroutine.
* Fifth patch makes the `--in-reply-to` open a email file (if it
exists) and populates From:, To:, Cc:, In-reply-to and
References: fields.
* Sixth patch quotes the message body in the cover letter if
`--compose` is set. Else, imply `--annotate` and insert quoted
message body below triple-dash in the first patch.
Changes since v3:
- test_cmp_noorder shell function fixed (patch 1/6)
- use fgrep instead of grep (patch 2/6)
- typo fixed (patch 3/6)
- email parser subroutine moved to Git.pm library (patch 4/6)
- test if $mail->{"cc"} is defined (patch 5/6)
[PATCH v4 1/6] t9001: non order-sensitive file comparison
[PATCH v4 2/6] t9001: check email address is in Cc: field
[PATCH v4 3/6] send-email: shorten send-email's output
[PATCH v4 4/6] send-email: create email parser subroutine
[PATCH v4 5/6] send-email: --in-reply-to=<file> populate header
[PATCH v4 6/6] send-email: add option --cite to quote the message
Documentation/git-send-email.txt | 17 +++++-
git-send-email.perl | 150 ++++++++++++++++++++++++++++++++++++++++++++-----
perl/Git.pm | 34 ++++++++++++
t/t9001-send-email.sh | 190 +++++++++++++++++++++++++++++++++++++++++++++++++++------------
4 files changed, 339 insertions(+), 52 deletions(-)
^ permalink raw reply [flat|nested] 256+ messages in thread
* [PATCH v4 1/6] t9001: non order-sensitive file comparison
2016-06-08 13:01 ` (unknown), Samuel GROOT
@ 2016-06-08 13:01 ` Samuel GROOT
2016-06-08 14:22 ` Remi Galan Alfonso
` (2 more replies)
2016-06-08 13:01 ` [PATCH v4 2/6] t9001: check email address is in Cc: field Samuel GROOT
` (4 subsequent siblings)
5 siblings, 3 replies; 256+ messages in thread
From: Samuel GROOT @ 2016-06-08 13:01 UTC (permalink / raw)
To: git
Cc: samuel.groot, tom.russello, erwan.mathoniere, jordan.de-gea,
matthieu.moy, gitster, aaron, e
Tests might fail if lines compared in text files don't have the same
order.
Signed-off-by: Samuel GROOT <samuel.groot@grenoble-inp.org>
Signed-off-by: Tom RUSSELLO <tom.russello@grenoble-inp.org>
Signed-off-by: Matthieu MOY <matthieu.moy@grenoble-inp.fr>
---
t/t9001-send-email.sh | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index b3355d2..56ad8ce 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -39,6 +39,13 @@ test_expect_success $PREREQ 'Extract patches' '
patches=$(git format-patch -s --cc="One <one@example.com>" --cc=two@example.com -n HEAD^1)
'
+# Check if two files have the same content, non-order sensitive
+test_cmp_noorder () {
+ sort "$1" >"$1_noorder"
+ sort "$2" >"$2_noorder"
+ test_cmp $1 $2
+}
+
# Test no confirm early to ensure remaining tests will not hang
test_no_confirm () {
rm -f no_confirm_okay
@@ -97,7 +104,7 @@ test_expect_success $PREREQ 'setup expect' '
'
test_expect_success $PREREQ 'Verify commandline' '
- test_cmp expected commandline1
+ test_cmp_noorder expected commandline1
'
test_expect_success $PREREQ 'Send patches with --envelope-sender' '
@@ -117,7 +124,7 @@ test_expect_success $PREREQ 'setup expect' '
'
test_expect_success $PREREQ 'Verify commandline' '
- test_cmp expected commandline1
+ test_cmp_noorder expected commandline1
'
test_expect_success $PREREQ 'Send patches with --envelope-sender=auto' '
@@ -137,7 +144,7 @@ test_expect_success $PREREQ 'setup expect' '
'
test_expect_success $PREREQ 'Verify commandline' '
- test_cmp expected commandline1
+ test_cmp_noorder expected commandline1
'
test_expect_success $PREREQ 'setup expect' "
--
2.8.2.537.gb153d2a
^ permalink raw reply related [flat|nested] 256+ messages in thread
* Re: [PATCH v4 1/6] t9001: non order-sensitive file comparison
2016-06-08 13:01 ` [PATCH v4 1/6] t9001: non order-sensitive file comparison Samuel GROOT
@ 2016-06-08 14:22 ` Remi Galan Alfonso
2016-06-08 14:29 ` Samuel GROOT
2016-06-08 16:56 ` Junio C Hamano
2016-06-08 17:17 ` Junio C Hamano
2 siblings, 1 reply; 256+ messages in thread
From: Remi Galan Alfonso @ 2016-06-08 14:22 UTC (permalink / raw)
To: Samuel GROOT
Cc: git, tom russello, erwan mathoniere, jordan de-gea, matthieu moy,
gitster, aaron, e
Hi Samuel,
Samuel GROOT <samuel.groot@grenoble-inp.org> writes:
> +test_cmp_noorder () {
> + sort "$1" >"$1_noorder"
> + sort "$2" >"$2_noorder"
> + test_cmp $1 $2
You meant `test_cmp "$1_noorder" "$2_noorder"`, I guess.
Thanks,
Rémi
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [PATCH v4 1/6] t9001: non order-sensitive file comparison
2016-06-08 14:22 ` Remi Galan Alfonso
@ 2016-06-08 14:29 ` Samuel GROOT
0 siblings, 0 replies; 256+ messages in thread
From: Samuel GROOT @ 2016-06-08 14:29 UTC (permalink / raw)
To: Remi Galan Alfonso
Cc: git, tom russello, erwan mathoniere, jordan de-gea, matthieu moy,
gitster, aaron, e
On 06/08/2016 04:22 PM, Remi Galan Alfonso wrote:
>> +test_cmp_noorder () {
>> + sort "$1" >"$1_noorder"
>> + sort "$2" >"$2_noorder"
>> + test_cmp $1 $2
>
> You meant `test_cmp "$1_noorder" "$2_noorder"`, I guess.
Yes, thanks for pointing it out!
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [PATCH v4 1/6] t9001: non order-sensitive file comparison
2016-06-08 13:01 ` [PATCH v4 1/6] t9001: non order-sensitive file comparison Samuel GROOT
2016-06-08 14:22 ` Remi Galan Alfonso
@ 2016-06-08 16:56 ` Junio C Hamano
2016-06-08 19:21 ` Samuel GROOT
2016-06-08 17:17 ` Junio C Hamano
2 siblings, 1 reply; 256+ messages in thread
From: Junio C Hamano @ 2016-06-08 16:56 UTC (permalink / raw)
To: Samuel GROOT
Cc: git, tom.russello, erwan.mathoniere, jordan.de-gea, matthieu.moy,
aaron, e
Samuel GROOT <samuel.groot@grenoble-inp.org> writes:
> @@ -117,7 +124,7 @@ test_expect_success $PREREQ 'setup expect' '
> '
>
> test_expect_success $PREREQ 'Verify commandline' '
> - test_cmp expected commandline1
> + test_cmp_noorder expected commandline1
> '
>
> test_expect_success $PREREQ 'Send patches with --envelope-sender=auto' '
I think this comment applies to all the other hunk in this patch (I
didn't check very carefully though), but this is trying to see if
the command line arguments that drives send-email are like this (one
arg per line, enclosed in !! pairs for clarity):
!patch@example.com!
!-i!
!nobody@example.com!
!author@example.com!
!one@example.com!
!two@example.com!
when these addresses are given from the command line:
git send-email \
--envelope-sender="Patch Contributor <patch@example.com>" \
--suppress-cc=sob \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
--smtp-server="$(pwd)/fake.sendmail" $patches 2>errors
that creates something like
$TRASH_DIRECTORY/fake.sendmail -f patch@example.com -i \
nobody@example.com author@example.com one@example.com two@example.com
(all on a single line).
The earliest address patch@example.com and later addresses have
quite different meaning (the first one is meant to be the envelope
sender address, and does not name a recipient). While I think it is
a good idea to tell the test that the order of recipient addresses
given to the sendmail command (i.e. nobody, author, one and two)
does not matter by comparing sorted list of addresses, sorting the
whole argument list and comparing is making the test _too_ loose.
Don't you want to catch a potential bug that adds the envelope
sender address to the list of recipients by mistake, for example?
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [PATCH v4 1/6] t9001: non order-sensitive file comparison
2016-06-08 16:56 ` Junio C Hamano
@ 2016-06-08 19:21 ` Samuel GROOT
0 siblings, 0 replies; 256+ messages in thread
From: Samuel GROOT @ 2016-06-08 19:21 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, tom.russello, erwan.mathoniere, jordan.de-gea, matthieu.moy,
aaron, e
On 06/08/2016 06:56 PM, Junio C Hamano wrote:
> The earliest address patch@example.com and later addresses have
> quite different meaning (the first one is meant to be the envelope
> sender address, and does not name a recipient). While I think it is
> a good idea to tell the test that the order of recipient addresses
> given to the sendmail command (i.e. nobody, author, one and two)
> does not matter by comparing sorted list of addresses, sorting the
> whole argument list and comparing is making the test _too_ loose.
> Don't you want to catch a potential bug that adds the envelope
> sender address to the list of recipients by mistake, for example?
That could be an idea to make a more precise test. But I rather focus on
our `--quote-email` option, I will put this one aside for now.
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [PATCH v4 1/6] t9001: non order-sensitive file comparison
2016-06-08 13:01 ` [PATCH v4 1/6] t9001: non order-sensitive file comparison Samuel GROOT
2016-06-08 14:22 ` Remi Galan Alfonso
2016-06-08 16:56 ` Junio C Hamano
@ 2016-06-08 17:17 ` Junio C Hamano
2016-06-08 19:19 ` Samuel GROOT
2 siblings, 1 reply; 256+ messages in thread
From: Junio C Hamano @ 2016-06-08 17:17 UTC (permalink / raw)
To: Samuel GROOT
Cc: git, tom.russello, erwan.mathoniere, jordan.de-gea, matthieu.moy,
aaron, e
Samuel GROOT <samuel.groot@grenoble-inp.org> writes:
> @@ -97,7 +104,7 @@ test_expect_success $PREREQ 'setup expect' '
> '
>
> test_expect_success $PREREQ 'Verify commandline' '
> - test_cmp expected commandline1
> + test_cmp_noorder expected commandline1
> '
>
> test_expect_success $PREREQ 'Send patches with --envelope-sender' '
By the way, don't you find it irritating to review this patch that
has three hunks, all of which look like the above? You cannot
easily tell which 3 among 27 instances of test_cmp are modified,
because the hunks do not give useful context.
This is not at all your fault, but because the existing tests are
structured poorly. It separates one logical step into three pieces
without a good reason.
Here is an illustration of an organization that I think would be
easier to read, and would result in a more readable patch when
modification is made on top. The first two hunks collapse the
overall "setup" steps that appear as three separate tests into a
single "setup" test. The last hunk that begin at -83/+79 collapses
a logically-single test that is split across three into one, and
makes the order of things done in the test to (1) set an
expectation, (2) execute the command and (3) compare the result with
the expectation.
I am not going to commit this myself, because I do not want to
create conflicts with the change your topic is trying to do, and
besides, almost all the remainder of the tests follow "one logical
test split into three" pattern and need to be corrected before this
"illustration" can become a real patch.
I do not mind if you take it and complete it as a preliminary
clean-up step in your series; or you can "keep it in mind, but
ignore it for now", in which case this can be a "low hanging fruit"
somebody else, hopefully somebody new to the development community,
can use to dip their toes ;-)
t/t9001-send-email.sh | 33 ++++++++++++++-------------------
1 file changed, 14 insertions(+), 19 deletions(-)
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index b3355d2..858bdbe 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -6,14 +6,16 @@ test_description='git send-email'
# May be altered later in the test
PREREQ="PERL"
-test_expect_success $PREREQ 'prepare reference tree' '
+clean_fake_sendmail () {
+ rm -f commandline* msgtxt*
+}
+
+test_expect_success $PREREQ 'setup' '
echo "1A quick brown fox jumps over the" >file &&
echo "lazy dog" >>file &&
git add file &&
- GIT_AUTHOR_NAME="A" git commit -a -m "Initial."
-'
+ GIT_AUTHOR_NAME="A" git commit -a -m "Initial." &&
-test_expect_success $PREREQ 'Setup helper tool' '
write_script fake.sendmail <<-\EOF &&
shift
output=1
@@ -28,14 +30,8 @@ test_expect_success $PREREQ 'Setup helper tool' '
cat >"msgtxt$output"
EOF
git add fake.sendmail &&
- GIT_AUTHOR_NAME="A" git commit -a -m "Second."
-'
-
-clean_fake_sendmail () {
- rm -f commandline* msgtxt*
-}
+ GIT_AUTHOR_NAME="A" git commit -a -m "Second." &&
-test_expect_success $PREREQ 'Extract patches' '
patches=$(git format-patch -s --cc="One <one@example.com>" --cc=two@example.com -n HEAD^1)
'
@@ -83,20 +79,19 @@ test_expect_success $PREREQ 'No confirm with sendemail.confirm=never' '
check_no_confirm
'
-test_expect_success $PREREQ 'Send patches' '
- git send-email --suppress-cc=sob --from="Example <nobody@example.com>" --to=nobody@example.com --smtp-server="$(pwd)/fake.sendmail" $patches 2>errors
-'
-
-test_expect_success $PREREQ 'setup expect' '
- cat >expected <<-\EOF
+test_expect_success $PREREQ 'with --suppress-cc=sob --from and --to' '
+ cat >expected <<-\EOF &&
!nobody@example.com!
!author@example.com!
!one@example.com!
!two@example.com!
EOF
-'
-test_expect_success $PREREQ 'Verify commandline' '
+ git send-email --suppress-cc=sob \
+ --from="Example <nobody@example.com>" \
+ --to=nobody@example.com \
+ --smtp-server="$(pwd)/fake.sendmail" $patches 2>errors &&
+
test_cmp expected commandline1
'
^ permalink raw reply related [flat|nested] 256+ messages in thread
* Re: [PATCH v4 1/6] t9001: non order-sensitive file comparison
2016-06-08 17:17 ` Junio C Hamano
@ 2016-06-08 19:19 ` Samuel GROOT
0 siblings, 0 replies; 256+ messages in thread
From: Samuel GROOT @ 2016-06-08 19:19 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, tom.russello, erwan.mathoniere, jordan.de-gea, matthieu.moy,
aaron, e
On 06/08/2016 07:17 PM, Junio C Hamano wrote:
> Here is an illustration of an organization that I think would be
> easier to read, and would result in a more readable patch when
> modification is made on top. The first two hunks collapse the
> overall "setup" steps that appear as three separate tests into a
> single "setup" test. The last hunk that begin at -83/+79 collapses
> a logically-single test that is split across three into one, and
> makes the order of things done in the test to (1) set an
> expectation, (2) execute the command and (3) compare the result with
> the expectation.
I totally agree. (1), (2) and (3) aren't even always in that order, some
tests are very confusing.
> I am not going to commit this myself, because I do not want to
> create conflicts with the change your topic is trying to do, and
> besides, almost all the remainder of the tests follow "one logical
> test split into three" pattern and need to be corrected before this
> "illustration" can become a real patch.
>
> I do not mind if you take it and complete it as a preliminary
> clean-up step in your series; or you can "keep it in mind, but
> ignore it for now", in which case this can be a "low hanging fruit"
> somebody else, hopefully somebody new to the development community,
> can use to dip their toes ;-)
As said in my other reply, I will put this one aside for now, but t9001
definitely deserves its own cleanup patch series.
^ permalink raw reply [flat|nested] 256+ messages in thread
* [PATCH v4 2/6] t9001: check email address is in Cc: field
2016-06-08 13:01 ` (unknown), Samuel GROOT
2016-06-08 13:01 ` [PATCH v4 1/6] t9001: non order-sensitive file comparison Samuel GROOT
@ 2016-06-08 13:01 ` Samuel GROOT
2016-06-08 17:34 ` Junio C Hamano
2016-06-08 13:01 ` [PATCH v4 3/6] send-email: shorten send-email's output Samuel GROOT
` (3 subsequent siblings)
5 siblings, 1 reply; 256+ messages in thread
From: Samuel GROOT @ 2016-06-08 13:01 UTC (permalink / raw)
To: git
Cc: samuel.groot, tom.russello, erwan.mathoniere, jordan.de-gea,
matthieu.moy, gitster, aaron, e
Check if the given utf-8 email address is in the Cc: field.
Signed-off-by: Tom RUSSELLO <tom.russello@grenoble-inp.org>
Signed-off-by: Samuel GROOT <samuel.groot@grenoble-inp.org>
Signed-off-by: Matthieu MOY <matthieu.moy@grenoble-inp.fr>
---
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 56ad8ce..943e6b7 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -888,8 +888,8 @@ test_expect_success $PREREQ 'utf8 Cc is rfc2047 encoded' '
--to=nobody@example.com \
--smtp-server="$(pwd)/fake.sendmail" \
outdir/*.patch &&
- grep "^ " msgtxt1 |
- grep "=?UTF-8?q?=C3=A0=C3=A9=C3=AC=C3=B6=C3=BA?= <utf8@example.com>"
+ cc_adr=$(awk "/^Cc: /{flag=1}/^Subject: /{flag=0} flag {print}" msgtxt1) &&
+ echo "$cc_adr" | fgrep "=?UTF-8?q?=C3=A0=C3=A9=C3=AC=C3=B6=C3=BA?= <utf8@example.com>"
'
test_expect_success $PREREQ '--compose adds MIME for utf8 body' '
--
2.8.2.537.gb153d2a
^ permalink raw reply related [flat|nested] 256+ messages in thread
* Re: [PATCH v4 2/6] t9001: check email address is in Cc: field
2016-06-08 13:01 ` [PATCH v4 2/6] t9001: check email address is in Cc: field Samuel GROOT
@ 2016-06-08 17:34 ` Junio C Hamano
2016-06-08 19:23 ` Samuel GROOT
0 siblings, 1 reply; 256+ messages in thread
From: Junio C Hamano @ 2016-06-08 17:34 UTC (permalink / raw)
To: Samuel GROOT
Cc: git, tom.russello, erwan.mathoniere, jordan.de-gea, matthieu.moy,
aaron, e
Samuel GROOT <samuel.groot@grenoble-inp.org> writes:
> Check if the given utf-8 email address is in the Cc: field.
>
> Signed-off-by: Tom RUSSELLO <tom.russello@grenoble-inp.org>
> Signed-off-by: Samuel GROOT <samuel.groot@grenoble-inp.org>
> Signed-off-by: Matthieu MOY <matthieu.moy@grenoble-inp.fr>
> ---
> 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 56ad8ce..943e6b7 100755
> --- a/t/t9001-send-email.sh
> +++ b/t/t9001-send-email.sh
> @@ -888,8 +888,8 @@ test_expect_success $PREREQ 'utf8 Cc is rfc2047 encoded' '
> --to=nobody@example.com \
> --smtp-server="$(pwd)/fake.sendmail" \
> outdir/*.patch &&
> - grep "^ " msgtxt1 |
> - grep "=?UTF-8?q?=C3=A0=C3=A9=C3=AC=C3=B6=C3=BA?= <utf8@example.com>"
> + cc_adr=$(awk "/^Cc: /{flag=1}/^Subject: /{flag=0} flag {print}" msgtxt1) &&
> + echo "$cc_adr" | fgrep "=?UTF-8?q?=C3=A0=C3=A9=C3=AC=C3=B6=C3=BA?= <utf8@example.com>"
> '
This still depends on that the output has Cc: before Subject: and
there is no other header that can have an address on it. E.g.
To: a@example.com
Cc: b@example.com
X-foo: <<whatever address you are looking for>>
Subject: [PATCH] A sample patch
would still say that the address is _on_ the CC: list.
I do not usually do awk, but I think you should be able to avoid
capturing output from it, echoing and then grepping, which is way
too ugly. Perhaps you can start from something like below?
#!/bin/sh
awk '
BEGIN { in_cc = 0 }
/^[Cc][Cc]: / {
sub("^[Cc][Cc]: *", "")
in_cc = 1
}
/^[^ ]*:/ {
in_cc = 0
}
/^$/ { exit }
in_cc {
sub("^ *", "")
sub(", *$", "")
print
}
' <<\EOF
To: a@example.com
Cc: b@example.com,
c@example.com,
d@example.com
X-foo: e@example.com
Subject: [PATCH] A sample patch
Cc: foo@example.com
EOF
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [PATCH v4 2/6] t9001: check email address is in Cc: field
2016-06-08 17:34 ` Junio C Hamano
@ 2016-06-08 19:23 ` Samuel GROOT
0 siblings, 0 replies; 256+ messages in thread
From: Samuel GROOT @ 2016-06-08 19:23 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, tom.russello, erwan.mathoniere, jordan.de-gea, matthieu.moy,
aaron, e
On 06/08/2016 07:34 PM, Junio C Hamano wrote:
> Samuel GROOT <samuel.groot@grenoble-inp.org> writes:
>> diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
>> index 56ad8ce..943e6b7 100755
>> --- a/t/t9001-send-email.sh
>> +++ b/t/t9001-send-email.sh
>> @@ -888,8 +888,8 @@ test_expect_success $PREREQ 'utf8 Cc is rfc2047 encoded' '
>> --to=nobody@example.com \
>> --smtp-server="$(pwd)/fake.sendmail" \
>> outdir/*.patch &&
>> - grep "^ " msgtxt1 |
>> - grep "=?UTF-8?q?=C3=A0=C3=A9=C3=AC=C3=B6=C3=BA?= <utf8@example.com>"
>> + cc_adr=$(awk "/^Cc: /{flag=1}/^Subject: /{flag=0} flag {print}" msgtxt1) &&
>> + echo "$cc_adr" | fgrep "=?UTF-8?q?=C3=A0=C3=A9=C3=AC=C3=B6=C3=BA?= <utf8@example.com>"
>> '
>
> This still depends on that the output has Cc: before Subject: and
> there is no other header that can have an address on it. E.g.
>
> To: a@example.com
> Cc: b@example.com
> X-foo: <<whatever address you are looking for>>
> Subject: [PATCH] A sample patch
>
> would still say that the address is _on_ the CC: list.
We thought of that but did not find the proper way to do it.
> I do not usually do awk, but I think you should be able to avoid
> capturing output from it, echoing and then grepping, which is way
> too ugly. Perhaps you can start from something like below?
>
> #!/bin/sh
> awk '
> BEGIN { in_cc = 0 }
> /^[Cc][Cc]: / {
> sub("^[Cc][Cc]: *", "")
> in_cc = 1
> }
> /^[^ ]*:/ {
> in_cc = 0
> }
> /^$/ { exit }
> in_cc {
> sub("^ *", "")
> sub(", *$", "")
> print
> }
> ' <<\EOF
> To: a@example.com
> Cc: b@example.com,
> c@example.com,
> d@example.com
> X-foo: e@example.com
> Subject: [PATCH] A sample patch
>
> Cc: foo@example.com
> EOF
Thanks, I will work on that :-)
^ permalink raw reply [flat|nested] 256+ messages in thread
* [PATCH v4 3/6] send-email: shorten send-email's output
2016-06-08 13:01 ` (unknown), Samuel GROOT
2016-06-08 13:01 ` [PATCH v4 1/6] t9001: non order-sensitive file comparison Samuel GROOT
2016-06-08 13:01 ` [PATCH v4 2/6] t9001: check email address is in Cc: field Samuel GROOT
@ 2016-06-08 13:01 ` Samuel GROOT
2016-06-08 17:37 ` Junio C Hamano
2016-06-09 6:17 ` Matthieu Moy
2016-06-08 13:01 ` [PATCH v4 4/6] send-email: create email parser subroutine Samuel GROOT
` (2 subsequent siblings)
5 siblings, 2 replies; 256+ messages in thread
From: Samuel GROOT @ 2016-06-08 13:01 UTC (permalink / raw)
To: git
Cc: samuel.groot, tom.russello, erwan.mathoniere, jordan.de-gea,
matthieu.moy, gitster, aaron, e
Messages displayed by `send-email` should be shortened to avoid displaying
unnecessary information.
Signed-off-by: Samuel GROOT <samuel.groot@grenoble-inp.org>
Signed-off-by: Tom RUSSELLO <tom.russello@grenoble-inp.org>
Signed-off-by: Matthieu MOY <matthieu.moy@grenoble-inp.fr>
---
git-send-email.perl | 22 +++++++++----------
t/t9001-send-email.sh | 58 +++++++++++++++++++++++++--------------------------
2 files changed, 40 insertions(+), 40 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 6958785..9b51062 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -1478,14 +1478,14 @@ foreach my $t (@files) {
$sauthor = sanitize_address($author);
next if $suppress_cc{'author'};
next if $suppress_cc{'self'} and $sauthor eq $sender;
- printf("(mbox) Adding cc: %s from line '%s'\n",
- $1, $_) unless $quiet;
+ printf("Adding cc: %s from From: header\n",
+ $1) unless $quiet;
push @cc, $1;
}
elsif (/^To:\s+(.*)$/i) {
foreach my $addr (parse_address_line($1)) {
- printf("(mbox) Adding to: %s from line '%s'\n",
- $addr, $_) unless $quiet;
+ printf("Adding to: %s from To: header\n",
+ $addr) unless $quiet;
push @to, $addr;
}
}
@@ -1498,8 +1498,8 @@ foreach my $t (@files) {
} else {
next if ($suppress_cc{'cc'});
}
- printf("(mbox) Adding cc: %s from line '%s'\n",
- $addr, $_) unless $quiet;
+ printf("Adding cc: %s from Cc: header\n",
+ $addr) unless $quiet;
push @cc, $addr;
}
}
@@ -1532,8 +1532,8 @@ foreach my $t (@files) {
# So let's support that, too.
$input_format = 'lots';
if (@cc == 0 && !$suppress_cc{'cc'}) {
- printf("(non-mbox) Adding cc: %s from line '%s'\n",
- $_, $_) unless $quiet;
+ printf("Adding cc: %s from Cc: header\n",
+ $_) unless $quiet;
push @cc, $_;
} elsif (!defined $subject) {
$subject = $_;
@@ -1555,8 +1555,8 @@ foreach my $t (@files) {
next if $suppress_cc{'bodycc'} and $what =~ /Cc/i;
}
push @cc, $c;
- printf("(body) Adding cc: %s from line '%s'\n",
- $c, $_) unless $quiet;
+ printf("Adding cc: %s from Signed-off-by: trailer\n",
+ $c) unless $quiet;
}
}
close $fh;
@@ -1660,7 +1660,7 @@ sub recipients_cmd {
$address = sanitize_address($address);
next if ($address eq $sender and $suppress_cc{'self'});
push @addresses, $address;
- printf("($prefix) Adding %s: %s from: '%s'\n",
+ printf("Adding %s: %s from: '%s'\n",
$what, $address, $cmd) unless $quiet;
}
close $fh
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 943e6b7..aca7d5c 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -150,9 +150,9 @@ test_expect_success $PREREQ 'Verify commandline' '
test_expect_success $PREREQ 'setup expect' "
cat >expected-show-all-headers <<\EOF
0001-Second.patch
-(mbox) Adding cc: A <author@example.com> from line 'From: A <author@example.com>'
-(mbox) Adding cc: One <one@example.com> from line 'Cc: One <one@example.com>, two@example.com'
-(mbox) Adding cc: two@example.com from line 'Cc: One <one@example.com>, two@example.com'
+Adding cc: A <author@example.com> from From: header
+Adding cc: One <one@example.com> from Cc: header
+Adding cc: two@example.com from Cc: header
Dry-OK. Log says:
Server: relay.example.com
MAIL FROM:<from@example.com>
@@ -503,9 +503,9 @@ test_expect_success $PREREQ 'second message is patch' '
test_expect_success $PREREQ 'setup expect' "
cat >expected-suppress-sob <<\EOF
0001-Second.patch
-(mbox) Adding cc: A <author@example.com> from line 'From: A <author@example.com>'
-(mbox) Adding cc: One <one@example.com> from line 'Cc: One <one@example.com>, two@example.com'
-(mbox) Adding cc: two@example.com from line 'Cc: One <one@example.com>, two@example.com'
+Adding cc: A <author@example.com> from From: header
+Adding cc: One <one@example.com> from Cc: header
+Adding cc: two@example.com from Cc: header
Dry-OK. Log says:
Server: relay.example.com
MAIL FROM:<from@example.com>
@@ -555,9 +555,9 @@ test_expect_success $PREREQ 'sendemail.cc set' '
test_expect_success $PREREQ 'setup expect' "
cat >expected-suppress-sob <<\EOF
0001-Second.patch
-(mbox) Adding cc: A <author@example.com> from line 'From: A <author@example.com>'
-(mbox) Adding cc: One <one@example.com> from line 'Cc: One <one@example.com>, two@example.com'
-(mbox) Adding cc: two@example.com from line 'Cc: One <one@example.com>, two@example.com'
+Adding cc: A <author@example.com> from From: header
+Adding cc: One <one@example.com> from Cc: header
+Adding cc: two@example.com from Cc: header
Dry-OK. Log says:
Server: relay.example.com
MAIL FROM:<from@example.com>
@@ -587,10 +587,10 @@ test_expect_success $PREREQ 'sendemail.cc unset' '
test_expect_success $PREREQ 'setup expect' "
cat >expected-suppress-cccmd <<\EOF
0001-Second.patch
-(mbox) Adding cc: A <author@example.com> from line 'From: A <author@example.com>'
-(mbox) Adding cc: One <one@example.com> from line 'Cc: One <one@example.com>, two@example.com'
-(mbox) Adding cc: two@example.com from line 'Cc: One <one@example.com>, two@example.com'
-(body) Adding cc: C O Mitter <committer@example.com> from line 'Signed-off-by: C O Mitter <committer@example.com>'
+Adding cc: A <author@example.com> from From: header
+Adding cc: One <one@example.com> from Cc: header
+Adding cc: two@example.com from Cc: header
+Adding cc: C O Mitter <committer@example.com> from Signed-off-by: trailer
Dry-OK. Log says:
Server: relay.example.com
MAIL FROM:<from@example.com>
@@ -647,10 +647,10 @@ test_expect_success $PREREQ '--suppress-cc=all' '
test_expect_success $PREREQ 'setup expect' "
cat >expected-suppress-body <<\EOF
0001-Second.patch
-(mbox) Adding cc: A <author@example.com> from line 'From: A <author@example.com>'
-(mbox) Adding cc: One <one@example.com> from line 'Cc: One <one@example.com>, two@example.com'
-(mbox) Adding cc: two@example.com from line 'Cc: One <one@example.com>, two@example.com'
-(cc-cmd) Adding cc: cc-cmd@example.com from: './cccmd'
+Adding cc: A <author@example.com> from From: header
+Adding cc: One <one@example.com> from Cc: header
+Adding cc: two@example.com from Cc: header
+Adding cc: cc-cmd@example.com from: './cccmd'
Dry-OK. Log says:
Server: relay.example.com
MAIL FROM:<from@example.com>
@@ -681,9 +681,9 @@ test_expect_success $PREREQ '--suppress-cc=body' '
test_expect_success $PREREQ 'setup expect' "
cat >expected-suppress-body-cccmd <<\EOF
0001-Second.patch
-(mbox) Adding cc: A <author@example.com> from line 'From: A <author@example.com>'
-(mbox) Adding cc: One <one@example.com> from line 'Cc: One <one@example.com>, two@example.com'
-(mbox) Adding cc: two@example.com from line 'Cc: One <one@example.com>, two@example.com'
+Adding cc: A <author@example.com> from From: header
+Adding cc: One <one@example.com> from Cc: header
+Adding cc: two@example.com from Cc: header
Dry-OK. Log says:
Server: relay.example.com
MAIL FROM:<from@example.com>
@@ -712,9 +712,9 @@ test_expect_success $PREREQ '--suppress-cc=body --suppress-cc=cccmd' '
test_expect_success $PREREQ 'setup expect' "
cat >expected-suppress-sob <<\EOF
0001-Second.patch
-(mbox) Adding cc: A <author@example.com> from line 'From: A <author@example.com>'
-(mbox) Adding cc: One <one@example.com> from line 'Cc: One <one@example.com>, two@example.com'
-(mbox) Adding cc: two@example.com from line 'Cc: One <one@example.com>, two@example.com'
+Adding cc: A <author@example.com> from From: header
+Adding cc: One <one@example.com> from Cc: header
+Adding cc: two@example.com from Cc: header
Dry-OK. Log says:
Server: relay.example.com
MAIL FROM:<from@example.com>
@@ -744,10 +744,10 @@ test_expect_success $PREREQ '--suppress-cc=sob' '
test_expect_success $PREREQ 'setup expect' "
cat >expected-suppress-bodycc <<\EOF
0001-Second.patch
-(mbox) Adding cc: A <author@example.com> from line 'From: A <author@example.com>'
-(mbox) Adding cc: One <one@example.com> from line 'Cc: One <one@example.com>, two@example.com'
-(mbox) Adding cc: two@example.com from line 'Cc: One <one@example.com>, two@example.com'
-(body) Adding cc: C O Mitter <committer@example.com> from line 'Signed-off-by: C O Mitter <committer@example.com>'
+Adding cc: A <author@example.com> from From: header
+Adding cc: One <one@example.com> from Cc: header
+Adding cc: two@example.com from Cc: header
+Adding cc: C O Mitter <committer@example.com> from Signed-off-by: trailer
Dry-OK. Log says:
Server: relay.example.com
MAIL FROM:<from@example.com>
@@ -778,8 +778,8 @@ test_expect_success $PREREQ '--suppress-cc=bodycc' '
test_expect_success $PREREQ 'setup expect' "
cat >expected-suppress-cc <<\EOF
0001-Second.patch
-(mbox) Adding cc: A <author@example.com> from line 'From: A <author@example.com>'
-(body) Adding cc: C O Mitter <committer@example.com> from line 'Signed-off-by: C O Mitter <committer@example.com>'
+Adding cc: A <author@example.com> from From: header
+Adding cc: C O Mitter <committer@example.com> from Signed-off-by: trailer
Dry-OK. Log says:
Server: relay.example.com
MAIL FROM:<from@example.com>
--
2.8.2.537.gb153d2a
^ permalink raw reply related [flat|nested] 256+ messages in thread
* Re: [PATCH v4 3/6] send-email: shorten send-email's output
2016-06-08 13:01 ` [PATCH v4 3/6] send-email: shorten send-email's output Samuel GROOT
@ 2016-06-08 17:37 ` Junio C Hamano
2016-06-08 19:18 ` Samuel GROOT
2016-06-09 6:17 ` Matthieu Moy
1 sibling, 1 reply; 256+ messages in thread
From: Junio C Hamano @ 2016-06-08 17:37 UTC (permalink / raw)
To: Samuel GROOT
Cc: git, tom.russello, erwan.mathoniere, jordan.de-gea, matthieu.moy,
aaron, e
Samuel GROOT <samuel.groot@grenoble-inp.org> writes:
> + printf("Adding cc: %s from From: header\n",
> + $1) unless $quiet;
> + printf("Adding to: %s from To: header\n",
> + $addr) unless $quiet;
> + printf("Adding cc: %s from Cc: header\n",
> + $addr) unless $quiet;
> push @cc, $addr;
> + printf("Adding cc: %s from Cc: header\n",
> + $_) unless $quiet;
These make the end result prettier by not repeating the same address
twice, but is it just me who finds these inexplicable case
differences irritating? Shouldn't these field references in the
result mirror the field references in the origin of the information?
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [PATCH v4 3/6] send-email: shorten send-email's output
2016-06-08 17:37 ` Junio C Hamano
@ 2016-06-08 19:18 ` Samuel GROOT
2016-06-08 19:33 ` Junio C Hamano
0 siblings, 1 reply; 256+ messages in thread
From: Samuel GROOT @ 2016-06-08 19:18 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, tom.russello, erwan.mathoniere, jordan.de-gea, matthieu.moy,
aaron, e
On 06/08/2016 07:37 PM, Junio C Hamano wrote:
> Samuel GROOT <samuel.groot@grenoble-inp.org> writes:
>> + printf("Adding cc: %s from From: header\n",
>> + $1) unless $quiet;
>
>> + printf("Adding to: %s from To: header\n",
>> + $addr) unless $quiet;
>
>> + printf("Adding cc: %s from Cc: header\n",
>> + $addr) unless $quiet;
>> push @cc, $addr;
>
>> + printf("Adding cc: %s from Cc: header\n",
>> + $_) unless $quiet;
>
> These make the end result prettier by not repeating the same address
> twice, but is it just me who finds these inexplicable case
> differences irritating? Shouldn't these field references in the
> result mirror the field references in the origin of the information?
It makes sense only in the case below...
>> + printf("Adding cc: %s from From: header\n",
>> + $1) unless $quiet;
... because the sender should receive its own copy (at least to avoid
breaking threaded view in his mailer) and be cc-ed. By the way, we
should cc the sender when sending the cover letter too for the same reason.
But in other cases, it seems pointless to display identical field
reference twice.
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [PATCH v4 3/6] send-email: shorten send-email's output
2016-06-08 19:18 ` Samuel GROOT
@ 2016-06-08 19:33 ` Junio C Hamano
2016-06-08 19:40 ` Samuel GROOT
0 siblings, 1 reply; 256+ messages in thread
From: Junio C Hamano @ 2016-06-08 19:33 UTC (permalink / raw)
To: Samuel GROOT
Cc: git, tom.russello, erwan.mathoniere, jordan.de-gea, matthieu.moy,
aaron, e
Samuel GROOT <samuel.groot@grenoble-inp.org> writes:
> On 06/08/2016 07:37 PM, Junio C Hamano wrote:
>> Samuel GROOT <samuel.groot@grenoble-inp.org> writes:
>>> + printf("Adding cc: %s from From: header\n",
>>> + $1) unless $quiet;
>>
>>> + printf("Adding to: %s from To: header\n",
>>> + $addr) unless $quiet;
>>
>>> + printf("Adding cc: %s from Cc: header\n",
>>> + $addr) unless $quiet;
>>> push @cc, $addr;
>>
>>> + printf("Adding cc: %s from Cc: header\n",
>>> + $_) unless $quiet;
>>
>> These make the end result prettier by not repeating the same address
>> twice, but is it just me who finds these inexplicable case
>> differences irritating? Shouldn't these field references in the
>> result mirror the field references in the origin of the information?
>
> It makes sense only in the case below...
>
>>> + printf("Adding cc: %s from From: header\n",
>>> + $1) unless $quiet;
>
> ... because the sender should receive its own copy (at least to avoid
> breaking threaded view in his mailer) and be cc-ed. By the way, we
> should cc the sender when sending the cover letter too for the same
> reason.
>
> But in other cases, it seems pointless to display identical field
> reference twice.
My comment may have been a bit too oblique. What I meant was
Adding cc: Samuel from From: header
looked strange, and I thought it would be better written
Adding Cc: Samuel from From: header
Same for
Adding to: Samuel from To: header
being strange, and a better version of it would be
Adding To: Samuel from To: header
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [PATCH v4 3/6] send-email: shorten send-email's output
2016-06-08 19:33 ` Junio C Hamano
@ 2016-06-08 19:40 ` Samuel GROOT
0 siblings, 0 replies; 256+ messages in thread
From: Samuel GROOT @ 2016-06-08 19:40 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, tom.russello, erwan.mathoniere, jordan.de-gea, matthieu.moy,
aaron, e
On 06/08/2016 09:33 PM, Junio C Hamano wrote:
> Samuel GROOT <samuel.groot@grenoble-inp.org> writes:
>
>> On 06/08/2016 07:37 PM, Junio C Hamano wrote:
>>> Samuel GROOT <samuel.groot@grenoble-inp.org> writes:
>>>> + printf("Adding cc: %s from From: header\n",
>>>> + $1) unless $quiet;
>>>
>>>> + printf("Adding to: %s from To: header\n",
>>>> + $addr) unless $quiet;
>>>
>>>> + printf("Adding cc: %s from Cc: header\n",
>>>> + $addr) unless $quiet;
>>>> push @cc, $addr;
>>>
>>>> + printf("Adding cc: %s from Cc: header\n",
>>>> + $_) unless $quiet;
>>>
>>> These make the end result prettier by not repeating the same address
>>> twice, but is it just me who finds these inexplicable case
>>> differences irritating? Shouldn't these field references in the
>>> result mirror the field references in the origin of the information?
>>
>> It makes sense only in the case below...
>>
>>>> + printf("Adding cc: %s from From: header\n",
>>>> + $1) unless $quiet;
>>
>> ... because the sender should receive its own copy (at least to avoid
>> breaking threaded view in his mailer) and be cc-ed. By the way, we
>> should cc the sender when sending the cover letter too for the same
>> reason.
>>
>> But in other cases, it seems pointless to display identical field
>> reference twice.
>
> My comment may have been a bit too oblique. What I meant was
>
> Adding cc: Samuel from From: header
>
> looked strange, and I thought it would be better written
>
> Adding Cc: Samuel from From: header
>
> Same for
>
> Adding to: Samuel from To: header
>
> being strange, and a better version of it would be
>
> Adding To: Samuel from To: header
Oh, I read your email a bit too fast, sorry.
I kept the sentence as it was except for trimmed part, but it makes
sense to have the same case. It will be fixed :-)
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [PATCH v4 3/6] send-email: shorten send-email's output
2016-06-08 13:01 ` [PATCH v4 3/6] send-email: shorten send-email's output Samuel GROOT
2016-06-08 17:37 ` Junio C Hamano
@ 2016-06-09 6:17 ` Matthieu Moy
2016-06-13 22:19 ` Samuel GROOT
1 sibling, 1 reply; 256+ messages in thread
From: Matthieu Moy @ 2016-06-09 6:17 UTC (permalink / raw)
To: Samuel GROOT
Cc: git, tom.russello, erwan.mathoniere, jordan.de-gea, gitster, aaron, e
Samuel GROOT <samuel.groot@grenoble-inp.org> writes:
> @@ -647,10 +647,10 @@ test_expect_success $PREREQ '--suppress-cc=all' '
> test_expect_success $PREREQ 'setup expect' "
> cat >expected-suppress-body <<\EOF
> 0001-Second.patch
> -(mbox) Adding cc: A <author@example.com> from line 'From: A <author@example.com>'
> -(mbox) Adding cc: One <one@example.com> from line 'Cc: One <one@example.com>, two@example.com'
> -(mbox) Adding cc: two@example.com from line 'Cc: One <one@example.com>, two@example.com'
> -(cc-cmd) Adding cc: cc-cmd@example.com from: './cccmd'
> +Adding cc: A <author@example.com> from From: header
> +Adding cc: One <one@example.com> from Cc: header
> +Adding cc: two@example.com from Cc: header
> +Adding cc: cc-cmd@example.com from: './cccmd'
This hunk differs from the others a bit. I totally agree that removing
the (mbox) prefix makes sense, but you're removing (cc-cmd) here, which
did carry some information.
I'd write it as
Adding cc: cc-cmd@example.com from --cc-cmd: ./cccmd
It might make sense to split this into two patches: one for (mbox) +
headers and one for (cc-cmd) and (to-cmd). Spotting special-cases like
the above inside a long patch is hard for reviewers.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [PATCH v4 3/6] send-email: shorten send-email's output
2016-06-09 6:17 ` Matthieu Moy
@ 2016-06-13 22:19 ` Samuel GROOT
0 siblings, 0 replies; 256+ messages in thread
From: Samuel GROOT @ 2016-06-13 22:19 UTC (permalink / raw)
To: Matthieu Moy
Cc: git, tom.russello, erwan.mathoniere, jordan.de-gea, gitster, aaron, e
On 06/09/2016 08:17 AM, Matthieu Moy wrote:
> Samuel GROOT <samuel.groot@grenoble-inp.org> writes:
>
>> @@ -647,10 +647,10 @@ test_expect_success $PREREQ '--suppress-cc=all' '
>> test_expect_success $PREREQ 'setup expect' "
>> cat >expected-suppress-body <<\EOF
>> 0001-Second.patch
>> -(mbox) Adding cc: A <author@example.com> from line 'From: A <author@example.com>'
>> -(mbox) Adding cc: One <one@example.com> from line 'Cc: One <one@example.com>, two@example.com'
>> -(mbox) Adding cc: two@example.com from line 'Cc: One <one@example.com>, two@example.com'
>> -(cc-cmd) Adding cc: cc-cmd@example.com from: './cccmd'
>> +Adding cc: A <author@example.com> from From: header
>> +Adding cc: One <one@example.com> from Cc: header
>> +Adding cc: two@example.com from Cc: header
>> +Adding cc: cc-cmd@example.com from: './cccmd'
>
> This hunk differs from the others a bit. I totally agree that removing
> the (mbox) prefix makes sense, but you're removing (cc-cmd) here, which
> did carry some information.
>
> I'd write it as
>
> Adding cc: cc-cmd@example.com from --cc-cmd: ./cccmd
Indeed it's clearer, I will change that.
> It might make sense to split this into two patches: one for (mbox) +
> headers and one for (cc-cmd) and (to-cmd). Spotting special-cases like
> the above inside a long patch is hard for reviewers.
I will split in the future patch series dedicated to clean send-email.
^ permalink raw reply [flat|nested] 256+ messages in thread
* [PATCH v4 4/6] send-email: create email parser subroutine
2016-06-08 13:01 ` (unknown), Samuel GROOT
` (2 preceding siblings ...)
2016-06-08 13:01 ` [PATCH v4 3/6] send-email: shorten send-email's output Samuel GROOT
@ 2016-06-08 13:01 ` Samuel GROOT
2016-06-08 17:58 ` Junio C Hamano
2016-06-08 20:38 ` Eric Wong
2016-06-08 13:07 ` [PATCH v4 5/6] send-email: --in-reply-to=<file> populate header fields Samuel GROOT
2016-06-08 13:08 ` [PATCH v4 6/6] send-email: add option --cite to quote the message body Samuel GROOT
5 siblings, 2 replies; 256+ messages in thread
From: Samuel GROOT @ 2016-06-08 13:01 UTC (permalink / raw)
To: git
Cc: samuel.groot, tom.russello, erwan.mathoniere, jordan.de-gea,
matthieu.moy, gitster, aaron, e
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 <samuel.groot@grenoble-inp.org>
Signed-off-by: Tom RUSSELLO <tom.russello@grenoble-inp.org>
Signed-off-by: Matthieu MOY <matthieu.moy@grenoble-inp.fr>
---
We chose to create our own simple email parser and only use it for the
"quote email" feature to pave the way for the refactorization of the patch
parser [1] that may come after our current school project.
[1] * http://thread.gmane.org/gmane.comp.version-control.git/295752
perl/Git.pm | 34 ++++++++++++++++++++++++++++++++++
1 file changed, 34 insertions(+)
diff --git a/perl/Git.pm b/perl/Git.pm
index ce7e4e8..1af4805 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -865,6 +865,40 @@ sub ident_person {
return "$ident[0] <$ident[1]>";
}
+=item parse_email
+
+Return a hash of email fields extracted from a file handler.
+
+=cut
+
+sub parse_email {
+ my %mail = ();
+ my $fh = shift;
+ my $last_header;
+
+ # Unfold and parse multiline header fields
+ while (<$fh>) {
+ last if /^\s*$/;
+ s/\r\n|\n|\r//;
+ if (/^([^\s:]+):[\s]+(.*)$/) {
+ $last_header = lc($1);
+ @{$mail{$last_header}} = ()
+ unless defined $mail{$last_header};
+ push @{$mail{$last_header}}, $2;
+ } elsif (/^\s+\S/ and defined $last_header) {
+ s/^\s+/ /;
+ push @{$mail{$last_header}}, $_;
+ } else {
+ die("Mail format undefined!\n");
+ }
+ }
+
+ # Separate body from header
+ $mail{"body"} = [(<$fh>)];
+
+ return \%mail;
+}
+
=item parse_mailboxes
Return an array of mailboxes extracted from a string.
--
2.8.2.537.gb153d2a
^ permalink raw reply related [flat|nested] 256+ messages in thread
* Re: [PATCH v4 4/6] send-email: create email parser subroutine
2016-06-08 13:01 ` [PATCH v4 4/6] send-email: create email parser subroutine Samuel GROOT
@ 2016-06-08 17:58 ` Junio C Hamano
2016-06-08 18:12 ` Eric Sunshine
2016-06-08 19:36 ` Samuel GROOT
2016-06-08 20:38 ` Eric Wong
1 sibling, 2 replies; 256+ messages in thread
From: Junio C Hamano @ 2016-06-08 17:58 UTC (permalink / raw)
To: Samuel GROOT
Cc: git, tom.russello, erwan.mathoniere, jordan.de-gea, matthieu.moy,
aaron, e
Samuel GROOT <samuel.groot@grenoble-inp.org> writes:
> +sub parse_email {
> + my %mail = ();
> + my $fh = shift;
> + my $last_header;
> + # Unfold and parse multiline header fields
> + while (<$fh>) {
> + last if /^\s*$/;
You stop at the end of fields before the message body starts.
> + s/\r\n|\n|\r//;
The pattern is not anchored at the right end of the string;
intended? Is it worth worrying about a lone '\r'?
> + if (/^([^\s:]+):[\s]+(.*)$/) {
> + $last_header = lc($1);
> + @{$mail{$last_header}} = ()
> + unless defined $mail{$last_header};
> + push @{$mail{$last_header}}, $2;
> + } elsif (/^\s+\S/ and defined $last_header) {
> + s/^\s+/ /;
> + push @{$mail{$last_header}}, $_;
Even though the comment said "unfold", you do not really do the
unfolding here and the caller can (if it wants to) figure out where
one logical header was folded in the original into multiple physical
lines, because you are returning an arrayref.
However, that means the caller still cannot tell what the original
was if you are given:
X-header: a b
c
X-header: d
as you would return { 'X-header' => ["a b", "c", "d")] }
In that sense, it may be better to do a real unfolding here, so that
it would return { 'X-header' => ["a b c", "d"] } from here instead?
I.e. instead of "push @{...}, $_", append $_ to the last element of
that array?
> + } else {
> + die("Mail format undefined!\n");
What does that mean? It would probably help if you included the
line that the code did not understand in the message.
> + }
> + }
> +
> + # Separate body from header
> + $mail{"body"} = [(<$fh>)];
> +
> + return \%mail;
The name of the local thing is not observable from the caller, but
because this is "parse-email-header" and returns "header fields"
without reading the "mail", perhaps call it %header instead?
> +}
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [PATCH v4 4/6] send-email: create email parser subroutine
2016-06-08 17:58 ` Junio C Hamano
@ 2016-06-08 18:12 ` Eric Sunshine
2016-06-08 18:32 ` Junio C Hamano
2016-06-08 19:30 ` Samuel GROOT
2016-06-08 19:36 ` Samuel GROOT
1 sibling, 2 replies; 256+ messages in thread
From: Eric Sunshine @ 2016-06-08 18:12 UTC (permalink / raw)
To: Junio C Hamano
Cc: Samuel GROOT, Git List, tom.russello, erwan.mathoniere,
jordan.de-gea, Matthieu Moy, aaron, Eric Wong
On Wed, Jun 8, 2016 at 1:58 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Samuel GROOT <samuel.groot@grenoble-inp.org> writes:
>> +sub parse_email {
>> + my %mail = ();
>> + my $fh = shift;
>> + my $last_header;
>
>> + # Unfold and parse multiline header fields
>> + while (<$fh>) {
>> + last if /^\s*$/;
>
> You stop at the end of fields before the message body starts.
>
>> + s/\r\n|\n|\r//;
>
> The pattern is not anchored at the right end of the string;
> intended? Is it worth worrying about a lone '\r'?
Thanks, I think you covered pretty much everything I was going to say.
I'd just add that if the matching is going to be kept loose like this
(rather than anchoring it), then s/[\r\n]+//g might be easier to read,
but it's a minor point.
>> + if (/^([^\s:]+):[\s]+(.*)$/) {
>> + $last_header = lc($1);
>> + @{$mail{$last_header}} = ()
>> + unless defined $mail{$last_header};
>> + push @{$mail{$last_header}}, $2;
>
>> + } elsif (/^\s+\S/ and defined $last_header) {
>> + s/^\s+/ /;
>> + push @{$mail{$last_header}}, $_;
>
> Even though the comment said "unfold", you do not really do the
> unfolding here and the caller can (if it wants to) figure out where
> one logical header was folded in the original into multiple physical
> lines, because you are returning an arrayref.
Also, the comment about folding lines should be moved down the part of
the code which is actually (supposed to be) doing the folding rather
than having the comment at the top of the loop.
> However, that means the caller still cannot tell what the original
> was if you are given:
>
> X-header: a b
> c
> X-header: d
>
> as you would return { 'X-header' => ["a b", "c", "d")] }
>
> In that sense, it may be better to do a real unfolding here, so that
> it would return { 'X-header' => ["a b c", "d"] } from here instead?
>
> I.e. instead of "push @{...}, $_", append $_ to the last element of
> that array?
Right.
>> + # Separate body from header
>> + $mail{"body"} = [(<$fh>)];
>> +
>> + return \%mail;
>
> The name of the local thing is not observable from the caller, but
> because this is "parse-email-header" and returns "header fields"
> without reading the "mail", perhaps call it %header instead?
If there is (for some reason) a mail header named 'body', then this
assignment of the body portion of the message will overwrite it.
Perhaps this function should instead return multiple values: the
header hash, and the message body.
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [PATCH v4 4/6] send-email: create email parser subroutine
2016-06-08 18:12 ` Eric Sunshine
@ 2016-06-08 18:32 ` Junio C Hamano
2016-06-08 19:26 ` Samuel GROOT
2016-06-08 19:30 ` Samuel GROOT
1 sibling, 1 reply; 256+ messages in thread
From: Junio C Hamano @ 2016-06-08 18:32 UTC (permalink / raw)
To: Eric Sunshine
Cc: Samuel GROOT, Git List, tom.russello, erwan.mathoniere,
jordan.de-gea, Matthieu Moy, aaron, Eric Wong
Eric Sunshine <sunshine@sunshineco.com> writes:
>>> + # Separate body from header
>>> + $mail{"body"} = [(<$fh>)];
>>> +
>>> + return \%mail;
>>
>> The name of the local thing is not observable from the caller, but
>> because this is "parse-email-header" and returns "header fields"
>> without reading the "mail", perhaps call it %header instead?
>
> If there is (for some reason) a mail header named 'body', then this
> assignment of the body portion of the message will overwrite it.
> Perhaps this function should instead return multiple values: the
> header hash, and the message body.
Ah, I missed that it is attempting to return the body, too.
Because the function takes an open filehandle, I think it is better
to leave it to the callers. A caller that is only interested in
headers can just close $fh after this helper returns without reading
body that it is not interested in, and a caller that wants to read
the body can do the slurping itself.
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [PATCH v4 4/6] send-email: create email parser subroutine
2016-06-08 18:32 ` Junio C Hamano
@ 2016-06-08 19:26 ` Samuel GROOT
2016-06-08 19:31 ` Junio C Hamano
0 siblings, 1 reply; 256+ messages in thread
From: Samuel GROOT @ 2016-06-08 19:26 UTC (permalink / raw)
To: Junio C Hamano, Eric Sunshine
Cc: Git List, tom.russello, erwan.mathoniere, jordan.de-gea,
Matthieu Moy, aaron, Eric Wong
On 06/08/2016 08:32 PM, Junio C Hamano wrote:
> Eric Sunshine <sunshine@sunshineco.com> writes:
>>>> + # Separate body from header
>>>> + $mail{"body"} = [(<$fh>)];
>>>> +
>>>> + return \%mail;
>>>
>>> The name of the local thing is not observable from the caller, but
>>> because this is "parse-email-header" and returns "header fields"
>>> without reading the "mail", perhaps call it %header instead?
>>
>> If there is (for some reason) a mail header named 'body', then this
>> assignment of the body portion of the message will overwrite it.
>> Perhaps this function should instead return multiple values: the
>> header hash, and the message body.
>
> Ah, I missed that it is attempting to return the body, too.
>
> Because the function takes an open filehandle, I think it is better
> to leave it to the callers. A caller that is only interested in
> headers can just close $fh after this helper returns without reading
> body that it is not interested in, and a caller that wants to read
> the body can do the slurping itself.
I think it's the best way to do it indeed. Furthermore, we did trim CRs
and LFs in header fields, but not in the message, making the subroutine
inconsistent.
Should we rename the subroutine to `parse_header` or leave it as it is?
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [PATCH v4 4/6] send-email: create email parser subroutine
2016-06-08 19:26 ` Samuel GROOT
@ 2016-06-08 19:31 ` Junio C Hamano
2016-06-08 19:42 ` Samuel GROOT
0 siblings, 1 reply; 256+ messages in thread
From: Junio C Hamano @ 2016-06-08 19:31 UTC (permalink / raw)
To: Samuel GROOT
Cc: Eric Sunshine, Git List, tom.russello, erwan.mathoniere,
jordan.de-gea, Matthieu Moy, aaron, Eric Wong
Samuel GROOT <samuel.groot@grenoble-inp.org> writes:
> I think it's the best way to do it indeed. Furthermore, we did trim
> CRs and LFs in header fields, but not in the message, making the
> subroutine inconsistent.
>
> Should we rename the subroutine to `parse_header` or leave it as it is?
If it lives inside git-send-email, then parse_header is sufficient
as everybody would know it is about e-mail without being told. If
it is in Git.pm, then parse_email_header would be more appropriate.
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [PATCH v4 4/6] send-email: create email parser subroutine
2016-06-08 19:31 ` Junio C Hamano
@ 2016-06-08 19:42 ` Samuel GROOT
0 siblings, 0 replies; 256+ messages in thread
From: Samuel GROOT @ 2016-06-08 19:42 UTC (permalink / raw)
To: Junio C Hamano
Cc: Eric Sunshine, Git List, tom.russello, erwan.mathoniere,
jordan.de-gea, Matthieu Moy, aaron, Eric Wong
On 06/08/2016 09:31 PM, Junio C Hamano wrote:
> Samuel GROOT <samuel.groot@grenoble-inp.org> writes:
>
>> I think it's the best way to do it indeed. Furthermore, we did trim
>> CRs and LFs in header fields, but not in the message, making the
>> subroutine inconsistent.
>>
>> Should we rename the subroutine to `parse_header` or leave it as it is?
>
> If it lives inside git-send-email, then parse_header is sufficient
> as everybody would know it is about e-mail without being told. If
> it is in Git.pm, then parse_email_header would be more appropriate.
It currently lives in Git.pm, following Eric Wong's advice to have a
more packaged code.
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [PATCH v4 4/6] send-email: create email parser subroutine
2016-06-08 18:12 ` Eric Sunshine
2016-06-08 18:32 ` Junio C Hamano
@ 2016-06-08 19:30 ` Samuel GROOT
2016-06-08 20:13 ` Eric Sunshine
1 sibling, 1 reply; 256+ messages in thread
From: Samuel GROOT @ 2016-06-08 19:30 UTC (permalink / raw)
To: Eric Sunshine, Junio C Hamano
Cc: Git List, tom.russello, erwan.mathoniere, jordan.de-gea,
Matthieu Moy, aaron, Eric Wong
On 06/08/2016 08:12 PM, Eric Sunshine wrote:
> On Wed, Jun 8, 2016 at 1:58 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Samuel GROOT <samuel.groot@grenoble-inp.org> writes:
>>> +sub parse_email {
>>> + my %mail = ();
>>> + my $fh = shift;
>>> + my $last_header;
>>
>>> + # Unfold and parse multiline header fields
>>> + while (<$fh>) {
>>> + last if /^\s*$/;
>>
>> You stop at the end of fields before the message body starts.
>>
>>> + s/\r\n|\n|\r//;
>>
>> The pattern is not anchored at the right end of the string;
>> intended? Is it worth worrying about a lone '\r'?
>
> Thanks, I think you covered pretty much everything I was going to say.
> I'd just add that if the matching is going to be kept loose like this
> (rather than anchoring it), then s/[\r\n]+//g might be easier to read,
> but it's a minor point.
Indeed s/[\r\n]+//g is way better, it works even if there's a CR in the
middle of the line.
>>> + if (/^([^\s:]+):[\s]+(.*)$/) {
>>> + $last_header = lc($1);
>>> + @{$mail{$last_header}} = ()
>>> + unless defined $mail{$last_header};
>>> + push @{$mail{$last_header}}, $2;
>>
>>> + } elsif (/^\s+\S/ and defined $last_header) {
>>> + s/^\s+/ /;
>>> + push @{$mail{$last_header}}, $_;
>>
>> Even though the comment said "unfold", you do not really do the
>> unfolding here and the caller can (if it wants to) figure out where
>> one logical header was folded in the original into multiple physical
>> lines, because you are returning an arrayref.
>
> Also, the comment about folding lines should be moved down the part of
> the code which is actually (supposed to be) doing the folding rather
> than having the comment at the top of the loop.
Will do in next re-roll.
>>> + # Separate body from header
>>> + $mail{"body"} = [(<$fh>)];
>>> +
>>> + return \%mail;
>>
>> The name of the local thing is not observable from the caller, but
>> because this is "parse-email-header" and returns "header fields"
>> without reading the "mail", perhaps call it %header instead?
>
> If there is (for some reason) a mail header named 'body', then this
> assignment of the body portion of the message will overwrite it.
> Perhaps this function should instead return multiple values: the
> header hash, and the message body.
I will drop the body part in re-roll.
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [PATCH v4 4/6] send-email: create email parser subroutine
2016-06-08 19:30 ` Samuel GROOT
@ 2016-06-08 20:13 ` Eric Sunshine
2016-06-08 20:17 ` Junio C Hamano
0 siblings, 1 reply; 256+ messages in thread
From: Eric Sunshine @ 2016-06-08 20:13 UTC (permalink / raw)
To: Samuel GROOT
Cc: Junio C Hamano, Git List, tom.russello, erwan.mathoniere,
jordan.de-gea, Matthieu Moy, aaron, Eric Wong
On Wed, Jun 8, 2016 at 3:30 PM, Samuel GROOT
<samuel.groot@grenoble-inp.org> wrote:
> On 06/08/2016 08:12 PM, Eric Sunshine wrote:
>> On Wed, Jun 8, 2016 at 1:58 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Samuel GROOT <samuel.groot@grenoble-inp.org> writes:
>>> The pattern is not anchored at the right end of the string;
>>> intended? Is it worth worrying about a lone '\r'?
>>
>> Thanks, I think you covered pretty much everything I was going to say.
>> I'd just add that if the matching is going to be kept loose like this
>> (rather than anchoring it), then s/[\r\n]+//g might be easier to read,
>> but it's a minor point.
>
> Indeed s/[\r\n]+//g is way better, it works even if there's a CR in the
> middle of the line.
An embedded CR probably shouldn't happen, but I'm not convinced that
folding it out is a good idea. I would think that you'd want to
preserve the header's value verbatim. If anything, I'd expect to see
the regex tightened to:
s/\r?\n$//;
Alternately, consider using 'chop' or 'chomp'.
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [PATCH v4 4/6] send-email: create email parser subroutine
2016-06-08 20:13 ` Eric Sunshine
@ 2016-06-08 20:17 ` Junio C Hamano
2016-06-08 23:54 ` Samuel GROOT
0 siblings, 1 reply; 256+ messages in thread
From: Junio C Hamano @ 2016-06-08 20:17 UTC (permalink / raw)
To: Eric Sunshine
Cc: Samuel GROOT, Git List, tom.russello, erwan.mathoniere,
jordan.de-gea, Matthieu Moy, aaron, Eric Wong
Eric Sunshine <sunshine@sunshineco.com> writes:
> An embedded CR probably shouldn't happen, but I'm not convinced that
> folding it out is a good idea. I would think that you'd want to
> preserve the header's value verbatim. If anything, I'd expect to see
> the regex tightened to:
>
> s/\r?\n$//;
Yes, that would be more sensible than silently removing \r in the
middle which _is_ a sign of something funny going on.
> Alternately, consider using 'chop' or 'chomp'.
Even if you use chomp(), you'd still need to worry about possible \r
at the end, no?
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [PATCH v4 4/6] send-email: create email parser subroutine
2016-06-08 20:17 ` Junio C Hamano
@ 2016-06-08 23:54 ` Samuel GROOT
2016-06-09 0:21 ` Eric Wong
2016-06-09 6:51 ` Eric Sunshine
0 siblings, 2 replies; 256+ messages in thread
From: Samuel GROOT @ 2016-06-08 23:54 UTC (permalink / raw)
To: Junio C Hamano, Eric Sunshine
Cc: Git List, tom.russello, erwan.mathoniere, jordan.de-gea,
Matthieu Moy, aaron, Eric Wong
On 06/08/2016 10:17 PM, Junio C Hamano wrote:
> Eric Sunshine <sunshine@sunshineco.com> writes:
>
>> An embedded CR probably shouldn't happen, but I'm not convinced that
>> folding it out is a good idea. I would think that you'd want to
>> preserve the header's value verbatim. If anything, I'd expect to see
>> the regex tightened to:
>>
>> s/\r?\n$//;
>
> Yes, that would be more sensible than silently removing \r in the
> middle which _is_ a sign of something funny going on.
>> Alternately, consider using 'chop' or 'chomp'.
>
> Even if you use chomp(), you'd still need to worry about possible \r
> at the end, no?
'chomp' is what we used before, but with *.eml files (microsoft's file
format, with CRLF), '\n' were removed but '\r' remained, that's why we
used s/\r\n|\r|\n//.
s/\r?\n$// looks fine.
Email::Simple library uses qr/\x0a\x0d|\x0d\x0a|\x0a|\x0d/ [1]. Should
we handle \n\r at end of line as well?
[1] *
http://cpansearch.perl.org/src/RJBS/Email-Simple-2.210/lib/Email/Simple.pm
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [PATCH v4 4/6] send-email: create email parser subroutine
2016-06-08 23:54 ` Samuel GROOT
@ 2016-06-09 0:21 ` Eric Wong
2016-06-13 22:18 ` Samuel GROOT
2016-06-09 6:51 ` Eric Sunshine
1 sibling, 1 reply; 256+ messages in thread
From: Eric Wong @ 2016-06-09 0:21 UTC (permalink / raw)
To: Samuel GROOT
Cc: Junio C Hamano, Eric Sunshine, Git List, tom.russello,
erwan.mathoniere, jordan.de-gea, Matthieu Moy, aaron
Samuel GROOT <samuel.groot@grenoble-inp.org> wrote:
> Email::Simple library uses qr/\x0a\x0d|\x0d\x0a|\x0a|\x0d/ [1].
> Should we handle \n\r at end of line as well?
"\n\r" can never happen with local $/ = "\n"
> [1] * http://cpansearch.perl.org/src/RJBS/Email-Simple-2.210/lib/Email/Simple.pm
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [PATCH v4 4/6] send-email: create email parser subroutine
2016-06-09 0:21 ` Eric Wong
@ 2016-06-13 22:18 ` Samuel GROOT
2016-06-13 22:47 ` Eric Wong
0 siblings, 1 reply; 256+ messages in thread
From: Samuel GROOT @ 2016-06-13 22:18 UTC (permalink / raw)
To: Eric Wong
Cc: Junio C Hamano, Eric Sunshine, Git List, tom.russello,
erwan.mathoniere, jordan.de-gea, Matthieu Moy, aaron
On 06/09/2016 02:21 AM, Eric Wong wrote:
> Samuel GROOT <samuel.groot@grenoble-inp.org> wrote:
>> Email::Simple library uses qr/\x0a\x0d|\x0d\x0a|\x0a|\x0d/ [1].
>> Should we handle \n\r at end of line as well?
>
> "\n\r" can never happen with local $/ = "\n"
If the email file contains "\n\r", setting $/ = "\n" will leave "\r" at
the beginning of each line.
We could trim them with:
s/^\r//;
s/\r?\n$//;
But is it worth adding `s/^\r//;` to handle that extremely rare case?
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [PATCH v4 4/6] send-email: create email parser subroutine
2016-06-13 22:18 ` Samuel GROOT
@ 2016-06-13 22:47 ` Eric Wong
2016-06-14 22:18 ` Samuel GROOT
0 siblings, 1 reply; 256+ messages in thread
From: Eric Wong @ 2016-06-13 22:47 UTC (permalink / raw)
To: Samuel GROOT
Cc: Junio C Hamano, Eric Sunshine, Git List, tom.russello,
erwan.mathoniere, jordan.de-gea, Matthieu Moy, aaron
Samuel GROOT <samuel.groot@grenoble-inp.org> wrote:
> On 06/09/2016 02:21 AM, Eric Wong wrote:
> >Samuel GROOT <samuel.groot@grenoble-inp.org> wrote:
> >>Email::Simple library uses qr/\x0a\x0d|\x0d\x0a|\x0a|\x0d/ [1].
> >>Should we handle \n\r at end of line as well?
> >
> >"\n\r" can never happen with local $/ = "\n"
>
> If the email file contains "\n\r", setting $/ = "\n" will leave "\r" at
> the beginning of each line.
>
> We could trim them with:
>
> s/^\r//;
> s/\r?\n$//;
>
> But is it worth adding `s/^\r//;` to handle that extremely rare case?
I doubt it. Having a "\r" in the wrong place is likely a bug in
whatever program that generated the email. It should be exposed
so whoever generated that email has a chance to fix it on their
end rather than being quietly hidden.
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [PATCH v4 4/6] send-email: create email parser subroutine
2016-06-13 22:47 ` Eric Wong
@ 2016-06-14 22:18 ` Samuel GROOT
0 siblings, 0 replies; 256+ messages in thread
From: Samuel GROOT @ 2016-06-14 22:18 UTC (permalink / raw)
To: Eric Wong
Cc: Junio C Hamano, Eric Sunshine, Git List, tom.russello,
erwan.mathoniere, jordan.de-gea, Matthieu Moy, aaron
On 06/14/2016 12:47 AM, Eric Wong wrote:
> Samuel GROOT <samuel.groot@grenoble-inp.org> wrote:
>> On 06/09/2016 02:21 AM, Eric Wong wrote:
>>> Samuel GROOT <samuel.groot@grenoble-inp.org> wrote:
>>>> Email::Simple library uses qr/\x0a\x0d|\x0d\x0a|\x0a|\x0d/ [1].
>>>> Should we handle \n\r at end of line as well?
>>>
>>> "\n\r" can never happen with local $/ = "\n"
>>
>> If the email file contains "\n\r", setting $/ = "\n" will leave "\r" at
>> the beginning of each line.
>>
>> We could trim them with:
>>
>> s/^\r//;
>> s/\r?\n$//;
>>
>> But is it worth adding `s/^\r//;` to handle that extremely rare case?
>
> I doubt it. Having a "\r" in the wrong place is likely a bug in
> whatever program that generated the email. It should be exposed
> so whoever generated that email has a chance to fix it on their
> end rather than being quietly hidden.
s/\r?\n$// is fine then.
Thanks.
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [PATCH v4 4/6] send-email: create email parser subroutine
2016-06-08 23:54 ` Samuel GROOT
2016-06-09 0:21 ` Eric Wong
@ 2016-06-09 6:51 ` Eric Sunshine
2016-06-13 22:15 ` Samuel GROOT
1 sibling, 1 reply; 256+ messages in thread
From: Eric Sunshine @ 2016-06-09 6:51 UTC (permalink / raw)
To: Samuel GROOT
Cc: Junio C Hamano, Git List, tom.russello, erwan.mathoniere,
jordan.de-gea, Matthieu Moy, aaron, Eric Wong
On Wed, Jun 8, 2016 at 7:54 PM, Samuel GROOT
<samuel.groot@grenoble-inp.org> wrote:
> On 06/08/2016 10:17 PM, Junio C Hamano wrote:
>> Eric Sunshine <sunshine@sunshineco.com> writes:
>>> An embedded CR probably shouldn't happen, but I'm not convinced that
>>> folding it out is a good idea. I would think that you'd want to
>>> preserve the header's value verbatim. If anything, I'd expect to see
>>> the regex tightened to:
>>>
>>> s/\r?\n$//;
>>
>> Yes, that would be more sensible than silently removing \r in the
>> middle which _is_ a sign of something funny going on.
>
> s/\r?\n$// looks fine.
>
> Email::Simple library uses qr/\x0a\x0d|\x0d\x0a|\x0a|\x0d/ [1].
> [1] * http://cpansearch.perl.org/src/RJBS/Email-Simple-2.210/lib/Email/Simple.pm
You could certainly use s/\x0d?\x0a$// rather than s/\r?\n$// to be
really robust, but I doubt it matters much today. The reason for using
hex codes is that \r and \n will resolve to CR and LF in the local
character encoding, and those may not be 0x0d and 0x0a, respectively.
I believe the canonical example given in the Camel book was EBCIDIC in
which \r is 0x0d, but \n is 0x25, not 0x0a as it is in ASCII.
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [PATCH v4 4/6] send-email: create email parser subroutine
2016-06-09 6:51 ` Eric Sunshine
@ 2016-06-13 22:15 ` Samuel GROOT
0 siblings, 0 replies; 256+ messages in thread
From: Samuel GROOT @ 2016-06-13 22:15 UTC (permalink / raw)
To: Eric Sunshine
Cc: Junio C Hamano, Git List, tom.russello, erwan.mathoniere,
jordan.de-gea, Matthieu Moy, aaron, Eric Wong
On 06/09/2016 08:51 AM, Eric Sunshine wrote:
> On Wed, Jun 8, 2016 at 7:54 PM, Samuel GROOT
> <samuel.groot@grenoble-inp.org> wrote:
>> On 06/08/2016 10:17 PM, Junio C Hamano wrote:
>>> Eric Sunshine <sunshine@sunshineco.com> writes:
>>>> An embedded CR probably shouldn't happen, but I'm not convinced that
>>>> folding it out is a good idea. I would think that you'd want to
>>>> preserve the header's value verbatim. If anything, I'd expect to see
>>>> the regex tightened to:
>>>>
>>>> s/\r?\n$//;
>>>
>>> Yes, that would be more sensible than silently removing \r in the
>>> middle which _is_ a sign of something funny going on.
>>
>> s/\r?\n$// looks fine.
>>
>> Email::Simple library uses qr/\x0a\x0d|\x0d\x0a|\x0a|\x0d/ [1].
>> [1] * http://cpansearch.perl.org/src/RJBS/Email-Simple-2.210/lib/Email/Simple.pm
>
> You could certainly use s/\x0d?\x0a$// rather than s/\r?\n$// to be
> really robust, but I doubt it matters much today. The reason for using
> hex codes is that \r and \n will resolve to CR and LF in the local
> character encoding, and those may not be 0x0d and 0x0a, respectively.
> I believe the canonical example given in the Camel book was EBCIDIC in
> which \r is 0x0d, but \n is 0x25, not 0x0a as it is in ASCII.
My question was more about the `\n\r` case handled by Email::Simple,
does it make sense to handle it?
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [PATCH v4 4/6] send-email: create email parser subroutine
2016-06-08 17:58 ` Junio C Hamano
2016-06-08 18:12 ` Eric Sunshine
@ 2016-06-08 19:36 ` Samuel GROOT
1 sibling, 0 replies; 256+ messages in thread
From: Samuel GROOT @ 2016-06-08 19:36 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, tom.russello, erwan.mathoniere, jordan.de-gea, matthieu.moy,
aaron, e
On 06/08/2016 07:58 PM, Junio C Hamano wrote:
> Samuel GROOT <samuel.groot@grenoble-inp.org> writes:
>> +sub parse_email {
>> + my %mail = ();
>> + my $fh = shift;
>> + my $last_header;
>
>> + # Unfold and parse multiline header fields
>> + while (<$fh>) {
>> + last if /^\s*$/;
>
> You stop at the end of fields before the message body starts.
>
>> + s/\r\n|\n|\r//;
>
> The pattern is not anchored at the right end of the string;
> intended? Is it worth worrying about a lone '\r'?
A lone '\r' shouldn't happen, but we are never too careful. It's fixed
with what Eric suggested.
>> + if (/^([^\s:]+):[\s]+(.*)$/) {
>> + $last_header = lc($1);
>> + @{$mail{$last_header}} = ()
>> + unless defined $mail{$last_header};
>> + push @{$mail{$last_header}}, $2;
>
>> + } elsif (/^\s+\S/ and defined $last_header) {
>> + s/^\s+/ /;
>> + push @{$mail{$last_header}}, $_;
>
> Even though the comment said "unfold", you do not really do the
> unfolding here and the caller can (if it wants to) figure out where
> one logical header was folded in the original into multiple physical
> lines, because you are returning an arrayref.
>
> However, that means the caller still cannot tell what the original
> was if you are given:
>
> X-header: a b
> c
> X-header: d
>
> as you would return { 'X-header' => ["a b", "c", "d")] }
>
> In that sense, it may be better to do a real unfolding here, so that
> it would return { 'X-header' => ["a b c", "d"] } from here instead?
>
> I.e. instead of "push @{...}, $_", append $_ to the last element of
> that array?
I will do that. It makes more sense regarding Subject split into several
lines, for example.
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [PATCH v4 4/6] send-email: create email parser subroutine
2016-06-08 13:01 ` [PATCH v4 4/6] send-email: create email parser subroutine Samuel GROOT
2016-06-08 17:58 ` Junio C Hamano
@ 2016-06-08 20:38 ` Eric Wong
1 sibling, 0 replies; 256+ messages in thread
From: Eric Wong @ 2016-06-08 20:38 UTC (permalink / raw)
To: Samuel GROOT
Cc: git, tom.russello, erwan.mathoniere, jordan.de-gea, matthieu.moy,
gitster, aaron, Eric Sunshine
Samuel GROOT <samuel.groot@grenoble-inp.org> wrote:
> +++ b/perl/Git.pm
> +sub parse_email {
> + my %mail = ();
> + my $fh = shift;
> + my $last_header;
> +
> + # Unfold and parse multiline header fields
When you libify, I suggest you localize $/ since $/
may be set to something other than "\n" by a caller
and change the behavior of <$fh> and $fh->getline.
local $/ = "\n";
> + while (<$fh>) {
> + last if /^\s*$/;
> + s/\r\n|\n|\r//;
And, as Eric Sunshine stated:
s/\r?\n$//;
Explicitly localizing $/ means you wouldn't have to worry about
multiple \n showing up in the line, either.
And chomp/chop wouldn't work, here.
Otherwise I like the move to Git.pm, thanks.
^ permalink raw reply [flat|nested] 256+ messages in thread
* [PATCH v4 5/6] send-email: --in-reply-to=<file> populate header fields
2016-06-08 13:01 ` (unknown), Samuel GROOT
` (3 preceding siblings ...)
2016-06-08 13:01 ` [PATCH v4 4/6] send-email: create email parser subroutine Samuel GROOT
@ 2016-06-08 13:07 ` Samuel GROOT
2016-06-08 18:23 ` Junio C Hamano
2016-06-09 9:45 ` Matthieu Moy
2016-06-08 13:08 ` [PATCH v4 6/6] send-email: add option --cite to quote the message body Samuel GROOT
5 siblings, 2 replies; 256+ messages in thread
From: Samuel GROOT @ 2016-06-08 13:07 UTC (permalink / raw)
To: git
Cc: samuel.groot, tom.russello, erwan.mathoniere, jordan.de-gea,
matthieu.moy, gitster, aaron, e
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: [<email_file>'s subject]` in the introductory message.
Signed-off-by: Tom RUSSELLO <tom.russello@grenoble-inp.org>
Signed-off-by: Samuel GROOT <samuel.groot@grenoble-inp.org>
Signed-off-by: Matthieu MOY <matthieu.moy@grenoble-inp.fr>
---
Documentation/git-send-email.txt | 9 +++--
git-send-email.perl | 51 +++++++++++++++++++++++-
t/t9001-send-email.sh | 83 ++++++++++++++++++++++++++++++++++++++++
3 files changed, 138 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index edbba3a..21776f0 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -84,13 +84,16 @@ See the CONFIGURATION section for 'sendemail.multiEdit'.
the value of GIT_AUTHOR_IDENT, or GIT_COMMITTER_IDENT if that is not
set, as returned by "git var -l".
---in-reply-to=<identifier>::
+--in-reply-to=<Message-Id|email_file>::
Make the first mail (or all the mails with `--no-thread`) appear as a
- reply to the given Message-Id, which avoids breaking threads to
- provide a new patch series.
+ reply to the given Message-Id (given directly by argument or via the email
+ file), which avoids breaking threads to provide a new patch series.
The second and subsequent emails will be sent as replies according to
the `--[no]-chain-reply-to` setting.
+
+Furthermore, if the argument is an email file, parse it and populate header
+fields appropriately for the reply.
++
So for example when `--thread` and `--no-chain-reply-to` are specified, the
second and subsequent patches will be replies to the first one like in the
illustration below where `[PATCH v2 0/3]` is in reply to `[PATCH 0/2]`:
diff --git a/git-send-email.perl b/git-send-email.perl
index 9b51062..b444ea6 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -55,6 +55,7 @@ git send-email --dump-aliases
--[no-]bcc <str> * Email Bcc:
--subject <str> * Email "Subject:"
--in-reply-to <str> * Email "In-Reply-To:"
+ --in-reply-to <file> * Populate header fields appropriately.
--[no-]xmailer * Add "X-Mailer:" header (default).
--[no-]annotate * Review each patch that will be sent in an editor.
--compose * Open an editor for introduction.
@@ -160,7 +161,7 @@ my $re_encoded_word = qr/=\?($re_token)\?($re_token)\?($re_encoded_text)\?=/;
# Variables we fill in automatically, or via prompting:
my (@to,$no_to,@initial_to,@cc,$no_cc,@initial_cc,@bcclist,$no_bcc,@xh,
- $initial_reply_to,$initial_subject,@files,
+ $initial_reply_to,$initial_references,$initial_subject,@files,
$author,$sender,$smtp_authpass,$annotate,$use_xmailer,$compose,$time);
my $envelope_sender;
@@ -639,6 +640,52 @@ if (@files) {
usage();
}
+if ($initial_reply_to && -f $initial_reply_to) {
+ my $error = validate_patch($initial_reply_to);
+ die "fatal: $initial_reply_to: $error\nwarning: no patches were sent\n"
+ if $error;
+
+ open my $fh, "<", $initial_reply_to or die "can't open file $initial_reply_to";
+ my $mail = Git::parse_email($fh);
+ close $fh;
+
+ my $initial_sender = $sender || $repoauthor || $repocommitter || '';
+
+ my $prefix_re = "";
+ my $subject_re = $mail->{"subject"}[0];
+ if ($subject_re =~ /^[^Re:]/) {
+ $prefix_re = "Re: ";
+ }
+ $initial_subject = $prefix_re . $subject_re;
+
+ push @initial_to, $mail->{"from"}[0];
+
+ foreach my $to_addr (parse_address_line(join ",", @{$mail->{"to"}})) {
+ if (!($to_addr eq $initial_sender)) {
+ push @initial_cc, $to_addr;
+ }
+ }
+
+ if (defined $mail->{"cc"}) {
+ foreach my $cc_addr (parse_address_line(join ",", @{$mail->{"cc"}})) {
+ my $qaddr = unquote_rfc2047($cc_addr);
+ my $saddr = sanitize_address($qaddr);
+ if ($saddr eq $initial_sender) {
+ next if ($suppress_cc{'self'});
+ } else {
+ next if ($suppress_cc{'cc'});
+ }
+ push @initial_cc, $cc_addr;
+ }
+ }
+
+ $initial_reply_to = $mail->{"message-id"}[0];
+ if ($mail->{"references"}) {
+ $initial_references = join("", @{$mail->{"references"}}) .
+ " " . $initial_reply_to;
+ }
+}
+
sub get_patch_subject {
my $fn = shift;
open (my $fh, '<', $fn);
@@ -1426,7 +1473,7 @@ Message-Id: $message_id
}
$reply_to = $initial_reply_to;
-$references = $initial_reply_to || '';
+$references = $initial_references || $initial_reply_to || '';
$subject = $initial_subject;
$message_num = 0;
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index aca7d5c..7591342 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -1892,4 +1892,87 @@ test_expect_success $PREREQ 'leading and trailing whitespaces are removed' '
test_cmp expected-list actual-list
'
+test_expect_success $PREREQ 'setup expect' '
+ cat >email <<-\EOF
+ Subject: subject goes here
+ From: author@example.com
+ To: to1@example.com
+ Cc: cc1@example.com, cc2@example.com,
+ cc3@example.com
+ Date: Sat, 12 Jun 2010 15:53:58 +0200
+ Message-Id: <author_123456@example.com>
+ References: <firstauthor_654321@example.com>
+ <secondauthor_01546567@example.com>
+ <thirdauthor_1395838@example.com>
+
+ Have you seen my previous email?
+ > Previous content
+ EOF
+'
+
+test_expect_success $PREREQ 'Fields with --in-reply-to are correct' '
+ clean_fake_sendmail &&
+ git send-email \
+ --in-reply-to=email \
+ --from="Example <nobody@example.com>" \
+ --smtp-server="$(pwd)/fake.sendmail" \
+ -2 \
+ 2>errors &&
+ grep "From: Example <nobody@example.com>" msgtxt1 &&
+ grep "In-Reply-To: <author_123456@example.com>" msgtxt1 &&
+ to_adr=$(awk "/^To: /{flag=1}/^Cc: /{flag=0} flag {print}" msgtxt1) &&
+ cc_adr=$(awk "/^Cc: /{flag=1}/^Subject: /{flag=0} flag {print}" msgtxt1) &&
+ ref_adr=$(awk "/^References: /{flag=1}/^MIME-Version: /{flag=0} flag {print}" \
+ msgtxt1) &&
+ echo "$to_adr" | grep author@example.com &&
+ echo "$cc_adr" | grep to1@example.com &&
+ echo "$cc_adr" | grep cc1@example.com &&
+ echo "$cc_adr" | grep cc2@example.com &&
+ echo "$cc_adr" | grep cc3@example.com &&
+ echo "$ref_adr" | grep "<firstauthor_654321@example.com>" &&
+ echo "$ref_adr" | grep "<secondauthor_01546567@example.com>" &&
+ echo "$ref_adr" | grep "<thirdauthor_1395838@example.com>" &&
+ echo "$ref_adr" | grep "<author_123456@example.com>" &&
+ echo "$ref_adr" | grep -v "References: <author_123456@example.com>"
+'
+
+test_expect_success $PREREQ 'Fields with --in-reply-to and --compose are correct' '
+ clean_fake_sendmail &&
+ git send-email \
+ --in-reply-to=email \
+ --compose \
+ --from="Example <nobody@example.com>" \
+ --smtp-server="$(pwd)/fake.sendmail" \
+ -1 \
+ 2>errors &&
+ grep "From: Example <nobody@example.com>" msgtxt1 &&
+ grep "In-Reply-To: <author_123456@example.com>" msgtxt1 &&
+ grep "Subject: Re: subject goes here" msgtxt1 &&
+ to_adr=$(awk "/^To: /{flag=1}/^Cc: /{flag=0} flag {print}" msgtxt1) &&
+ cc_adr=$(awk "/^Cc: /{flag=1}/^Subject: /{flag=0} flag {print}" msgtxt1) &&
+ ref_adr=$(awk "/^References: /{flag=1}/^MIME-Version: /{flag=0} flag {print}" \
+ msgtxt1) &&
+ echo "$to_adr" | grep author@example.com &&
+ echo "$cc_adr" | grep to1@example.com &&
+ echo "$cc_adr" | grep cc1@example.com &&
+ echo "$cc_adr" | grep cc2@example.com &&
+ echo "$cc_adr" | grep cc3@example.com &&
+ echo "$ref_adr" | grep "<firstauthor_654321@example.com>" &&
+ echo "$ref_adr" | grep "<secondauthor_01546567@example.com>" &&
+ echo "$ref_adr" | grep "<thirdauthor_1395838@example.com>" &&
+ echo "$ref_adr" | grep "<author_123456@example.com>" &&
+ echo "$ref_adr" | grep -v "References: <author_123456@example.com>"
+'
+
+test_expect_success $PREREQ 'Re: written only once with --in-reply-to and --compose ' '
+ git send-email \
+ --in-reply-to=msgtxt1 \
+ --compose \
+ --from="Example <nobody@example.com>" \
+ --smtp-server="$(pwd)/fake.sendmail" \
+ -1 \
+ 2>errors &&
+ grep "Subject: Re: subject goes here" msgtxt3
+'
+
test_done
--
2.8.2.537.gb153d2a
^ permalink raw reply related [flat|nested] 256+ messages in thread
* Re: [PATCH v4 5/6] send-email: --in-reply-to=<file> populate header fields
2016-06-08 13:07 ` [PATCH v4 5/6] send-email: --in-reply-to=<file> populate header fields Samuel GROOT
@ 2016-06-08 18:23 ` Junio C Hamano
2016-06-14 22:26 ` Samuel GROOT
2016-06-09 9:45 ` Matthieu Moy
1 sibling, 1 reply; 256+ messages in thread
From: Junio C Hamano @ 2016-06-08 18:23 UTC (permalink / raw)
To: Samuel GROOT
Cc: git, tom.russello, erwan.mathoniere, jordan.de-gea, matthieu.moy,
aaron, e
Samuel GROOT <samuel.groot@grenoble-inp.org> writes:
> +if ($initial_reply_to && -f $initial_reply_to) {
> + my $error = validate_patch($initial_reply_to);
This call is wrong, isn't it?
You are not going to send out the message you are responding to (the
message may not even be a patch), and you do not want to die with an
error message that says "patch contains an overlong line".
> + die "fatal: $initial_reply_to: $error\nwarning: no patches were sent\n"
> + if $error;
> +
> + open my $fh, "<", $initial_reply_to or die "can't open file $initial_reply_to";
> + my $mail = Git::parse_email($fh);
> + close $fh;
my $header = Git::parse_email_header($fh);
perhaps?
> + my $initial_sender = $sender || $repoauthor || $repocommitter || '';
> +
> + my $prefix_re = "";
> + my $subject_re = $mail->{"subject"}[0];
> + if ($subject_re =~ /^[^Re:]/) {
> + $prefix_re = "Re: ";
> + }
> + $initial_subject = $prefix_re . $subject_re;
I am not sure what the significance of the fact that the subject
happens to begin with a letter other than 'R', 'e', or ':'.
Did you mean to do something like this instead?
my $subject = $mail->{"subject"}[0];
$subject =~ s/^(re:\s*)+//i; # strip "Re: Re: ..."
$initial_subject = "Re: $subject";
instead?
By the way, this is a good example why your "unfold" implementation
in 4/6 is unwieldy for the caller. Imagine a rather long subject
that is folded, i.e.
To: Samuel
Subject: Help! I am having a trouble running git-send-email
correctly.
Message-id: <...>
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [PATCH v4 5/6] send-email: --in-reply-to=<file> populate header fields
2016-06-08 18:23 ` Junio C Hamano
@ 2016-06-14 22:26 ` Samuel GROOT
0 siblings, 0 replies; 256+ messages in thread
From: Samuel GROOT @ 2016-06-14 22:26 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, tom.russello, erwan.mathoniere, jordan.de-gea, matthieu.moy,
aaron, e
On 06/08/2016 08:23 PM, Junio C Hamano wrote:
> Samuel GROOT <samuel.groot@grenoble-inp.org> writes:
>
>> +if ($initial_reply_to && -f $initial_reply_to) {
>> + my $error = validate_patch($initial_reply_to);
>
> This call is wrong, isn't it?
>
> You are not going to send out the message you are responding to (the
> message may not even be a patch), and you do not want to die with an
> error message that says "patch contains an overlong line".
We used to handle email files like patch files (with Cc:, To:, From:,
... fields, a patch is almost an email, with some trailers).
But that `validate_patch` subroutine call is indeed useless here, I will
remove it.
>> + die "fatal: $initial_reply_to: $error\nwarning: no patches were sent\n"
>> + if $error;
>> +
>> + open my $fh, "<", $initial_reply_to or die "can't open file $initial_reply_to";
>> + my $mail = Git::parse_email($fh);
>> + close $fh;
>
> my $header = Git::parse_email_header($fh);
>
> perhaps?
Git::parse_email will be renamed into Git::parse_email_header in v5.
>> + my $initial_sender = $sender || $repoauthor || $repocommitter || '';
>> +
>> + my $prefix_re = "";
>> + my $subject_re = $mail->{"subject"}[0];
>> + if ($subject_re =~ /^[^Re:]/) {
>> + $prefix_re = "Re: ";
>> + }
>> + $initial_subject = $prefix_re . $subject_re;
>
> I am not sure what the significance of the fact that the subject
> happens to begin with a letter other than 'R', 'e', or ':'.
>
> Did you mean to do something like this instead?
>
> my $subject = $mail->{"subject"}[0];
> $subject =~ s/^(re:\s*)+//i; # strip "Re: Re: ..."
> $initial_subject = "Re: $subject";
>
> instead?
That's way cleaner, thanks!
> By the way, this is a good example why your "unfold" implementation
> in 4/6 is unwieldy for the caller. Imagine a rather long subject
> that is folded, i.e.
>
> To: Samuel
> Subject: Help! I am having a trouble running git-send-email
> correctly.
> Message-id: <...>
It's a good point. What you suggested in 4/6 reply will be used in v5.
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [PATCH v4 5/6] send-email: --in-reply-to=<file> populate header fields
2016-06-08 13:07 ` [PATCH v4 5/6] send-email: --in-reply-to=<file> populate header fields Samuel GROOT
2016-06-08 18:23 ` Junio C Hamano
@ 2016-06-09 9:45 ` Matthieu Moy
2016-06-14 22:35 ` Samuel GROOT
1 sibling, 1 reply; 256+ messages in thread
From: Matthieu Moy @ 2016-06-09 9:45 UTC (permalink / raw)
To: Samuel GROOT
Cc: git, tom.russello, erwan.mathoniere, jordan.de-gea, gitster, aaron, e
Samuel GROOT <samuel.groot@grenoble-inp.org> writes:
> diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
> index edbba3a..21776f0 100644
> --- a/Documentation/git-send-email.txt
> +++ b/Documentation/git-send-email.txt
> @@ -84,13 +84,16 @@ See the CONFIGURATION section for 'sendemail.multiEdit'.
> the value of GIT_AUTHOR_IDENT, or GIT_COMMITTER_IDENT if that is not
> set, as returned by "git var -l".
>
> ---in-reply-to=<identifier>::
> +--in-reply-to=<Message-Id|email_file>::
> Make the first mail (or all the mails with `--no-thread`) appear as a
> - reply to the given Message-Id, which avoids breaking threads to
> - provide a new patch series.
> + reply to the given Message-Id (given directly by argument or via the email
> + file), which avoids breaking threads to provide a new patch series.
> The second and subsequent emails will be sent as replies according to
> the `--[no]-chain-reply-to` setting.
> +
> +Furthermore, if the argument is an email file, parse it and populate header
> +fields appropriately for the reply.
"populate header fields appropriately" would seem obscure to someone not
having followed this converation. At least s/fields/To: and Cc: fields/.
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -55,6 +55,7 @@ git send-email --dump-aliases
> --[no-]bcc <str> * Email Bcc:
> --subject <str> * Email "Subject:"
> --in-reply-to <str> * Email "In-Reply-To:"
> + --in-reply-to <file> * Populate header fields appropriately.
Likewise. To avoid an overly long line, I'd write just "Populate
To/Cc/In-reply-to".
Probably <file> should be <email_file>.
> +if ($initial_reply_to && -f $initial_reply_to) {
> + my $error = validate_patch($initial_reply_to);
> + die "fatal: $initial_reply_to: $error\nwarning: no patches were sent\n"
> + if $error;
> +
> + open my $fh, "<", $initial_reply_to or die "can't open file $initial_reply_to";
> + my $mail = Git::parse_email($fh);
> + close $fh;
> +
> + my $initial_sender = $sender || $repoauthor || $repocommitter || '';
This is duplicated from the "if ($compose) { ... my $tpl_sender = ..." a
bit later in the existing file. It would be better to get this "my
$initial_sender = ..." out of your "if" and use $initial_sender directly
later IMHO.
Actually, $initial_sender does not seem to be a good variable name. It's
not really "initial", right?
> + my $prefix_re = "";
> + my $subject_re = $mail->{"subject"}[0];
> + if ($subject_re =~ /^[^Re:]/) {
> + $prefix_re = "Re: ";
> + }
> + $initial_subject = $prefix_re . $subject_re;
Why introduce $prefix_re. You can just
my $subject = $mail->{"subject"}[0];
if (...) {
$subject = "Re: " . $subject;
}
(preferably using sensible as '...' as noted by Junio ;-) ).
In previous iterations of this series, you had issues with non-ascii
characters in at least To: and Cc: fields (perhaps in the Subject field
too?). Are they solved? I don't see any tests about it ...
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [PATCH v4 5/6] send-email: --in-reply-to=<file> populate header fields
2016-06-09 9:45 ` Matthieu Moy
@ 2016-06-14 22:35 ` Samuel GROOT
0 siblings, 0 replies; 256+ messages in thread
From: Samuel GROOT @ 2016-06-14 22:35 UTC (permalink / raw)
To: Matthieu Moy
Cc: git, tom.russello, erwan.mathoniere, jordan.de-gea, gitster, aaron, e
On 06/09/2016 11:45 AM, Matthieu Moy wrote:
> Samuel GROOT <samuel.groot@grenoble-inp.org> writes:
>
>> diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
>> index edbba3a..21776f0 100644
>> --- a/Documentation/git-send-email.txt
>> +++ b/Documentation/git-send-email.txt
>> @@ -84,13 +84,16 @@ See the CONFIGURATION section for 'sendemail.multiEdit'.
>> the value of GIT_AUTHOR_IDENT, or GIT_COMMITTER_IDENT if that is not
>> set, as returned by "git var -l".
>>
>> ---in-reply-to=<identifier>::
>> +--in-reply-to=<Message-Id|email_file>::
>> Make the first mail (or all the mails with `--no-thread`) appear as a
>> - reply to the given Message-Id, which avoids breaking threads to
>> - provide a new patch series.
>> + reply to the given Message-Id (given directly by argument or via the email
>> + file), which avoids breaking threads to provide a new patch series.
>> The second and subsequent emails will be sent as replies according to
>> the `--[no]-chain-reply-to` setting.
>> +
>> +Furthermore, if the argument is an email file, parse it and populate header
>> +fields appropriately for the reply.
>
> "populate header fields appropriately" would seem obscure to someone not
> having followed this converation. At least s/fields/To: and Cc: fields/.
We weren't sure how precise the documentation had to be, and tried to
keep it concise.
>> --- a/git-send-email.perl
>> +++ b/git-send-email.perl
>> @@ -55,6 +55,7 @@ git send-email --dump-aliases
>> --[no-]bcc <str> * Email Bcc:
>> --subject <str> * Email "Subject:"
>> --in-reply-to <str> * Email "In-Reply-To:"
>> + --in-reply-to <file> * Populate header fields appropriately.
>
> Likewise. To avoid an overly long line, I'd write just "Populate
> To/Cc/In-reply-to".
>
> Probably <file> should be <email_file>.
Thanks, will do in v5.
>> +if ($initial_reply_to && -f $initial_reply_to) {
>> + my $error = validate_patch($initial_reply_to);
>> + die "fatal: $initial_reply_to: $error\nwarning: no patches were sent\n"
>> + if $error;
>> +
>> + open my $fh, "<", $initial_reply_to or die "can't open file $initial_reply_to";
>> + my $mail = Git::parse_email($fh);
>> + close $fh;
>> +
>> + my $initial_sender = $sender || $repoauthor || $repocommitter || '';
>
> This is duplicated from the "if ($compose) { ... my $tpl_sender = ..." a
> bit later in the existing file. It would be better to get this "my
> $initial_sender = ..." out of your "if" and use $initial_sender directly
> later IMHO.
>
> Actually, $initial_sender does not seem to be a good variable name. It's
> not really "initial", right?
$sender looks like a better name, I will work on that, thanks!
>> + my $prefix_re = "";
>> + my $subject_re = $mail->{"subject"}[0];
>> + if ($subject_re =~ /^[^Re:]/) {
>> + $prefix_re = "Re: ";
>> + }
>> + $initial_subject = $prefix_re . $subject_re;
>
> Why introduce $prefix_re. You can just
>
> my $subject = $mail->{"subject"}[0];
> if (...) {
> $subject = "Re: " . $subject;
> }
>
> (preferably using sensible as '...' as noted by Junio ;-) ).
I will keep Junio's suggestion :-)
> In previous iterations of this series, you had issues with non-ascii
> characters in at least To: and Cc: fields (perhaps in the Subject field
> too?). Are they solved? I don't see any tests about it ...
Non-ascii characters are still an issue, I will work on that next week.
^ permalink raw reply [flat|nested] 256+ messages in thread
* [PATCH v4 6/6] send-email: add option --cite to quote the message body
2016-06-08 13:01 ` (unknown), Samuel GROOT
` (4 preceding siblings ...)
2016-06-08 13:07 ` [PATCH v4 5/6] send-email: --in-reply-to=<file> populate header fields Samuel GROOT
@ 2016-06-08 13:08 ` Samuel GROOT
2016-06-09 11:49 ` Matthieu Moy
5 siblings, 1 reply; 256+ messages in thread
From: Samuel GROOT @ 2016-06-08 13:08 UTC (permalink / raw)
To: git
Cc: samuel.groot, tom.russello, erwan.mathoniere, jordan.de-gea,
matthieu.moy, gitster, aaron, e
If used with `in-reply-to=<email_file>`, cite the message body of the given
email file. Otherwise, do nothing.
If `--compose` is also set, quote the message body in the cover letter. Else,
imply `--annotate` by default and quote the message body below the triple-dash
section in the first patch only.
Signed-off-by: Tom RUSSELLO <tom.russello@grenoble-inp.org>
Signed-off-by: Samuel GROOT <samuel.groot@grenoble-inp.org>
Signed-off-by: Matthieu MOY <matthieu.moy@grenoble-inp.fr>
---
Documentation/git-send-email.txt | 8 ++++
git-send-email.perl | 81 ++++++++++++++++++++++++++++++++++++++--
t/t9001-send-email.sh | 32 ++++++++++++++++
3 files changed, 117 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 21776f0..23cbd17 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -109,6 +109,14 @@ illustration below where `[PATCH v2 0/3]` is in reply to `[PATCH 0/2]`:
Only necessary if --compose is also set. If --compose
is not set, this will be prompted for.
+--cite::
+ When used with `--in-reply-to=<email_file>`, quote the message body of the
+ given email file.
++
+If `--compose` is also set, the message cited will be in the cover letter. If
+`--compose` is not set, `--annotate` option is implied by default and the
+message body will be cited in the "below-triple-dash" section.
+
--subject=<string>::
Specify the initial subject of the email thread.
Only necessary if --compose is also set. If --compose
diff --git a/git-send-email.perl b/git-send-email.perl
index b444ea6..6877ea7 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -26,6 +26,7 @@ use Text::ParseWords;
use Term::ANSIColor;
use File::Temp qw/ tempdir tempfile /;
use File::Spec::Functions qw(catfile);
+use File::Copy;
use Error qw(:try);
use Git;
@@ -56,6 +57,8 @@ git send-email --dump-aliases
--subject <str> * Email "Subject:"
--in-reply-to <str> * Email "In-Reply-To:"
--in-reply-to <file> * Populate header fields appropriately.
+ --cite * Quote the message body in the cover if
+ --compose is set, else in the first patch.
--[no-]xmailer * Add "X-Mailer:" header (default).
--[no-]annotate * Review each patch that will be sent in an editor.
--compose * Open an editor for introduction.
@@ -161,7 +164,7 @@ my $re_encoded_word = qr/=\?($re_token)\?($re_token)\?($re_encoded_text)\?=/;
# Variables we fill in automatically, or via prompting:
my (@to,$no_to,@initial_to,@cc,$no_cc,@initial_cc,@bcclist,$no_bcc,@xh,
- $initial_reply_to,$initial_references,$initial_subject,@files,
+ $initial_reply_to,$initial_references,$cite,$initial_subject,@files,
$author,$sender,$smtp_authpass,$annotate,$use_xmailer,$compose,$time);
my $envelope_sender;
@@ -305,6 +308,7 @@ $rc = GetOptions(
"sender|from=s" => \$sender,
"in-reply-to=s" => \$initial_reply_to,
"subject=s" => \$initial_subject,
+ "cite" => \$cite,
"to=s" => \@initial_to,
"to-cmd=s" => \$to_cmd,
"no-to" => \$no_to,
@@ -640,6 +644,7 @@ if (@files) {
usage();
}
+my $message_cited;
if ($initial_reply_to && -f $initial_reply_to) {
my $error = validate_patch($initial_reply_to);
die "fatal: $initial_reply_to: $error\nwarning: no patches were sent\n"
@@ -658,7 +663,8 @@ if ($initial_reply_to && -f $initial_reply_to) {
}
$initial_subject = $prefix_re . $subject_re;
- push @initial_to, $mail->{"from"}[0];
+ my $recipient = $mail->{"from"}[0];
+ push @initial_to, $recipient;
foreach my $to_addr (parse_address_line(join ",", @{$mail->{"to"}})) {
if (!($to_addr eq $initial_sender)) {
@@ -684,6 +690,25 @@ if ($initial_reply_to && -f $initial_reply_to) {
$initial_references = join("", @{$mail->{"references"}}) .
" " . $initial_reply_to;
}
+
+ if ($cite) {
+ my $date = $mail->{"date"}[0];
+ my $tpl_date = $date && "On $date, " || '';
+ $message_cited = $tpl_date . $recipient . " wrote:\n";
+
+ # Quote the message body
+ foreach (@{$mail->{"body"}}) {
+ my $space = "";
+ if (/^[^>]/) {
+ $space = " ";
+ }
+ $message_cited .= ">" . $space . $_;
+ }
+
+ if (!$compose) {
+ $annotate = 1;
+ }
+ }
}
sub get_patch_subject {
@@ -711,6 +736,9 @@ if ($compose) {
my $tpl_sender = $sender || $repoauthor || $repocommitter || '';
my $tpl_subject = $initial_subject || '';
my $tpl_reply_to = $initial_reply_to || '';
+ my $tpl_quote = $message_cited &&
+ "\nGIT: Please, trim down irrelevant sections in the cited message\n".
+ "GIT: to keep your email concise.\n" . $message_cited || '';
print $c <<EOT;
From $tpl_sender # This line is ignored.
@@ -722,7 +750,7 @@ GIT: Clear the body content if you don't wish to send a summary.
From: $tpl_sender
Subject: $tpl_subject
In-Reply-To: $tpl_reply_to
-
+$tpl_quote
EOT
for my $f (@files) {
print $c get_patch_subject($f);
@@ -787,7 +815,52 @@ EOT
$compose = -1;
}
} elsif ($annotate) {
- do_edit(@files);
+ if ($message_cited) {
+ my $cite_email_filename = ($repo ?
+ tempfile(".gitsendemail.msg.XXXXXX",
+ DIR => $repo->repo_path()) :
+ tempfile(".gitsendemail.msg.XXXXXX",
+ DIR => "."))[1];
+
+ # Insertion in a temporary file to keep the original file clean
+ # in case of cancellation/error.
+ do_insert_cited_message($cite_email_filename, $files[0]);
+
+ my $tmp = $files[0];
+ $files[0] = $cite_email_filename;
+
+ do_edit(@files);
+
+ # Erase the original patch if the edition went well
+ move($cite_email_filename, $tmp);
+ $files[0] = $tmp;
+ } else {
+ do_edit(@files);
+ }
+}
+
+sub do_insert_cited_message {
+ my $tmp_file = shift;
+ my $original_file = shift;
+
+ open my $c, "<", $original_file
+ or die "Failed to open $original_file: " . $!;
+
+ open my $c2, ">", $tmp_file
+ or die "Failed to open $tmp_file: " . $!;
+
+ # Insertion after the triple-dash
+ while (<$c>) {
+ print $c2 $_;
+ last if (/^---$/);
+ }
+ print $c2 $message_cited;
+ while (<$c>) {
+ print $c2 $_;
+ }
+
+ close $c;
+ close $c2;
}
sub ask {
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 7591342..29e28f2 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -1915,6 +1915,7 @@ test_expect_success $PREREQ 'Fields with --in-reply-to are correct' '
git send-email \
--in-reply-to=email \
--from="Example <nobody@example.com>" \
+ --cite \
--smtp-server="$(pwd)/fake.sendmail" \
-2 \
2>errors &&
@@ -1936,10 +1937,22 @@ test_expect_success $PREREQ 'Fields with --in-reply-to are correct' '
echo "$ref_adr" | grep -v "References: <author_123456@example.com>"
'
+test_expect_success $PREREQ 'correct cited message with --in-reply-to' '
+ msg_cited=$(grep -A 3 "^---$" msgtxt1) &&
+ echo "$msg_cited" | grep "On Sat, 12 Jun 2010 15:53:58 +0200, author@example.com wrote:" &&
+ echo "$msg_cited" | grep "> Have you seen my previous email?" &&
+ echo "$msg_cited" | grep ">> Previous content"
+'
+
+test_expect_success $PREREQ 'second patch body is not modified by --in-reply-to' '
+ ! grep "Have you seen my previous email?" msgtxt2
+'
+
test_expect_success $PREREQ 'Fields with --in-reply-to and --compose are correct' '
clean_fake_sendmail &&
git send-email \
--in-reply-to=email \
+ --cite \
--compose \
--from="Example <nobody@example.com>" \
--smtp-server="$(pwd)/fake.sendmail" \
@@ -1967,6 +1980,7 @@ test_expect_success $PREREQ 'Fields with --in-reply-to and --compose are correct
test_expect_success $PREREQ 'Re: written only once with --in-reply-to and --compose ' '
git send-email \
--in-reply-to=msgtxt1 \
+ --cite \
--compose \
--from="Example <nobody@example.com>" \
--smtp-server="$(pwd)/fake.sendmail" \
@@ -1975,4 +1989,22 @@ test_expect_success $PREREQ 'Re: written only once with --in-reply-to and --comp
grep "Subject: Re: subject goes here" msgtxt3
'
+test_expect_success $PREREQ 'correct cited message with --in-reply-to and --compose' '
+ grep "> On Sat, 12 Jun 2010 15:53:58 +0200, author@example.com wrote:" msgtxt3 &&
+ grep ">> Have you seen my previous email?" msgtxt3 &&
+ grep ">>> Previous content" msgtxt3
+'
+
+test_expect_success $PREREQ 'Message is not cited with only --in-reply-to' '
+ clean_fake_sendmail &&
+ git send-email \
+ --in-reply-to=email \
+ --compose \
+ --from="Example <nobody@example.com>" \
+ --smtp-server="$(pwd)/fake.sendmail" \
+ -1 \
+ 2>errors &&
+ ! grep "Have you seen my previous email?" msgtxt1
+'
+
test_done
--
2.8.2.537.gb153d2a
^ permalink raw reply related [flat|nested] 256+ messages in thread
* Re: [PATCH v4 6/6] send-email: add option --cite to quote the message body
2016-06-08 13:08 ` [PATCH v4 6/6] send-email: add option --cite to quote the message body Samuel GROOT
@ 2016-06-09 11:49 ` Matthieu Moy
2016-06-14 22:53 ` Samuel GROOT
2016-06-15 22:21 ` Tom Russello
0 siblings, 2 replies; 256+ messages in thread
From: Matthieu Moy @ 2016-06-09 11:49 UTC (permalink / raw)
To: Samuel GROOT
Cc: git, tom.russello, erwan.mathoniere, jordan.de-gea, gitster, aaron, e
Samuel GROOT <samuel.groot@grenoble-inp.org> writes:
> If used with `in-reply-to=<email_file>`, cite the message body of the given
> email file. Otherwise, do nothing.
It should at least warn when --in-reply-to=<email_file> is not given
(either no --in-reply-to or --in-reply-to=<id>). I don't see any
use-case where a user would want --cite on the command-line and not want
--in-reply-to=<email_file>. OTOH, it seems a plausible user-error, and
the user would appreciate a message saying what's going on.
> @@ -56,6 +57,8 @@ git send-email --dump-aliases
> --subject <str> * Email "Subject:"
> --in-reply-to <str> * Email "In-Reply-To:"
> --in-reply-to <file> * Populate header fields appropriately.
> + --cite * Quote the message body in the cover if
> + --compose is set, else in the first patch.
> --[no-]xmailer * Add "X-Mailer:" header (default).
> --[no-]annotate * Review each patch that will be sent in an editor.
> --compose * Open an editor for introduction.
Just wondering: would it make sense to activate --cite by default when
--in-reply-to=file is used, and to allow --no-cite to disable this?
This is something we can easily do now without breaking backward
compatibility (--in-reply-to=file doesn't exist yet), but would be more
painful to do later.
> @@ -640,6 +644,7 @@ if (@files) {
> usage();
> }
>
> +my $message_cited;
Nit: I read "$message_cited" as "Boolean saying whether the message was
cited". $cited_message would be clearer to me (but this is to be taken
with a grain of salt as I'm not a native speaker), since the variable
holds the content of the cited message.
> +sub do_insert_cited_message {
> + my $tmp_file = shift;
> + my $original_file = shift;
> +
> + open my $c, "<", $original_file
> + or die "Failed to open $original_file: " . $!;
> +
> + open my $c2, ">", $tmp_file
> + or die "Failed to open $tmp_file: " . $!;
> +
> + # Insertion after the triple-dash
> + while (<$c>) {
> + print $c2 $_;
> + last if (/^---$/);
> + }
> + print $c2 $message_cited;
I would add a newline here to get a blank line between the message cited
and the diffstat.
I think non-ascii characters would deserve particular attention here
too. For example, if the patch contain only ascii and the cited part
contains UTF-8, does the generated patch have a proper Content-type:
header?
I can imagine worse, like a patch containing latin1 character and a
cited message with another 8-bit encoding.
> +test_expect_success $PREREQ 'correct cited message with --in-reply-to and --compose' '
> + grep "> On Sat, 12 Jun 2010 15:53:58 +0200, author@example.com wrote:" msgtxt3 &&
I would prefer to have the full address including the real name here (A
<author@example.com>) in this example. Actually, after a quick look at
the code, I don't understand where the name has gone (what's shown here
is extracted from the From: header).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [PATCH v4 6/6] send-email: add option --cite to quote the message body
2016-06-09 11:49 ` Matthieu Moy
@ 2016-06-14 22:53 ` Samuel GROOT
2016-06-15 22:21 ` Tom Russello
1 sibling, 0 replies; 256+ messages in thread
From: Samuel GROOT @ 2016-06-14 22:53 UTC (permalink / raw)
To: Matthieu Moy
Cc: git, tom.russello, erwan.mathoniere, jordan.de-gea, gitster, aaron, e
On 06/09/2016 01:49 PM, Matthieu Moy wrote:
> Samuel GROOT <samuel.groot@grenoble-inp.org> writes:
>
>> If used with `in-reply-to=<email_file>`, cite the message body of the given
>> email file. Otherwise, do nothing.
>
> It should at least warn when --in-reply-to=<email_file> is not given
> (either no --in-reply-to or --in-reply-to=<id>). I don't see any
> use-case where a user would want --cite on the command-line and not want
> --in-reply-to=<email_file>. OTOH, it seems a plausible user-error, and
> the user would appreciate a message saying what's going on.
We weren't sure how to warn the user.
If --in-reply-to is not an mail file, should we check it with a regex to
make sure it's a message-id?
>> @@ -56,6 +57,8 @@ git send-email --dump-aliases
>> --subject <str> * Email "Subject:"
>> --in-reply-to <str> * Email "In-Reply-To:"
>> --in-reply-to <file> * Populate header fields appropriately.
>> + --cite * Quote the message body in the cover if
>> + --compose is set, else in the first patch.
>> --[no-]xmailer * Add "X-Mailer:" header (default).
>> --[no-]annotate * Review each patch that will be sent in an editor.
>> --compose * Open an editor for introduction.
>
> Just wondering: would it make sense to activate --cite by default when
> --in-reply-to=file is used, and to allow --no-cite to disable this?
>
> This is something we can easily do now without breaking backward
> compatibility (--in-reply-to=file doesn't exist yet), but would be more
> painful to do later.
It's an interesting question.
IMHO we should have `--cite` by default and allow `--no-cite` to disable
quoting the message body, because it's easier to remove extra unwanted
lines than copying lines from another file and adding "> " before each line.
>> @@ -640,6 +644,7 @@ if (@files) {
>> usage();
>> }
>>
>> +my $message_cited;
>
> Nit: I read "$message_cited" as "Boolean saying whether the message was
> cited". $cited_message would be clearer to me (but this is to be taken
> with a grain of salt as I'm not a native speaker), since the variable
> holds the content of the cited message.
>
>> +sub do_insert_cited_message {
>> + my $tmp_file = shift;
>> + my $original_file = shift;
>> +
>> + open my $c, "<", $original_file
>> + or die "Failed to open $original_file: " . $!;
>> +
>> + open my $c2, ">", $tmp_file
>> + or die "Failed to open $tmp_file: " . $!;
>> +
>> + # Insertion after the triple-dash
>> + while (<$c>) {
>> + print $c2 $_;
>> + last if (/^---$/);
>> + }
>> + print $c2 $message_cited;
>
> I would add a newline here to get a blank line between the message cited
> and the diffstat.
A newline here makes it easier to distinguish the different sections in
the email file indeed.
> I think non-ascii characters would deserve particular attention here
> too. For example, if the patch contain only ascii and the cited part
> contains UTF-8, does the generated patch have a proper Content-type:
> header?
Non-ascii characters are still an issue, I'll work on that next week.
> I can imagine worse, like a patch containing latin1 character and a
> cited message with another 8-bit encoding.
>
>> +test_expect_success $PREREQ 'correct cited message with --in-reply-to and --compose' '
>> + grep "> On Sat, 12 Jun 2010 15:53:58 +0200, author@example.com wrote:" msgtxt3 &&
>
> I would prefer to have the full address including the real name here (A
> <author@example.com>) in this example. Actually, after a quick look at
> the code, I don't understand where the name has gone (what's shown here
> is extracted from the From: header).
Yep, after a quick look at the code involved, I don't understand either,
I will investigate this week.
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [PATCH v4 6/6] send-email: add option --cite to quote the message body
2016-06-09 11:49 ` Matthieu Moy
2016-06-14 22:53 ` Samuel GROOT
@ 2016-06-15 22:21 ` Tom Russello
1 sibling, 0 replies; 256+ messages in thread
From: Tom Russello @ 2016-06-15 22:21 UTC (permalink / raw)
To: Matthieu Moy, Samuel GROOT
Cc: git, erwan.mathoniere, jordan.de-gea, gitster, aaron, e
Le 09/06/2016 à 13:49, Matthieu Moy a écrit :
> Samuel GROOT <samuel.groot@grenoble-inp.org> writes:
>
>> If used with `in-reply-to=<email_file>`, cite the message body of the given
>> email file. Otherwise, do nothing.
>
> It should at least warn when --in-reply-to=<email_file> is not given
> (either no --in-reply-to or --in-reply-to=<id>). I don't see any
> use-case where a user would want --cite on the command-line and not want
> --in-reply-to=<email_file>. OTOH, it seems a plausible user-error, and
> the user would appreciate a message saying what's going on.
You're right. We'll warn the user with the next version.
>> @@ -56,6 +57,8 @@ git send-email --dump-aliases
>> --subject <str> * Email "Subject:"
>> --in-reply-to <str> * Email "In-Reply-To:"
>> --in-reply-to <file> * Populate header fields appropriately.
>> + --cite * Quote the message body in the cover if
>> + --compose is set, else in the first patch.
>> --[no-]xmailer * Add "X-Mailer:" header (default).
>> --[no-]annotate * Review each patch that will be sent in an editor.
>> --compose * Open an editor for introduction.
>
> Just wondering: would it make sense to activate --cite by default when
> --in-reply-to=file is used, and to allow --no-cite to disable this?
> This is something we can easily do now without breaking backward
> compatibility (--in-reply-to=file doesn't exist yet), but would be more
> painful to do later.
Indeed, it can be more intuitive especially for a user who is used to
cite messages.
>> @@ -640,6 +644,7 @@ if (@files) {
>> usage();
>> }
>>
>> +my $message_cited;
>
> Nit: I read "$message_cited" as "Boolean saying whether the message was
> cited". $cited_message would be clearer to me (but this is to be taken
> with a grain of salt as I'm not a native speaker), since the variable
> holds the content of the cited message.
Sorry, French habits.. :-)
>> +sub do_insert_cited_message {
>> + my $tmp_file = shift;
>> + my $original_file = shift;
>> +
>> + open my $c, "<", $original_file
>> + or die "Failed to open $original_file: " . $!;
>> +
>> + open my $c2, ">", $tmp_file
>> + or die "Failed to open $tmp_file: " . $!;
>> +
>> + # Insertion after the triple-dash
>> + while (<$c>) {
>> + print $c2 $_;
>> + last if (/^---$/);
>> + }
>> + print $c2 $message_cited;
>
> I would add a newline here to get a blank line between the message cited
> and the diffstat.
Agreed.
> I think non-ascii characters would deserve particular attention here
> too. For example, if the patch contain only ascii and the cited part
> contains UTF-8, does the generated patch have a proper Content-type:
> header?
>
> I can imagine worse, like a patch containing latin1 character and a
> cited message with another 8-bit encoding.
I tried to manage them with the built-in Base64 module but there is
still work in progress.
>> +test_expect_success $PREREQ 'correct cited message with --in-reply-to and --compose' '
>> + grep "> On Sat, 12 Jun 2010 15:53:58 +0200, author@example.com wrote:" msgtxt3 &&
>
> I would prefer to have the full address including the real name here (A
> <author@example.com>) in this example. Actually, after a quick look at
> the code, I don't understand where the name has gone (what's shown here
> is extracted from the From: header).
Agreed, I'll figure out where the problem is.
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown)
@ 2016-06-16 3:54 岸洋介
0 siblings, 0 replies; 256+ messages in thread
From: 岸洋介 @ 2016-06-16 3:54 UTC (permalink / raw)
To: git
w
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2016-06-12 9:38 Financial Service
0 siblings, 0 replies; 256+ messages in thread
From: Financial Service @ 2016-06-12 9:38 UTC (permalink / raw)
Greetings, Have you been looking for finance options for your new home purchase, construction, refinance, medical cash, family cash, personal or business purpose. Welcome to the future! Finance made easy with us. Contact us as we offer our finance service at a low and affordable interest rate for long and short cash term,reply to this Email for more Info
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2016-05-16 15:58 Nathan Wendt
0 siblings, 0 replies; 256+ messages in thread
From: Nathan Wendt @ 2016-05-16 15:58 UTC (permalink / raw)
To: git
Recently I have run into an issue with the git-completion.tcsh script
where an error would occur upon sourcing the file on login. The error
that would occur was:
__git_tcsh_completion_version: Subscript out of range.
In taking a look at the script, I noticed that when the script parses
the tcsh version that I am running it does not put the output into an
array. Thus, when it attempts to access subscript 2 of
__git_tcsh_completion_version it throws the above error. To correct
this, I changed
set __git_tcsh_completion_version = ` \echo ${tcsh} | \sed 's/\./ /g'`
to
set __git_tcsh_completion_version = `( \echo ${tcsh} | \sed 's/\./ /g' )`
and the script runs correctly. I could not find others having issues
with this in the forums so I am not sure if this is unique to my
system or not. Thought I would pass it along.
For reference, I am running tcsh 6.17.00 on RHEL 6.8
Thanks.
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2016-04-11 19:04 miwilliams
0 siblings, 0 replies; 256+ messages in thread
From: miwilliams @ 2016-04-11 19:04 UTC (permalink / raw)
To: git
From 7201fe08ede76e502211a781250c9a0b702a78b2 Mon Sep 17 00:00:00 2001
From: Mike Williams <miwilliams@google.com>
Date: Mon, 11 Apr 2016 14:18:39 -0400
Subject: [PATCH 1/1] wt-status: Remove '!!' from
wt_status_collect_changed_cb
The wt_status_collect_changed_cb function uses an extraneous double
negation (!!)
when determining whether or not a submodule has new commits.
Signed-off-by: Mike Williams <miwilliams@google.com>
---
wt-status.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/wt-status.c b/wt-status.c
index ef74864..b955179 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -431,7 +431,7 @@ static void wt_status_collect_changed_cb(struct
diff_queue_struct *q,
d->worktree_status = p->status;
d->dirty_submodule = p->two->dirty_submodule;
if (S_ISGITLINK(p->two->mode))
- d->new_submodule_commits = !!hashcmp(p->one->sha1, p->two->sha1);
+ d->new_submodule_commits = hashcmp(p->one->sha1, p->two->sha1);
}
}
--
2.8.0
^ permalink raw reply related [flat|nested] 256+ messages in thread
* (unknown)
@ 2016-04-11 16:02 Michael S. Tsirkin
0 siblings, 0 replies; 256+ messages in thread
From: Michael S. Tsirkin @ 2016-04-11 16:02 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, bafain, sunshine
Cc junio
Bcc:
Subject: Re: [PATCH 1/4] rebase -i: add ack action
Message-ID: <20160411184535-mutt-send-email-mst@redhat.com>
Reply-To:
In-Reply-To: <alpine.DEB.2.20.1604111736060.2967@virtualbox>
On Mon, Apr 11, 2016 at 05:36:45PM +0200, Johannes Schindelin wrote:
> Hi Michael,
>
> On Mon, 11 Apr 2016, Michael S. Tsirkin wrote:
>
> > So far I only see examples of adding footers. If that's all we can think
> > up, why code in all this genericity?
>
> Because as far as I can see, the only benefitor of your patches would be
> you.
>
> Ciao,
> Johannes
This seems unlikely. Just merging the patches won't benefit me directly
- I have maintained them in my tree for a couple of years now with very
little effort. For sure, I could benefit if they get merged and then
someone improves them further - that was the point of posting them - but
then I'm not the only benefitor.
The workflow including getting acks for patches by email is not handled
well by upstream git right now. It would surprise me if no one uses it
if it's upstream, as you seem to suggest. But maybe most people moved
on and just do pull requests instead.
--
MST
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2016-03-28 13:38 ratheesh kannoth
0 siblings, 0 replies; 256+ messages in thread
From: ratheesh kannoth @ 2016-03-28 13:38 UTC (permalink / raw)
To: git
subscribe
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2015-12-16 3:02 David Greene
2015-12-16 5:57 ` (unknown) Junio C Hamano
0 siblings, 1 reply; 256+ messages in thread
From: David Greene @ 2015-12-16 3:02 UTC (permalink / raw)
To: git; +Cc: john, sandals, peff, gitster
This patch isn't ready for prime-time yet but I wanted to get it out
for some discussion.
While cleaning up and enhancing git-subtree, I've come across the
need to have rebase behave nicely in the case of empty and redundant
commits. There's a case in pick_one_preserving_merges where
git-cherry pick is used to process the rebase and if cherry-pick
fails, the rebase aborts. This change does two things:
- If --keep-empty is specified, invoke cherry-pick with --allow-empty.
- If new option --keep-redundant is specified, invoke cherry-pick with
--keep-redundant-commits.
This allows the rebase to go forward without intrruption in the
included tests.
I will also need a third option that has cherry-pick ignore redundant
commits and remove them from the history. Unfortunately, I can't
make out exactly how to do that in commit.c, which is where I gather
the cherry-pick stuff happens. I'll need some help with that if
there's general agreement that this is a useful enhancement.
During the course of developing this, I've encountered some
strange rebase behavior. I'll send another message about that.
I'd appreciate feedback on this direction and any help with the
cherry-pick stuff. Thanks!
-David
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: (unknown)
2015-12-16 3:02 (unknown), David Greene
@ 2015-12-16 5:57 ` Junio C Hamano
2015-12-16 8:44 ` (unknown) Patrick Steinhardt
0 siblings, 1 reply; 256+ messages in thread
From: Junio C Hamano @ 2015-12-16 5:57 UTC (permalink / raw)
To: David Greene; +Cc: git, john, sandals, peff
David Greene <greened@obbligato.org> writes:
> - If new option --keep-redundant is specified, invoke cherry-pick with
> --keep-redundant-commits.
This came up in the past several weeks, I think; you would need to
disable patch-equivalence based commit filtering if you really want
to do a --keep-redundant that is reproducible and/or reliable.
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: (unknown)
2015-12-16 5:57 ` (unknown) Junio C Hamano
@ 2015-12-16 8:44 ` Patrick Steinhardt
2015-12-18 17:35 ` (unknown) David Greene
0 siblings, 1 reply; 256+ messages in thread
From: Patrick Steinhardt @ 2015-12-16 8:44 UTC (permalink / raw)
To: David Greene; +Cc: git, john, sandals, peff, Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 720 bytes --]
On Tue, Dec 15, 2015 at 09:57:50PM -0800, Junio C Hamano wrote:
> David Greene <greened@obbligato.org> writes:
>
> > - If new option --keep-redundant is specified, invoke cherry-pick with
> > --keep-redundant-commits.
>
> This came up in the past several weeks, I think; you would need to
> disable patch-equivalence based commit filtering if you really want
> to do a --keep-redundant that is reproducible and/or reliable.
Here are the links to the previous proposal [1] and following
discussion [2] (see 'ps/rebase-keep-empty') if you are
interested.
Patrick
[1]: http://thread.gmane.org/gmane.comp.version-control.git/281515
[2]: http://thread.gmane.org/gmane.comp.version-control.git/281917
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: (unknown)
2015-12-16 8:44 ` (unknown) Patrick Steinhardt
@ 2015-12-18 17:35 ` David Greene
0 siblings, 0 replies; 256+ messages in thread
From: David Greene @ 2015-12-18 17:35 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git, john, sandals, peff, Junio C Hamano
Patrick Steinhardt <ps@pks.im> writes:
> On Tue, Dec 15, 2015 at 09:57:50PM -0800, Junio C Hamano wrote:
>> David Greene <greened@obbligato.org> writes:
>>
>> > - If new option --keep-redundant is specified, invoke cherry-pick with
>> > --keep-redundant-commits.
>>
>> This came up in the past several weeks, I think; you would need to
>> disable patch-equivalence based commit filtering if you really want
>> to do a --keep-redundant that is reproducible and/or reliable.
>
> Here are the links to the previous proposal [1] and following
> discussion [2] (see 'ps/rebase-keep-empty') if you are
> interested.
>
> Patrick
>
> [1]: http://thread.gmane.org/gmane.comp.version-control.git/281515[2]: http://thread.gmane.org/gmane.comp.version-control.git/281917
Thanks. That makes total sense.
I actually would prefer a behavior where cherry-pick would just drop
redundant commits rather than stopping and asking the user to reset.
The problem is that rebase --preserve-merges seems to force the drop to
use cherry-pick and cherry-pick doesn't behave well (from a scripting
perspective) in the presence of redundant commits.
As it is, it's difficult to rebase as part of a scripted operation due
to this issue.
Any ideas on how to teach cherry-pick to automatically drop such
commits?
-David
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown)
@ 2015-12-14 13:14 Ros Sothen
0 siblings, 0 replies; 256+ messages in thread
From: Ros Sothen @ 2015-12-14 13:14 UTC (permalink / raw)
To: git
Sent from my iPhone
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2015-11-06 3:34 David Greene
0 siblings, 0 replies; 256+ messages in thread
From: David Greene @ 2015-11-06 3:34 UTC (permalink / raw)
To: git
Cc: techlivezheng, alex.crezoff, davvid, cbailey32, danny0838,
prohaska, th.acker, sschuberth, peff, gitter.spiros, nod.helm
I'm processing some old patches I have lying around. These clean up
git-subtree's test base and refactor the test code so that each test
is independent of the others. This greatly aids debugging and
post-mortem analysis.
I have rebased these old patches on master, ensuring that new tests
that have been added in the interim are incorporated into the new test
code.
After using git-subtree in real projects for a couple of years and
exploring similar tools that have been developed, I'm fairly convinced
we should change some current behavor of git-subtree. I have also run
into the need for some additional features. I'm now in a position
where I can work on those.
This patch set is a prerequisite for that work.
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2015-09-28 17:55 Kosta Zertsekel
0 siblings, 0 replies; 256+ messages in thread
From: Kosta Zertsekel @ 2015-09-28 17:55 UTC (permalink / raw)
To: git
subscribe git
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2015-09-19 10:58 戸島達哉
0 siblings, 0 replies; 256+ messages in thread
From: 戸島達哉 @ 2015-09-19 10:58 UTC (permalink / raw)
To: git
subscribe git
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2015-09-01 2:13 David Turner
0 siblings, 0 replies; 256+ messages in thread
From: David Turner @ 2015-09-01 2:13 UTC (permalink / raw)
To: git, mhagger, Christian Couder
This version of the patch series squashes in Junio's comment fix and
the xstrndup fix.
In addition, it removes refs/worktree, and just makes refs/bisect
per-worktree. If we later discover that other things need to be
per-worktree, we can do refs/worktree, but for now, this is
backwards-compatible so we'll do this.
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown)
@ 2015-08-05 12:47 Ivan Chernyavsky
0 siblings, 0 replies; 256+ messages in thread
From: Ivan Chernyavsky @ 2015-08-05 12:47 UTC (permalink / raw)
To: git
Dear community,
For some time I'm wondering why there's no "--grep" option to the "git branch" command, which would request to print only branches having specified string/regexp in their history.
So for example:
$ git branch -r --grep=BUG12345
should be roughly equivalent to following expression I'm using now for the same task:
$ for r in `git rev-list --grep=BUG12345 --remotes=origin`; do git branch -r --list --contains=$r 'origin/*'; done | sort -u
Am I missing something, is there some smarter/simpler way to do this?
Thanks a lot in advance!
--
Ivan
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2015-05-12 12:38 Varis Van Rob
0 siblings, 0 replies; 256+ messages in thread
From: Varis Van Rob @ 2015-05-12 12:38 UTC (permalink / raw)
Good Day!
My name is Mr Varis Van Rob, I have a business proposal that will benefit
you.contact me for more details.
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2015-05-11 17:56 dturner
0 siblings, 0 replies; 256+ messages in thread
From: dturner @ 2015-05-11 17:56 UTC (permalink / raw)
To: git
This version includes style fixups suggested by Junio Hamano. As
suggested, I moved the addition of the new object_context field to the
patch where it is used.
In addition, I moved a few variables into smaller scopes.
I also (hopefully) fixed the tests on Windows thanks to some
suggestions from Johannes Sixt
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2015-04-08 20:44 Mamta Upadhyay
0 siblings, 0 replies; 256+ messages in thread
From: Mamta Upadhyay @ 2015-04-08 20:44 UTC (permalink / raw)
To: git
Hi git team,
I tried to research everywhere on a issue I am facing and emailing you
as the last resource. This is critical for me and I needed your help.
I am trying to run the latest git 1.9.5 installer on windows. When I
run strings on libneon-25.dll it shows this:
./libneon-25.dll: OpenSSL 1.0.1h 5 Jun 2014
But when I load this dll in dependency walker, it picks up
msys-openssl 1.0.1m and has no trace of openssl-1.0.1h. My questions
to you:
1. Is libneon-25.dll statically linked with openssl-1.0.1h?
2. If not, where is the reference to 1.0.1h coming from?
I am asked to rebuild git with libneon-25.dll linked against
openssl-1.0.1m. But I am having a feeling that this is not needed,
since libneon is already picking the latest openssl version. Can you
please confirm?
Thanks,
Mamta
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown)
@ 2015-03-13 1:34 cody.taylor
0 siblings, 0 replies; 256+ messages in thread
From: cody.taylor @ 2015-03-13 1:34 UTC (permalink / raw)
To: git; +Cc: szeder, felipe.contreras
>From 3e4e22e93bf07355b40ba0abcb3a15c4941cfee7 Mon Sep 17 00:00:00 2001
From: Cody A Taylor <codemister99@yahoo.com>
Date: Thu, 12 Mar 2015 20:36:44 -0400
Subject: [PATCH] git prompt: Use toplevel to find untracked files.
The __git_ps1() prompt function would not show an untracked
state when the current working directory was not a parent of
the untracked file.
Signed-off-by: Cody A Taylor <codemister99@yahoo.com>
---
contrib/completion/git-prompt.sh | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 214e859f99e7..f0d8a2669236 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -487,7 +487,8 @@ __git_ps1 ()
if [ -n "${GIT_PS1_SHOWUNTRACKEDFILES-}" ] &&
[ "$(git config --bool bash.showUntrackedFiles)" != "false" ] &&
- git ls-files --others --exclude-standard --error-unmatch -- '*' >/dev/null 2>/dev/null
+ git ls-files --others --exclude-standard --error-unmatch -- \
+ "$(git rev-parse --show-toplevel)/*" >/dev/null 2>/dev/null
then
u="%${ZSH_VERSION+%}"
fi
--
2.3.2
^ permalink raw reply related [flat|nested] 256+ messages in thread
* (unknown)
@ 2015-02-25 8:53 stefan leijen
0 siblings, 0 replies; 256+ messages in thread
From: stefan leijen @ 2015-02-25 8:53 UTC (permalink / raw)
To: git
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [PATCH] read-cache.c: free cache entry when refreshing fails
@ 2015-02-17 18:14 Junio C Hamano
2015-02-17 18:27 ` (unknown), Stefan Beller
0 siblings, 1 reply; 256+ messages in thread
From: Junio C Hamano @ 2015-02-17 18:14 UTC (permalink / raw)
To: Stefan Beller; +Cc: git
Stefan Beller <sbeller@google.com> writes:
> This fixes a memory leak, when building the cache entries as
> refresh_cache_entry may decide to return NULL in case of
>
in case of what?
I briefly wondered if refresh_cache_ent() should do the freeing but
that does not make sense at all if done unconditionally because the
other caller of the function does want to retain ce on error, and it
makes little sense to invent FREE_CE_ON_ERROR bit in refresh_option,
either, so this fix looks sensible.
> I am not sure how severe this memory leak is as it was found by
> scan.coverity.com, CID 290041.
>
> Signed-off-by: Stefan Beller <sbeller@google.com>
> ---
> read-cache.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/read-cache.c b/read-cache.c
> index 9cff715..8d71860 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -725,7 +725,7 @@ struct cache_entry *make_cache_entry(unsigned int mode,
> unsigned int refresh_options)
> {
> int size, len;
> - struct cache_entry *ce;
> + struct cache_entry *ce, *ret;
>
> if (!verify_path(path)) {
> error("Invalid path '%s'", path);
> @@ -742,7 +742,13 @@ struct cache_entry *make_cache_entry(unsigned int mode,
> ce->ce_namelen = len;
> ce->ce_mode = create_ce_mode(mode);
>
> - return refresh_cache_entry(ce, refresh_options);
> + ret = refresh_cache_entry(ce, refresh_options);
> + if (!ret) {
> + free(ce);
> + return NULL;
> + } else {
> + return ret;
> + }
> }
>
> int ce_same_name(const struct cache_entry *a, const struct cache_entry *b)
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
2015-02-17 18:14 [PATCH] read-cache.c: free cache entry when refreshing fails Junio C Hamano
@ 2015-02-17 18:27 ` Stefan Beller
0 siblings, 0 replies; 256+ messages in thread
From: Stefan Beller @ 2015-02-17 18:27 UTC (permalink / raw)
To: gitster; +Cc: git, Stefan Beller
On Tue, Feb 17, 2015 at 10:14 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Stefan Beller <sbeller@google.com> writes:
>
>> This fixes a memory leak, when building the cache entries as
>> refresh_cache_entry may decide to return NULL in case of
>>
>
> in case of what?
Yeah, I got distracted when rewriting the commit message as I was
looking at refresh_cache_ent() wondering if there is a better place to
free the memory. Just as you said below.
Maybe we can drop that part of the sentence as it doesn't matter
why refresh_cache_ent() returns NULL. All that matters is the
possibility of it returning NULL.
>
> I briefly wondered if refresh_cache_ent() should do the freeing but
> that does not make sense at all if done unconditionally because the
> other caller of the function does want to retain ce on error, and it
> makes little sense to invent FREE_CE_ON_ERROR bit in refresh_option,
> either, so this fix looks sensible.
>
So here is a reworded commit message:
---8<---
From 3a1f646c1dbe828b68e1b269290d2b5593f86455 Mon Sep 17 00:00:00 2001
From: Stefan Beller <sbeller@google.com>
Date: Tue, 17 Feb 2015 10:05:36 -0800
Subject: [PATCH] read-cache.c: free cache entry when refreshing fails
This fixes a memory leak when building the cache entries as
refresh_cache_entry may decide to return NULL, but it doesn't
free the cache entry structure which was passed in as an argument.
I am not sure how severe this memory leak is as it was found by
scan.coverity.com, CID 290041.
Signed-off-by: Stefan Beller <sbeller@google.com>
---
read-cache.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index 9cff715..8d71860 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -725,7 +725,7 @@ struct cache_entry *make_cache_entry(unsigned int mode,
unsigned int refresh_options)
{
int size, len;
- struct cache_entry *ce;
+ struct cache_entry *ce, *ret;
if (!verify_path(path)) {
error("Invalid path '%s'", path);
@@ -742,7 +742,13 @@ struct cache_entry *make_cache_entry(unsigned int mode,
ce->ce_namelen = len;
ce->ce_mode = create_ce_mode(mode);
- return refresh_cache_entry(ce, refresh_options);
+ ret = refresh_cache_entry(ce, refresh_options);
+ if (!ret) {
+ free(ce);
+ return NULL;
+ } else {
+ return ret;
+ }
}
int ce_same_name(const struct cache_entry *a, const struct cache_entry *b)
--
2.3.0.81.gc37f363
^ permalink raw reply related [flat|nested] 256+ messages in thread
* (unknown),
@ 2015-01-12 20:59 امير الاحزان
0 siblings, 0 replies; 256+ messages in thread
From: امير الاحزان @ 2015-01-12 20:59 UTC (permalink / raw)
To: git
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2014-10-30 12:23 Fedor Eftimitsa
0 siblings, 0 replies; 256+ messages in thread
From: Fedor Eftimitsa @ 2014-10-30 12:23 UTC (permalink / raw)
To: git
Greetings!
I have very large git repository (>20Gb) and after repack the size of it increases by 1.3-2 times.
I try to understand why it is happened and how to solve this matter.
Details
I work in gamedev and we store under git all what we have: source code, textures and other binary data.
Now size of the main repository (.git) is about 23Gb right after cloning.
But if I run 'git gc' or 'git gc --aggressive' size of repository increases to more than 40Gb.
'git gc --auto' doesn't change existing packs and doesn't increase size so much.
For a long time we disabled 'gc auto' for all work PCs and repacked repository by script at night.
Script configures some options and runs 'git gc' without --auto and now the size of most repositories is more than 50Gb.
Here this options from script:
-- pack.threads 2
-- pack.windowMemory 16m
-- pack.depth 1
-- pack.window 10
-- gc.aggressiveWindow 10
-- pack.packSizeLimit 2g
I try to improve this script and find the way to decrease size of these repositories to initial (after clone) size. The size of repository is very important because it's located on SSD disk for comfort work.
I've tried different options for 'git gc' and 'git gc --aggressive' but can't achieve this - size of repository always about 40Gb and more.
Best result provides 'git gc --aggressive' with disabled pack.packSizeLimit, window and depth is 250 - it creates single pack about 36Gb.
In worst case repository size can be more than 60Gb.
Can you help me to understand what options I can try to repack repositories to initial size?
All work PCs have Windows 7 and git version >=1.8.1 installed.
All the best,
Fedor Eftimitsa
Senior Programmer
Nival
www.nival.com
www.zzima.com
Skype: d9fault
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown)
@ 2014-09-28 10:51 bambecapuno06
0 siblings, 0 replies; 256+ messages in thread
From: bambecapuno06 @ 2014-09-28 10:51 UTC (permalink / raw)
To: git
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2014-09-08 11:36 R. Klomp
0 siblings, 0 replies; 256+ messages in thread
From: R. Klomp @ 2014-09-08 11:36 UTC (permalink / raw)
To: git; +Cc: p.duijst
It seems like there's a bug involving git difftool's -d flag and Beyond Compare.
When using the difftool Beyond Compare, git difftool <..> <..> -d
immidiatly shuts down once the diff tree has been created. Beyond
Compare successfully shows the files that differ.
However, since git difftool doesn't wait for Beyond Compare to shut
down, all temporary files are gone. Due to this it's impossible to
view changes made inside files using the -d flag.
I haven't tested if this issue also happens with other difftools.
I'm using the latest versions of both Beyond Compare 3 (3.3.12, Pro
Edition for Windows) and Git (1.9.4 for Windows).
Thanks in advance for your help!
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2014-08-26 11:16 mail
0 siblings, 0 replies; 256+ messages in thread
From: mail @ 2014-08-26 11:16 UTC (permalink / raw)
To: git
Hi everyone.
Normally if I am tracking a file in a Directory which satisfies one of my
.gitignore rules, I can just add them via "git add foo", and I have no
issues.
For example, let me create a new repo. I create a directory "lib"
containing file "foo.txt", and a Directory "lib2" with a file "bar.txt".
I add and commit both files.
Now I create a .gitignore file containing the rule "lib*/". I modify
lib/foo.txt and lib2/bar.txt. I do "git status" and I'm informed that
foo.txt and bar.txt are modified. So far so good.
The following commands work as expected:
git add lib/foo.txt
git add lib2/bar.txt
But if I instead do:
git add lib/foo.txt lib2/bar.txt
I get the following response:
The following paths are ignored by one of your .gitignore files:
lib
lib2
I have verified this behavior in git 1.9.3 and 2.1.0. Is this desired
behavior or is it a bug? If it is desired behavior, could someone please
describe the utility to me?
Many thanks for your excellent work
Glen Stark
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2014-07-15 16:31 Woody Wu
0 siblings, 0 replies; 256+ messages in thread
From: Woody Wu @ 2014-07-15 16:31 UTC (permalink / raw)
To: git
Hi,
I have tried some methods introduced in the network, but always failed. Some big files committed by me to a very old branch then the files deleted and new branches were continuously created. Now the checkout directory has grown to about 80 megabytes. What's the right way to permenently erase those garbage big files?
Thanks in advance.
-
Woody Wu from mobile phone
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2014-06-17 17:13 David Turner
0 siblings, 0 replies; 256+ messages in thread
From: David Turner @ 2014-06-17 17:13 UTC (permalink / raw)
To: git
This version changes only the commit message; there is no longer any
configure.ac code.
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2014-06-01 21:24 C. Benson Manica
0 siblings, 0 replies; 256+ messages in thread
From: C. Benson Manica @ 2014-06-01 21:24 UTC (permalink / raw)
To: git
The documentation for installing git from source here,
http://git-scm.com/book/en/Getting-Started-Installing-Git, incorrectly
fails to mention that the MakeMaker perl module is also required and
is installable via
$ yum install perl-ExtUtils-MakeMaker
Also, you might want to let people know that you've configured your
mail system for 1987 mode and do not accept HTML-formatted mail.
--
C. Benson Manica
cbmanica@gmail.com
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2014-05-22 22:35 Mrs. Jiang Ming
0 siblings, 0 replies; 256+ messages in thread
From: Mrs. Jiang Ming @ 2014-05-22 22:35 UTC (permalink / raw)
--
Compliment of the day,
I am Mrs. Jiang Ming, a staff of Lloyds TSB Group Plc. here in
Hong Kong attached with Private Banking Services;I have a secured business
proposal for you. Should you be interested please reach me on my private
emailaddress (mrsjiangming1903@outlook.com) And after that I shall provide
you with
more details of my proposal.
Your earliest response to this letter will be appreciated.
Yours Sincerely,
Jiang Ming
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2014-04-19 14:27 Siegel, Suzan
0 siblings, 0 replies; 256+ messages in thread
From: Siegel, Suzan @ 2014-04-19 14:27 UTC (permalink / raw)
T0 get your entitlement, write me via; siedmond@outlook.com
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown)
@ 2014-03-19 0:45 szager
0 siblings, 0 replies; 256+ messages in thread
From: szager @ 2014-03-19 0:45 UTC (permalink / raw)
To: git
Subject: [PATCH] Enable index-pack threading in msysgit.
This adds a Windows implementation of pread. Note that it is NOT
safe to intersperse calls to read() and pread() on a file
descriptor. According to the ReadFile spec, using the 'overlapped'
argument should not affect the implicit position pointer of the
descriptor. Experiments have shown that this is, in fact, a lie.
To accomodate that fact, this change also incorporates:
http://article.gmane.org/gmane.comp.version-control.git/196042
... which gives each index-pack thread its own file descriptor.
---
builtin/index-pack.c | 21 ++++++++++++++++-----
compat/mingw.c | 31 ++++++++++++++++++++++++++++++-
compat/mingw.h | 3 +++
config.mak.uname | 1 -
4 files changed, 49 insertions(+), 7 deletions(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index 2f37a38..c02dd4c 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-pack.c
@@ -51,6 +51,7 @@ struct thread_local {
#endif
struct base_data *base_cache;
size_t base_cache_used;
+ int pack_fd;
};
/*
@@ -91,7 +92,8 @@ static off_t consumed_bytes;
static unsigned deepest_delta;
static git_SHA_CTX input_ctx;
static uint32_t input_crc32;
-static int input_fd, output_fd, pack_fd;
+static const char *curr_pack;
+static int input_fd, output_fd;
#ifndef NO_PTHREADS
@@ -134,6 +136,7 @@ static inline void unlock_mutex(pthread_mutex_t *mutex)
*/
static void init_thread(void)
{
+ int i;
init_recursive_mutex(&read_mutex);
pthread_mutex_init(&counter_mutex, NULL);
pthread_mutex_init(&work_mutex, NULL);
@@ -141,11 +144,17 @@ static void init_thread(void)
pthread_mutex_init(&deepest_delta_mutex, NULL);
pthread_key_create(&key, NULL);
thread_data = xcalloc(nr_threads, sizeof(*thread_data));
+ for (i = 0; i < nr_threads; i++) {
+ thread_data[i].pack_fd = open(curr_pack, O_RDONLY);
+ if (thread_data[i].pack_fd == -1)
+ die_errno("unable to open %s", curr_pack);
+ }
threads_active = 1;
}
static void cleanup_thread(void)
{
+ int i;
if (!threads_active)
return;
threads_active = 0;
@@ -155,6 +164,8 @@ static void cleanup_thread(void)
if (show_stat)
pthread_mutex_destroy(&deepest_delta_mutex);
pthread_key_delete(key);
+ for (i = 0; i < nr_threads; i++)
+ close(thread_data[i].pack_fd);
free(thread_data);
}
@@ -288,13 +299,13 @@ static const char *open_pack_file(const char *pack_name)
output_fd = open(pack_name, O_CREAT|O_EXCL|O_RDWR, 0600);
if (output_fd < 0)
die_errno(_("unable to create '%s'"), pack_name);
- pack_fd = output_fd;
+ nothread_data.pack_fd = output_fd;
} else {
input_fd = open(pack_name, O_RDONLY);
if (input_fd < 0)
die_errno(_("cannot open packfile '%s'"), pack_name);
output_fd = -1;
- pack_fd = input_fd;
+ nothread_data.pack_fd = input_fd;
}
git_SHA1_Init(&input_ctx);
return pack_name;
@@ -542,7 +553,7 @@ static void *unpack_data(struct object_entry *obj,
do {
ssize_t n = (len < 64*1024) ? len : 64*1024;
- n = pread(pack_fd, inbuf, n, from);
+ n = pread(get_thread_data()->pack_fd, inbuf, n, from);
if (n < 0)
die_errno(_("cannot pread pack file"));
if (!n)
@@ -1490,7 +1501,7 @@ static void show_pack_info(int stat_only)
int cmd_index_pack(int argc, const char **argv, const char *prefix)
{
int i, fix_thin_pack = 0, verify = 0, stat_only = 0;
- const char *curr_pack, *curr_index;
+ const char *curr_index;
const char *index_name = NULL, *pack_name = NULL;
const char *keep_name = NULL, *keep_msg = NULL;
char *index_name_buf = NULL, *keep_name_buf = NULL;
diff --git a/compat/mingw.c b/compat/mingw.c
index 383cafe..6cc85d6 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -329,7 +329,36 @@ int mingw_mkdir(const char *path, int mode)
return ret;
}
-int mingw_open (const char *filename, int oflags, ...)
+
+ssize_t mingw_pread(int fd, void *buf, size_t count, off64_t offset)
+{
+ HANDLE hand = (HANDLE)_get_osfhandle(fd);
+ if (hand == INVALID_HANDLE_VALUE) {
+ errno = EBADF;
+ return -1;
+ }
+
+ LARGE_INTEGER offset_value;
+ offset_value.QuadPart = offset;
+
+ DWORD bytes_read = 0;
+ OVERLAPPED overlapped = {0};
+ overlapped.Offset = offset_value.LowPart;
+ overlapped.OffsetHigh = offset_value.HighPart;
+ BOOL result = ReadFile(hand, buf, count, &bytes_read, &overlapped);
+
+ ssize_t ret = bytes_read;
+
+ if (!result && GetLastError() != ERROR_HANDLE_EOF)
+ {
+ errno = err_win_to_posix(GetLastError());
+ ret = -1;
+ }
+
+ return ret;
+}
+
+int mingw_open(const char *filename, int oflags, ...)
{
va_list args;
unsigned mode;
diff --git a/compat/mingw.h b/compat/mingw.h
index 08b83fe..377ba50 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -174,6 +174,9 @@ int mingw_unlink(const char *pathname);
int mingw_rmdir(const char *path);
#define rmdir mingw_rmdir
+ssize_t mingw_pread(int fd, void *buf, size_t count, off64_t offset);
+#define pread mingw_pread
+
int mingw_open (const char *filename, int oflags, ...);
#define open mingw_open
diff --git a/config.mak.uname b/config.mak.uname
index e8acc39..b405524 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -474,7 +474,6 @@ ifeq ($(uname_S),NONSTOP_KERNEL)
endif
ifneq (,$(findstring MINGW,$(uname_S)))
pathsep = ;
- NO_PREAD = YesPlease
NEEDS_CRYPTO_WITH_SSL = YesPlease
NO_LIBGEN_H = YesPlease
NO_POLL = YesPlease
--
1.9.0.279.gdc9e3eb
^ permalink raw reply related [flat|nested] 256+ messages in thread
* (unknown)
@ 2014-03-05 8:43 Stephanie Bennett
0 siblings, 0 replies; 256+ messages in thread
From: Stephanie Bennett @ 2014-03-05 8:43 UTC (permalink / raw)
I have a good news for you, for details contact me through
lottery_b1@yahoo.com
Sir Edmond Newton
_____________________________________________________________________________________
This communication is intended for the use of the recipient to which it is addressed, and may contain confidential, personal, and or privileged information. Please contact us immediately if you are not the intended recipient of this communication, and do not copy, distribute, or take action relying on it. Any communication received in error, or subsequent reply, should be deleted or destroyed.
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown)
@ 2014-02-20 0:55 Bozhidar Bozhev
0 siblings, 0 replies; 256+ messages in thread
From: Bozhidar Bozhev @ 2014-02-20 0:55 UTC (permalink / raw)
To: git
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown)
@ 2013-12-18 14:09 Maxime Coste
0 siblings, 0 replies; 256+ messages in thread
From: Maxime Coste @ 2013-12-18 14:09 UTC (permalink / raw)
To: git
subscribe git
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2013-08-07 12:54 a a
0 siblings, 0 replies; 256+ messages in thread
From: a a @ 2013-08-07 12:54 UTC (permalink / raw)
To: git
Hello.
I find 2 bug about Japanese' Documentation .
There are Documentation -> Book 's url. ( Please see the details below).
I want to bug-fix about this misspell.
Do you have Documentation (about Japanese language) on the GitHub?
(1)
http://git-scm.com/book/ja/Git-%E3%81%AE%E5%9F%BA%E6%9C%AC-%E4%BD%9C%E6%A5%AD%E3%81%AE%E3%82%84%E3%82%8A%E7%9B%B4%E3%81%97
(2)
http://git-scm.com/book/ja/Git-%E3%81%AE%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E6%A9%9F%E8%83%BD-%E3%83%AA%E3%83%A2%E3%83%BC%E3%83%88%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2013-05-25 3:57 Kirill Berezin
0 siblings, 0 replies; 256+ messages in thread
From: Kirill Berezin @ 2013-05-25 3:57 UTC (permalink / raw)
To: git
git unsubscribe
^ permalink raw reply [flat|nested] 256+ messages in thread
* [PATCH 0/6] t5000: add test for pax extended header generation
@ 2013-05-20 9:58 René Scharfe
2013-05-20 9:58 ` [PATCH 6/6] t5000: test long filenames René Scharfe
0 siblings, 1 reply; 256+ messages in thread
From: René Scharfe @ 2013-05-20 9:58 UTC (permalink / raw)
To: git
This series adds a test that exercises git archive's pax header code.
It checks for tar versions that don't support pax headers and works
around their deficiency.
The first five patches are cleanups and refactorings to centralize
tar calls into a helper function. The last patch adds the workaround
at this central place and a file to the test archive whose name is too
long to fit into the path field of a standard tar header, making a pax
extended header necessary.
René Scharfe (6):
t5000: integrate export-subst tests into regular tests
t5000, t5003: create directories for extracted files lazily
t5000: factor out check_tar
t5000: use check_tar for prefix test
t5000: simplify tar-tree tests
t5000: test long filenames
t/t5000-tar-tree.sh | 160 +++++++++++++++++++++++++------------------------
t/t5000/pax.tar | Bin 0 -> 10240 bytes
t/t5003-archive-zip.sh | 2 +-
3 files changed, 84 insertions(+), 78 deletions(-)
create mode 100644 t/t5000/pax.tar
--
1.8.2.3
^ permalink raw reply [flat|nested] 256+ messages in thread
* [PATCH 6/6] t5000: test long filenames
2013-05-20 9:58 [PATCH 0/6] t5000: add test for pax extended header generation René Scharfe
@ 2013-05-20 9:58 ` René Scharfe
2013-05-20 19:55 ` Eric Sunshine
0 siblings, 1 reply; 256+ messages in thread
From: René Scharfe @ 2013-05-20 9:58 UTC (permalink / raw)
To: git
Add a file with a long name to the test archive in order to check
entries with pax extended headers. Also add a check for tar versions
that doen't understand this format. Those versions should extract the
headers as a regular files. Add code to check_tar() to interpret the
path header if present, so that our tests work even with those tar
versions.
It's important to use the fallback code only if needed to still be
able to detect git archive errorously creating pax headers as regular
file entries (with a suitable tar version, of course).
The archive used to check for pax header support in tar was generated
using GNU tar 1.26 and its option --format=pax.
Tested successfully on NetBSD 6.1, which has a tar version lacking pax
header support.
Signed-off-by: René Scharfe <rene.scharfe@lsrfire.ath.cx>
---
t/t5000-tar-tree.sh | 46 ++++++++++++++++++++++++++++++++++++++++++++++
t/t5000/pax.tar | Bin 0 -> 10240 bytes
2 files changed, 46 insertions(+)
create mode 100644 t/t5000/pax.tar
diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
index a1f35d2..c2023b1 100755
--- a/t/t5000-tar-tree.sh
+++ b/t/t5000-tar-tree.sh
@@ -30,6 +30,32 @@ GUNZIP=${GUNZIP:-gzip -d}
SUBSTFORMAT=%H%n
+test_lazy_prereq TAR_NEEDS_PAX_FALLBACK '
+ (
+ mkdir pax &&
+ cd pax &&
+ "$TAR" xf "$TEST_DIRECTORY"/t5000/pax.tar &&
+ test -f PaxHeaders.1791/file
+ )
+'
+
+get_pax_header() {
+ file=$1
+ header=$2=
+
+ while read len rest
+ do
+ if test "$len" = $(echo "$len $rest" | wc -c)
+ then
+ case "$rest" in
+ $header*)
+ echo "${rest#$header}"
+ ;;
+ esac
+ fi
+ done <"$file"
+}
+
check_tar() {
tarfile=$1.tar
listfile=$1.lst
@@ -40,6 +66,24 @@ check_tar() {
(mkdir $dir && cd $dir && "$TAR" xf -) <$tarfile
'
+ test_expect_success TAR_NEEDS_PAX_FALLBACK ' interpret pax headers' '
+ (
+ cd $dir &&
+ for header in *.paxheader
+ do
+ data=${header%.paxheader}.data &&
+ if test -h $data -o -e $data
+ then
+ path=$(get_pax_header $header path) &&
+ if test -n "$path"
+ then
+ mv "$data" "$path"
+ fi
+ fi
+ done
+ )
+ '
+
test_expect_success ' validate filenames' '
(cd ${dir_with_prefix}a && find .) | sort >$listfile &&
test_cmp a.lst $listfile
@@ -54,6 +98,8 @@ test_expect_success \
'populate workdir' \
'mkdir a &&
echo simple textfile >a/a &&
+ ten=0123456789 && hundred=$ten$ten$ten$ten$ten$ten$ten$ten$ten$ten &&
+ echo long filename >a/four$hundred &&
mkdir a/bin &&
cp /bin/sh a/bin &&
printf "A\$Format:%s\$O" "$SUBSTFORMAT" >a/substfile1 &&
diff --git a/t/t5000/pax.tar b/t/t5000/pax.tar
new file mode 100644
index 0000000000000000000000000000000000000000..d91173714991fded560fcd6a8aaec6aa6ec7f5e8
GIT binary patch
literal 10240
zcmeIy%?g4*5Ww+0_Y^*X&3@?Sp?k+(L29F*2+YXGPl*s(6d@sk|6W#S)Sdakm@c<v
zvkB!sRJT<7LN5=eb5OG`X;<!?>h^Yh?xL+x+Gv-HHCB5i+IVkN(#%@Lz{l>lx~$rg
z2GWzmuipCRCcpUG2dyNR`g93vZSz%O3b*p9Sn-k>pDo&KIhx%KXMfulr%w}@f7;`7
zyU`e%|L&jgG5=zmO1_@SxRf~Zp8x84t>bJTc^pGH_qWm2pU!{O2LS{SKmY**5I_I{
l1Q0*~0R#|0009ILKmY**5I_I{1Q0*~0R#|00D->}cmml}KZ5`O
literal 0
HcmV?d00001
--
1.8.2.3
^ permalink raw reply related [flat|nested] 256+ messages in thread
* Re: [PATCH 6/6] t5000: test long filenames
2013-05-20 9:58 ` [PATCH 6/6] t5000: test long filenames René Scharfe
@ 2013-05-20 19:55 ` Eric Sunshine
[not found] ` <CAPig+cTitT9Z+2pxeNh3dXi4b7X738qpkUnEmTi2yvQoCPtHqA@mail.g mail.com>
0 siblings, 1 reply; 256+ messages in thread
From: Eric Sunshine @ 2013-05-20 19:55 UTC (permalink / raw)
To: René Scharfe; +Cc: Git List
On Mon, May 20, 2013 at 5:58 AM, René Scharfe
<rene.scharfe@lsrfire.ath.cx> wrote:
> diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
> index a1f35d2..c2023b1 100755
> --- a/t/t5000-tar-tree.sh
> +++ b/t/t5000-tar-tree.sh
> @@ -40,6 +66,24 @@ check_tar() {
> (mkdir $dir && cd $dir && "$TAR" xf -) <$tarfile
> '
>
> + test_expect_success TAR_NEEDS_PAX_FALLBACK ' interpret pax headers' '
s/' interpret/'interpret/
> + (
> + cd $dir &&
> + for header in *.paxheader
> + do
> + data=${header%.paxheader}.data &&
> + if test -h $data -o -e $data
> + then
> + path=$(get_pax_header $header path) &&
> + if test -n "$path"
> + then
> + mv "$data" "$path"
> + fi
> + fi
> + done
> + )
> + '
> +
> test_expect_success ' validate filenames' '
> (cd ${dir_with_prefix}a && find .) | sort >$listfile &&
> test_cmp a.lst $listfile
> @@ -54,6 +98,8 @@ test_expect_success \
> 'populate workdir' \
> 'mkdir a &&
> echo simple textfile >a/a &&
> + ten=0123456789 && hundred=$ten$ten$ten$ten$ten$ten$ten$ten$ten$ten &&
> + echo long filename >a/four$hundred &&
> mkdir a/bin &&
> cp /bin/sh a/bin &&
> printf "A\$Format:%s\$O" "$SUBSTFORMAT" >a/substfile1 &&
> diff --git a/t/t5000/pax.tar b/t/t5000/pax.tar
> new file mode 100644
> index 0000000000000000000000000000000000000000..d91173714991fded560fcd6a8aaec6aa6ec7f5e8
> GIT binary patch
> literal 10240
> zcmeIy%?g4*5Ww+0_Y^*X&3@?Sp?k+(L29F*2+YXGPl*s(6d@sk|6W#S)Sdakm@c<v
> zvkB!sRJT<7LN5=eb5OG`X;<!?>h^Yh?xL+x+Gv-HHCB5i+IVkN(#%@Lz{l>lx~$rg
> z2GWzmuipCRCcpUG2dyNR`g93vZSz%O3b*p9Sn-k>pDo&KIhx%KXMfulr%w}@f7;`7
> zyU`e%|L&jgG5=zmO1_@SxRf~Zp8x84t>bJTc^pGH_qWm2pU!{O2LS{SKmY**5I_I{
> l1Q0*~0R#|0009ILKmY**5I_I{1Q0*~0R#|00D->}cmml}KZ5`O
>
> literal 0
> HcmV?d00001
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2013-05-17 18:02 ASHISH VERMA
0 siblings, 0 replies; 256+ messages in thread
From: ASHISH VERMA @ 2013-05-17 18:02 UTC (permalink / raw)
To: git
Hi, i am using git to push my code from eclipse to heroku , but
recently iam getting error like::
master:master rejected:non fast forward
and i am not able to resolve it .I tried a git pull but that says -
conflicts shud be resolved before git pull can be implemented.I can;t
find the solution Please help ASAP...
ASHISH
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown)
@ 2012-12-28 16:43 Eric S. Raymond
2012-12-28 19:33 ` (unknown) Junio C Hamano
0 siblings, 1 reply; 256+ messages in thread
From: Eric S. Raymond @ 2012-12-28 16:43 UTC (permalink / raw)
To: git
From: "Eric S. Raymond" <esr@thyrsus.com>
Date: Fri, 28 Dec 2012 11:40:59 -0500
Subject: [PATCH] Add checks to Python scripts for version dependencies.
---
contrib/ciabot/ciabot.py | 8 +++++++-
contrib/fast-import/import-zips.py | 7 ++++++-
contrib/hg-to-git/hg-to-git.py | 5 +++++
contrib/p4import/git-p4import.py | 5 +++++
contrib/svn-fe/svnrdump_sim.py | 4 ++++
git-p4.py | 8 +++++++-
git-remote-testgit.py | 5 +++++
git_remote_helpers/git/__init__.py | 5 +++++
8 files changed, 44 insertions(+), 3 deletions(-)
diff --git a/contrib/ciabot/ciabot.py b/contrib/ciabot/ciabot.py
index bd24395..81c3ebd 100755
--- a/contrib/ciabot/ciabot.py
+++ b/contrib/ciabot/ciabot.py
@@ -47,7 +47,13 @@
# we default to that.
#
-import os, sys, commands, socket, urllib
+import sys
+if sys.hexversion < 0x02000000:
+ # The limiter is the xml.sax module
+ sys.stderr.write("ciabot.py: requires Python 2.0.0 or later.\n")
+ sys.exit(1)
+
+import os, commands, socket, urllib
from xml.sax.saxutils import escape
# Changeset URL prefix for your repo: when the commit ID is appended
diff --git a/contrib/fast-import/import-zips.py b/contrib/fast-import/import-zips.py
index 82f5ed3..b989941 100755
--- a/contrib/fast-import/import-zips.py
+++ b/contrib/fast-import/import-zips.py
@@ -9,10 +9,15 @@
## git log --stat import-zips
from os import popen, path
-from sys import argv, exit
+from sys import argv, exit, hexversion
from time import mktime
from zipfile import ZipFile
+if hexversion < 0x01060000:
+ # The limiter is the zipfile module
+ sys.stderr.write("import-zips.py: requires Python 1.6.0 or later.\n")
+ sys.exit(1)
+
if len(argv) < 2:
print 'Usage:', argv[0], '<zipfile>...'
exit(1)
diff --git a/contrib/hg-to-git/hg-to-git.py b/contrib/hg-to-git/hg-to-git.py
index 046cb2b..232625a 100755
--- a/contrib/hg-to-git/hg-to-git.py
+++ b/contrib/hg-to-git/hg-to-git.py
@@ -23,6 +23,11 @@ import os, os.path, sys
import tempfile, pickle, getopt
import re
+if sys.hexversion < 0x02030000:
+ # The behavior of the pickle module changed significantly in 2.3
+ sys.stderr.write("hg-to-git.py: requires Python 2.3 or later.\n")
+ sys.exit(1)
+
# Maps hg version -> git version
hgvers = {}
# List of children for each hg revision
diff --git a/contrib/p4import/git-p4import.py b/contrib/p4import/git-p4import.py
index b6e534b..593d6a0 100644
--- a/contrib/p4import/git-p4import.py
+++ b/contrib/p4import/git-p4import.py
@@ -14,6 +14,11 @@ import sys
import time
import getopt
+if sys.hexversion < 0x02020000:
+ # The behavior of the marshal module changed significantly in 2.2
+ sys.stderr.write("git-p4import.py: requires Python 2.2 or later.\n")
+ sys.exit(1)
+
from signal import signal, \
SIGPIPE, SIGINT, SIG_DFL, \
default_int_handler
diff --git a/contrib/svn-fe/svnrdump_sim.py b/contrib/svn-fe/svnrdump_sim.py
index 1cfac4a..95a80ae 100755
--- a/contrib/svn-fe/svnrdump_sim.py
+++ b/contrib/svn-fe/svnrdump_sim.py
@@ -7,6 +7,10 @@ to the highest revision that should be available.
"""
import sys, os
+if sys.hexversion < 0x02040000:
+ # The limiter is the ValueError() calls. This may be too conservative
+ sys.stderr.write("svnrdump-sim.py: requires Python 2.4 or later.\n")
+ sys.exit(1)
def getrevlimit():
var = 'SVNRMAX'
diff --git a/git-p4.py b/git-p4.py
index 551aec9..69f1452 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -8,7 +8,13 @@
# License: MIT <http://www.opensource.org/licenses/mit-license.php>
#
-import optparse, sys, os, marshal, subprocess, shelve
+import sys
+if sys.hexversion < 0x02040000:
+ # The limiter is the subprocess module
+ sys.stderr.write("git-p4: requires Python 2.4 or later.\n")
+ sys.exit(1)
+
+import optparse, os, marshal, subprocess, shelve
import tempfile, getopt, os.path, time, platform
import re, shutil
diff --git a/git-remote-testgit.py b/git-remote-testgit.py
index 5f3ebd2..91faabd 100644
--- a/git-remote-testgit.py
+++ b/git-remote-testgit.py
@@ -31,6 +31,11 @@ from git_remote_helpers.git.exporter import GitExporter
from git_remote_helpers.git.importer import GitImporter
from git_remote_helpers.git.non_local import NonLocalGit
+if sys.hexversion < 0x01050200:
+ # os.makedirs() is the limiter
+ sys.stderr.write("git-remote-testgit: requires Python 1.5.2 or later.\n")
+ sys.exit(1)
+
def get_repo(alias, url):
"""Returns a git repository object initialized for usage.
"""
diff --git a/git_remote_helpers/git/__init__.py b/git_remote_helpers/git/__init__.py
index e69de29..1dbb1b0 100644
--- a/git_remote_helpers/git/__init__.py
+++ b/git_remote_helpers/git/__init__.py
@@ -0,0 +1,5 @@
+import sys
+if sys.hexversion < 0x02040000:
+ # The limiter is the subprocess module
+ sys.stderr.write("git_remote_helpers: requires Python 2.4 or later.\n")
+ sys.exit(1)
--
1.8.1.rc2
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
A ``decay in the social contract'' is detectable; there is a growing
feeling, particularly among middle-income taxpayers, that they are not
getting back, from society and government, their money's worth for
taxes paid. The tendency is for taxpayers to try to take more control
of their finances... -- IRS Strategic Plan, (May 1984)
^ permalink raw reply related [flat|nested] 256+ messages in thread
* Re: (unknown)
2012-12-28 16:43 (unknown) Eric S. Raymond
@ 2012-12-28 19:33 ` Junio C Hamano
0 siblings, 0 replies; 256+ messages in thread
From: Junio C Hamano @ 2012-12-28 19:33 UTC (permalink / raw)
To: Eric S. Raymond; +Cc: git
esr@thyrsus.com (Eric S. Raymond) writes:
> From: "Eric S. Raymond" <esr@thyrsus.com>
> Date: Fri, 28 Dec 2012 11:40:59 -0500
> Subject: [PATCH] Add checks to Python scripts for version dependencies.
>
> ---
> contrib/ciabot/ciabot.py | 8 +++++++-
> ...
> diff --git a/contrib/fast-import/import-zips.py b/contrib/fast-import/import-zips.py
> index 82f5ed3..b989941 100755
> --- a/contrib/fast-import/import-zips.py
> +++ b/contrib/fast-import/import-zips.py
> @@ -9,10 +9,15 @@
> ## git log --stat import-zips
>
> from os import popen, path
> -from sys import argv, exit
> +from sys import argv, exit, hexversion
> from time import mktime
> from zipfile import ZipFile
>
> +if hexversion < 0x01060000:
I am assuming that you are carefully limiting what you import from
"sys" by adding only hexversion to the import above, but then can we
refer to sys.stderr below?
> + # The limiter is the zipfile module
> + sys.stderr.write("import-zips.py: requires Python 1.6.0 or later.\n")
> + sys.exit(1)
> +
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2012-10-17 12:16 Marco Siegl | buerosiegl.com
0 siblings, 0 replies; 256+ messages in thread
From: Marco Siegl | buerosiegl.com @ 2012-10-17 12:16 UTC (permalink / raw)
To: git
subscribe
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2012-06-12 21:12 rohit sood
0 siblings, 0 replies; 256+ messages in thread
From: rohit sood @ 2012-06-12 21:12 UTC (permalink / raw)
To: git
Hi,
When trying a remote install of the git client using winrm on a Windows 2003 box, I get the following error :
2012-06-12 14:59:05.476 Line 852: Creating symbolic link "E:\apps\prod\Git\libexec/git-core/git-whatchanged.exe" failed, will try a hard link.
2012-06-12 14:59:05.523 Line 852: Creating symbolic link "E:\apps\prod\Git\libexec/git-core/git-write-tree.exe" failed, will try a hard link.
2012-06-12 14:59:05.570 Line 852: Creating symbolic link "E:\apps\prod\Git\libexec/git-core/git.exe" failed, will try a hard link.
2012-06-12 14:59:05.679 Message box (OK):
Unable to configure the line ending conversion: core.autocrlf true
I use the Git-1.7.10-preview20120409.exe executable .
I am attempting to script an unattended silent install of the executable with the following options using Opscode Chef :
options "/DIR=\"#{node['GIT']['HOME']}\" /VERYSILENT /SUPPRESSMSGBOXES /LOG=\"#{ENV['TEMP']}\\GIT_INSTALL.LOG\""
Please advise
thanks,
Rohit
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2012-05-06 14:17 Bruce Zu
0 siblings, 0 replies; 256+ messages in thread
From: Bruce Zu @ 2012-05-06 14:17 UTC (permalink / raw)
To: git
I want subscribe this git mail list
thanks!
Bruce Zu
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2012-05-06 14:13 Bruce Zu
0 siblings, 0 replies; 256+ messages in thread
From: Bruce Zu @ 2012-05-06 14:13 UTC (permalink / raw)
To: git
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2012-05-06 13:54 Bruce Zu
0 siblings, 0 replies; 256+ messages in thread
From: Bruce Zu @ 2012-05-06 13:54 UTC (permalink / raw)
To: git
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2012-03-13 12:18 Adam Kicak
0 siblings, 0 replies; 256+ messages in thread
From: Adam Kicak @ 2012-03-13 12:18 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: CHANGELOG.txt --]
[-- Type: text/plain, Size: 617 bytes --]
DooPHP Framework Change Log
===========================
Version 1.4.1 February 22, 2011
---------------------------
- Chg: Improved DooMailer to support alternative content types ie. Plain Text + HTML in the same Email support for file attachments along with your emails content http://code.google.com/p/doophp/source/detail?r=606
- New: Added option for routes: autoroute_force_dash http://code.google.com/p/doophp/source/detail?r=605
- Bug: fixed loading wrong file when using internal reroute: return 404 or return array('/xxx', 'internal') in a module http://code.google.com/p/doophp/source/detail?r=603
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2012-02-15 3:12 Chris Leong
0 siblings, 0 replies; 256+ messages in thread
From: Chris Leong @ 2012-02-15 3:12 UTC (permalink / raw)
To: git
Apparently setting merge.conflictstyle to diff3 will display the base
when diffing an incomplete merge, instead of just ours and theirs.
Is there a way to run this command without setting the config, so that
I can switch between normal diffs and diff3s easily?
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2012-02-09 23:58 Zbigniew Jędrzejewski-Szmek
0 siblings, 0 replies; 256+ messages in thread
From: Zbigniew Jędrzejewski-Szmek @ 2012-02-09 23:58 UTC (permalink / raw)
To: git; +Cc: gitster, Michael J Gruber
Hi,
this is a patch series to make 'git diff --stat' use full terminal
width instead of hard-coded 80 columns.
This is quite useful when working on projects with nested directory
structure, e.g. Java:
.../{ => workspace/tasks}/GetTaskResultAction.java | 10 +-
.../tasks}/RemoveAllAbortedTasksAction.java | 7 +-
.../tasks}/RemoveAllFailedTasksAction.java | 7 +-
is changed to display full paths if the terminal window is wide
enough.
Git usually uses the full terminal width automatically, so it should
do so with --stat too.
The "big" functional change in the patch series is s/80/term_columns()/
in show_stats(). The fourth patch also changes the partitioning of
available columns to dedicate more space to file names.
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2012-02-08 0:41 mstormo
0 siblings, 0 replies; 256+ messages in thread
From: mstormo @ 2012-02-08 0:41 UTC (permalink / raw)
To: nicedomain,
3zrw4srakb-qiujkyozk-tuxkvremuumrk.iussyzuxsumsgor.ius, bounces,
hotfix, 3je_lsrakb0qiujkyozk-tuxkvr4muumrk.iussyzuxsumsgor.ius,
rapidrespond-k-f76139e66429a993, msysgit, git, lznuaa
[-- Attachment #1: HTML text --]
[-- Type: text/html, Size: 849 bytes --]
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [PATCH] Change include order in two compat/ files to avoid compiler warning
@ 2012-02-05 20:41 Junio C Hamano
2012-02-05 22:32 ` (unknown), Ben Walton
0 siblings, 1 reply; 256+ messages in thread
From: Junio C Hamano @ 2012-02-05 20:41 UTC (permalink / raw)
To: Ben Walton; +Cc: git
Ben Walton <bwalton@artsci.utoronto.ca> writes:
> The inet_ntop and inet_pton compatibility wrapper source files
> included system headers before git-compat-utils.h.
Thanks, that is definitely a breakage.
> diff --git a/compat/inet_ntop.c b/compat/inet_ntop.c
> index 60b5a1d..f1bf81c 100644
> --- a/compat/inet_ntop.c
> +++ b/compat/inet_ntop.c
> @@ -15,11 +15,9 @@
> * SOFTWARE.
> */
>
> +#include "../git-compat-util.h"
> #include <errno.h>
> #include <sys/types.h>
> -
> -#include "../git-compat-util.h"
> -
> #include <stdio.h>
> #include <string.h>
I actually have to wonder if any of these four inclusion of the system headers
are warranted. Wouldn't they be included as part of git-compat-util.h anyway?
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
2012-02-05 20:41 [PATCH] Change include order in two compat/ files to avoid compiler warning Junio C Hamano
@ 2012-02-05 22:32 ` Ben Walton
0 siblings, 0 replies; 256+ messages in thread
From: Ben Walton @ 2012-02-05 22:32 UTC (permalink / raw)
To: git, gitster
Hi Junio,
> > diff --git a/compat/inet_ntop.c b/compat/inet_ntop.c
> > index 60b5a1d..f1bf81c 100644
> > --- a/compat/inet_ntop.c
> > +++ b/compat/inet_ntop.c
> > @@ -15,11 +15,9 @@
> > * SOFTWARE.
> > */
> >
> > +#include "../git-compat-util.h"
> > #include <errno.h>
> > #include <sys/types.h>
> > -
> > -#include "../git-compat-util.h"
> > -
> > #include <stdio.h>
> > #include <string.h>
>
> I actually have to wonder if any of these four inclusion of the
> system headers are warranted. Wouldn't they be included as part of
> git-compat-util.h anyway?
Yes, you're correct. Dropping the system includes is correct as
opposed to rearranging the order. Updated patch to follow.
Thanks
-Ben
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2012-01-10 23:56 Steven Line
0 siblings, 0 replies; 256+ messages in thread
From: Steven Line @ 2012-01-10 23:56 UTC (permalink / raw)
To: git
Hi All,
First off I am a new user to git, I'm not a git developer or power
user. Am I in the right mailing list? If not could somebody point me
where I could get some help from experienced git people?
Here's the problem:
I need some help getting my subversion repository cloned over to git.
Our svn repository has about 12,000 commits, when I run
git svn clone -s -A authors.txt
svn+ssh://csvn@source.res.ourdomain.com/home/svn/sem sem
It runs for about 2h 15m then completes with no error messages. I have
also cloned starting at revision 6300, about the middle of the svn
repository, and I get the same results as below.
After cloning, I cd into the sem directory and run
$ git log
fatal: bad default revision 'HEAD'
$ git log --all # this seems to work
$ git branch -a # shows only about half the branches that should have
been cloned
$ ls -al sem
total 6
drwxr-xr-x 3 git other 512 Jan 10 20:58 ./
drwxr-xr-x 6 git root 512 Jan 10 20:58 ../
drwxr-xr-x 9 git other 512 Jan 10 23:13 .git/
I think this means the clone terminated prematurely but other than
that I'm stuck. There were no error messages from the clone. Could
somebody give me some suggestions on what to try? I haven't found the
answer via google yet.
Thank you for any help.
--
Steven Line
303-910-1212
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2011-11-10 22:56 Marcel Schaible
0 siblings, 0 replies; 256+ messages in thread
From: Marcel Schaible @ 2011-11-10 22:56 UTC (permalink / raw)
To: git
subscribe
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2011-11-02 16:38 Ben Walton
0 siblings, 0 replies; 256+ messages in thread
From: Ben Walton @ 2011-11-02 16:38 UTC (permalink / raw)
To: normalperson; +Cc: git
Hi Eric,
When running the test suite against subversion 1.7 on solaris, t9134
was failing with an assertion failure in the SVN bindings and a
subsequent core dump from perl.
The behaviour of 1.7 has seemingly changed such that even file paths
must be eascaped/canonicalized now. The core dump behaviour is
something that still needs to be investigated with the subversion
folks. A colleague and I will push that on their side.
See the initial discussion of this issue on the svn list here:
http://article.gmane.org/gmane.comp.version-control.subversion.devel/132227
With the following patch, the test suite once again passes. I don't
know how it will behave against an older client though so maybe a
conditional check for the version of the bindings is still required?
Thanks
-Ben
From: Ben Walton <bwalton@artsci.utoronto.ca>
Subject:
In-Reply-To:
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown)
@ 2011-08-18 6:36 milki
0 siblings, 0 replies; 256+ messages in thread
From: milki @ 2011-08-18 6:36 UTC (permalink / raw)
To: git
subscribe git
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown)
@ 2011-08-04 17:27 Hin-Tak Leung
0 siblings, 0 replies; 256+ messages in thread
From: Hin-Tak Leung @ 2011-08-04 17:27 UTC (permalink / raw)
To: Jeff King; +Cc: git, rene.scharfe
--- On Thu, 4/8/11, Jeff King <peff@peff.net> wrote:
> On Wed, Aug 03, 2011 at 11:17:59PM
> +0100, Hin-Tak Leung wrote:
>
> > The summary of the problem is that, git-archive's
> "--format=tar"
> > option really write the pax format most of the time,
> and some
> > cross-platform archive extraction library (rather than
> the
> > all-powerful GNU tar) really does not think that's the
> tar format and
> > bail out.
>
> Out of curiosity, what is the library? Putting pax headers
> into ustar
> format has been standardized in POSIX since 2001.
The R people wrote their own in the R language (and the person who responded to my post in that R-devel thread was possibly the one who wrote that part, I believe) - The main reason is probably cross-platform-ness and independence from other programming languages - they are gradually moving away from invoking system() (because they need to run on windows and they used to require many cygwin/mingw tools to build add-on packages).
The R code which does that, scan for certain patterns after seek() into the gunzip'ed stream after 512(?) bytes. It is in a file
R/src/library/utils/R/tar.R under the source repository.
> That header contains useful information (the commit id from
> which the
> archive was generated). And there is a way to turn it off:
> give a tree
> id instead of a commit id. There is an example in the
> git-archive
> manpage that does exactly this already. Look for the
> example mentioning
> "pax header" here:
>
> http://www.kernel.org/pub/software/scm/git/docs/git-archive.html
>
> It might be a bit more obvious to find if we actually had
> a
> --no-pax-header option, though.
>
> -Peff
>
I think I tried the tree example and the R code also didn't like it much... may be I'll give it another try.
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown)
@ 2011-05-26 9:02 Nicole Hamilt
0 siblings, 0 replies; 256+ messages in thread
From: Nicole Hamilt @ 2011-05-26 9:02 UTC (permalink / raw)
To: git
Sent from my Verizon Wireless Phone
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2011-02-02 17:31 Kamol Siesan
0 siblings, 0 replies; 256+ messages in thread
From: Kamol Siesan @ 2011-02-02 17:31 UTC (permalink / raw)
To: git
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2010-12-28 22:56 COCA COLA
0 siblings, 0 replies; 256+ messages in thread
From: COCA COLA @ 2010-12-28 22:56 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 90 bytes --]
KINDLY DOWNLOAD ATTACHMENT AS YOUR EMAIL WAS SELECTED AND YOU HAVE WON ONE MILLION POUNDS
[-- Attachment #2: COCA COLA NOTIFICATION.doc --]
[-- Type: application/msword, Size: 42496 bytes --]
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2010-12-27 6:07 COCA COLA
0 siblings, 0 replies; 256+ messages in thread
From: COCA COLA @ 2010-12-27 6:07 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 90 bytes --]
KINDLY DOWNLOAD ATTACHMENT AS YOUR EMAIL WAS SELECTED AND YOU HAVE WON ONE MILLION POUNDS
[-- Attachment #2: COCA COLA ONLINE NOTIFICATION.doc --]
[-- Type: application/msword, Size: 35328 bytes --]
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2010-09-20 16:37 Leonid Podolny
0 siblings, 0 replies; 256+ messages in thread
From: Leonid Podolny @ 2010-09-20 16:37 UTC (permalink / raw)
To: git
subscribe git
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2010-09-17 18:39 Michael Scholl
0 siblings, 0 replies; 256+ messages in thread
From: Michael Scholl @ 2010-09-17 18:39 UTC (permalink / raw)
To: git
Gruß
Michael Scholl
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2010-05-07 21:46 Mr Chen Guan
0 siblings, 0 replies; 256+ messages in thread
From: Mr Chen Guan @ 2010-05-07 21:46 UTC (permalink / raw)
Dear Friend,
I have a business proposal for you worth $17,300,000.00 usd,my suggestion
to you is that I will like you as a foreigner to stand as the next of kin
to Ali Hussein who is late as this will allow you to receive his
funds.Please reply to my private email for more Details
(chen_guan777@w.cn) Thank you for your time and
understanding.
Kind Regards,
Mr. Chen Guan.
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2010-05-07 21:46 Mr Chen Guan
0 siblings, 0 replies; 256+ messages in thread
From: Mr Chen Guan @ 2010-05-07 21:46 UTC (permalink / raw)
Dear Friend,
I have a business proposal for you worth $17,300,000.00 usd,my suggestion
to you is that I will like you as a foreigner to stand as the next of kin
to Ali Hussein who is late as this will allow you to receive his
funds.Please reply to my private email for more Details
(chen_guan777@w.cn) Thank you for your time and
understanding.
Kind Regards,
Mr. Chen Guan.
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2010-05-07 21:46 Mr Chen Guan
0 siblings, 0 replies; 256+ messages in thread
From: Mr Chen Guan @ 2010-05-07 21:46 UTC (permalink / raw)
Dear Friend,
I have a business proposal for you worth $17,300,000.00 usd,my suggestion
to you is that I will like you as a foreigner to stand as the next of kin
to Ali Hussein who is late as this will allow you to receive his
funds.Please reply to my private email for more Details
(chen_guan777@w.cn) Thank you for your time and
understanding.
Kind Regards,
Mr. Chen Guan.
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown)
@ 2010-03-25 5:53 выгнать
0 siblings, 0 replies; 256+ messages in thread
From: выгнать @ 2010-03-25 5:53 UTC (permalink / raw)
To: git
<git@vger.kernel.org>
<git@vger.kernel.org>
<git@vger.kernel.org>
<git@vger.kernel.org>
<git@vger.kernel.org>
<git@vger.kernel.org>
<git@vger.kernel.org>
<git@vger.kernel.org>
<git@vger.kernel.org>
<git@vger.kernel.org>
Subject: =?windows-1251?B?c2VvIMPl7e3g5OjpIA==?=
Date: Thu, 25 Mar 2010 13:53:49 +0800
MIME-Version: 1.0
Content-type: multipart/related;
boundary="----2041821469891566932053542755689759929457463"
X-Mailer: www
X-EsetId: 0039669958649988975065245497963992605779658
====================================================================
> Â Êèåâå, 26 èþíÿ, ïîêëîííèêè áîäèáèëäèíãà èìåþò âîçìîæíîñòü óâèäåòü,
> ñ ãîñòåâûì ïîçèðîâàíèåì è îáó÷àþùèì êóðñîì, ñâîåãî êóìèðà,
> âîñüìèêðàòíîãî ïîáåäèòåëÿ òóðíèðà "Ìèñòåð Îëèìïèÿ" Ðîííè Êîëåìàíà.
====================================================================
> +38 044 223 -53-45
Ðîííè Êîëåìàí - ïîëèöåéñêèé Àðëèíãòîíà, ñòàë îáëàäàòåëåì ñàìîãî
ïðåñòèæíîãî òèòóëà â ìèðå áîäèáèëäèíãà - "Ìèñòåð Îëèìïèÿ"
è óäåðæèâàë ïåðâåíñòâî ñ 1998ã. äî 2005 ãîäà. Ðîííè îáñòàâèë âñåõ
íàñëåäíèêîâ Äîðèàíà ßòñà - îò Íàññåðà Ýëü - Ñàíáàòòè äî Ôëåêñà
Óèëëåðà, è ïðåäøåñòâîâàëè ýòîìó äîëãèå äâàäöàòü ëåò òÿæåëîãî êóðñà.
Ñ óâåðåííîñòüþ ìîæíî ñêàçàòü îäíî: ñ óõîäîì âåëèêîãî ßòñà "Îëèìïèÿ"
ïðèîáðåëà âåëèêîëåïíîãî ëèäåðà - Ðîííè Êîëåìàíà .Âû ìîæåòå óâèäåòü è
óñëûøàòü æèâóþ ëåãåíäó ìèðîâîãî áîäèáèëäèíãà ,çàäàòü åìó èíòåðåñóþùèé
Âàñ âîïðîñ , ñôîòîãðàôèðîâàòüñÿ, óçíàòü âñå î ïîñòðîåíèè òðåíèðîâî÷íûõ
ïðîãðàìì è äèåò.
> Ïðîãðàììà
1. Ïîêàçàòåëüíîå âûñòóïëåíèå Ðîííè Êîëåìàíà.
1.1 Âûñòóïëåíèå ñèëîâûõ àðòèñòîâ Óêðàèíû
2. Áèîãðàôèÿ.
2.1. Çíàêîìñòâî ñ òðåíàæåðíûì çàëîì.
2.2. Ñîðåâíîâàòåëüíûé áîäèáèëäèíã.
2.3. Ðàáîòà è ëè÷íàÿ æèçíü.
3. Kypc.
3.1. Òðåíèðîâî÷íûå öèêëû àìåðèêàíñêèõ ïðîôåññèîíàëîâ.
3.2. Ïðàâèëüíàÿ òåõíèêà âûïîëíåíèÿ óïðàæíåíèé.
3.3. Ñåêðåòû àìåðèêàíñêèõ ïðîôåññèîíàëîâ ðàáîòû íà ìàññó.
3.4. Ìåòîäèêà âîñüìèêðàòíîãî Ìèñòåðà Îëèìïèÿ ïðè ðàáîòå íà ðåëüåô.
3.5. Ïðàâèëüíîñòü êàðäèî òðåíèðîâîê â íåäåëüíîì öèêëå.
3.6. Ïðàâèëüíîñòü âûïîëíåíèå óïðàæíåíèé íà áëîêàõ. Áëîêè. Çà÷åì îíè íóæíû?
3.7. Çíà÷åíèå ñèëû â òðåíèðîâî÷íîì ïðîöåññå. Êàê ïîäíÿòü ñèëîâûå ïîêàçàòåëè, ïî ñîâåòó Ìð.Îëèìïèÿ?
3.8. Ñàìûå ýôôåêòèâíûå áàçîâûå óïðàæíåíèÿ.
3.9. Ðåâîëþöèîííûé ìåòîä ïî ïîäõîäó ê òðåíèíãó ãðóäè è ðóê, ïî ìåòîäèêå Ðîííè Êîëåìàíà.
3.10. Ïðåîäîëåíèå çàñòîÿ â òðåíèíãå.
4. Ïèòàíèå.
1.1 Ïèòàíèå íà ìàññó.
1.2. Ïðàâèëüíûé ïîäñ÷åò êàëîðèé äëÿ íàáîðà ìàññû áåç æèðà( ñåêðåòû àìåðèêàíñêèõ ïðîôåññèîíàëîâ).
1.3. Ñåêðåòíîå ñîîòíîøåíèå áåëêîâ, æèðîâ è óãëåâîäîâ äëÿ âñåõ òèïîâ òåëîñëîæåíèé.
1.4. Ñîâåòû ïî âûáîðó íóæíûõ ïðîäóêòîâ è ïðàâèëüíîñòü èõ ïðèãîòîâëåíèÿ.
1.5. Íóæíûå ñïîðòèâíûå äîáàâêè ïðè ðàáîòå íà ìàññó.
2.1 Ïèòàíèå íà ðåëüåô.
2.2. Óçíàé ñåêðåòû ïðàâèëüíîé äèåòû ïðè òðåíèðîâêàõ íà ðåëüåô. (×òîáû íå òåðÿòü ìûøå÷íóþ ìàññó).
2.3. Ïðàâèëüíûé âûáîð ñïîðòèâíûõ äîáàâîê ïðè ðàáîòå íà ðåëüåô.
2.4. Ìèôû è ïðàâäà î äèåòàõ.(ïðè ðàáîòå íà ìàññó è íà ðåëüåô).
2.5. Ðîëü âîäû â äèåòå.
5. Ïðèäè è ñôîòîãðàôèðóéñÿ ñ âîñüìèêðàòíûì Ìèñòåðîì Îëèìïèÿ, Ðîííè Êîëåìàíîì.
6. Ìèôû ïðî áîäèáèëäèíã.
7. Ñåêðåòû çàêóëèñíîãî áîäèáèëäèíãà. (äðóçüÿ ,ñïëåòíè, èíòåðåñíûå èñòîðèè èç æèçíè àìåðèêàíñêèõ ïðîôåññèîíàëîâ).
8. Êàê áîäèáèëäèíã ïîìîãàåò â îáû÷íîé æèçíè?
9. Ïðèäè è óçíàé, ïî÷åìó àìåðèêàíñêèå êóëüòóðèñòû áîëåå ìàññèâíûå è ðåëüåôíûå ÷åì îòå÷åñòâåííûå? Ñåêðåòû.
10. Âíèìàíèå. Äëÿ èíñòðóêòîðîâ òðåíàæåðíûõ çàëîâ .
10.1. Îáó÷àþùàÿ ïðîãðàììà äëÿ èíñòðóêòîðîâ òðåíàæåðíûõ çàëîâ.
10.2. Ïîñëå ïîñåùåíèå îáó÷àþùåãî êóðñà, èíñòðóêòîðîì òðåíàæåðíîãî çàëà, êîëè÷åñòâî êëèåíòîâ Âàøåãî çàëà óâåëè÷èòñÿ, ïîòîìó ÷òî òðåíåð óçíàåò âñå ñåêðåòû âîñüìèêðàòíîãî Ìèñòåðà Îëèìïèÿ è ïðîôåññèîíàëîâ ÑØÀ. Èíôîðìàöèþ êîòîðóþ ïîëó÷èò òðåíåð ,áóäåò î÷åíü èíòåðåñíà è ïîëåçíà âñåì êëèåíòàì òðåíàæåðíûõ çàëîâ. À òàêæå èíñòðóêòîð ïîëó÷èòü äèïëîì è ôîòîãðàôèþ ñ Ðîííè Êîëåìàíîì, êîòîðûìè òðåíåð ìîæåò óêðàñèò ïî÷åòíóþ ñòåíó ñâîåãî òðåíàæåðíîãî çàëà.
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2010-03-19 21:12 Michael Cox
0 siblings, 0 replies; 256+ messages in thread
From: Michael Cox @ 2010-03-19 21:12 UTC (permalink / raw)
To: git
unsubscribe git
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown)
@ 2010-03-08 21:56 Timur Aydin
0 siblings, 0 replies; 256+ messages in thread
From: Timur Aydin @ 2010-03-08 21:56 UTC (permalink / raw)
To: git
unsubscribe git
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2010-02-25 5:55 yingshou guo
0 siblings, 0 replies; 256+ messages in thread
From: yingshou guo @ 2010-02-25 5:55 UTC (permalink / raw)
To: git
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2010-01-22 2:14 Horst H. von Brand
0 siblings, 0 replies; 256+ messages in thread
From: Horst H. von Brand @ 2010-01-22 2:14 UTC (permalink / raw)
To: git; +Cc: gitster
A bunch of random spelling (and similar) fixes to Documentation/*
Stuff like trying to use SHA-1, UTF-8, ASCII (case and spelling) more
consistently
Use HTTP and HTTPS, etc (uppercase) where it refers to the protocol
A few real spelling fixes
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown)
@ 2009-09-12 13:00 Tito
0 siblings, 0 replies; 256+ messages in thread
From: Tito @ 2009-09-12 13:00 UTC (permalink / raw)
To: git
subscribe git
^ permalink raw reply [flat|nested] 256+ messages in thread
* [PATCH 0/2] Section renaming can lose content
@ 2009-07-24 21:21 Alex Vandiver
2009-07-24 21:21 ` [PATCH 1/2] Make section_name_match start on '[', and return the length on success Alex Vandiver
0 siblings, 1 reply; 256+ messages in thread
From: Alex Vandiver @ 2009-07-24 21:21 UTC (permalink / raw)
To: git
I submitted a patch to the testfile on the 8th; what follows is a pass
at solving the underlying bug as well.
- Alex
^ permalink raw reply [flat|nested] 256+ messages in thread
* [PATCH 1/2] Make section_name_match start on '[', and return the length on success
2009-07-24 21:21 [PATCH 0/2] Section renaming can lose content Alex Vandiver
@ 2009-07-24 21:21 ` Alex Vandiver
2009-07-24 21:21 ` [PATCH 2/2] After renaming a section, print any trailing variable definitions Alex Vandiver
0 siblings, 1 reply; 256+ messages in thread
From: Alex Vandiver @ 2009-07-24 21:21 UTC (permalink / raw)
To: git
Signed-off-by: Alex Vandiver <alex@chmrr.net>
---
config.c | 19 ++++++++++++++++---
1 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/config.c b/config.c
index 04380bb..7d6f6f6 100644
--- a/config.c
+++ b/config.c
@@ -1194,7 +1194,9 @@ write_err_out:
static int section_name_match (const char *buf, const char *name)
{
int i = 0, j = 0, dot = 0;
- for (; buf[i] && buf[i] != ']'; i++) {
+ if (buf[i] != '[')
+ return 0;
+ for (i = 1; buf[i] && buf[i] != ']'; i++) {
if (!dot && isspace(buf[i])) {
dot = 1;
if (name[j++] != '.')
@@ -1215,7 +1217,17 @@ static int section_name_match (const char *buf, const char *name)
if (buf[i] != name[j++])
break;
}
- return (buf[i] == ']' && name[j] == 0);
+ if (buf[i] == ']' && name[j] == 0) {
+ /*
+ * We match, now just find the right length offset by
+ * gobbling up any whitespace after it, as well
+ */
+ i++;
+ for (; buf[i] && isspace(buf[i]); i++)
+ ; /* do nothing */
+ return i;
+ }
+ return 0;
}
/* if new_name == NULL, the section is removed instead */
@@ -1249,7 +1261,8 @@ int git_config_rename_section(const char *old_name, const char *new_name)
; /* do nothing */
if (buf[i] == '[') {
/* it's a section */
- if (section_name_match (&buf[i+1], old_name)) {
+ int offset = section_name_match (&buf[i], old_name);
+ if (offset > 0) {
ret++;
if (new_name == NULL) {
remove = 1;
--
1.6.3.3.473.gb74fc4.dirty
^ permalink raw reply related [flat|nested] 256+ messages in thread
* [PATCH 2/2] After renaming a section, print any trailing variable definitions
2009-07-24 21:21 ` [PATCH 1/2] Make section_name_match start on '[', and return the length on success Alex Vandiver
@ 2009-07-24 21:21 ` Alex Vandiver
2009-07-24 22:11 ` Nanako Shiraishi
0 siblings, 1 reply; 256+ messages in thread
From: Alex Vandiver @ 2009-07-24 21:21 UTC (permalink / raw)
To: git
Signed-off-by: Alex Vandiver <alex@chmrr.net>
---
config.c | 22 +++++++++++++++++++---
t/t1300-repo-config.sh | 22 ++++++++++++++++++++++
2 files changed, 41 insertions(+), 3 deletions(-)
diff --git a/config.c b/config.c
index 7d6f6f6..3a2965e 100644
--- a/config.c
+++ b/config.c
@@ -1257,6 +1257,7 @@ int git_config_rename_section(const char *old_name, const char *new_name)
while (fgets(buf, sizeof(buf), config_file)) {
int i;
int length;
+ char* output = buf;
for (i = 0; buf[i] && isspace(buf[i]); i++)
; /* do nothing */
if (buf[i] == '[') {
@@ -1273,14 +1274,29 @@ int git_config_rename_section(const char *old_name, const char *new_name)
ret = write_error(lock->filename);
goto out;
}
- continue;
+ /*
+ * We wrote out the new section, with
+ * a newline, now skip the old
+ * section's length
+ */
+ output += offset + i;
+ if (strlen(output) > 0) {
+ /*
+ * More content means there's
+ * a declaration to put on the
+ * next line; indent with a
+ * tab
+ */
+ output -= 1;
+ output[0] = '\t';
+ }
}
remove = 0;
}
if (remove)
continue;
- length = strlen(buf);
- if (write_in_full(out_fd, buf, length) != length) {
+ length = strlen(output);
+ if (write_in_full(out_fd, output, length) != length) {
ret = write_error(lock->filename);
goto out;
}
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 43ea283..8c43dcd 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -460,6 +460,28 @@ EOF
test_expect_success "rename succeeded" "test_cmp expect .git/config"
cat >> .git/config << EOF
+[branch "vier"] z = 1
+EOF
+
+test_expect_success "rename a section with a var on the same line" \
+ 'git config --rename-section branch.vier branch.zwei'
+
+cat > expect << EOF
+# Hallo
+ #Bello
+[branch "zwei"]
+ x = 1
+[branch "zwei"]
+ y = 1
+[branch "drei"]
+weird
+[branch "zwei"]
+ z = 1
+EOF
+
+test_expect_success "rename succeeded" "test_cmp expect .git/config"
+
+cat >> .git/config << EOF
[branch "zwei"] a = 1 [branch "vier"]
EOF
--
1.6.3.3.473.gb74fc4.dirty
^ permalink raw reply related [flat|nested] 256+ messages in thread
* Re: [PATCH 2/2] After renaming a section, print any trailing variable definitions
2009-07-24 21:21 ` [PATCH 2/2] After renaming a section, print any trailing variable definitions Alex Vandiver
@ 2009-07-24 22:11 ` Nanako Shiraishi
2009-07-24 23:39 ` Junio C Hamano
0 siblings, 1 reply; 256+ messages in thread
From: Nanako Shiraishi @ 2009-07-24 22:11 UTC (permalink / raw)
To: Alex Vandiver; +Cc: git
Quoting Alex Vandiver <alex@chmrr.net>
> diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
> index 43ea283..8c43dcd 100755
> --- a/t/t1300-repo-config.sh
> +++ b/t/t1300-repo-config.sh
> @@ -460,6 +460,28 @@ EOF
> test_expect_success "rename succeeded" "test_cmp expect .git/config"
>
> cat >> .git/config << EOF
> +[branch "vier"] z = 1
> +EOF
Isn't this a syntax error?
Documentation/config.txt says this.
Subsection names are case sensitive and can contain any characters
except newline (doublequote `"` and backslash have to be escaped as
`\"` and `\\`, respectively). Section headers cannot span multiple
lines. Variables may belong directly to a section or to a given
subsection. You can have `[section]` if you have `[section
"subsection"]`, but you don't need to.
There is also a case insensitive alternative `[section.subsection]`
syntax. In this syntax, subsection names follow the same restrictions
as for section names.
All the other lines are recognized as setting variables, in the form
'name = value'. If there is no equal sign on the line, the entire
line ...
I read "All the other lines" to mean that the section headers and variable definitions are supposed to be on different lines.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [PATCH 2/2] After renaming a section, print any trailing variable definitions
2009-07-24 22:11 ` Nanako Shiraishi
@ 2009-07-24 23:39 ` Junio C Hamano
2009-07-25 0:28 ` (unknown), Nanako Shiraishi
0 siblings, 1 reply; 256+ messages in thread
From: Junio C Hamano @ 2009-07-24 23:39 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Alex Vandiver, git, Johannes Schindelin
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting Alex Vandiver <alex@chmrr.net>
>
>> diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
>> index 43ea283..8c43dcd 100755
>> --- a/t/t1300-repo-config.sh
>> +++ b/t/t1300-repo-config.sh
>> @@ -460,6 +460,28 @@ EOF
>> test_expect_success "rename succeeded" "test_cmp expect .git/config"
>>
>> cat >> .git/config << EOF
>> +[branch "vier"] z = 1
>> +EOF
>
> Isn't this a syntax error?
>
> Documentation/config.txt says this.
Even if it were, I think it would be nice to allow it. I'll have to
re-read Alex's patch, but I thought it was sane. Perhaps we can update
the documentation, mildly hinting that it is allowed without encouraging
it too strongly, as I think it is a good style to have these on separate
lines.
Dscho? Have any suggestions/comments on the patch?
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
2009-07-24 23:39 ` Junio C Hamano
@ 2009-07-25 0:28 ` Nanako Shiraishi
0 siblings, 0 replies; 256+ messages in thread
From: Nanako Shiraishi @ 2009-07-25 0:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Vandiver, git, Johannes Schindelin
Subject: [PATCH] Documentation/config.txt: a variable can be defined on the section header line
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---
Quoting Junio C Hamano <gitster@pobox.com>:
> Nanako Shiraishi <nanako3@lavabit.com> writes:
>
>> Isn't this a syntax error?
>>
>> Documentation/config.txt says this.
>
> Even if it were, I think it would be nice to allow it. I'll have to
> re-read Alex's patch, but I thought it was sane. Perhaps we can update
> the documentation, mildly hinting that it is allowed without encouraging
> it too strongly, as I think it is a good style to have these on separate
> lines.
How about this small update to the documentation, then?
Documentation/config.txt | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 6857d2f..c6f09f8 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -49,7 +49,8 @@ There is also a case insensitive alternative `[section.subsection]` syntax.
In this syntax, subsection names follow the same restrictions as for section
names.
-All the other lines are recognized as setting variables, in the form
+All the other lines (and the remainder of the line after the section
+header) are recognized as setting variables, in the form
'name = value'. If there is no equal sign on the line, the entire line
is taken as 'name' and the variable is recognized as boolean "true".
The variable names are case-insensitive and only alphanumeric
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related [flat|nested] 256+ messages in thread
* (unknown)
@ 2009-07-16 19:22 Henrik Austad
0 siblings, 0 replies; 256+ messages in thread
From: Henrik Austad @ 2009-07-16 19:22 UTC (permalink / raw)
To: git
subscibe git
--
henrik
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown)
@ 2009-06-23 1:07 Larry D'Anna
0 siblings, 0 replies; 256+ messages in thread
From: Larry D'Anna @ 2009-06-23 1:07 UTC (permalink / raw)
To: git
>From 1efb13a16b86b0e7d4735b583cf8d90bd74728fb Mon Sep 17 00:00:00 2001
In-Reply-To: <20090622214032.GC19364@coredump.intra.peff.net>
References: <20090622214032.GC19364@coredump.intra.peff.net>
From: Larry D'Anna <larry@elder-gods.org>
Date: Mon, 22 Jun 2009 21:02:55 -0400
Subject: [PATCH] add --porcelain option to git-push
If --porcelain is used git-push will produce machine-readable output. The
output status line for each ref will be tab-separated and sent to stdout instead
of stderr. The full symbolic names of the refs will be given. For example
$ git push --dry-run --porcelain master :foobar 2>/dev/null \
| perl -pe 's/\t/ TAB /g'
= TAB refs/heads/master:refs/heads/master TAB [up to date]
- TAB :refs/heads/foobar TAB [deleted]
---
Documentation/git-push.txt | 11 ++++++
builtin-push.c | 3 +-
transport.c | 75 +++++++++++++++++++++++++------------------
transport.h | 1 +
4 files changed, 58 insertions(+), 32 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index fd53c49..2653388 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -85,6 +85,11 @@ nor in any Push line of the corresponding remotes file---see below).
--dry-run::
Do everything except actually send the updates.
+--porcelain::
+ Produce machine-readable output. The output status line for each ref
+ will be tab-separated and sent to stdout instead of stderr. The full
+ symbolic names of the refs will be given.
+
--tags::
All refs under `$GIT_DIR/refs/tags` are pushed, in
addition to refspecs explicitly listed on the command
@@ -148,6 +153,12 @@ representing the status of a single ref. Each line is of the form:
<flag> <summary> <from> -> <to> (<reason>)
-------------------------------
+If --porcelain is used, then each line of the output is of the form:
+
+-------------------------------
+ <flag> \t <from>:<to> \t <summary> (<reason>)
+-------------------------------
+
flag::
A single character indicating the status of the ref. This is
blank for a successfully pushed ref, `!` for a ref that was
diff --git a/builtin-push.c b/builtin-push.c
index 7be1239..0a0297f 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -10,7 +10,7 @@
#include "parse-options.h"
static const char * const push_usage[] = {
- "git push [--all | --mirror] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>] [--repo=<repository>] [-f | --force] [-v] [<repository> <refspec>...]",
+ "git push [--all | --mirror] [--dry-run] [--porcelain] [--tags] [--receive-pack=<git-receive-pack>] [--repo=<repository>] [-f | --force] [-v] [<repository> <refspec>...]",
NULL,
};
@@ -200,6 +200,7 @@ int cmd_push(int argc, const char **argv, const char *prefix)
(TRANSPORT_PUSH_MIRROR|TRANSPORT_PUSH_FORCE)),
OPT_BOOLEAN( 0 , "tags", &tags, "push tags"),
OPT_BIT( 0 , "dry-run", &flags, "dry run", TRANSPORT_PUSH_DRY_RUN),
+ OPT_BIT( 0, "porcelain", &flags, "machine-readable output", TRANSPORT_PUSH_PORCELAIN),
OPT_BIT('f', "force", &flags, "force updates", TRANSPORT_PUSH_FORCE),
OPT_BOOLEAN( 0 , "thin", &thin, "use thin pack"),
OPT_STRING( 0 , "receive-pack", &receivepack, "receive-pack", "receive pack program"),
diff --git a/transport.c b/transport.c
index 501a77b..b074067 100644
--- a/transport.c
+++ b/transport.c
@@ -719,19 +719,30 @@ static void update_tracking_ref(struct remote *remote, struct ref *ref, int verb
#define SUMMARY_WIDTH (2 * DEFAULT_ABBREV + 3)
-static void print_ref_status(char flag, const char *summary, struct ref *to, struct ref *from, const char *msg)
+static void print_ref_status(char flag, const char *summary, struct ref *to, struct ref *from, const char *msg, int porcelain)
{
- fprintf(stderr, " %c %-*s ", flag, SUMMARY_WIDTH, summary);
- if (from)
- fprintf(stderr, "%s -> %s", prettify_refname(from->name), prettify_refname(to->name));
- else
- fputs(prettify_refname(to->name), stderr);
- if (msg) {
- fputs(" (", stderr);
- fputs(msg, stderr);
- fputc(')', stderr);
+ if (porcelain) {
+ if (from)
+ fprintf(stdout, "%c\t%s:%s\t", flag, from->name, to->name);
+ else
+ fprintf(stdout, "%c\t:%s\t", flag, to->name);
+ if (msg)
+ fprintf(stdout, "%s (%s)\n", summary, msg);
+ else
+ fprintf(stdout, "%s\n", summary);
+ } else {
+ fprintf(stderr, " %c %-*s ", flag, SUMMARY_WIDTH, summary);
+ if (from)
+ fprintf(stderr, "%s -> %s", prettify_refname(from->name), prettify_refname(to->name));
+ else
+ fputs(prettify_refname(to->name), stderr);
+ if (msg) {
+ fputs(" (", stderr);
+ fputs(msg, stderr);
+ fputc(')', stderr);
+ }
+ fputc('\n', stderr);
}
- fputc('\n', stderr);
}
static const char *status_abbrev(unsigned char sha1[20])
@@ -739,15 +750,15 @@ static const char *status_abbrev(unsigned char sha1[20])
return find_unique_abbrev(sha1, DEFAULT_ABBREV);
}
-static void print_ok_ref_status(struct ref *ref)
+static void print_ok_ref_status(struct ref *ref, int porcelain)
{
if (ref->deletion)
- print_ref_status('-', "[deleted]", ref, NULL, NULL);
+ print_ref_status('-', "[deleted]", ref, NULL, NULL, porcelain);
else if (is_null_sha1(ref->old_sha1))
print_ref_status('*',
(!prefixcmp(ref->name, "refs/tags/") ? "[new tag]" :
- "[new branch]"),
- ref, ref->peer_ref, NULL);
+ "[new branch]"),
+ ref, ref->peer_ref, NULL, porcelain);
else {
char quickref[84];
char type;
@@ -765,50 +776,51 @@ static void print_ok_ref_status(struct ref *ref)
}
strcat(quickref, status_abbrev(ref->new_sha1));
- print_ref_status(type, quickref, ref, ref->peer_ref, msg);
+ print_ref_status(type, quickref, ref, ref->peer_ref, msg, porcelain);
}
}
-static int print_one_push_status(struct ref *ref, const char *dest, int count)
+static int print_one_push_status(struct ref *ref, const char *dest, int count, int porcelain)
{
if (!count)
fprintf(stderr, "To %s\n", dest);
switch(ref->status) {
case REF_STATUS_NONE:
- print_ref_status('X', "[no match]", ref, NULL, NULL);
+ print_ref_status('X', "[no match]", ref, NULL, NULL, porcelain);
break;
case REF_STATUS_REJECT_NODELETE:
print_ref_status('!', "[rejected]", ref, NULL,
- "remote does not support deleting refs");
+ "remote does not support deleting refs", porcelain);
break;
case REF_STATUS_UPTODATE:
print_ref_status('=', "[up to date]", ref,
- ref->peer_ref, NULL);
+ ref->peer_ref, NULL, porcelain);
break;
case REF_STATUS_REJECT_NONFASTFORWARD:
print_ref_status('!', "[rejected]", ref, ref->peer_ref,
- "non-fast forward");
+ "non-fast forward", porcelain);
break;
case REF_STATUS_REMOTE_REJECT:
print_ref_status('!', "[remote rejected]", ref,
- ref->deletion ? NULL : ref->peer_ref,
- ref->remote_status);
+ ref->deletion ? NULL : ref->peer_ref,
+ ref->remote_status, porcelain);
break;
case REF_STATUS_EXPECTING_REPORT:
print_ref_status('!', "[remote failure]", ref,
- ref->deletion ? NULL : ref->peer_ref,
- "remote failed to report status");
+ ref->deletion ? NULL : ref->peer_ref,
+ "remote failed to report status", porcelain);
break;
case REF_STATUS_OK:
- print_ok_ref_status(ref);
+ print_ok_ref_status(ref, porcelain);
break;
}
return 1;
}
-static void print_push_status(const char *dest, struct ref *refs, int verbose)
+static void print_push_status(const char *dest, struct ref *refs,
+ int verbose, int porcelain)
{
struct ref *ref;
int n = 0;
@@ -816,18 +828,18 @@ static void print_push_status(const char *dest, struct ref *refs, int verbose)
if (verbose) {
for (ref = refs; ref; ref = ref->next)
if (ref->status == REF_STATUS_UPTODATE)
- n += print_one_push_status(ref, dest, n);
+ n += print_one_push_status(ref, dest, n, porcelain);
}
for (ref = refs; ref; ref = ref->next)
if (ref->status == REF_STATUS_OK)
- n += print_one_push_status(ref, dest, n);
+ n += print_one_push_status(ref, dest, n, porcelain);
for (ref = refs; ref; ref = ref->next) {
if (ref->status != REF_STATUS_NONE &&
ref->status != REF_STATUS_UPTODATE &&
ref->status != REF_STATUS_OK)
- n += print_one_push_status(ref, dest, n);
+ n += print_one_push_status(ref, dest, n, porcelain);
}
}
@@ -997,6 +1009,7 @@ int transport_push(struct transport *transport,
struct ref *local_refs = get_local_heads();
int match_flags = MATCH_REFS_NONE;
int verbose = flags & TRANSPORT_PUSH_VERBOSE;
+ int porcelain = flags & TRANSPORT_PUSH_PORCELAIN;
int ret;
if (flags & TRANSPORT_PUSH_ALL)
@@ -1011,7 +1024,7 @@ int transport_push(struct transport *transport,
ret = transport->push_refs(transport, remote_refs, flags);
- print_push_status(transport->url, remote_refs, verbose);
+ print_push_status(transport->url, remote_refs, verbose | porcelain, porcelain);
if (!(flags & TRANSPORT_PUSH_DRY_RUN)) {
struct ref *ref;
diff --git a/transport.h b/transport.h
index 27bfc52..51b5397 100644
--- a/transport.h
+++ b/transport.h
@@ -35,6 +35,7 @@ struct transport {
#define TRANSPORT_PUSH_DRY_RUN 4
#define TRANSPORT_PUSH_MIRROR 8
#define TRANSPORT_PUSH_VERBOSE 16
+#define TRANSPORT_PUSH_PORCELAIN 32
/* Returns a transport suitable for the url */
struct transport *transport_get(struct remote *, const char *);
--
1.6.0.4
^ permalink raw reply related [flat|nested] 256+ messages in thread
* (unknown),
@ 2009-05-27 13:28 David Forman
0 siblings, 0 replies; 256+ messages in thread
From: David Forman @ 2009-05-27 13:28 UTC (permalink / raw)
To: git
I've encountered the following whenever I access Git and try to compress the
database due to loose objects.
error: cannot lock ref 'HEAD~'
error: cannot lock ref 'refs/heads/collections~'
error: cannot lock ref 'refs/heads/master~'
I'm on a Windows box (no comments please!), I've tried gc from the command
line, as well as the GUI option, with the same results. Any help would be
greatly appreciated, last count was over 2000 loose objects.
Thanks,
David Forman
Systems Manager
dairyfood USA, Inc.
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2009-05-13 5:11 Tom H
0 siblings, 0 replies; 256+ messages in thread
From: Tom H @ 2009-05-13 5:11 UTC (permalink / raw)
To: git
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown)
@ 2009-05-11 18:57 Don Slutz
0 siblings, 0 replies; 256+ messages in thread
From: Don Slutz @ 2009-05-11 18:57 UTC (permalink / raw)
To: git
>From 49878211a2f7f907a59b2b0289685e9e68585be9 Mon Sep 17 00:00:00 2001
From: Don Slutz <Don.Slutz@SierraAtlantic.com>
Date: Mon, 11 May 2009 12:29:00 -0400
Subject: [PATCH 6/6] Add 'make test-text'
Signed-off-by: Don Slutz <Don.Slutz@SierraAtlantic.com>
---
Makefile | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 6e21643..03176a4 100644
--- a/Makefile
+++ b/Makefile
@@ -1482,6 +1482,16 @@ export NO_SVN_TESTS
test: all
$(MAKE) -C t/ all
+test-text: all
+ifeq ($(uname_O),Cygwin)
+ @echo Test text mode mount
+ mount -f -u -t $(shell sh -c 'cygpath -m -a t') $(shell sh -c 'cygpath -u -a t')
+ $(MAKE) -C t/ all
+ umount -u $(shell sh -c 'cygpath -u -a t')
+else
+ GIT_TEST_AUTO_CRLF=$${GIT_TEST_AUTO_CRLF:-true} $(MAKE) -C t/ all
+endif
+
test-ctype$X: ctype.o
test-date$X: date.o ctype.o
--
1.6.3.15.g49878
^ permalink raw reply related [flat|nested] 256+ messages in thread
* (unknown)
@ 2009-05-11 18:57 Don Slutz
0 siblings, 0 replies; 256+ messages in thread
From: Don Slutz @ 2009-05-11 18:57 UTC (permalink / raw)
To: git
>From 96607bf6ffca78c88278e206ed40dce3abc1d4d9 Mon Sep 17 00:00:00 2001
From: Don Slutz <Don.Slutz@SierraAtlantic.com>
Date: Mon, 11 May 2009 11:58:32 -0400
Subject: [PATCH 3/6] Fix tests to work with core.autocrlf=true
Use the new functions to fix tests.
Signed-off-by: Don Slutz <Don.Slutz@SierraAtlantic.com>
---
t/t0002-gitfile.sh | 3 +-
t/t2004-checkout-cache-temp.sh | 42 ++++++++++++++--------------
t/t2008-checkout-subdir.sh | 14 +++++-----
t/t3404-rebase-interactive.sh | 2 +-
t/t3410-rebase-preserve-dropped-merges.sh | 12 ++++----
t/t3413-rebase-hook.sh | 32 +++++++++++-----------
t/t3503-cherry-pick-root.sh | 2 +-
t/t3903-stash.sh | 12 ++++----
t/t4102-apply-rename.sh | 5 ++-
t/t4124-apply-ws-rule.sh | 23 ++++++++++++---
t/t4125-apply-ws-fuzz.sh | 9 +++++-
t/t4128-apply-root.sh | 8 +++---
t/t4150-am.sh | 4 +-
t/t4252-am-options.sh | 16 ++++++++---
t/t5000-tar-tree.sh | 12 +++++---
t/t5001-archive-attr.sh | 3 ++
t/t5520-pull.sh | 12 ++++----
t/t7003-filter-branch.sh | 4 +-
t/t7201-co.sh | 2 +-
t/t7402-submodule-rebase.sh | 4 +-
t/t7610-mergetool.sh | 6 ++--
t/t7800-difftool.sh | 13 +++++----
t/t9700-perl-git.sh | 2 +-
23 files changed, 139 insertions(+), 103 deletions(-)
diff --git a/t/t0002-gitfile.sh b/t/t0002-gitfile.sh
index cb14425..3762714 100755
--- a/t/t0002-gitfile.sh
+++ b/t/t0002-gitfile.sh
@@ -60,7 +60,8 @@ test_expect_success 'final setup + check rev-parse --git-dir' '
test_expect_success 'check hash-object' '
echo "foo" >bar &&
- SHA=$(cat bar | git hash-object -w --stdin) &&
+ SHA=$(cat bar | git hash-object -w --stdin --path=bar) &&
+ test_debug "echo SHA=$SHA" &&
objck $SHA
'
diff --git a/t/t2004-checkout-cache-temp.sh b/t/t2004-checkout-cache-temp.sh
index 36cca14..ce4c584 100755
--- a/t/t2004-checkout-cache-temp.sh
+++ b/t/t2004-checkout-cache-temp.sh
@@ -44,7 +44,7 @@ test $(wc -l <out) = 1 &&
test $(cut "-d " -f2 out) = path1 &&
p=$(cut "-d " -f1 out) &&
test -f $p &&
-test $(cat $p) = tree1path1'
+test_cat_eq $p tree1path1'
test_expect_success \
'checkout all stage 0 to temporary files' '
@@ -57,7 +57,7 @@ do
test $(grep $f out | cut "-d " -f2) = $f &&
p=$(grep $f out | cut "-d " -f1) &&
test -f $p &&
- test $(cat $p) = tree1$f
+ test_cat_eq $p tree1$f
done'
test_expect_success \
@@ -73,7 +73,7 @@ test $(wc -l <out) = 1 &&
test $(cut "-d " -f2 out) = path1 &&
p=$(cut "-d " -f1 out) &&
test -f $p &&
-test $(cat $p) = tree2path1'
+test_cat_eq $p tree2path1'
test_expect_success \
'checkout all stage 2 to temporary files' '
@@ -85,7 +85,7 @@ do
test $(grep $f out | cut "-d " -f2) = $f &&
p=$(grep $f out | cut "-d " -f1) &&
test -f $p &&
- test $(cat $p) = tree2$f
+ test_cat_eq $p tree2$f
done'
test_expect_success \
@@ -104,9 +104,9 @@ cut "-d " -f1 out | (read s1 s2 s3 &&
test -f $s1 &&
test -f $s2 &&
test -f $s3 &&
-test $(cat $s1) = tree1path1 &&
-test $(cat $s2) = tree2path1 &&
-test $(cat $s3) = tree3path1)'
+test_cat_eq $s1 tree1path1 &&
+test_cat_eq $s2 tree2path1 &&
+test_cat_eq $s3 tree3path1)'
test_expect_success \
'checkout some stages/one file to temporary files' '
@@ -118,8 +118,8 @@ cut "-d " -f1 out | (read s1 s2 s3 &&
test $s1 = . &&
test -f $s2 &&
test -f $s3 &&
-test $(cat $s2) = tree2path2 &&
-test $(cat $s3) = tree3path2)'
+test_cat_eq $s2 tree2path2 &&
+test_cat_eq $s3 tree3path2)'
test_expect_success \
'checkout all stages/all files to temporary files' '
@@ -138,9 +138,9 @@ grep path1 out | cut "-d " -f1 | (read s1 s2 s3 &&
test -f $s1 &&
test -f $s2 &&
test -f $s3 &&
-test $(cat $s1) = tree1path1 &&
-test $(cat $s2) = tree2path1 &&
-test $(cat $s3) = tree3path1)'
+test_cat_eq $s1 tree1path1 &&
+test_cat_eq $s2 tree2path1 &&
+test_cat_eq $s3 tree3path1)'
test_expect_success \
'-- path2: no stage 1, have stage 2 and 3' '
@@ -149,8 +149,8 @@ grep path2 out | cut "-d " -f1 | (read s1 s2 s3 &&
test $s1 = . &&
test -f $s2 &&
test -f $s3 &&
-test $(cat $s2) = tree2path2 &&
-test $(cat $s3) = tree3path2)'
+test_cat_eq $s2 tree2path2 &&
+test_cat_eq $s3 tree3path2)'
test_expect_success \
'-- path3: no stage 2, have stage 1 and 3' '
@@ -159,8 +159,8 @@ grep path3 out | cut "-d " -f1 | (read s1 s2 s3 &&
test -f $s1 &&
test $s2 = . &&
test -f $s3 &&
-test $(cat $s1) = tree1path3 &&
-test $(cat $s3) = tree3path3)'
+test_cat_eq $s1 tree1path3 &&
+test_cat_eq $s3 tree3path3)'
test_expect_success \
'-- path4: no stage 3, have stage 1 and 3' '
@@ -169,8 +169,8 @@ grep path4 out | cut "-d " -f1 | (read s1 s2 s3 &&
test -f $s1 &&
test -f $s2 &&
test $s3 = . &&
-test $(cat $s1) = tree1path4 &&
-test $(cat $s2) = tree2path4)'
+test_cat_eq $s1 tree1path4 &&
+test_cat_eq $s2 tree2path4)'
test_expect_success \
'-- asubdir/path5: no stage 2 and 3 have stage 1' '
@@ -179,7 +179,7 @@ grep asubdir/path5 out | cut "-d " -f1 | (read s1 s2 s3 &&
test -f $s1 &&
test $s2 = . &&
test $s3 = . &&
-test $(cat $s1) = tree1asubdir/path5)'
+test_cat_eq $s1 tree1asubdir/path5)'
test_expect_success \
'checkout --temp within subdir' '
@@ -191,7 +191,7 @@ test_expect_success \
test -f ../$s1 &&
test $s2 = . &&
test $s3 = . &&
- test $(cat ../$s1) = tree1asubdir/path5)
+ test_cat_eq ../$s1 tree1asubdir/path5)
)'
test_expect_success SYMLINKS \
@@ -207,6 +207,6 @@ test $(wc -l <out) = 1 &&
test $(cut "-d " -f2 out) = a &&
p=$(cut "-d " -f1 out) &&
test -f $p &&
-test $(cat $p) = b'
+test_cat_eq $p b'
test_done
diff --git a/t/t2008-checkout-subdir.sh b/t/t2008-checkout-subdir.sh
index 3e098ab..7933197 100755
--- a/t/t2008-checkout-subdir.sh
+++ b/t/t2008-checkout-subdir.sh
@@ -27,14 +27,14 @@ test_expect_success 'remove and restore with relative path' '
cd dir1 &&
rm ../file0 &&
git checkout HEAD -- ../file0 &&
- test "base" = "$(cat ../file0)" &&
+ test_eq_cat base ../file0 &&
rm ../dir2/file2 &&
git checkout HEAD -- ../dir2/file2 &&
- test "bonjour" = "$(cat ../dir2/file2)" &&
+ test_eq_cat bonjour ../dir2/file2 &&
rm ../file0 ./file1 &&
git checkout HEAD -- .. &&
- test "base" = "$(cat ../file0)" &&
- test "hello" = "$(cat file1)"
+ test_eq_cat base ../file0 &&
+ test_eq_cat hello file1
)
'
@@ -43,7 +43,7 @@ test_expect_success 'checkout with empty prefix' '
rm file0 &&
git checkout HEAD -- file0 &&
- test "base" = "$(cat file0)"
+ test_eq_cat base file0
'
@@ -51,10 +51,10 @@ test_expect_success 'checkout with simple prefix' '
rm dir1/file1 &&
git checkout HEAD -- dir1 &&
- test "hello" = "$(cat dir1/file1)" &&
+ test_eq_cat hello dir1/file1 &&
rm dir1/file1 &&
git checkout HEAD -- dir1/file1 &&
- test "hello" = "$(cat dir1/file1)"
+ test_eq_cat hello dir1/file1
'
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index c32ff66..6990c77 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -162,7 +162,7 @@ test_expect_success 'squash' '
GIT_AUTHOR_NAME="Nitfol" git commit -m "nitfol" file7 &&
echo "******************************" &&
FAKE_LINES="1 squash 2" git rebase -i --onto master HEAD~2 &&
- test B = $(cat file7) &&
+ test_eq_cat B file7 &&
test $(git rev-parse HEAD^) = $(git rev-parse master)
'
diff --git a/t/t3410-rebase-preserve-dropped-merges.sh b/t/t3410-rebase-preserve-dropped-merges.sh
index c49143a..a044962 100755
--- a/t/t3410-rebase-preserve-dropped-merges.sh
+++ b/t/t3410-rebase-preserve-dropped-merges.sh
@@ -52,9 +52,9 @@ test_expect_success 'skip same-resolution merges with -p' '
test_commit K file7 file7 &&
git rebase -i -p L &&
test $(git rev-parse HEAD^^) = $(git rev-parse L) &&
- test "23" = "$(cat file1)" &&
- test "I" = "$(cat file6)" &&
- test "file7" = "$(cat file7)"
+ test_eq_cat 23 file1 &&
+ test_eq_cat I file6 &&
+ test_eq_cat file7 file7
'
# A - B - C - D - E
@@ -77,9 +77,9 @@ test_expect_success 'keep different-resolution merges with -p' '
git add file1 &&
git rebase --continue &&
test $(git rev-parse HEAD^^^) = $(git rev-parse L2) &&
- test "234" = "$(cat file1)" &&
- test "I" = "$(cat file6)" &&
- test "file7" = "$(cat file7)"
+ test_eq_cat 234 file1 &&
+ test_eq_cat I file6 &&
+ test_eq_cat file7 file7
'
test_done
diff --git a/t/t3413-rebase-hook.sh b/t/t3413-rebase-hook.sh
index 098b755..ac9ad05 100755
--- a/t/t3413-rebase-hook.sh
+++ b/t/t3413-rebase-hook.sh
@@ -27,14 +27,14 @@ test_expect_success 'rebase' '
git checkout test &&
git reset --hard side &&
git rebase master &&
- test "z$(cat git)" = zworld
+ test_cat_eq git world
'
test_expect_success 'rebase -i' '
git checkout test &&
git reset --hard side &&
EDITOR=true git rebase -i master &&
- test "z$(cat git)" = zworld
+ test_cat_eq git world
'
test_expect_success 'setup pre-rebase hook' '
@@ -50,8 +50,8 @@ test_expect_success 'pre-rebase hook gets correct input (1)' '
git checkout test &&
git reset --hard side &&
git rebase master &&
- test "z$(cat git)" = zworld &&
- test "z$(cat .git/PRE-REBASE-INPUT)" = zmaster,
+ test_cat_eq git world &&
+ test_cat_eq .git/PRE-REBASE-INPUT master,
'
@@ -59,8 +59,8 @@ test_expect_success 'pre-rebase hook gets correct input (2)' '
git checkout test &&
git reset --hard side &&
git rebase master test &&
- test "z$(cat git)" = zworld &&
- test "z$(cat .git/PRE-REBASE-INPUT)" = zmaster,test
+ test_cat_eq git world &&
+ test_cat_eq .git/PRE-REBASE-INPUT master,test
'
test_expect_success 'pre-rebase hook gets correct input (3)' '
@@ -68,16 +68,16 @@ test_expect_success 'pre-rebase hook gets correct input (3)' '
git reset --hard side &&
git checkout master &&
git rebase master test &&
- test "z$(cat git)" = zworld &&
- test "z$(cat .git/PRE-REBASE-INPUT)" = zmaster,test
+ test_cat_eq git world &&
+ test_cat_eq .git/PRE-REBASE-INPUT master,test
'
test_expect_success 'pre-rebase hook gets correct input (4)' '
git checkout test &&
git reset --hard side &&
EDITOR=true git rebase -i master &&
- test "z$(cat git)" = zworld &&
- test "z$(cat .git/PRE-REBASE-INPUT)" = zmaster,
+ test_cat_eq git world &&
+ test_cat_eq .git/PRE-REBASE-INPUT master,
'
@@ -85,8 +85,8 @@ test_expect_success 'pre-rebase hook gets correct input (5)' '
git checkout test &&
git reset --hard side &&
EDITOR=true git rebase -i master test &&
- test "z$(cat git)" = zworld &&
- test "z$(cat .git/PRE-REBASE-INPUT)" = zmaster,test
+ test_cat_eq git world &&
+ test_cat_eq .git/PRE-REBASE-INPUT master,test
'
test_expect_success 'pre-rebase hook gets correct input (6)' '
@@ -94,8 +94,8 @@ test_expect_success 'pre-rebase hook gets correct input (6)' '
git reset --hard side &&
git checkout master &&
EDITOR=true git rebase -i master test &&
- test "z$(cat git)" = zworld &&
- test "z$(cat .git/PRE-REBASE-INPUT)" = zmaster,test
+ test_cat_eq git world &&
+ test_cat_eq .git/PRE-REBASE-INPUT master,test
'
test_expect_success 'setup pre-rebase hook that fails' '
@@ -132,7 +132,7 @@ test_expect_success 'rebase --no-verify overrides pre-rebase (1)' '
git reset --hard side &&
git rebase --no-verify master &&
test "z$(git symbolic-ref HEAD)" = zrefs/heads/test &&
- test "z$(cat git)" = zworld
+ test_cat_eq git world
'
test_expect_success 'rebase --no-verify overrides pre-rebase (2)' '
@@ -140,7 +140,7 @@ test_expect_success 'rebase --no-verify overrides pre-rebase (2)' '
git reset --hard side &&
EDITOR=true git rebase --no-verify -i master &&
test "z$(git symbolic-ref HEAD)" = zrefs/heads/test &&
- test "z$(cat git)" = zworld
+ test_cat_eq git world
'
test_done
diff --git a/t/t3503-cherry-pick-root.sh b/t/t3503-cherry-pick-root.sh
index b0faa29..dfcd72a 100755
--- a/t/t3503-cherry-pick-root.sh
+++ b/t/t3503-cherry-pick-root.sh
@@ -23,7 +23,7 @@ test_expect_success setup '
test_expect_success 'cherry-pick a root commit' '
git cherry-pick master &&
- test first = $(cat file1)
+ test_eq_cat first file1
'
diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index 7484cbe..7c1e169 100755
--- a/t/t3903-stash.sh
+++ b/t/t3903-stash.sh
@@ -49,7 +49,7 @@ test_expect_success 'apply stashed changes' '
test_tick &&
git commit -m other-file &&
git stash apply &&
- test 3 = $(cat file) &&
+ test_eq_cat 3 file &&
test 1 = $(git show :file) &&
test 1 = $(git show HEAD:file)
'
@@ -61,7 +61,7 @@ test_expect_success 'apply stashed changes (including index)' '
test_tick &&
git commit -m other-file &&
git stash apply --index &&
- test 3 = $(cat file) &&
+ test_eq_cat 3 file &&
test 2 = $(git show :file) &&
test 1 = $(git show HEAD:file)
'
@@ -83,7 +83,7 @@ test_expect_success 'drop top stash' '
git stash list > stashlist2 &&
diff stashlist1 stashlist2 &&
git stash apply &&
- test 3 = $(cat file) &&
+ test_eq_cat 3 file &&
test 1 = $(git show :file) &&
test 1 = $(git show HEAD:file)
'
@@ -97,13 +97,13 @@ test_expect_success 'drop middle stash' '
git stash drop stash@{1} &&
test 2 = $(git stash list | wc -l) &&
git stash apply &&
- test 9 = $(cat file) &&
+ test_eq_cat 9 file &&
test 1 = $(git show :file) &&
test 1 = $(git show HEAD:file) &&
git reset --hard &&
git stash drop &&
git stash apply &&
- test 3 = $(cat file) &&
+ test_eq_cat 3 file &&
test 1 = $(git show :file) &&
test 1 = $(git show HEAD:file)
'
@@ -111,7 +111,7 @@ test_expect_success 'drop middle stash' '
test_expect_success 'stash pop' '
git reset --hard &&
git stash pop &&
- test 3 = $(cat file) &&
+ test_eq_cat 3 file &&
test 1 = $(git show :file) &&
test 1 = $(git show HEAD:file) &&
test 0 = $(git stash list | wc -l)
diff --git a/t/t4102-apply-rename.sh b/t/t4102-apply-rename.sh
index 1597965..5c7300d 100755
--- a/t/t4102-apply-rename.sh
+++ b/t/t4102-apply-rename.sh
@@ -43,7 +43,7 @@ test_expect_success FILEMODE validate \
test_expect_success 'apply reverse' \
'git apply -R --index --stat --summary --apply test-patch &&
- test "$(cat foo)" = "This is foo"'
+ test_cat_eq foo "This is foo"'
cat >test-patch <<\EOF
diff --git a/foo b/bar
@@ -59,6 +59,7 @@ EOF
test_expect_success 'apply copy' \
'git apply --index --stat --summary --apply test-patch &&
- test "$(cat bar)" = "This is bar" -a "$(cat foo)" = "This is foo"'
+ test_cat_eq bar "This is bar" &&
+ test_cat_eq foo "This is foo"'
test_done
diff --git a/t/t4124-apply-ws-rule.sh b/t/t4124-apply-ws-rule.sh
index f83322e..3933dd9 100755
--- a/t/t4124-apply-ws-rule.sh
+++ b/t/t4124-apply-ws-rule.sh
@@ -38,13 +38,19 @@ apply_patch () {
git apply "$@"
}
+remove_cr () {
+ tr '\015' Q <"$1" | sed -e 's/Q$//'
+}
+
test_fix () {
# fix should not barf
apply_patch --whitespace=fix || return 1
+ test_debug "echo patch applied: [$1]"
# find touched lines
- diff file target | sed -n -e "s/^> //p" >fixed
+ remove_cr target >target1
+ diff file target1 | sed -n -e "s/^> //p" >fixed
# the changed lines are all expeced to change
fixed_cnt=$(wc -l <fixed)
@@ -52,6 +58,7 @@ test_fix () {
'') expect_cnt=$fixed_cnt ;;
?*) expect_cnt=$(grep "[$1]" <fixed | wc -l) ;;
esac
+ test_debug "echo fixed: $fixed_cnt vs $expect_cnt"
test $fixed_cnt -eq $expect_cnt || return 1
# and we are not missing anything
@@ -59,12 +66,14 @@ test_fix () {
'') expect_cnt=0 ;;
?*) expect_cnt=$(grep "[$1]" <file | wc -l) ;;
esac
+ test_debug "echo missing: $fixed_cnt vs $expect_cnt"
test $fixed_cnt -eq $expect_cnt || return 1
# Get the patch actually applied
git diff-files -p target >fixed-patch
test -s fixed-patch && return 0
+ test_debug "echo failed to apply, try and fix"
# Make sure it is complaint-free
>target
git apply --whitespace=error-all <fixed-patch
@@ -85,14 +94,16 @@ test_expect_success setup '
test_expect_success 'whitespace=nowarn, default rule' '
apply_patch --whitespace=nowarn &&
- diff file target
+ remove_cr target >target1 &&
+ diff file target1
'
test_expect_success 'whitespace=warn, default rule' '
apply_patch --whitespace=warn &&
- diff file target
+ remove_cr target >target1 &&
+ diff file target1
'
@@ -108,7 +119,8 @@ test_expect_success 'whitespace=error-all, no rule' '
git config core.whitespace -trailing,-space-before,-indent &&
apply_patch --whitespace=error-all &&
- diff file target
+ remove_cr target >target1 &&
+ diff file target1
'
@@ -117,7 +129,8 @@ test_expect_success 'whitespace=error-all, no rule (attribute)' '
git config --unset core.whitespace &&
echo "target -whitespace" >.gitattributes &&
apply_patch --whitespace=error-all &&
- diff file target
+ remove_cr target >target1 &&
+ diff file target1
'
diff --git a/t/t4125-apply-ws-fuzz.sh b/t/t4125-apply-ws-fuzz.sh
index 3b471b6..c02fe08 100755
--- a/t/t4125-apply-ws-fuzz.sh
+++ b/t/t4125-apply-ws-fuzz.sh
@@ -4,6 +4,10 @@ test_description='applying patch that has broken whitespaces in context'
. ./test-lib.sh
+remove_cr () {
+ tr '\015' Q <"$1" | sed -e 's/Q$//'
+}
+
test_expect_success setup '
>file &&
@@ -91,12 +95,13 @@ test_expect_success 'withfix (backward)' '
sed -e /h/d file-fixed >fixed-head &&
sed -e /h/d file >file-head &&
- test_cmp fixed-head file-head &&
+ remove_cr file-head >file-head1
+ diff fixed-head file-head1 &&
sed -n -e /h/p file-fixed >fixed-tail &&
sed -n -e /h/p file >file-tail &&
- ! test_cmp fixed-tail file-tail
+ ! diff fixed-tail file-tail
'
diff --git a/t/t4128-apply-root.sh b/t/t4128-apply-root.sh
index 8f6aea4..a03a9c8 100755
--- a/t/t4128-apply-root.sh
+++ b/t/t4128-apply-root.sh
@@ -27,7 +27,7 @@ test_expect_success 'apply --directory -p (1)' '
git apply --directory=some/sub -p3 --index patch &&
test Bello = $(git show :some/sub/dir/file) &&
- test Bello = $(cat some/sub/dir/file)
+ test_eq_cat Bello some/sub/dir/file
'
@@ -36,7 +36,7 @@ test_expect_success 'apply --directory -p (2) ' '
git reset --hard initial &&
git apply --directory=some/sub/ -p3 --index patch &&
test Bello = $(git show :some/sub/dir/file) &&
- test Bello = $(cat some/sub/dir/file)
+ test_eq_cat Bello some/sub/dir/file
'
@@ -54,7 +54,7 @@ test_expect_success 'apply --directory (new file)' '
git reset --hard initial &&
git apply --directory=some/sub/dir/ --index patch &&
test content = $(git show :some/sub/dir/newfile) &&
- test content = $(cat some/sub/dir/newfile)
+ test_eq_cat content some/sub/dir/newfile
'
cat > patch << EOF
@@ -89,7 +89,7 @@ test_expect_success 'apply --directory (quoted filename)' '
git reset --hard initial &&
git apply --directory=some/sub/dir/ --index patch &&
test content = $(git show :some/sub/dir/quotefile) &&
- test content = $(cat some/sub/dir/quotefile)
+ test_eq_cat content some/sub/dir/quotefile
'
test_done
diff --git a/t/t4150-am.sh b/t/t4150-am.sh
index d6ebbae..27570b7 100755
--- a/t/t4150-am.sh
+++ b/t/t4150-am.sh
@@ -190,7 +190,7 @@ test_expect_success 'am --skip works' '
git am --skip &&
! test -d .git/rebase-apply &&
test -z "$(git diff lorem2^^ -- file)" &&
- test goodbye = "$(cat another)"
+ test_eq_cat goodbye another
'
test_expect_success 'am --resolved works' '
@@ -201,7 +201,7 @@ test_expect_success 'am --resolved works' '
git add file &&
git am --resolved &&
! test -d .git/rebase-apply &&
- test goodbye = "$(cat another)"
+ test_eq_cat goodbye another
'
test_expect_success 'am takes patches from a Pine mailbox' '
diff --git a/t/t4252-am-options.sh b/t/t4252-am-options.sh
index f603c1b..342fc1a 100755
--- a/t/t4252-am-options.sh
+++ b/t/t4252-am-options.sh
@@ -3,6 +3,10 @@
test_description='git am with options and not losing them'
. ./test-lib.sh
+remove_cr () {
+ tr '\015' Q <"$1" | sed -e 's/Q$//'
+}
+
tm="$TEST_DIRECTORY/t4252"
test_expect_success setup '
@@ -20,7 +24,8 @@ test_expect_success 'interrupted am --whitespace=fix' '
test_must_fail git am --whitespace=fix "$tm"/am-test-1-? &&
git am --skip &&
grep 3 file-1 &&
- grep "^Six$" file-2
+ remove_cr file-2 >file-2a &&
+ grep "^Six$" file-2a
'
test_expect_success 'interrupted am -C1' '
@@ -29,7 +34,8 @@ test_expect_success 'interrupted am -C1' '
test_must_fail git am -C1 "$tm"/am-test-2-? &&
git am --skip &&
grep 3 file-1 &&
- grep "^Three$" file-2
+ remove_cr file-2 >file-2a &&
+ grep "^Three$" file-2a
'
test_expect_success 'interrupted am -p2' '
@@ -38,7 +44,8 @@ test_expect_success 'interrupted am -p2' '
test_must_fail git am -p2 "$tm"/am-test-3-? &&
git am --skip &&
grep 3 file-1 &&
- grep "^Three$" file-2
+ remove_cr file-2 >file-2a &&
+ grep "^Three$" file-2a
'
test_expect_success 'interrupted am -C1 -p2' '
@@ -47,7 +54,8 @@ test_expect_success 'interrupted am -C1 -p2' '
test_must_fail git am -p2 -C1 "$tm"/am-test-4-? &&
git am --skip &&
grep 3 file-1 &&
- grep "^Three$" file-2
+ remove_cr file-2 >file-2a &&
+ grep "^Three$" file-2a
'
test_expect_success 'interrupted am --directory="frotz nitfol"' '
diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
index abb41b0..28d6291 100755
--- a/t/t5000-tar-tree.sh
+++ b/t/t5000-tar-tree.sh
@@ -25,6 +25,8 @@ commit id embedding:
'
. ./test-lib.sh
+autocrlf=$(git config core.autocrlf)
+
UNZIP=${UNZIP:-unzip}
SUBSTFORMAT=%H%n
@@ -66,6 +68,8 @@ test_expect_success \
'git clone --bare . bare.git &&
cp .git/info/attributes bare.git/info/attributes'
+test ! -z "$autocrlf" && (cd bare.git; git config core.autocrlf $autocrlf)
+
test_expect_success \
'remove ignored file' \
'rm a/ignored'
@@ -118,7 +122,7 @@ test_expect_success \
test_expect_success \
'validate file contents' \
- 'diff -r a b/a'
+ 'diff -rb a b/a'
test_expect_success \
'git tar-tree with prefix' \
@@ -135,7 +139,7 @@ test_expect_success \
test_expect_success \
'validate file contents with prefix' \
- 'diff -r a c/prefix/a'
+ 'diff -rb a c/prefix/a'
test_expect_success \
'create archives with substfiles' \
@@ -203,7 +207,7 @@ test_expect_success UNZIP \
test_expect_success UNZIP \
'validate file contents' \
- 'diff -r a d/a'
+ 'diff -rb a d/a'
test_expect_success \
'git archive --format=zip with prefix' \
@@ -220,7 +224,7 @@ test_expect_success UNZIP \
test_expect_success UNZIP \
'validate file contents with prefix' \
- 'diff -r a e/prefix/a'
+ 'diff -rb a e/prefix/a'
test_expect_success \
'git archive --list outside of a git repo' \
diff --git a/t/t5001-archive-attr.sh b/t/t5001-archive-attr.sh
index 426b319..2efa018 100755
--- a/t/t5001-archive-attr.sh
+++ b/t/t5001-archive-attr.sh
@@ -3,6 +3,7 @@
test_description='git archive attribute tests'
. ./test-lib.sh
+autocrlf=$(git config core.autocrlf)
SUBSTFORMAT=%H%n
@@ -39,6 +40,8 @@ test_expect_success 'setup' '
cp .git/info/attributes bare/info/attributes
'
+test ! -z "$autocrlf" && (cd bare; git config core.autocrlf $autocrlf)
+
test_expect_success 'git archive' '
git archive HEAD >archive.tar &&
(mkdir archive && cd archive && "$TAR" xf -) <archive.tar
diff --git a/t/t5520-pull.sh b/t/t5520-pull.sh
index 725771f..4d4e7ac 100755
--- a/t/t5520-pull.sh
+++ b/t/t5520-pull.sh
@@ -49,9 +49,9 @@ test_expect_success 'test . as a remote' '
echo updated >file &&
git commit -a -m updated &&
git checkout copy &&
- test `cat file` = file &&
+ test_cat_eq file file &&
git pull &&
- test `cat file` = updated
+ test_cat_eq file updated
'
test_expect_success 'the default remote . should not break explicit pull' '
@@ -60,9 +60,9 @@ test_expect_success 'the default remote . should not break explicit pull' '
git commit -a -m modified &&
git checkout copy &&
git reset --hard HEAD^ &&
- test `cat file` = file &&
+ test_cat_eq file file &&
git pull . second &&
- test `cat file` = modified
+ test_cat_eq file modified
'
test_expect_success '--rebase' '
@@ -99,8 +99,8 @@ test_expect_success '--rebase with rebased upstream' '
echo file > file2 &&
git commit -m to-rebase file2 &&
git pull --rebase me copy &&
- test "conflicting modification" = "$(cat file)" &&
- test file = $(cat file2)
+ test_eq_cat "conflicting modification" file &&
+ test_eq_cat file file2
'
diff --git a/t/t7003-filter-branch.sh b/t/t7003-filter-branch.sh
index 329c851..c6e9fb5 100755
--- a/t/t7003-filter-branch.sh
+++ b/t/t7003-filter-branch.sh
@@ -72,7 +72,7 @@ test_expect_success 'test that the file was renamed' '
test d = "$(git show HEAD:doh --)" &&
! test -f d &&
test -f doh &&
- test d = "$(cat doh)"
+ test_eq_cat d doh
'
test_expect_success 'rewrite, renaming a specific directory' '
@@ -85,7 +85,7 @@ test_expect_success 'test that the directory was renamed' '
test -d diroh &&
! test -d diroh/dir &&
test -f diroh/d &&
- test dir/d = "$(cat diroh/d)"
+ test_eq_cat dir/d diroh/d
'
git tag oldD HEAD~4
diff --git a/t/t7201-co.sh b/t/t7201-co.sh
index bdb808a..62f58eb 100755
--- a/t/t7201-co.sh
+++ b/t/t7201-co.sh
@@ -434,7 +434,7 @@ test_expect_success 'checkout unmerged stage' '
test_cmp expect filf &&
test_cmp expect file &&
git checkout --theirs file &&
- test ztheirside = "z$(cat file)"
+ test_eq_cat theirside file
'
test_expect_success 'checkout with --merge' '
diff --git a/t/t7402-submodule-rebase.sh b/t/t7402-submodule-rebase.sh
index f919c8d..8e5d747 100755
--- a/t/t7402-submodule-rebase.sh
+++ b/t/t7402-submodule-rebase.sh
@@ -80,11 +80,11 @@ test_expect_success 'stash with a dirty submodule' '
echo new > file &&
CURRENT=$(cd submodule && git rev-parse HEAD) &&
git stash &&
- test new != $(cat file) &&
+ test_ne_cat new file &&
test submodule = $(git diff --name-only) &&
test $CURRENT = $(cd submodule && git rev-parse HEAD) &&
git stash apply &&
- test new = $(cat file) &&
+ test_eq_cat new file &&
test $CURRENT = $(cd submodule && git rev-parse HEAD)
'
diff --git a/t/t7610-mergetool.sh b/t/t7610-mergetool.sh
index e768c3e..bf39e45 100755
--- a/t/t7610-mergetool.sh
+++ b/t/t7610-mergetool.sh
@@ -45,9 +45,9 @@ test_expect_success 'custom mergetool' '
( yes "" | git mergetool file1 >/dev/null 2>&1 ) &&
( yes "" | git mergetool file2 >/dev/null 2>&1 ) &&
( yes "" | git mergetool subdir/file3 >/dev/null 2>&1 ) &&
- test "$(cat file1)" = "master updated" &&
- test "$(cat file2)" = "master new" &&
- test "$(cat subdir/file3)" = "master new sub" &&
+ test_cat_eq file1 "master updated" &&
+ test_cat_eq file2 "master new" &&
+ test_cat_eq subdir/file3 "master new sub" &&
git commit -m "branch1 resolved with mergetool"
'
diff --git a/t/t7800-difftool.sh b/t/t7800-difftool.sh
index ebdccf9..b95069a 100755
--- a/t/t7800-difftool.sh
+++ b/t/t7800-difftool.sh
@@ -35,11 +35,12 @@ restore_test_defaults()
unset GIT_DIFFTOOL_PROMPT
unset GIT_DIFFTOOL_NO_PROMPT
git config diff.tool test-tool &&
- git config difftool.test-tool.cmd 'cat $LOCAL'
+ git config difftool.test-tool.cmd "tr '\015' '\012' <\$LOCAL"
}
prompt_given()
{
+ test_debug "echo prompt_given:$1"
prompt="$1"
test "$prompt" = "Hit return to launch 'test-tool': branch"
}
@@ -59,7 +60,7 @@ test_expect_success 'setup' '
# Configure a custom difftool.<tool>.cmd and use it
test_expect_success 'custom commands' '
restore_test_defaults &&
- git config difftool.test-tool.cmd "cat \$REMOTE" &&
+ git config difftool.test-tool.cmd "tr '\''\015'\'' '\''\012'\'' <\$REMOTE" &&
diff=$(git difftool --no-prompt branch) &&
test "$diff" = "master" &&
@@ -136,7 +137,7 @@ test_expect_success 'GIT_DIFFTOOL_PROMPT variable' '
GIT_DIFFTOOL_PROMPT=true &&
export GIT_DIFFTOOL_PROMPT &&
- prompt=$(echo | git difftool --prompt branch | tail -1) &&
+ prompt=$(echo | git difftool --prompt branch | head -3 | tail -1) &&
prompt_given "$prompt" &&
restore_test_defaults
@@ -166,7 +167,7 @@ test_expect_success 'difftool.prompt can overridden with -y' '
test_expect_success 'difftool.prompt can overridden with --prompt' '
git config difftool.prompt false &&
- prompt=$(echo | git difftool --prompt branch | tail -1) &&
+ prompt=$(echo | git difftool --prompt branch | head -3 | tail -1) &&
prompt_given "$prompt" &&
restore_test_defaults
@@ -179,7 +180,7 @@ test_expect_success 'difftool last flag wins' '
restore_test_defaults &&
- prompt=$(echo | git difftool --no-prompt --prompt branch | tail -1) &&
+ prompt=$(echo | git difftool --no-prompt --prompt branch | head -3 | tail -1) &&
prompt_given "$prompt" &&
restore_test_defaults
@@ -190,7 +191,7 @@ test_expect_success 'difftool last flag wins' '
test_expect_success 'difftool + mergetool config variables' '
remove_config_vars
git config merge.tool test-tool &&
- git config mergetool.test-tool.cmd "cat \$LOCAL" &&
+ git config mergetool.test-tool.cmd "tr '\''\015'\'' '\''\012'\'' <\$LOCAL" &&
diff=$(git difftool --no-prompt branch) &&
test "$diff" = "branch" &&
diff --git a/t/t9700-perl-git.sh b/t/t9700-perl-git.sh
index b4ca244..76f741f 100755
--- a/t/t9700-perl-git.sh
+++ b/t/t9700-perl-git.sh
@@ -42,7 +42,7 @@ test_expect_success \
git config --add test.int 2k
'
-test_external_without_stderr \
+test_external_with_only_warning \
'Perl API' \
perl "$TEST_DIRECTORY"/t9700/test.pl
--
1.6.3.15.g49878
^ permalink raw reply related [flat|nested] 256+ messages in thread
* (unknown)
@ 2009-05-11 18:57 Don Slutz
0 siblings, 0 replies; 256+ messages in thread
From: Don Slutz @ 2009-05-11 18:57 UTC (permalink / raw)
To: git
>From 3f0280a44185d1c7f6b653988bc0b46d239cdd17 Mon Sep 17 00:00:00 2001
From: Don Slutz <Don.Slutz@SierraAtlantic.com>
Date: Mon, 11 May 2009 11:48:54 -0400
Subject: [PATCH 2/6] Fix tests to work with core.autocrlf=true
test-lib changes.
Run the tests via:
GIT_TEST_AUTO_CRLF=true make test
Change the default value of GIT_TEST_CMP to ignore whitespace changes
when core.autocrlf=true
Add support functions: test_external_with_only_warning, test_eq_cat,
test_cat_eq, and test_ne_cat all of which will ignore CR if it is in
the file.
Signed-off-by: Don Slutz <Don.Slutz@SierraAtlantic.com>
---
t/test-lib.sh | 59 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 58 insertions(+), 1 deletions(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 218bd82..84846cd 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -59,7 +59,6 @@ export GIT_MERGE_VERBOSITY
export GIT_AUTHOR_EMAIL GIT_AUTHOR_NAME
export GIT_COMMITTER_EMAIL GIT_COMMITTER_NAME
export EDITOR VISUAL
-GIT_TEST_CMP=${GIT_TEST_CMP:-diff -u}
# Protect ourselves from common misconfiguration to export
# CDPATH into the environment
@@ -129,6 +128,11 @@ case $(uname -s) in
*)
;;
esac
+if test ! -z $GIT_TEST_AUTO_CRLF && test $GIT_TEST_AUTO_CRLF = true; then
+ GIT_TEST_CMP=${GIT_TEST_CMP:-diff -uw}
+else
+ GIT_TEST_CMP=${GIT_TEST_CMP:-diff -u}
+fi
if test -n "$color"; then
say_color () {
@@ -459,6 +463,35 @@ test_external_without_stderr () {
fi
}
+# Like test_external, but in addition tests that the command generated
+# only "warning: LF will be replaced by CRLF" output on stderr.
+test_external_with_only_warning () {
+ # The temporary file has no (and must have no) security
+ # implications.
+ tmp="$TMPDIR"; if [ -z "$tmp" ]; then tmp=/tmp; fi
+ stderr="$tmp/git-external-stderr.$$.tmp"
+ test_external "$@" 4> "$stderr"
+ [ -f "$stderr" ] || error "Internal error: $stderr disappeared."
+ descr="only warning: $1"
+ shift
+ say >&3 "expecting only warnings from previous command"
+ output=$(grep -v "warning: LF will be replaced by CRLF in" $stderr)
+ test_debug "echo non-warning: $output"
+ if [ -z "$output" ]; then
+ rm "$stderr"
+ test_ok_ "$descr"
+ else
+ if [ "$verbose" = t ]; then
+ output=`echo; echo Stderr is:; cat "$stderr"`
+ else
+ output=
+ fi
+ # rm first in case test_failure exits.
+ rm "$stderr"
+ test_failure_ "$descr" "$@" "$output"
+ fi
+}
+
# This is not among top-level (test_expect_success | test_expect_failure)
# but is a prefix that can be used in the test script, like:
#
@@ -493,6 +526,30 @@ test_cmp() {
$GIT_TEST_CMP "$@"
}
+# test_eq_cat is a helper function to compare a 1 word file
+# with a string.
+# It almost the same as: test foo = $(cat bar)
+# for: test_eq_cat foo bar
+#
+# However it works when core.autocrlf = true.
+
+test_eq_cat() {
+ test "$1" = "$(tr '\015' '\012' < "$2")"
+}
+
+# the but not-equal -- may not catch all cases
+
+test_ne_cat() {
+ test "$1" != "$(tr '\015' '\012' < "$2")"
+}
+
+# the same as test_eq_cat, but file is 1st.
+
+test_cat_eq() {
+ test "$(tr '\015' '\012' < "$1")" = "$2"
+}
+
+
# Most tests can use the created repository, but some may need to create more.
# Usage: test_create_repo <directory>
test_create_repo () {
--
1.6.3.15.g49878
^ permalink raw reply related [flat|nested] 256+ messages in thread
* (unknown)
@ 2009-05-11 18:57 Don Slutz
0 siblings, 0 replies; 256+ messages in thread
From: Don Slutz @ 2009-05-11 18:57 UTC (permalink / raw)
To: git
From: Don Slutz <Don.Slutz@SierraAtlantic.com>
Date: Fri, 1 May 2009 15:32:18 -0400
Subject: [PATCH 0/6] Add core.autocrlf=true on cygwin by default during tests
This is a patch set to do the work from mail message:
http://kerneltrap.org/mailarchive/git/2007/8/7/254415
It is split into 6 parts. This is because the tests do not work on
Linux if autocrlf=true.
1) The change to autocrlf=true by default for cygwin
2) Changes to t/test-lib.sh
3) The simple changes to tests to use the new functions.
4) Force core.autocrlf=false tests
5) The changes that switch from using cmp to using test_cmp.
6) Add 'make test-text' to use these changes
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown)
@ 2009-05-11 18:57 Don Slutz
0 siblings, 0 replies; 256+ messages in thread
From: Don Slutz @ 2009-05-11 18:57 UTC (permalink / raw)
To: git
>From 96f9b68bba7ad2ec2c9623709b417f27c2831790 Mon Sep 17 00:00:00 2001
From: Don Slutz <Don.Slutz@SierraAtlantic.com>
Date: Fri, 1 May 2009 15:32:18 -0400
Subject: [PATCH 1/6] Add core.autocrlf=true on cygwin by default during tests
It can be disabled or enabled by using the GIT_TEST_AUTO_CRLF environment
variable.
Signed-off-by: Don Slutz <Don.Slutz@SierraAtlantic.com>
---
t/test-lib.sh | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index dad1437..218bd82 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -119,6 +119,17 @@ do
esac
done
+# Switch to core.autolf = true on cygwin but only by default
+case $(uname -s) in
+*CYGWIN*)
+ GIT_TEST_AUTO_CRLF=${GIT_TEST_AUTO_CRLF:-true}
+ test "$debug" = "" ||
+ echo "Test in mode" $(cygpath --mode . | cut -d: -f2-) "mount"
+ ;;
+*)
+ ;;
+esac
+
if test -n "$color"; then
say_color () {
(
@@ -493,6 +504,11 @@ test_create_repo () {
cd "$repo" || error "Cannot setup test environment"
"$GIT_EXEC_PATH/git-init" "--template=$TEST_DIRECTORY/../templates/blt/" >&3 2>&4 ||
error "cannot run git init -- have you built things yet?"
+ test ! -z "$GIT_TEST_AUTO_CRLF" &&
+ test_debug "echo Switching to autocrlf=$GIT_TEST_AUTO_CRLF" && {
+ git config core.autocrlf $GIT_TEST_AUTO_CRLF ||
+ error "Failed to switch to autocrlf=$GIT_TEST_AUTO_CRLF"
+ }
mv .git/hooks .git/hooks-disabled
cd "$owd"
}
--
1.6.3.15.g49878
^ permalink raw reply related [flat|nested] 256+ messages in thread
* (unknown)
@ 2009-05-11 18:57 Don Slutz
0 siblings, 0 replies; 256+ messages in thread
From: Don Slutz @ 2009-05-11 18:57 UTC (permalink / raw)
To: git
>From c03250cd23864b53986708070cf6d03f4334475d Mon Sep 17 00:00:00 2001
From: Don Slutz <Don.Slutz@SierraAtlantic.com>
Date: Mon, 11 May 2009 12:19:37 -0400
Subject: [PATCH 5/6] Fix tests to work with core.autocrlf=true
Switch from using cmp to using test_cmp in these tests.
Signed-off-by: Don Slutz <Don.Slutz@SierraAtlantic.com>
---
t/t0021-conversion.sh | 12 ++++++------
t/t1020-subdirectory.sh | 12 ++++++------
t/t4127-apply-same-fn.sh | 2 +-
t/t6021-merge-criss-cross.sh | 2 +-
t/t6026-merge-attr.sh | 10 +++++-----
5 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/t/t0021-conversion.sh b/t/t0021-conversion.sh
index 8fc39d7..7a6d8c7 100755
--- a/t/t0021-conversion.sh
+++ b/t/t0021-conversion.sh
@@ -33,17 +33,17 @@ test_expect_success setup '
git checkout -- test test.t test.i
'
-script='s/^\$Id: \([0-9a-f]*\) \$/\1/p'
-
test_expect_success check '
- cmp test.o test &&
- cmp test.o test.t &&
+ test_cmp test.o test &&
+ test_cmp test.o test.t &&
# ident should be stripped in the repository
git diff --raw --exit-code :test :test.i &&
id=$(git rev-parse --verify :test) &&
- embedded=$(sed -ne "$script" test.i) &&
+ test_debug "echo id=$id"
+ embedded=$(grep Id: test.i | cut -d\ -f2) &&
+ test_debug "echo embedded=$embedded"
test "z$id" = "z$embedded" &&
git cat-file blob :test.t > test.r &&
@@ -85,7 +85,7 @@ test_expect_success expanded_in_repo '
rm -f expanded-keywords &&
git checkout -- expanded-keywords &&
cat expanded-keywords &&
- cmp expanded-keywords expected-output
+ test_cmp expanded-keywords expected-output
'
test_done
diff --git a/t/t1020-subdirectory.sh b/t/t1020-subdirectory.sh
index 210e594..ce67e6c 100755
--- a/t/t1020-subdirectory.sh
+++ b/t/t1020-subdirectory.sh
@@ -86,10 +86,10 @@ test_expect_success 'write-tree' '
test_expect_success 'checkout-index' '
cd "$HERE" &&
git checkout-index -f -u one &&
- cmp one original.one &&
+ test_cmp one original.one &&
cd dir &&
git checkout-index -f -u two &&
- cmp two ../original.two
+ test_cmp two ../original.two
'
test_expect_success 'read-tree' '
@@ -97,13 +97,13 @@ test_expect_success 'read-tree' '
rm -f one dir/two &&
tree=`git write-tree` &&
git read-tree --reset -u "$tree" &&
- cmp one original.one &&
- cmp dir/two original.two &&
+ test_cmp one original.one &&
+ test_cmp dir/two original.two &&
cd dir &&
rm -f two &&
git read-tree --reset -u "$tree" &&
- cmp two ../original.two &&
- cmp ../one ../original.one
+ test_cmp two ../original.two &&
+ test_cmp ../one ../original.one
'
test_expect_success 'no file/rev ambiguity check inside .git' '
diff --git a/t/t4127-apply-same-fn.sh b/t/t4127-apply-same-fn.sh
index 3a8202e..66b774f 100755
--- a/t/t4127-apply-same-fn.sh
+++ b/t/t4127-apply-same-fn.sh
@@ -27,7 +27,7 @@ test_expect_success 'apply same filename with independent changes' '
cp same_fn same_fn2 &&
git reset --hard &&
git apply patch0 &&
- diff same_fn same_fn2
+ test_cmp same_fn same_fn2
'
test_expect_success 'apply same filename with overlapping changes' '
diff --git a/t/t6021-merge-criss-cross.sh b/t/t6021-merge-criss-cross.sh
index 331b9b0..53fdfd8 100755
--- a/t/t6021-merge-criss-cross.sh
+++ b/t/t6021-merge-criss-cross.sh
@@ -87,7 +87,7 @@ cat > file-expect <<EOF
9
EOF
-test_expect_success 'Criss-cross merge result' 'cmp file file-expect'
+test_expect_success 'Criss-cross merge result' 'test_cmp file file-expect'
test_expect_success 'Criss-cross merge fails (-s resolve)' \
'git reset --hard A^ &&
diff --git a/t/t6026-merge-attr.sh b/t/t6026-merge-attr.sh
index 1ba0a25..0b57c68 100755
--- a/t/t6026-merge-attr.sh
+++ b/t/t6026-merge-attr.sh
@@ -63,7 +63,7 @@ test_expect_success 'check merge result in working tree' '
git cat-file -p HEAD:binary >binary-orig &&
grep "<<<<<<<" text &&
- cmp binary-orig binary &&
+ test_cmp binary-orig binary &&
! grep "<<<<<<<" union &&
grep Master union &&
grep Side union
@@ -104,14 +104,14 @@ test_expect_success 'custom merge backend' '
git merge master &&
- cmp binary union &&
+ test_cmp binary union &&
sed -e 1,3d text >check-1 &&
o=$(git unpack-file master^:text) &&
a=$(git unpack-file side^:text) &&
b=$(git unpack-file master:text) &&
sh -c "./custom-merge $o $a $b 0" &&
sed -e 1,3d $a >check-2 &&
- cmp check-1 check-2 &&
+ test_cmp check-1 check-2 &&
rm -f $o $a $b
'
@@ -131,14 +131,14 @@ test_expect_success 'custom merge backend' '
echo "Ok, conflicted"
fi &&
- cmp binary union &&
+ test_cmp binary union &&
sed -e 1,3d text >check-1 &&
o=$(git unpack-file master^:text) &&
a=$(git unpack-file anchor:text) &&
b=$(git unpack-file master:text) &&
sh -c "./custom-merge $o $a $b 0" &&
sed -e 1,3d $a >check-2 &&
- cmp check-1 check-2 &&
+ test_cmp check-1 check-2 &&
rm -f $o $a $b
'
--
1.6.3.15.g49878
^ permalink raw reply related [flat|nested] 256+ messages in thread
* (unknown)
@ 2009-05-11 18:57 Don Slutz
0 siblings, 0 replies; 256+ messages in thread
From: Don Slutz @ 2009-05-11 18:57 UTC (permalink / raw)
To: git
>From d60f6f2fdfcdc5cbbd468992ccbc56438fe0e149 Mon Sep 17 00:00:00 2001
From: Don Slutz <Don.Slutz@SierraAtlantic.com>
Date: Mon, 11 May 2009 12:16:55 -0400
Subject: [PATCH 4/6] Fix tests to work with core.autocrlf=true
Force core.autocrlf=false for these tests. Most of these tests are checking
for whitespace differences and so are not simple to fix. The rest are not
clear how to fix.
Signed-off-by: Don Slutz <Don.Slutz@SierraAtlantic.com>
---
t/t1002-read-tree-m-u-2way.sh | 3 ++-
t/t4015-diff-whitespace.sh | 2 ++
t/t4019-diff-wserror.sh | 1 +
t/t4116-apply-reverse.sh | 1 +
t/t4200-rerere.sh | 2 ++
5 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/t/t1002-read-tree-m-u-2way.sh b/t/t1002-read-tree-m-u-2way.sh
index 5e40cec..acc9474 100755
--- a/t/t1002-read-tree-m-u-2way.sh
+++ b/t/t1002-read-tree-m-u-2way.sh
@@ -37,7 +37,8 @@ check_cache_at () {
test_expect_success \
setup \
- 'echo frotz >frotz &&
+ 'git config core.autocrlf false &&
+ echo frotz >frotz &&
echo nitfol >nitfol &&
echo bozbar >bozbar &&
echo rezrov >rezrov &&
diff --git a/t/t4015-diff-whitespace.sh b/t/t4015-diff-whitespace.sh
index 6d13da3..122557e 100755
--- a/t/t4015-diff-whitespace.sh
+++ b/t/t4015-diff-whitespace.sh
@@ -9,6 +9,8 @@ test_description='Test special whitespace in diff engine.
. ./test-lib.sh
. "$TEST_DIRECTORY"/diff-lib.sh
+test_expect_success "setup" 'git config core.autocrlf false'
+
# Ray Lehtiniemi's example
cat << EOF > x
diff --git a/t/t4019-diff-wserror.sh b/t/t4019-diff-wserror.sh
index 84a1fe3..a580403 100755
--- a/t/t4019-diff-wserror.sh
+++ b/t/t4019-diff-wserror.sh
@@ -6,6 +6,7 @@ test_description='diff whitespace error detection'
test_expect_success setup '
+ git config core.autocrlf false &&
git config diff.color.whitespace "blue reverse" &&
>F &&
git add F &&
diff --git a/t/t4116-apply-reverse.sh b/t/t4116-apply-reverse.sh
index 2298ece..a846be6 100755
--- a/t/t4116-apply-reverse.sh
+++ b/t/t4116-apply-reverse.sh
@@ -11,6 +11,7 @@ test_description='git apply in reverse
test_expect_success setup '
+ git config core.autocrlf false &&
for i in a b c d e f g h i j k l m n; do echo $i; done >file1 &&
perl -pe "y/ijk/\\000\\001\\002/" <file1 >file2 &&
diff --git a/t/t4200-rerere.sh b/t/t4200-rerere.sh
index a6bc028..5e6cc82 100755
--- a/t/t4200-rerere.sh
+++ b/t/t4200-rerere.sh
@@ -8,6 +8,8 @@ test_description='git rerere
. ./test-lib.sh
+git config core.autocrlf false
+
cat > a1 << EOF
Some title
==========
--
1.6.3.15.g49878
^ permalink raw reply related [flat|nested] 256+ messages in thread
* [JGIT PATCH 1/2] Fix deadlock in native git protocol client for upload-pack
@ 2009-05-10 22:48 Shawn O. Pearce
2009-05-10 22:48 ` [JGIT PATCH 2/2] Decrease the fetch pack client buffer to the lower minimum Shawn O. Pearce
0 siblings, 1 reply; 256+ messages in thread
From: Shawn O. Pearce @ 2009-05-10 22:48 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
The upload-pack protocol states that for every flush packet
(aka "0000") sent by the client, we get exactly one NAK or
ACK line back. However, if multi_ack is enabled, we may
get multiple "ACK %s continue" lines before the ACK/NAK is
sent by the upload-pack server.
Unfortunately, JGit was counting an "ACK %s continue" as a response
to a flush packet, causing the client side to stop reading from
the server too early. This left a lot of "ACK %s continue" lines
in the server output buffer, eventually causing the server to stop
and wait for the output buffer to drain. However, the client would
also get stuck after sending too many "have %s" lines, eventually
deadlocking the entire client-server pair.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../jgit/transport/BasePackFetchConnection.java | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/BasePackFetchConnection.java b/org.spearce.jgit/src/org/spearce/jgit/transport/BasePackFetchConnection.java
index f07cc4e..eaa94bd 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/BasePackFetchConnection.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/BasePackFetchConnection.java
@@ -359,15 +359,15 @@ private void negotiate(final ProgressMonitor monitor) throws IOException,
continue;
}
- while (resultsPending > 0) {
+ for (;;) {
final PacketLineIn.AckNackResult anr;
anr = pckIn.readACK(ackId);
- resultsPending--;
if (anr == PacketLineIn.AckNackResult.NAK) {
// More have lines are necessary to compute the
// pack on the remote side. Keep doing that.
//
+ resultsPending--;
break;
}
--
1.6.3.48.g99c76
^ permalink raw reply related [flat|nested] 256+ messages in thread
* [JGIT PATCH 2/2] Decrease the fetch pack client buffer to the lower minimum
2009-05-10 22:48 [JGIT PATCH 1/2] Fix deadlock in native git protocol client for upload-pack Shawn O. Pearce
@ 2009-05-10 22:48 ` Shawn O. Pearce
2009-05-11 0:43 ` Junio C Hamano
0 siblings, 1 reply; 256+ messages in thread
From: Shawn O. Pearce @ 2009-05-10 22:48 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
This is the lowest buffer size we actually require to keep the
client and server sides from deadlocking against each other.
Also added documentation, and renamed the symbol to better match
its real purpose; naming the lower threshold we can allow for a
buffer.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../jgit/transport/BasePackFetchConnection.java | 10 +++++++++-
.../org/spearce/jgit/transport/TransportLocal.java | 2 +-
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/BasePackFetchConnection.java b/org.spearce.jgit/src/org/spearce/jgit/transport/BasePackFetchConnection.java
index eaa94bd..1d1b801 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/BasePackFetchConnection.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/BasePackFetchConnection.java
@@ -89,7 +89,15 @@
*/
private static final int MAX_HAVES = 256;
- protected static final int MAX_CLIENT_BUFFER = MAX_HAVES * 46 + 1024;
+ /**
+ * Amount of data the client sends before starting to read.
+ * <p>
+ * Any output stream given to the client must be able to buffer this many
+ * bytes before the client will stop writing and start reading from the
+ * input stream. If the output stream blocks before this many bytes are in
+ * the send queue, the system will deadlock.
+ */
+ protected static final int MIN_CLIENT_BUFFER = 2 * 32 * 46 + 4;
static final String OPTION_INCLUDE_TAG = "include-tag";
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/TransportLocal.java b/org.spearce.jgit/src/org/spearce/jgit/transport/TransportLocal.java
index cffdba1..428f73e 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/TransportLocal.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/TransportLocal.java
@@ -175,7 +175,7 @@ InternalLocalFetchConnection() throws TransportException {
// force the buffer to be big enough, otherwise it
// will deadlock both threads.
{
- buffer = new byte[MAX_CLIENT_BUFFER];
+ buffer = new byte[MIN_CLIENT_BUFFER];
}
};
out_w = new PipedOutputStream(out_r);
--
1.6.3.48.g99c76
^ permalink raw reply related [flat|nested] 256+ messages in thread
* Re: [JGIT PATCH 2/2] Decrease the fetch pack client buffer to the lower minimum
2009-05-10 22:48 ` [JGIT PATCH 2/2] Decrease the fetch pack client buffer to the lower minimum Shawn O. Pearce
@ 2009-05-11 0:43 ` Junio C Hamano
2009-05-11 0:55 ` Shawn O. Pearce
0 siblings, 1 reply; 256+ messages in thread
From: Junio C Hamano @ 2009-05-11 0:43 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Robin Rosenberg, git
"Shawn O. Pearce" <spearce@spearce.org> writes:
> This is the lowest buffer size we actually require to keep the
> client and server sides from deadlocking against each other.
Is this about the fetch-pack protocol where
(1) upload-pack shows what it has; fetch-pack keeps reading until it sees
a flush; then
(2) fetch-pack shows what it wants; upload-pack keeps reading; then
(3) fetch-pack sends a bunch of have's, followed by a flush; upload-pack
keeps reading and then responds with an ACK-continue or NAK, which
fetch-pack reads; this step continues zero or more times; and then
finally
(4) fetch-pack sends a bunch of have's, followed by a flush; upload-pack
keeps reading and then responds with an ACK, fetch-pack says done.
Where do you need "enough buffer"? The conversation looks very much "it's
my turn to talk", "now it's your turn to talk and I'll wait until I hear
from you", to me. I am puzzled.
> Also added documentation, and renamed the symbol to better match
> its real purpose; naming the lower threshold we can allow for a
> buffer.
>
> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
> ---
> .../jgit/transport/BasePackFetchConnection.java | 10 +++++++++-
> .../org/spearce/jgit/transport/TransportLocal.java | 2 +-
> 2 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/BasePackFetchConnection.java b/org.spearce.jgit/src/org/spearce/jgit/transport/BasePackFetchConnection.java
> index eaa94bd..1d1b801 100644
> --- a/org.spearce.jgit/src/org/spearce/jgit/transport/BasePackFetchConnection.java
> +++ b/org.spearce.jgit/src/org/spearce/jgit/transport/BasePackFetchConnection.java
> @@ -89,7 +89,15 @@
> */
> private static final int MAX_HAVES = 256;
>
> - protected static final int MAX_CLIENT_BUFFER = MAX_HAVES * 46 + 1024;
> + /**
> + * Amount of data the client sends before starting to read.
> + * <p>
> + * Any output stream given to the client must be able to buffer this many
> + * bytes before the client will stop writing and start reading from the
> + * input stream. If the output stream blocks before this many bytes are in
> + * the send queue, the system will deadlock.
> + */
> + protected static final int MIN_CLIENT_BUFFER = 2 * 32 * 46 + 4;
>
> static final String OPTION_INCLUDE_TAG = "include-tag";
>
> diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/TransportLocal.java b/org.spearce.jgit/src/org/spearce/jgit/transport/TransportLocal.java
> index cffdba1..428f73e 100644
> --- a/org.spearce.jgit/src/org/spearce/jgit/transport/TransportLocal.java
> +++ b/org.spearce.jgit/src/org/spearce/jgit/transport/TransportLocal.java
> @@ -175,7 +175,7 @@ InternalLocalFetchConnection() throws TransportException {
> // force the buffer to be big enough, otherwise it
> // will deadlock both threads.
> {
> - buffer = new byte[MAX_CLIENT_BUFFER];
> + buffer = new byte[MIN_CLIENT_BUFFER];
> }
> };
> out_w = new PipedOutputStream(out_r);
> --
> 1.6.3.48.g99c76
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [JGIT PATCH 2/2] Decrease the fetch pack client buffer to the lower minimum
2009-05-11 0:43 ` Junio C Hamano
@ 2009-05-11 0:55 ` Shawn O. Pearce
2009-05-11 3:51 ` Junio C Hamano
0 siblings, 1 reply; 256+ messages in thread
From: Shawn O. Pearce @ 2009-05-11 0:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Robin Rosenberg, git
Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> > This is the lowest buffer size we actually require to keep the
> > client and server sides from deadlocking against each other.
>
> Is this about the fetch-pack protocol where
Yes.
> (1) upload-pack shows what it has; fetch-pack keeps reading until it sees
> a flush; then
>
> (2) fetch-pack shows what it wants; upload-pack keeps reading; then
>
> (3) fetch-pack sends a bunch of have's, followed by a flush; upload-pack
> keeps reading and then responds with an ACK-continue or NAK, which
> fetch-pack reads; this step continues zero or more times; and then
> finally
>
> (4) fetch-pack sends a bunch of have's, followed by a flush; upload-pack
> keeps reading and then responds with an ACK, fetch-pack says done.
>
> Where do you need "enough buffer"? The conversation looks very much "it's
> my turn to talk", "now it's your turn to talk and I'll wait until I hear
> from you", to me. I am puzzled.
In step 3 during the first round the client can send up to 2 blocks
worth of data, with 32 haves per block. This means the client
writes 2952 bytes of data before it reads.
C Git doesn't run into this sort of problem because a normal pipe
would get 1 page (~4096 bytes) in the kernel for the FIFO buffer.
In SSH transport, we still have 4096 between us and the ssh client
process, plus that has its own buffering.
In TCP transport, we have the kernel TX buffer on this side, and the
kernel RX buffer on the remote side, plus network switch buffers in
the middle. 2952 bytes nicely fits into just over 2 IP packets,
and the TCP window is sufficiently large enough to allow these to
be sent without blocking the writer.
We need to be able to shove 2952 bytes down at the other guy before
we start listening to him. The upload-pack side of the system can
(at worst) send us 64 "ACK %s continue" lines. We must be able
to enter into the receive mode before the upload-pack side fills
their outgoing buffer.
In the Sun JVMs a pure in-memory pipe only has room for 1024 bytes
in the FIFO before it blocks. Though the technique I am using to
boost the FIFO from 1024 to 2952 bytes isn't necessarily going to
be portable to other JVMs. If both sides only have 1024 bytes of
buffer available and both sides can possibly write more than that,
we deadlock.
> > + /**
> > + * Amount of data the client sends before starting to read.
> > + * <p>
> > + * Any output stream given to the client must be able to buffer this many
> > + * bytes before the client will stop writing and start reading from the
> > + * input stream. If the output stream blocks before this many bytes are in
> > + * the send queue, the system will deadlock.
> > + */
> > + protected static final int MIN_CLIENT_BUFFER = 2 * 32 * 46 + 4;
And this should be + 8 here. F@!*!
Robin, can you amend? It should be + 8 because we send to end()
packets in that initial burst, each packet is 4 bytes in size.
--
Shawn.
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [JGIT PATCH 2/2] Decrease the fetch pack client buffer to the lower minimum
2009-05-11 0:55 ` Shawn O. Pearce
@ 2009-05-11 3:51 ` Junio C Hamano
2009-05-11 14:10 ` Shawn O. Pearce
0 siblings, 1 reply; 256+ messages in thread
From: Junio C Hamano @ 2009-05-11 3:51 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, Robin Rosenberg, git
"Shawn O. Pearce" <spearce@spearce.org> writes:
> In step 3 during the first round the client can send up to 2 blocks
> worth of data, with 32 haves per block. This means the client
> writes 2952 bytes of data before it reads.
Sorry, perhaps I am being extremely slow, but even if the client writes
millions of bytes before it starts reading, I do not see how it would be a
problem as long as the other side reads these millions of bytes before
saying "Ok, I've heard about them and my response so far is Ack-continue
(or NAK)", which the client needs to read.
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [JGIT PATCH 2/2] Decrease the fetch pack client buffer to the lower minimum
2009-05-11 3:51 ` Junio C Hamano
@ 2009-05-11 14:10 ` Shawn O. Pearce
2009-05-11 14:23 ` (unknown), Carl Mercier
0 siblings, 1 reply; 256+ messages in thread
From: Shawn O. Pearce @ 2009-05-11 14:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Robin Rosenberg, git
Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> > In step 3 during the first round the client can send up to 2 blocks
> > worth of data, with 32 haves per block. This means the client
> > writes 2952 bytes of data before it reads.
>
> Sorry, perhaps I am being extremely slow, but even if the client writes
> millions of bytes before it starts reading, I do not see how it would be a
> problem as long as the other side reads these millions of bytes before
> saying "Ok, I've heard about them and my response so far is Ack-continue
> (or NAK)", which the client needs to read.
Ok, maybe my understanding of the fetch-pack/upload-pack protocol
is incorrect.
If multi_ack is enabled then isn't it possible for the remote to
return "ACK %s continue" for the first 63 "have %s" lines the
client sent?
E.g. the case is the client has only one ref, and has only 1 commit
the other side doesn't have, and the other side has only one ref,
and has only 1 commit the client doesn't have (so the client will
fetch 1 commit). In such a case, the client will blast 64 have lines
before pausing to listen to the server. But the server will have
63 of those lines, and will try to send "ACK %s continue" in vain
at the client, hoping it will stop enumerating along that branch.
If there is insufficient buffering along one of those writers,
the entire thing deadlocks.
--
Shawn.
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2009-05-07 17:01 Bevan Watkiss
0 siblings, 0 replies; 256+ messages in thread
From: Bevan Watkiss @ 2009-05-07 17:01 UTC (permalink / raw)
To: git
I am trying to create a working tree for people to read from and have it
update from a bare repository regularly. Right now I am using git-pull to
fetch the changes, but its running slow due to the size of my repo and the
speed of the hardware as it seems to be checking the working tree for any
changes.
Is there a way to make the pull ignore the local working tree and only look
at files that are changed in the change sets being pulled?
Bevan
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2009-04-16 23:17 Fawad Hassan Ismail
0 siblings, 0 replies; 256+ messages in thread
From: Fawad Hassan Ismail @ 2009-04-16 23:17 UTC (permalink / raw)
To: git
subscribe
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2009-03-30 5:03 David Aguilar
0 siblings, 0 replies; 256+ messages in thread
From: David Aguilar @ 2009-03-30 5:03 UTC (permalink / raw)
To: gitster; +Cc: git
As promised, here is the patch series that removes the duplicate
code between git-difftool and git-mergetool.
This is based on top of Junio's "pu" branch and is a
continuation of the recent difftool series.
I created a new git-sh-tools shell lib for holding the
common functions. If anyone thinks I should have placed the
functions in git-sh-setup instead then just let me know.
Here's a total diffstat. If it wasn't for the documentation
and replacing the mixed spaces/tabs with all-tabs in
git-mergetool then we would have seen a lot more
happy removals.
.gitignore | 1 +
Documentation/git-sh-tools.txt | 52 ++++
Makefile | 1 +
command-list.txt | 1 +
git-difftool-helper.sh | 112 +-------
git-mergetool.sh | 639 ++++++++++++++++------------------------
git-sh-tools.sh | 181 ++++++++++++
7 files changed, 506 insertions(+), 481 deletions(-)
GIT:
From: David Aguilar <davvid@gmail.com>
Subject: Refactor git-{diff,merge}tool to remove duplicate code
In-Reply-To:
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2009-03-27 20:39 Lachlan Deck
0 siblings, 0 replies; 256+ messages in thread
From: Lachlan Deck @ 2009-03-27 20:39 UTC (permalink / raw)
To: git
subscribe
^ permalink raw reply [flat|nested] 256+ messages in thread
* undoing something
@ 2009-03-16 19:06 John Dlugosz
2009-03-16 19:14 ` Junio C Hamano
0 siblings, 1 reply; 256+ messages in thread
From: John Dlugosz @ 2009-03-16 19:06 UTC (permalink / raw)
To: git
I made a mistake. Big deal, now that I know that git storage is
immutable and changes just add to what's already there.
A quick look at
git reflog show topic
tells me that {1} is the one I want. So, how do I rewind branch topic
to point to topic@{1} ?
I did it by making a tag, and then in gitk pointing to it and picking
"reset to here" from the context menu.
A while back I was looking for the right/easy way to simply repoint my
branch to where I wanted. The best answer was to use push. But, I
wonder if gitk and other high-level commands simply call a more
primitive command that does this? And can I call it directly? Or is
push with a dot as the repository just doing this with no excessive
processing and trust that the side-effects are all vacuous?
--John
(please excuse the footer; it's not my choice)
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
If you received this in error, please contact the sender and delete the material from any computer.
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: undoing something
2009-03-16 19:06 undoing something John Dlugosz
@ 2009-03-16 19:14 ` Junio C Hamano
2009-03-16 19:48 ` John Dlugosz
0 siblings, 1 reply; 256+ messages in thread
From: Junio C Hamano @ 2009-03-16 19:14 UTC (permalink / raw)
To: John Dlugosz; +Cc: git
"John Dlugosz" <JDlugosz@TradeStation.com> writes:
> I made a mistake. Big deal, now that I know that git storage is
> immutable and changes just add to what's already there.
>
> A quick look at
> git reflog show topic
> tells me that {1} is the one I want. So, how do I rewind branch topic
> to point to topic@{1} ?
> I did it by making a tag, and then in gitk pointing to it and picking
> "reset to here" from the context menu.
>
> A while back I was looking for the right/easy way to simply repoint my
> branch to where I wanted. The best answer was to use push.
The answer was best only because in your previous question you wanted to
ensure fast-forwardness, i.e. "git push . origin/dev:dev" without plus in
front to cause it to fail if it is not fast-forward.
If you know you have one unwanted commit you would want to discard at the
tip of topic, you do not want fast-foward safety to kick in.
(1) if you are on the topic branch, you can say "git reset --hard HEAD^";
or
(2) if you are not, you can obviously check out topic and do the above,
or "git branch -f topic topic^".
If the garbage you have at the tip of the topic is not just a single
commit, you can replace HEAD^ and topic^ in the above with whatever commit
you would want to point the tip at.
^ permalink raw reply [flat|nested] 256+ messages in thread
* RE: undoing something
2009-03-16 19:14 ` Junio C Hamano
@ 2009-03-16 19:48 ` John Dlugosz
2009-03-16 21:45 ` (unknown), Nanako Shiraishi
0 siblings, 1 reply; 256+ messages in thread
From: John Dlugosz @ 2009-03-16 19:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
=== Re: ===
The answer was best only because in your previous question you wanted to
ensure fast-forwardness, i.e. "git push . origin/dev:dev" without plus
in
front to cause it to fail if it is not fast-forward.
=== end ===
No, I don't want to ensure ff. The remote may have been changed in
other ways. Though in that case I will avoid doing so; when it is not
the case it's even more important to see that your local copy is
different, and understand the tree, rather than blindly pulling.
=== Re: ===
If you know you have one unwanted commit you would want to discard at
the
tip of topic, you do not want fast-foward safety to kick in.
(1) if you are on the topic branch, you can say "git reset --hard
HEAD^";
or
=== end ===
It was a rebase, so the old value is not under the current, or even
visible on the tree. That's why I needed the reflog to find it.
Tagging it let it appear in gitk.
=== Re: ===
(2) if you are not, you can obviously check out topic and do the above,
or "git branch -f topic topic^".
=== end ===
As documented, this destroys the existing branch and makes a new one.
That would, by design, blow away the reflog for that branch. What I
want is a way to re-point it, and record that repointing =in= the
reflog. That is, a command-line version that does what I can do with
the GUI, but isn't limited to what I can point to with the mouse.
--John
(please excuse the footer, yadda yadda)
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
If you received this in error, please contact the sender and delete the material from any computer.
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
2009-03-16 19:48 ` John Dlugosz
@ 2009-03-16 21:45 ` Nanako Shiraishi
0 siblings, 0 replies; 256+ messages in thread
From: Nanako Shiraishi @ 2009-03-16 21:45 UTC (permalink / raw)
To: John Dlugosz; +Cc: Junio C Hamano, git
Quoting John Dlugosz <JDlugosz@TradeStation.com>:
> === Re: ===
> (2) if you are not, you can obviously check out topic and do the above,
> or "git branch -f topic topic^".
> === end ===
>
> As documented, this destroys the existing branch and makes a new one.
> That would, by design, blow away the reflog for that branch.
Does it? If so I think you have an incorrect documentation.
$ rm -fr /tmp/gomi && mkdir /tmp/gomi
$ cd /tmp/gomi
$ git init
$ echo hello >world
$ git add world
$ git commit -m initial
$ seq 1 100 | while read num; do echo $num >world; git commit -a -m $num; done
$ git checkout -b side master~60
$ git branch -f master master@{20}
$ git log --oneline -g master | head -n 10
0acf8c1 master@{0}: branch: Reset from master@{20}
945c3ee master@{1}: commit: 100
54fcb36 master@{2}: commit: 99
b314a1e master@{3}: commit: 98
e91d999 master@{4}: commit: 97
0d88853 master@{5}: commit: 96
0124315 master@{6}: commit: 95
5df2cc5 master@{7}: commit: 94
14bb58e master@{8}: commit: 93
0813a46 master@{9}: commit: 92
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown)
@ 2009-03-13 8:21 Werner Riener
0 siblings, 0 replies; 256+ messages in thread
From: Werner Riener @ 2009-03-13 8:21 UTC (permalink / raw)
To: git
subscribe
--
Werner Riener
Generalsekretär des
Aikikai Verband Österreichischer Aikido-Schulen
Tel: +43-0699-101 32 940
Email: riener_w@gmx.net
URI: http://www.aikikai.at
http://home.pages.at/werrie/
Nur bis 16.03.! DSL-Komplettanschluss inkl. WLAN-Modem für nur
17,95 ¿/mtl. + 1 Monat gratis!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2009-02-06 9:45 info
0 siblings, 0 replies; 256+ messages in thread
From: info @ 2009-02-06 9:45 UTC (permalink / raw)
Your Email Emerge a winner of 250,000.00 Euros dr.simonperez1@hotmail.co.uk
----------------------------------------------------------------
This message was sent using http://webmail.coqui.net
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2009-02-06 9:43 info
0 siblings, 0 replies; 256+ messages in thread
From: info @ 2009-02-06 9:43 UTC (permalink / raw)
Your Email Emerge a winner of 250,000.00 Euros dr.simonperez1@hotmail.co.uk
----------------------------------------------------------------
This message was sent using http://webmail.coqui.net
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown)
@ 2009-01-09 19:02 nathan.panike
0 siblings, 0 replies; 256+ messages in thread
From: nathan.panike @ 2009-01-09 19:02 UTC (permalink / raw)
>From 65c4fed27fe9752ffd0e3b7cb6807561a4dd4601 Mon Sep 17 00: 00:00 2001
From: Nathan W. Panike <nathan.panike@gmail.com>
Date: Fri, 9 Jan 2009 11:53:43 -0600
Subject: [PATCH] Get format-patch to show first commit after root commit
Currently, the command
git format-patch -1 e83c5163316f89bfbde
in the git repository creates an empty file. Instead, one is
forced to do
git format-patch -1 --root e83c5163316f89bfbde
This seems arbitrary. This patch fixes this case, so that
git format-patch -1 e83c5163316f89bfbde
will produce an actual patch.
---
builtin-log.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index 4a02ee9..5e7b61f 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -977,6 +977,8 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
list[nr - 1] = commit;
}
total = nr;
+ if (total == 1 && !list[0]->parents)
+ rev.show_root_diff=1;
if (!keep_subject && auto_number && total > 1)
numbered = 1;
if (numbered)
--
1.6.1.76.gc123b.dirty
^ permalink raw reply related [flat|nested] 256+ messages in thread
* (unknown),
@ 2008-10-05 23:36 Robin Rosenberg
0 siblings, 0 replies; 256+ messages in thread
From: Robin Rosenberg @ 2008-10-05 23:36 UTC (permalink / raw)
To: git; +Cc: spearce
This series decorates the graphical and text (jgit log) history listings
with tags. For the text command it is optional.
Reviewers may want to pay special attention to the changes in the Ref class.
-- robin
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown)
@ 2008-08-21 19:15 bpeeluk
0 siblings, 0 replies; 256+ messages in thread
From: bpeeluk @ 2008-08-21 19:15 UTC (permalink / raw)
>From e2b0f6749bca6f6bc7a5397fe2bd28de25db07c1 Mon Sep 17 00:00:00 2001
From: Neil Roberts <bpeeluk@yahoo.co.uk>
Date: Thu, 21 Aug 2008 19:49:58 +0100
Subject: [PATCH] config.mak.in: Pass on LDFLAGS from configure
The configure script allows you to specify flags to pass to the linker
step in the LDFLAGS environment variable but this was being ignored in
the Makefile. Now a make variable gets set to the value passed down
from the configure script.
Signed-off-by: Neil Roberts <bpeeluk@yahoo.co.uk>
---
config.mak.in | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/config.mak.in b/config.mak.in
index b776149..f67d673 100644
--- a/config.mak.in
+++ b/config.mak.in
@@ -3,6 +3,7 @@
CC = @CC@
CFLAGS = @CFLAGS@
+LDFLAGS = @LDFLAGS@
AR = @AR@
TAR = @TAR@
#INSTALL = @INSTALL@ # needs install-sh or install.sh in sources
--
1.5.4.3
^ permalink raw reply related [flat|nested] 256+ messages in thread
* (unknown),
@ 2008-08-13 14:54 aneesh.kumar
0 siblings, 0 replies; 256+ messages in thread
From: aneesh.kumar @ 2008-08-13 14:54 UTC (permalink / raw)
To: pasky; +Cc: git, Aneesh Kumar K.V
From: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
topgit: Implement tg-import
This can be used to import a set of commits
between range specified by range1..range2
This should help us to convert an already
existing quilt, stgit branches to topgit
managed one
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
---
Makefile | 2 +-
README | 7 ++++++
tg-create.sh | 22 ++++++++----------
tg-export.sh | 2 +-
tg-import.sh | 68 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
5 files changed, 87 insertions(+), 14 deletions(-)
diff --git a/Makefile b/Makefile
index 6eade1e..95624ac 100644
--- a/Makefile
+++ b/Makefile
@@ -6,7 +6,7 @@ sharedir = $(PREFIX)/share/topgit
hooksdir = $(cmddir)/hooks
-commands_in = tg-create.sh tg-delete.sh tg-export.sh tg-info.sh tg-patch.sh tg-summary.sh tg-update.sh
+commands_in = tg-create.sh tg-delete.sh tg-export.sh tg-info.sh tg-patch.sh tg-summary.sh tg-update.sh tg-import.sh
hooks_in = hooks/pre-commit.sh
commands_out = $(patsubst %.sh,%,$(commands_in))
diff --git a/README b/README
index b58a1b4..8b8f4d7 100644
--- a/README
+++ b/README
@@ -330,6 +330,13 @@ tg export
TODO: Make stripping of [PATCH] and other prefixes configurable
TODO: --mbox option for other mode of operation
+tg import
+~~~~~~~~
+ Import the commits between the given revision range into
+ a topgit managed branch
+
+ Usage: tg import rev1..rev2
+
tg update
~~~~~~~~~
Update the current topic branch wrt. changes in the branches
diff --git a/tg-create.sh b/tg-create.sh
index 939af33..6cce7ed 100644
--- a/tg-create.sh
+++ b/tg-create.sh
@@ -31,17 +31,18 @@ done
deps="${deps# }"
if [ -z "$deps" ]; then
- if [ -z "$name" -a -s "$git_dir/top-name" -a -s "$git_dir/top-deps" -a -s "$git_dir/top-merge" ]; then
- # We are setting up the base branch now; resume merge!
- name="$(cat "$git_dir/top-name")"
+ head="$(git symbolic-ref HEAD)"
+ bname="${head#refs/top-bases/}"
+ if [ "$bname" != "$head" -a -s "$git_dir/top-deps" -a -s "$git_dir/top-merge" ]; then
+ # We are on a base branch now; resume merge!
deps="$(cat "$git_dir/top-deps")"
merge="$(cat "$git_dir/top-merge")"
+ name="$bname"
restarted=1
info "Resuming $name setup..."
else
# The common case
[ -z "$name" ] && die "no branch name given"
- head="$(git symbolic-ref HEAD)"
deps="${head#refs/heads/}"
[ "$deps" != "$head" ] || die "refusing to auto-depend on non-head ref ($head)"
info "Automatically marking dependency on $deps"
@@ -58,7 +59,7 @@ done
die "branch '$name' already exists"
# Clean up any stale stuff
-rm -f "$git_dir/top-name" "$git_dir/top-deps" "$git_dir/top-merge"
+rm -f "$git_dir/top-deps" "$git_dir/top-merge"
## Create base
@@ -68,8 +69,7 @@ if [ -n "$merge" ]; then
branch="${merge%% *}"
merge="${merge#* }"
info "Creating $name base from $branch..."
- # We create a detached head so that we can abort this operation
- git checkout -q "$(git rev-parse "$branch")"
+ switch_to_base "$name" "$branch"
fi
@@ -83,10 +83,9 @@ while [ -n "$merge" ]; do
if ! git merge "$branch"; then
info "Please commit merge resolution and call: tg create"
- info "It is also safe to abort this operation using:"
- info "git reset --hard some_branch"
- info "(You are on a detached HEAD now.)"
- echo "$name" >"$git_dir/top-name"
+ info "It is also safe to abort this operation using \`git reset --hard\`"
+ info "but please remember you are on the base branch now;"
+ info "you will want to switch to a different branch."
echo "$deps" >"$git_dir/top-deps"
echo "$merge" >"$git_dir/top-merge"
exit 2
@@ -96,7 +95,6 @@ done
## Set up the topic branch
-git update-ref "refs/top-bases/$name" "HEAD" ""
git checkout -b "$name"
echo "$deps" | sed 's/ /\n/g' >"$root_dir/.topdeps"
diff --git a/tg-export.sh b/tg-export.sh
index 62361dd..73ad2ef 100644
--- a/tg-export.sh
+++ b/tg-export.sh
@@ -190,7 +190,7 @@ recurse_deps driver "$name"
if [ "$driver" = "collapse" ]; then
- git update-ref "refs/heads/$output" "$(cat "$playground/$name")" ""
+ git update-ref "refs/heads/$output" "$(cat "$playground/$name")"
depcount="$(cat "$playground/^ticker" | wc -l)"
echo "Exported topic branch $name (total $depcount topics) to branch $output"
diff --git a/tg-import.sh b/tg-import.sh
new file mode 100644
index 0000000..6c991c5
--- /dev/null
+++ b/tg-import.sh
@@ -0,0 +1,68 @@
+#!/bin/sh
+# TopGit - A different patch queue manager
+# GPLv2
+
+
+tg_get_commit_msg()
+{
+ commit="$1"
+ git log -1 --pretty=format:"From: %an <%ae>%n%n%s%n%n%b" "$commit"
+}
+
+tg_get_branch_name()
+{
+ # nice sed script from git-format-patch.sh
+ commit="$1"
+ titleScript='
+ s/[^-a-z.A-Z_0-9]/-/g
+ s/\.\.\.*/\./g
+ s/\.*$//
+ s/--*/-/g
+ s/^-//
+ s/-$//
+ q
+'
+ git log -1 --pretty=format:"%s" "$commit" | sed -e "$titleScript"
+}
+
+tg_process_commit()
+{
+ commit="$1"
+ branch_name=$(tg_get_branch_name "$commit")
+ echo "Importing $commit to $branch_name"
+ tg create tp/"$branch_name"
+ git read-tree "$commit"
+ tg_get_commit_msg "$commit" > .topmsg
+ git add -f .topmsg .topdeps
+ git commit -C "$commit"
+}
+
+# nice arg verification stolen from git-format-patch.sh
+for revpair
+do
+ case "$revpair" in
+ ?*..?*)
+ rev1=`expr "z$revpair" : 'z\(.*\)\.\.'`
+ rev2=`expr "z$revpair" : 'z.*\.\.\(.*\)'`
+ ;;
+ *)
+ die "Unknow range spec $revpair"
+ ;;
+ esac
+ git rev-parse --verify "$rev1^0" >/dev/null 2>&1 ||
+ die "Not a valid rev $rev1 ($revpair)"
+ git rev-parse --verify "$rev2^0" >/dev/null 2>&1 ||
+ die "Not a valid rev $rev2 ($revpair)"
+ git cherry -v "$rev1" "$rev2" |
+ while read sign rev comment
+ do
+ case "$sign" in
+ '-')
+ info "Merged already: $comment"
+ ;;
+ *)
+ tg_process_commit "$rev"
+ ;;
+ esac
+ done
+done
--
tg: (f27e693..) tp/topgit-Implement-tg-import (depends on: master)
^ permalink raw reply related [flat|nested] 256+ messages in thread
* (unknown),
@ 2008-06-23 20:54 VIP Casino Club
0 siblings, 0 replies; 256+ messages in thread
From: VIP Casino Club @ 2008-06-23 20:54 UTC (permalink / raw)
To: git
Enjoy all the action of Las Vegas with 24 hour customer services, great
offers and promotions
and reliable payments from your armchair with ClubVIP:
***Download and install our free software
***Register your account
***Purchase chips and get playing!
See you at the tables!
http://www.webtopjackpot.net
hewruhxycu lyyj bdihiabda
mauugema bu
siaocwenrvumip bfyxuu mueglofaeu
oereqyxlebjier k koopwanusohuc
znhiqs x
tivequwexe sju jeozenov
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown)
@ 2008-06-16 20:02 amery
0 siblings, 0 replies; 256+ messages in thread
From: amery @ 2008-06-16 20:02 UTC (permalink / raw)
>From 25cb047690dd6101527cdfa6198dd6a6f93bf095 Mon Sep 17 00:00:00 2001
From: Alejandro Mery <amery@geeks.cl>
Date: Mon, 16 Jun 2008 20:27:14 +0200
Subject: [PATCH] git-am: head -1 is obsolete and doesn't work on some new systems
http://www.opengroup.org/onlinepubs/009695399/utilities/head.html
---
git-am.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index b48096e..797988f 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -421,7 +421,7 @@ do
else
action=yes
fi
- FIRSTLINE=$(head -1 "$dotest/final-commit")
+ FIRSTLINE=$(head -n1 "$dotest/final-commit")
if test $action = skip
then
--
1.5.4.3
^ permalink raw reply related [flat|nested] 256+ messages in thread
* (unknown)
@ 2008-06-16 19:42 amery
0 siblings, 0 replies; 256+ messages in thread
From: amery @ 2008-06-16 19:42 UTC (permalink / raw)
>From 25cb047690dd6101527cdfa6198dd6a6f93bf095 Mon Sep 17 00:00:00 2001
From: Alejandro Mery <amery@geeks.cl>
Date: Mon, 16 Jun 2008 20:27:14 +0200
Subject: [PATCH] git-am: head -1 is obsolete and doesn't work on some new systems
http://www.opengroup.org/onlinepubs/009695399/utilities/head.html
---
git-am.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index b48096e..797988f 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -421,7 +421,7 @@ do
else
action=yes
fi
- FIRSTLINE=$(head -1 "$dotest/final-commit")
+ FIRSTLINE=$(head -n1 "$dotest/final-commit")
if test $action = skip
then
--
1.5.4.3
^ permalink raw reply related [flat|nested] 256+ messages in thread
* (unknown),
@ 2008-05-10 22:32 Krzysztof Kowalczyk
0 siblings, 0 replies; 256+ messages in thread
From: Krzysztof Kowalczyk @ 2008-05-10 22:32 UTC (permalink / raw)
To: git
subscribe git
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2008-01-20 21:59 Marc-André Lureau
0 siblings, 0 replies; 256+ messages in thread
From: Marc-André Lureau @ 2008-01-20 21:59 UTC (permalink / raw)
To: git
subscribe git
^ permalink raw reply [flat|nested] 256+ messages in thread
* [PATCH 0/6] builtin-remote
@ 2007-12-05 19:00 Johannes Schindelin
2007-12-05 19:00 ` (unknown) Johannes Schindelin
0 siblings, 1 reply; 256+ messages in thread
From: Johannes Schindelin @ 2007-12-05 19:00 UTC (permalink / raw)
To: git, gitster
Hi,
this series introduces remote as a builtin, and fixes a long-standing bug
(if you created a remote with --mirror, prune would not do the right
thing).
I know it is pretty late in the game for 1.5.4, but then, I do not expect
this to go into that version...
Ciao,
Dscho
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown)
2007-12-05 19:00 [PATCH 0/6] builtin-remote Johannes Schindelin
@ 2007-12-05 19:00 ` Johannes Schindelin
0 siblings, 0 replies; 256+ messages in thread
From: Johannes Schindelin @ 2007-12-05 19:00 UTC (permalink / raw)
To: git, gitster
[PATCH 1/6] path-list: add functions to work with unsorted lists
Up to now, path-lists were sorted at all times. But sometimes it
is much more convenient to build the list and sort it at the end,
or sort it not at all.
Add path_list_append() and sort_path_list() to allow that.
Also, add the unsorted_path_list_has_path() function, to do a linear
search.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
I should have done this much earlier...
path-list.c | 30 ++++++++++++++++++++++++++++++
path-list.h | 8 +++++++-
2 files changed, 37 insertions(+), 1 deletions(-)
diff --git a/path-list.c b/path-list.c
index 3d83b7b..92e5cf2 100644
--- a/path-list.c
+++ b/path-list.c
@@ -102,3 +102,33 @@ void print_path_list(const char *text, const struct path_list *p)
for (i = 0; i < p->nr; i++)
printf("%s:%p\n", p->items[i].path, p->items[i].util);
}
+
+struct path_list_item *path_list_append(const char *path, struct path_list *list)
+{
+ ALLOC_GROW(list->items, list->nr + 1, list->alloc);
+ list->items[list->nr].path =
+ list->strdup_paths ? xstrdup(path) : (char *)path;
+ return list->items + list->nr++;
+}
+
+static int cmp_items(const void *a, const void *b)
+{
+ const struct path_list_item *one = a;
+ const struct path_list_item *two = b;
+ return strcmp(one->path, two->path);
+}
+
+void sort_path_list(struct path_list *list)
+{
+ qsort(list->items, list->nr, sizeof(*list->items), cmp_items);
+}
+
+int unsorted_path_list_has_path(struct path_list *list, const char *path)
+{
+ int i;
+ for (i = 0; i < list->nr; i++)
+ if (!strcmp(path, list->items[i].path))
+ return 1;
+ return 0;
+}
+
diff --git a/path-list.h b/path-list.h
index 5931e2c..ca2cbba 100644
--- a/path-list.h
+++ b/path-list.h
@@ -13,10 +13,16 @@ struct path_list
};
void print_path_list(const char *text, const struct path_list *p);
+void path_list_clear(struct path_list *list, int free_util);
+/* Use these functions only on sorted lists: */
int path_list_has_path(const struct path_list *list, const char *path);
-void path_list_clear(struct path_list *list, int free_util);
struct path_list_item *path_list_insert(const char *path, struct path_list *list);
struct path_list_item *path_list_lookup(const char *path, struct path_list *list);
+/* Use these functions only on unsorted lists: */
+struct path_list_item *path_list_append(const char *path, struct path_list *list);
+void sort_path_list(struct path_list *list);
+int unsorted_path_list_has_path(struct path_list *list, const char *path);
+
#endif /* PATH_LIST_H */
--
1.5.3.7.2157.g9598e
^ permalink raw reply related [flat|nested] 256+ messages in thread
* (unknown)
@ 2007-11-26 20:00 Michael Dressel
0 siblings, 0 replies; 256+ messages in thread
From: Michael Dressel @ 2007-11-26 20:00 UTC (permalink / raw)
To: bulb; +Cc: git
>On Mon, Nov 26, 2007 at 20:12:37 +0100, David Kastrup wrote:
>> Jan Hudec <bulb@ucw.cz> writes:
>>
>> > On Mon, Nov 26, 2007 at 18:10:10 +0100, Benoit Sigoure wrote:
>> >> On Nov 26, 2007, at 5:46 PM, Andy Parkins wrote:
>> >> While we're discussing bad names, as someone already pointed out, I
agree
>> >> it's sad that "git push" is almost always understood as being the
opposite
>> >> of "git pull".
>> >
>> > Well, it is an oposite of pull. Compared to it, it is limited in that
it will
>> > not do a merge and on the other hand extended to *also* be an oposite
of
>> > fetch, but still oposite of pull is push.
>>
>> With the same reasoning the opposite of a duck is a lobster, since a
>> lobster has not only fewer wings, but also more legs.
>
>No.
>
>The basic pull/push actions are:
>
>git pull: Bring the remote ref value here.
>git push: Put the local ref value there.
>
>Are those not oposites?
>
>Than each command has it's different features on top of this -- pull
>merges
>and push can push multiple refs -- but in the basic operation they are
>oposites.
In the case remote branches are used push and pull are not exactly
opposite. Pull uses the remote branch and push does not.
.
LOCAL REPO . REMOTE REPO
.............................................................
a_local_branch ------------ push ------------->a_local_branch
^ . |
| . |
| . |
merge . |
| . |
| . |
a_remote_branch <----------fetch ---------------------
.
Cheers,
Michael
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown)
@ 2007-11-11 13:08 Michael Dressel
0 siblings, 0 replies; 256+ messages in thread
From: Michael Dressel @ 2007-11-11 13:08 UTC (permalink / raw)
To: git
>Michael Dressel wrote:
>Ok nice. Another thing is that git-push will push all the tracking
>branches in refs/remotes/origin.
I learned that I only have to edit the .git/config file to avoid that
git-push pushes everything.
I modified the remotes names and added push lines explicitly.
Is that the recommended way?
In my example (git-branch -a -v):
* exp aa854c6 shtest 4
master 34924b9 mastertest 1
origin/exp aa854c6 shtest 4
origin/master b68e7a9 brt master 1
I used the following .git/config:
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin1"]
url = /home/repo/src
fetch = +refs/heads/master:refs/remotes/origin/master
push = +refs/heads/master:refs/heads/master
[remote "origin2"]
url = /home/repo/src
fetch = +refs/heads/exp:refs/remotes/origin/exp
push = +refs/heads/exp:refs/heads/exp
[branch "master"]
remote = origin1
merge = refs/heads/master
[branch "exp"]
remote = origin2
merge = refs/heads/exp
Cheers,
Michael
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2007-11-01 20:44 Francesco Pretto
0 siblings, 0 replies; 256+ messages in thread
From: Francesco Pretto @ 2007-11-01 20:44 UTC (permalink / raw)
To: git
subscribe git
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown)
@ 2007-11-01 14:23 Heikki Orsila
0 siblings, 0 replies; 256+ messages in thread
From: Heikki Orsila @ 2007-11-01 14:23 UTC (permalink / raw)
To: git
>From bd2d661c565062eacc80dda90f3978303308f9bb Mon Sep 17 00:00:00 2001
From: Heikki Orsila <heikki.orsila@iki.fi>
Date: Thu, 1 Nov 2007 16:21:39 +0200
Subject: [PATCH] Make git-clone obey "--" (end argument parsing)
---
Documentation/git-clone.txt | 2 +-
git-clone.sh | 5 ++++-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 253f4f0..7fdcd42 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -12,7 +12,7 @@ SYNOPSIS
'git-clone' [--template=<template_directory>]
[-l] [-s] [--no-hardlinks] [-q] [-n] [--bare]
[-o <name>] [-u <upload-pack>] [--reference <repository>]
- [--depth <depth>] <repository> [<directory>]
+ [--depth <depth>] [--] <repository> [<directory>]
DESCRIPTION
-----------
diff --git a/git-clone.sh b/git-clone.sh
index 0ea3c24..3f00693 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -14,7 +14,7 @@ die() {
}
usage() {
- die "Usage: $0 [--template=<template_directory>] [--reference <reference-repo>] [--bare] [-l [-s]] [-q] [-u <upload-pack>] [--origin <name>] [--depth <n>] [-n] <repo> [<dir>]"
+ die "Usage: $0 [--template=<template_directory>] [--reference <reference-repo>] [--bare] [-l [-s]] [-q] [-u <upload-pack>] [--origin <name>] [--depth <n>] [-n] [--] <repo> [<dir>]"
}
get_repo_base() {
@@ -160,6 +160,9 @@ while
*,--depth)
shift
depth="--depth=$1";;
+ *,--)
+ shift
+ break ;;
*,-*) usage ;;
*) break ;;
esac
--
1.5.3.4.498.g9c514-dirty
^ permalink raw reply related [flat|nested] 256+ messages in thread
* (unknown)
@ 2007-10-22 18:16 racin
0 siblings, 0 replies; 256+ messages in thread
From: racin @ 2007-10-22 18:16 UTC (permalink / raw)
To: git
Hello,
I found the following on the development version of git.el: saving
non-git-managed files in Emacs threw an error.
It is due to a simple error in the call to condition-case in a
recently added function, git-update-save-file.
I attached the patch for your convenience.
Regards,
Matthieu Lemerre
PS: Please Cc me when you ackwowledge; I'm not subscribed to the list.
As a matter of fact, I found the bug only because I didn't find git.el
for my distribution (debian) so I got directly from the development
version on the website.
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2007-10-13 4:01 Michael Witten
0 siblings, 0 replies; 256+ messages in thread
From: Michael Witten @ 2007-10-13 4:01 UTC (permalink / raw)
To: git; +Cc: Jeff King
I apologize if this is received twice.
I did add some comments, though!
On 12 Oct 2007, at 10:49:10 PM, Jeff King wrote:
> You are presumably doing a 'git-pull' on the cvsimport-ed commits. Try
> doing a git-rebase, which will filter out commits which make the same
> changes. Yes, it means throwing away your original commits, but the
> new
> ones should be morally equivalent (and are now the "official" upstream
> of the CVS repository).
Now that you mention it, I think the best approach would be to:
(1) cvsexportcommit
(2) git reset --hard LAST_CVS_IMPORT_AND_MERGE
(3) git cvsimport ..... # and merge
I think this is what you mean; it seems to me that rebasing isn't
quite that.
However, this will not preserve more complicated history such as merges
from another git repository.
Basically, I want to treat my git repository as the official
repository; the CVS
repo is just their for the old farts to get the latest stuff ;-P
Thanks!
Michael
PS
Please send me other opinions.
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown)
@ 2007-09-04 13:59 Russ Brown
0 siblings, 0 replies; 256+ messages in thread
From: Russ Brown @ 2007-09-04 13:59 UTC (permalink / raw)
To: git
subscribe git
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown)
@ 2007-08-19 22:04 Luciano Rocha
0 siblings, 0 replies; 256+ messages in thread
From: Luciano Rocha @ 2007-08-19 22:04 UTC (permalink / raw)
To: git
subscribe git
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown)
@ 2007-07-01 18:25 Sean D'Epagnier
0 siblings, 0 replies; 256+ messages in thread
From: Sean D'Epagnier @ 2007-07-01 18:25 UTC (permalink / raw)
To: git
unsubscribe git
^ permalink raw reply [flat|nested] 256+ messages in thread
* [PATCH] Interpret :/<pattern> as a regular expression
@ 2007-06-13 0:50 Johannes Schindelin
2007-06-13 4:52 ` Junio C Hamano
0 siblings, 1 reply; 256+ messages in thread
From: Johannes Schindelin @ 2007-06-13 0:50 UTC (permalink / raw)
To: git
Earlier, Git interpreted the pattern as a strict prefix, which made
the operator unsuited in many cases.
Now, the pattern is interpreted as a regular expression (which does not
change the behaviour too much, since few onelines contain special regex
characters), so that you can say
git diff :/.*^Signed-off-by:.Zack.Brown
to see the diff against the most recent reachable commit which was
signed off by Zack, whose Kernel Cousin I miss very much.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
For fun, you can see which committer signed himself off:
git show :/.*^Signed-off:
*grin*
sha1_name.c | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index d9188ed..f1ba194 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -611,6 +611,8 @@ static int get_sha1_oneline(const char *prefix, unsigned char *sha1)
{
struct commit_list *list = NULL, *backup = NULL, *l;
int retval = -1;
+ regex_t regexp;
+ regmatch_t regmatch[1];
if (prefix[0] == '!') {
if (prefix[1] != '!')
@@ -622,6 +624,8 @@ static int get_sha1_oneline(const char *prefix, unsigned char *sha1)
for_each_ref(handle_one_ref, &list);
for (l = list; l; l = l->next)
commit_list_insert(l->item, &backup);
+ if (regcomp(®exp, prefix, REG_EXTENDED))
+ return error("invalid regexp: %s", prefix);
while (list) {
char *p;
struct commit *commit;
@@ -630,7 +634,9 @@ static int get_sha1_oneline(const char *prefix, unsigned char *sha1)
parse_object(commit->object.sha1);
if (!commit->buffer || !(p = strstr(commit->buffer, "\n\n")))
continue;
- if (!prefixcmp(p + 2, prefix)) {
+ if (!regexec(®exp, p + 2, 1, regmatch, 0) &&
+ printf("match: %d\n", regmatch[0].rm_so) &&
+ regmatch[0].rm_so == 0) {
hashcpy(sha1, commit->object.sha1);
retval = 0;
break;
@@ -639,6 +645,7 @@ static int get_sha1_oneline(const char *prefix, unsigned char *sha1)
free_commit_list(list);
for (l = backup; l; l = l->next)
clear_commit_marks(l->item, ONELINE_SEEN);
+ regfree(®exp);
return retval;
}
--
1.5.2.1.2827.gba84a8-dirty
^ permalink raw reply related [flat|nested] 256+ messages in thread
* Re: [PATCH] Interpret :/<pattern> as a regular expression
2007-06-13 0:50 [PATCH] Interpret :/<pattern> as a regular expression Johannes Schindelin
@ 2007-06-13 4:52 ` Junio C Hamano
2007-06-13 11:17 ` (unknown) Johannes Schindelin
0 siblings, 1 reply; 256+ messages in thread
From: Junio C Hamano @ 2007-06-13 4:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> diff --git a/sha1_name.c b/sha1_name.c
> index d9188ed..f1ba194 100644
> --- a/sha1_name.c
> +++ b/sha1_name.c
> @@ -611,6 +611,8 @@ static int get_sha1_oneline(const char *prefix, unsigned char *sha1)
> {
> struct commit_list *list = NULL, *backup = NULL, *l;
> int retval = -1;
> + regex_t regexp;
> + regmatch_t regmatch[1];
>
> if (prefix[0] == '!') {
> if (prefix[1] != '!')
Because you are not extracting any match substring, I do not
think you would need regmatch[] there.
> @@ -622,6 +624,8 @@ static int get_sha1_oneline(const char *prefix, unsigned char *sha1)
> for_each_ref(handle_one_ref, &list);
> for (l = list; l; l = l->next)
> commit_list_insert(l->item, &backup);
> + if (regcomp(®exp, prefix, REG_EXTENDED))
> + return error("invalid regexp: %s", prefix);
> while (list) {
> char *p;
> struct commit *commit;
Why EXTENDED?
I think our code prefer traditional regexp by default, but in
places where extended behaviour is truly useful (e.g. grepping
for bulk of text) have command line option to enable extended.
Of course, extended SHA-1 notation has no chance to do "command
line option", but it somehow feels inconsistent.
Also you probably want REG_NEWLINE.
> @@ -630,7 +634,9 @@ static int get_sha1_oneline(const char *prefix, unsigned char *sha1)
> parse_object(commit->object.sha1);
> if (!commit->buffer || !(p = strstr(commit->buffer, "\n\n")))
> continue;
> - if (!prefixcmp(p + 2, prefix)) {
> + if (!regexec(®exp, p + 2, 1, regmatch, 0) &&
> + printf("match: %d\n", regmatch[0].rm_so) &&
> + regmatch[0].rm_so == 0) {
> hashcpy(sha1, commit->object.sha1);
> retval = 0;
> break;
Do we want to detect return value other than REG_NOMATCH from
regexec() when it does not return zero?
Please lose the debugging printf() before submitting.
> @@ -639,6 +645,7 @@ static int get_sha1_oneline(const char *prefix, unsigned char *sha1)
> free_commit_list(list);
> for (l = backup; l; l = l->next)
> clear_commit_marks(l->item, ONELINE_SEEN);
> + regfree(®exp);
> return retval;
> }
>
Also I think you would want to fix get_sha1_oneline() so that it
not to refuse to work without save_commit_buffer. These are to
parse user supplied strings (it would be crazy for scripts to
throw hundreds of ':/random string' to drive git -- it must come
from the end user), and the user has every right to use this
syntax, if he wants to, to specify the starting point for a
command that deliberately turns off save_commit_buffer to save
memory, because the command knows ithat t will traverse tons of
commits without needing the contents of the commit buffer.
After parse_object(), if commit->buffer is NULL, read the buffer
with read_sha1_file() yourself to look for match (and if you did
so you are also responsible for discarding it yourself).
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown)
2007-06-13 4:52 ` Junio C Hamano
@ 2007-06-13 11:17 ` Johannes Schindelin
0 siblings, 0 replies; 256+ messages in thread
From: Johannes Schindelin @ 2007-06-13 11:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
[PATCH] Interpret :/<pattern> as a regular expression
Earlier, Git interpreted the pattern as a strict prefix, which made
the operator unsuited in many cases.
Now, the pattern is interpreted as a regular expression, on the whole
message, so that you can say
git diff :/.*^Signed-off-by:.Zack.Brown
to see the diff against the most recent reachable commit which was
signed off by Zack, whose Kernel Cousin I miss very much.
If you want to match just the oneline, but with a regular expression,
say something like
git diff ':/[^
]*intelligent'
Since it makes more sense to match the beginning of a message (otherwise,
a pattern like ':/git-gui: Improve' would match the _merge_ commit,
pulling in the commit you are likely to want), the implementation uses the
regmatch parameter of regexec() to anchor the pattern there.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Anyone who can teach me how to match / not-match a newline
using a more elegant syntax, please do so, by all means.
Documentation/git-rev-parse.txt | 6 +++---
sha1_name.c | 31 +++++++++++++++++++++++++------
2 files changed, 28 insertions(+), 9 deletions(-)
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index 6380676..56e1561 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -194,9 +194,9 @@ blobs contained in a commit.
found.
* A colon, followed by a slash, followed by a text: this names
- a commit whose commit message starts with the specified text.
- This name returns the youngest matching commit which is
- reachable from any ref. If the commit message starts with a
+ a commit whose commit message starts with the specified regular
+ expression. This name returns the youngest matching commit which
+ is reachable from any ref. If the commit message starts with a
'!', you have to repeat that; the special sequence ':/!',
followed by something else than '!' is reserved for now.
diff --git a/sha1_name.c b/sha1_name.c
index d9188ed..988d599 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -599,8 +599,8 @@ static int handle_one_ref(const char *path,
/*
* This interprets names like ':/Initial revision of "git"' by searching
- * through history and returning the first commit whose message starts
- * with the given string.
+ * through history and returning the first commit whose message matches
+ * the given regular expression.
*
* For future extension, ':/!' is reserved. If you want to match a message
* beginning with a '!', you have to repeat the exclamation mark.
@@ -611,34 +611,53 @@ static int get_sha1_oneline(const char *prefix, unsigned char *sha1)
{
struct commit_list *list = NULL, *backup = NULL, *l;
int retval = -1;
+ regex_t regexp;
+ regmatch_t regmatch[1];
+ char *temp_commit_buffer = NULL;
if (prefix[0] == '!') {
if (prefix[1] != '!')
die ("Invalid search pattern: %s", prefix);
prefix++;
}
- if (!save_commit_buffer)
- return error("Could not expand oneline-name.");
for_each_ref(handle_one_ref, &list);
for (l = list; l; l = l->next)
commit_list_insert(l->item, &backup);
+ if (regcomp(®exp, prefix, 0))
+ return error("invalid regexp: %s", prefix);
while (list) {
char *p;
struct commit *commit;
+ enum object_type type;
+ unsigned long size;
commit = pop_most_recent_commit(&list, ONELINE_SEEN);
parse_object(commit->object.sha1);
- if (!commit->buffer || !(p = strstr(commit->buffer, "\n\n")))
+ if (temp_commit_buffer)
+ free(temp_commit_buffer);
+ if (commit->buffer)
+ p = commit->buffer;
+ else {
+ p = read_sha1_file(commit->object.sha1, &type, &size);
+ if (!p)
+ continue;
+ temp_commit_buffer = p;
+ }
+ if (!(p = strstr(p, "\n\n")))
continue;
- if (!prefixcmp(p + 2, prefix)) {
+ if (!regexec(®exp, p + 2, 1, regmatch, 0) &&
+ regmatch[0].rm_so == 0) {
hashcpy(sha1, commit->object.sha1);
retval = 0;
break;
}
}
+ if (temp_commit_buffer)
+ free(temp_commit_buffer);
free_commit_list(list);
for (l = backup; l; l = l->next)
clear_commit_marks(l->item, ONELINE_SEEN);
+ regfree(®exp);
return retval;
}
--
1.5.2.1.2827.gba84a8-dirty
^ permalink raw reply related [flat|nested] 256+ messages in thread
* (unknown)
@ 2007-06-03 15:30 Randal L. Schwartz
0 siblings, 0 replies; 256+ messages in thread
From: Randal L. Schwartz @ 2007-06-03 15:30 UTC (permalink / raw)
To: git
>From 8948e5c81bf39ca7a8118746e4ca60b3b1566efa Mon Sep 17 00:00:00 2001
From: Randal L. Schwartz <merlyn@stonehenge.com>
Date: Sun, 3 Jun 2007 08:27:52 -0700
Subject: [PATCH] Add test-sha1 to .gitignore.
---
.gitignore | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/.gitignore b/.gitignore
index 15aed70..8e75c99 100644
--- a/.gitignore
+++ b/.gitignore
@@ -151,6 +151,7 @@ test-delta
test-dump-cache-tree
test-genrandom
test-match-trees
+test-sha1
common-cmds.h
*.tar.gz
*.dsc
--
1.5.2.1.111.gc94b
^ permalink raw reply related [flat|nested] 256+ messages in thread
* (unknown),
@ 2007-05-06 3:51 Aaron Gray
0 siblings, 0 replies; 256+ messages in thread
From: Aaron Gray @ 2007-05-06 3:51 UTC (permalink / raw)
To: Git Mailing List
subscribe git
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown)
@ 2007-04-04 16:59 Geert Bosch
0 siblings, 0 replies; 256+ messages in thread
From: Geert Bosch @ 2007-04-04 16:59 UTC (permalink / raw)
To: git
From: Geert Bosch <bosch@gnat.com>
Date: Mon, 2 Apr 2007 11:24:46 +0200
Subject: [PATCH] find_pack_entry_one: Use interpolation search for finding objects in the pack index.
Also be careful about avoiding overflow in signed integer arithmetic.
Signed-off-by: Geert Bosch <bosch@gnat.com>
---
This patch is what I used in my experiments before proposing an
alternative file format for the index. This gives about a 2.5%
speed-up for git-rev-list --all on the Linux repository,
while not changing anything at all for small repositories.
These tests were done on a Core 2 Duo MacBook Pro with Mac OS X.
While this passes the test suite, I'm not sure it should be applied,
because it doesn't really address the issues for very large repositories
with large numbers of pack files.
-Geert
sha1_file.c | 37 ++++++++++++++++++++++++++++++++-----
1 files changed, 32 insertions(+), 5 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 9c26038..e463710 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1547,14 +1547,39 @@ off_t find_pack_entry_one(const unsigned char *sha1,
struct packed_git *p)
{
const uint32_t *level1_ofs = p->index_data;
- int hi = ntohl(level1_ofs[*sha1]);
- int lo = ((*sha1 == 0x0) ? 0 : ntohl(level1_ofs[*sha1 - 1]));
+ const unsigned char level1_key = sha1[0];
+ const unsigned int level2_key = (sha1[1] << 16) + (sha1[2] << 8)
+ + sha1[3];
+ uint32_t hi = ntohl(level1_ofs[level1_key]);
+ uint32_t lo = !level1_key ? 0 : ntohl(level1_ofs[level1_key - 1]);
+ uint32_t mi = ((hi - lo) * (level2_key >> 13) >> 11) + lo;
const unsigned char *index = p->index_data;
+ const int ents = hi - lo;
+
+ uint32_t try;
index += 4 * 256;
- do {
- int mi = (lo + hi) / 2;
+ if (ents < 0xffffff)
+ do {
+ int ofs = 24 * mi + 4;
+
+ try = ntohl(*((uint32_t *) (index + ofs))) & 0xffffff;
+
+ if (try < level2_key) {
+ lo = mi + 1;
+ mi = lo + (((level2_key - try) >> 16) * ents >> 8);
+ if (mi >= hi || mi < lo) mi = hi - 1;
+ }
+ else if (try > level2_key)
+ {
+ hi = mi;
+ mi = hi - 1 - (((try - level2_key) >> 16) * ents >> 8);
+ if (mi < lo || mi >= hi) mi = lo;
+ }
+ } while (try != level2_key && lo + (ents >> 8) < hi);
+
+ while (lo < hi) {
int cmp = hashcmp(index + 24 * mi + 4, sha1);
if (!cmp)
return ntohl(*((uint32_t *)((char *)index + (24 * mi))));
@@ -1562,7 +1587,9 @@ off_t find_pack_entry_one(const unsigned char *sha1,
hi = mi;
else
lo = mi+1;
- } while (lo < hi);
+ mi = lo + (hi - lo) / 2;
+ };
+
return 0;
}
--
1.4.5-rc0.GIT
^ permalink raw reply related [flat|nested] 256+ messages in thread
* [wishlist] git branch -d -r remotename
@ 2007-03-18 9:36 Sam Vilain
2007-03-18 11:01 ` Sam Vilain
0 siblings, 1 reply; 256+ messages in thread
From: Sam Vilain @ 2007-03-18 9:36 UTC (permalink / raw)
To: git
I'm finding myself wanting to delete all local branch heads that are
already present on a remote.
You wouldn't want it to be too eager about it, and certainly you
wouldn't want to use it against any server that isn't considered
completely "upstream" of the repository you're doing it on, otherwise if
both ends run it and then "git remote prune" the refs will go away.
I think either "git remote prune" or "git branch -d" would be a good
place for that.
Thoughts?
Sam.
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [wishlist] git branch -d -r remotename
2007-03-18 9:36 [wishlist] git branch -d -r remotename Sam Vilain
@ 2007-03-18 11:01 ` Sam Vilain
2007-03-18 11:01 ` Sam Vilain
0 siblings, 1 reply; 256+ messages in thread
From: Sam Vilain @ 2007-03-18 11:01 UTC (permalink / raw)
To: git
> I'm finding myself wanting to delete all local branch heads that are
> already present on a remote.
Something like this.
Subject: [PATCH] git-remote: implement prune -c
It would be nice to prune local refs which are irrelevant; add an
option to git-remote prune, with documentation.
Signed-off-by: Sam Vilain <sam@vilain.net>
---
Documentation/git-remote.txt | 4 ++++
git-remote.perl | 33 +++++++++++++++++++++++++++++++--
2 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index ab04b86..7381b08 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt
@@ -63,6 +63,10 @@ referenced by <name>, but are still locally available in
With `-n` option, the remote heads are not confirmed first with `git
ls-remote <name>`; cached information is used instead. Use with
caution.
++
+With `-c` option, all *local* branches that can be found via this
+remote are removed. Useful for cleaning up old style remote branches,
+or temporary branches.
'fetch'::
diff --git a/git-remote.perl b/git-remote.perl
index 20f9f54..e74bce2 100755
--- a/git-remote.perl
+++ b/git-remote.perl
@@ -210,7 +210,7 @@ sub show_mapping {
}
sub prune_remote {
- my ($name, $ls_remote) = @_;
+ my ($name, $ls_remote, $clean_local) = @_;
if (!exists $remote->{$name}) {
print STDERR "No such remote $name\n";
return;
@@ -224,6 +224,32 @@ sub prune_remote {
my @v = $git->command(qw(rev-parse --verify), "$prefix/$to_prune");
$git->command(qw(update-ref -d), "$prefix/$to_prune", $v[0]);
}
+ if ( $clean_local ) {
+ my @refs = map { (split " ")[0] }
+ $git->command(qw(for-each-ref), $prefix);
+ print "Saw ".@refs." remote refs\n";
+ my %r = map { ($_ => undef) }
+ $git->command("rev-list", @refs);
+ print "Saw ".(keys %r)." revs\n";
+ my %l = map { (split " ")[2,0] }
+ $git->command(qw(for-each-ref refs/heads));
+ print "Saw ".(keys %l)." local heads\n";
+
+ # don't delete the current branch, but there must be a
+ # better way to find it out
+ chomp(my ($checked_out) = map { /^\* (.*)/ }
+ $git->command("branch"));
+ $checked_out = "refs/heads/$checked_out"
+ if $checked_out;
+
+ while ( my ($ref, $rev) = each %l ) {
+ next if $checked_out and $ref eq $checked_out;
+ if ( exists $r{$rev} ) {
+ print "$ref is obsolete\n";
+ $git->command(qw(update-ref -d), $ref, $rev);
+ }
+ }
+ }
}
sub show_remote {
@@ -344,6 +370,9 @@ elsif ($ARGV[0] eq 'prune') {
if ($ARGV[$i] eq '-n') {
$ls_remote = 0;
}
+ elsif ($ARGV[$i] eq '-c') {
+ $clean_local = 1;
+ }
else {
last;
}
@@ -353,7 +382,7 @@ elsif ($ARGV[0] eq 'prune') {
exit(1);
}
for (; $i < @ARGV; $i++) {
- prune_remote($ARGV[$i], $ls_remote);
+ prune_remote($ARGV[$i], $ls_remote, $clean_local);
}
}
elsif ($ARGV[0] eq 'add') {
--
1.5.0.4.210.gf8a7c-dirty
^ permalink raw reply related [flat|nested] 256+ messages in thread
* Re: [wishlist] git branch -d -r remotename
2007-03-18 11:01 ` Sam Vilain
@ 2007-03-18 11:01 ` Sam Vilain
2007-03-18 19:42 ` Junio C Hamano
0 siblings, 1 reply; 256+ messages in thread
From: Sam Vilain @ 2007-03-18 11:01 UTC (permalink / raw)
To: git
One time again, this time with the call to porcelain command
`git-branch` replaced with the plumbing command `symbolic-ref HEAD`
I also changed the output to be a little less "Got here\n" style.
Subject: [PATCH] git-remote: implement prune -c
It would be nice to prune local refs which are irrelevant; add an
option to git-remote prune, with documentation.
Signed-off-by: Sam Vilain <sam@vilain.net>
---
Documentation/git-remote.txt | 4 ++++
git-remote.perl | 29 +++++++++++++++++++++++++++--
2 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index ab04b86..7381b08 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt
@@ -63,6 +63,10 @@ referenced by <name>, but are still locally available in
With `-n` option, the remote heads are not confirmed first with `git
ls-remote <name>`; cached information is used instead. Use with
caution.
++
+With `-c` option, all *local* branches that can be found via this
+remote are removed. Useful for cleaning up old style remote branches,
+or temporary branches.
'fetch'::
diff --git a/git-remote.perl b/git-remote.perl
index 20f9f54..0ed8a77 100755
--- a/git-remote.perl
+++ b/git-remote.perl
@@ -210,7 +210,7 @@ sub show_mapping {
}
sub prune_remote {
- my ($name, $ls_remote) = @_;
+ my ($name, $ls_remote, $clean_local) = @_;
if (!exists $remote->{$name}) {
print STDERR "No such remote $name\n";
return;
@@ -224,6 +224,28 @@ sub prune_remote {
my @v = $git->command(qw(rev-parse --verify), "$prefix/$to_prune");
$git->command(qw(update-ref -d), "$prefix/$to_prune", $v[0]);
}
+ if ( $clean_local ) {
+ my @refs = map { (split " ")[0] }
+ $git->command(qw(for-each-ref), $prefix);
+ print "fetching revs for ".@refs." remote refs\n";
+ my %r = map { ($_ => undef) }
+ $git->command("rev-list", @refs);
+ print "fetched ".(keys %r)." revs\n";
+ my %l = map { (split " ")[2,0] }
+ $git->command(qw(for-each-ref refs/heads));
+ print "checking ".(keys %l)." local heads\n";
+
+ # don't delete the current branch
+ my ($checked_out) = $git->command(qw(symbolic-ref HEAD));
+
+ while ( my ($ref, $rev) = each %l ) {
+ next if $checked_out and $ref eq $checked_out;
+ if ( exists $r{$rev} ) {
+ print "$ref is obsolete\n";
+ $git->command(qw(update-ref -d), $ref, $rev);
+ }
+ }
+ }
}
sub show_remote {
@@ -344,6 +366,9 @@ elsif ($ARGV[0] eq 'prune') {
if ($ARGV[$i] eq '-n') {
$ls_remote = 0;
}
+ elsif ($ARGV[$i] eq '-c') {
+ $clean_local = 1;
+ }
else {
last;
}
@@ -353,7 +378,7 @@ elsif ($ARGV[0] eq 'prune') {
exit(1);
}
for (; $i < @ARGV; $i++) {
- prune_remote($ARGV[$i], $ls_remote);
+ prune_remote($ARGV[$i], $ls_remote, $clean_local);
}
}
elsif ($ARGV[0] eq 'add') {
--
1.5.0.4.210.gf8a7c-dirty
^ permalink raw reply related [flat|nested] 256+ messages in thread
* Re: [wishlist] git branch -d -r remotename
2007-03-18 11:01 ` Sam Vilain
@ 2007-03-18 19:42 ` Junio C Hamano
2007-03-18 21:46 ` Sam Vilain
0 siblings, 1 reply; 256+ messages in thread
From: Junio C Hamano @ 2007-03-18 19:42 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
Sam Vilain <sam@vilain.net> writes:
> One time again, this time with the call to porcelain command
> `git-branch` replaced with the plumbing command `symbolic-ref HEAD`
>
> I also changed the output to be a little less "Got here\n" style.
>
> Subject: [PATCH] git-remote: implement prune -c
>
> It would be nice to prune local refs which are irrelevant; add an
> option to git-remote prune, with documentation.
I do not understand what workflow you are assuming, so your use
of the word "irrelevant" does not mean much to me. I suspect
other readers of the patch and documentation wouldn't find it
clear in what situation this option is useful.
Perhaps you are thinking about this scenario? I am only
guessing because you are not clear enough:
$ git clone
... time passes ...
$ git checkout -b next origin/next
... build, install, have fun ...
$ git checkout master
... time passes ...
$ git branch
... notice that you do not hack on your copy of 'next'
... and want to remove it
$ git remote prune -c
In any case, are you checking irrelevancy? What if your foo branch has
more changes to be sent upstream? Even when the remote has a
bit older version doesn't your code remove yours? For example,
if you did this, instead of the above, what happens?
$ git clone
... time passes ...
$ git checkout -b next origin/next
... build, install, have fun ...
... find an opportunity to improve ...
$ edit
$ git commit ;# on your 'next'.
... build, install, test ...
$ git checkout master
... time passes ...
$ git branch
... notice that you do not hack on your copy of 'next' anymore,
... and want to remove it
$ git remote prune -c
If the above is the usage scenario you are trying to help, then
wouldn't it be helpful if you could also help removing 'my-next'
in this slightly altered example?
$ git clone
... time passes ...
$ git checkout -b my-next origin/next
... build, install, have fun ...
$ git checkout master
... time passes ...
$ git branch
... notice that you do not hack on your copy of 'next'
... which is 'my-next', and want to remove it
$ git remote prune -c
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [wishlist] git branch -d -r remotename
2007-03-18 19:42 ` Junio C Hamano
@ 2007-03-18 21:46 ` Sam Vilain
2007-03-19 6:18 ` Junio C Hamano
0 siblings, 1 reply; 256+ messages in thread
From: Sam Vilain @ 2007-03-18 21:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio C Hamano wrote:
>> Subject: [PATCH] git-remote: implement prune -c
>>
>> It would be nice to prune local refs which are irrelevant; add an
>> option to git-remote prune, with documentation.
>>
>
> I do not understand what workflow you are assuming, so your use
> of the word "irrelevant" does not mean much to me. I suspect
> other readers of the patch and documentation wouldn't find it
> clear in what situation this option is useful.
>
Bad choice of words. What I mean is to delete all local refs which are
already reachable by a remote ref on the given remote.
> Perhaps you are thinking about this scenario? I am only
> guessing because you are not clear enough:
>
> $ git clone
> ... time passes ...
> $ git checkout -b next origin/next
> ... build, install, have fun ...
> $ git checkout master
> ... time passes ...
> $ git branch
> ... notice that you do not hack on your copy of 'next'
> ... and want to remove it
> $ git remote prune -c
>
Yes, that's it. Or clean up the references you already pushed because
they are no longer of interest.
> In any case, are you checking irrelevancy? What if your foo branch has
> more changes to be sent upstream? Even when the remote has a
> bit older version doesn't your code remove yours? For example,
> if you did this, instead of the above, what happens?
>
> $ git clone
> ... time passes ...
> $ git checkout -b next origin/next
> ... build, install, have fun ...
> ... find an opportunity to improve ...
> $ edit
> $ git commit ;# on your 'next'.
> ... build, install, test ...
> $ git checkout master
> ... time passes ...
> $ git branch
> ... notice that you do not hack on your copy of 'next' anymore,
> ... and want to remove it
> $ git remote prune -c
>
It doesn't do that because the head doesn't match any revision that was
given to us by `rev-list refs/remotes/foo/*`
> If the above is the usage scenario you are trying to help, then
> wouldn't it be helpful if you could also help removing 'my-next'
> in this slightly altered example?
>
> $ git clone
> ... time passes ...
> $ git checkout -b my-next origin/next
> ... build, install, have fun ...
> $ git checkout master
> ... time passes ...
> $ git branch
> ... notice that you do not hack on your copy of 'next'
> ... which is 'my-next', and want to remove it
> $ git remote prune -c
Yes, the idea was to "sweep" all branches that were just local branches
of a remote and never worked on. This is most useful right now for
people switching from Cogito or old-style remotes, who have a lot of
branches that are remote tracking branches. Using this, they can just
set up a new remote, fetch and prune -c and be left in a tidy state.
Sam.
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [wishlist] git branch -d -r remotename
2007-03-18 21:46 ` Sam Vilain
@ 2007-03-19 6:18 ` Junio C Hamano
2007-03-19 6:40 ` Junio C Hamano
0 siblings, 1 reply; 256+ messages in thread
From: Junio C Hamano @ 2007-03-19 6:18 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
Sam Vilain <sam@vilain.net> writes:
> It doesn't do that because the head doesn't match any revision that was
> given to us by `rev-list refs/remotes/foo/*`
Gaah. That goes all the way down to the root commit.
+ print "fetching revs for ".@refs." remote refs\n";
Is this meant to be final message to the end-user, or debug?
+ my %r = map { ($_ => undef) }
+ $git->command("rev-list", @refs);
This traverses all the way down to the root commit, doesn't it?
That is probably good enough for a toy repository for testing,
but is impractical in real repositories, I am afraid. See below
for the standard ways to check ancestry.
+ # don't delete the current branch
+ my ($checked_out) = $git->command(qw(symbolic-ref HEAD));
When the HEAD is detached, does the error message go directly to
the end user?
+ while ( my ($ref, $rev) = each %l ) {
+ next if $checked_out and $ref eq $checked_out;
+ if ( exists $r{$rev} ) {
+ print "$ref is obsolete\n";
+ $git->command(qw(update-ref -d), $ref, $rev);
+ }
+ }
The standard way to check if commit A is included in (i.e. is an
ancestor of) commit B, without traversing the ancestry chain of
B all the way down to the root commit, is to run:
git merge-base --all A B
and see if A appears in its output (if so, then A is an ancestor
of B, otherwise it is not). This is a pair-wise check, and for
your purpose the check would become N*M operation (Yuck).
The same check can be done in parallel with:
git show-branch --independent A B C D...
whose output would include A if the commit is not included in
any of the other commits B C D... This parallel traversal has a
limit --- you can only check 25 branches at a time.
>> If the above is the usage scenario you are trying to help, then
>> wouldn't it be helpful if you could also help removing 'my-next'
>> in this slightly altered example?
>>
>> $ git clone
>> ... time passes ...
>> $ git checkout -b my-next origin/next
>> ... build, install, have fun ...
>> $ git checkout master
>> ... time passes ...
>> $ git branch
>> ... notice that you do not hack on your copy of 'next'
>> ... which is 'my-next', and want to remove it
>> $ git remote prune -c
>
> Yes, the idea was to "sweep" all branches that were just local branches
> of a remote and never worked on. This is most useful right now for
> people switching from Cogito or old-style remotes, who have a lot of
> branches that are remote tracking branches. Using this, they can just
> set up a new remote, fetch and prune -c and be left in a tidy state.
You make it sound like this is just a one-shot conversion issue,
in which case I really doubt we would want that. But it appears
to be a useful feature in general, provided if the assumed use
case is described clearly so that new users know when to use it.
In the form that was given to me, I think the documentation
leaves the user in a "Huh?" state.
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: [wishlist] git branch -d -r remotename
2007-03-19 6:18 ` Junio C Hamano
@ 2007-03-19 6:40 ` Junio C Hamano
2007-03-19 23:37 ` (unknown) Sam Vilain
0 siblings, 1 reply; 256+ messages in thread
From: Junio C Hamano @ 2007-03-19 6:40 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
Junio C Hamano <junkio@cox.net> writes:
> The standard way to check if commit A is included in (i.e. is an
> ancestor of) commit B, without traversing the ancestry chain of
> B all the way down to the root commit, is to run:
>
> git merge-base --all A B
>
> and see if A appears in its output (if so, then A is an ancestor
> of B, otherwise it is not). This is a pair-wise check, and for
> your purpose the check would become N*M operation (Yuck).
>
> The same check can be done in parallel with:
>
> git show-branch --independent A B C D...
>
> whose output would include A if the commit is not included in
> any of the other commits B C D... This parallel traversal has a
> limit --- you can only check 25 branches at a time.
Well, I was silly. If you want to see if A is an ancestor of
any of B C D..., the standard and most efficient way to do so is
with rev-list.
git rev-list A --not B C D...
will show _nothing_ only when A is an ancestor of one (or more)
of B C D..., so you invoke it and upon getting the first line of
output you declare A cannot be removed without reading the
remainder of the output.
show-branch --independent is an overkill for your purpose as it
does not treat A any more special from others (iow, it checks if
B is contained in A C D..., C is contained in A B D... all in
parallel), and you are not interested in finding out how remote
refs are related with each other.
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown)
2007-03-19 6:40 ` Junio C Hamano
@ 2007-03-19 23:37 ` Sam Vilain
0 siblings, 0 replies; 256+ messages in thread
From: Sam Vilain @ 2007-03-19 23:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio C Hamano wrote:
> If you want to see if A is an ancestor of
> any of B C D..., the standard and most efficient way to do so is
> with rev-list.
>
> git rev-list A --not B C D...
>
> will show _nothing_ only when A is an ancestor of one (or more)
> of B C D..., so you invoke it and upon getting the first line of
> output you declare A cannot be removed without reading the
> remainder of the output.
Sure. I figured the commands I put would only use about 30MB for a
300,000 commit repository, so it wouldn't be too bad. But I didn't
think of that.
Here we go, also based upon 'next' rather than the result of my
previous patches of the day.
Subject: [PATCH] git-remote: implement prune -c
It would be nice to be able to prune local refs which just point to
some place in the remote; add an option to git-remote prune, with
documentation.
Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
---
Documentation/git-remote.txt | 5 +++++
git-remote.perl | 25 +++++++++++++++++++++++--
2 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index f96b304..6a28e6c 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt
@@ -54,6 +54,11 @@ Gives some information about the remote <name>.
Deletes all stale tracking branches under <name>.
These stale branches have already been removed from the remote repository
referenced by <name>, but are still locally available in "remotes/<name>".
++
+With `-c` option, all *local* branches that exist in the history of
+any of the mirrored heads from the remote are removed. This is useful
+for discarding temporary local branches that you did not make any
+commits to.
DISCUSSION
diff --git a/git-remote.perl b/git-remote.perl
index 670bafb..84ac534 100755
--- a/git-remote.perl
+++ b/git-remote.perl
@@ -210,7 +210,7 @@ sub show_mapping {
}
sub prune_remote {
- my ($name, $ls_remote) = @_;
+ my ($name, $ls_remote, $clean_local) = @_;
if (!exists $remote->{$name}) {
print STDERR "No such remote $name\n";
return;
@@ -224,6 +224,24 @@ sub prune_remote {
my @v = $git->command(qw(rev-parse --verify), "$prefix/$to_prune");
$git->command(qw(update-ref -d), "$prefix/$to_prune", $v[0]);
}
+ if ( $clean_local ) {
+ my @remote = map { (split " ")[0] }
+ $git->command(qw(for-each-ref), $prefix);
+ my %local = map { (split " ")[2,0] }
+ $git->command(qw(for-each-ref refs/heads));
+ my %not_remote = map { ($_ => undef) }
+ $git->command("rev-list", keys %local, "--not", @remote);
+ # don't delete the current branch
+ my ($checked_out) = $git->command(qw(symbolic-ref HEAD));
+
+ while ( my ($ref, $rev) = each %local ) {
+ next if $checked_out and $ref eq $checked_out;
+ if ( not exists $not_remote{$rev} ) {
+ print "$ref is obsolete\n";
+ $git->command(qw(update-ref -d), $ref, $rev);
+ }
+ }
+ }
}
sub show_remote {
@@ -310,6 +328,9 @@ elsif ($ARGV[0] eq 'prune') {
if ($ARGV[$i] eq '-n') {
$ls_remote = 0;
}
+ elsif ($ARGV[$i] eq '-c') {
+ $clean_local = 1;
+ }
else {
last;
}
@@ -319,7 +340,7 @@ elsif ($ARGV[0] eq 'prune') {
exit(1);
}
for (; $i < @ARGV; $i++) {
- prune_remote($ARGV[$i], $ls_remote);
+ prune_remote($ARGV[$i], $ls_remote, $clean_local);
}
}
elsif ($ARGV[0] eq 'add') {
--
1.5.0.2.214.gb318
^ permalink raw reply related [flat|nested] 256+ messages in thread
* (unknown)
@ 2006-11-21 22:24 Johannes Schindelin
0 siblings, 0 replies; 256+ messages in thread
From: Johannes Schindelin @ 2006-11-21 22:24 UTC (permalink / raw)
To: Davide Libenzi, git
[PATCH] xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
This code is only lightly tested, but I am tired and hungry.
My hopes are that when I wake up in the morning, all bugs are
fixed, git-merge-one-file is rewritten as a builtin,
git-merge-index defaults to calling xdl_merge() directly when
no program is passed with "-o", and git-merge-recursive also
avoids fork()ing RCS' merge.
A funny side effect is that you can merge with white space
corruption by setting the xpparam flags to ignore whitespace.
The file passed as mf1 wins over mf2 in that case.
Oh, and maybe I did not need to use xdl_change_compact() (and
thus could have left that static to xdiffi.c)? Davide, if you
could enlighten me, I will take the time next weekend to port this
to LibXDiff ;-)
BTW if anybody wonders why these diffstats do not look correct:
"git apply --stat" does not yet have our new scaling...
Makefile | 3
xdiff/xdiff.h | 7 +
xdiff/xdiffi.c | 3
xdiff/xdiffi.h | 1
xdiff/xmerge.c | 433 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
5 files changed, 444 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index 4c3f87f..b10d65e 100644
--- a/Makefile
+++ b/Makefile
@@ -769,7 +769,8 @@ $(DIFF_OBJS): diffcore.h
$(LIB_FILE): $(LIB_OBJS)
rm -f $@ && $(AR) rcs $@ $(LIB_OBJS)
-XDIFF_OBJS=xdiff/xdiffi.o xdiff/xprepare.o xdiff/xutils.o xdiff/xemit.o
+XDIFF_OBJS=xdiff/xdiffi.o xdiff/xprepare.o xdiff/xutils.o xdiff/xemit.o \
+ xdiff/xmerge.o
$(XDIFF_OBJS): xdiff/xinclude.h xdiff/xmacros.h xdiff/xdiff.h xdiff/xtypes.h \
xdiff/xutils.h xdiff/xprepare.h xdiff/xdiffi.h xdiff/xemit.h
diff --git a/xdiff/xdiff.h b/xdiff/xdiff.h
index c9f8178..fa409d5 100644
--- a/xdiff/xdiff.h
+++ b/xdiff/xdiff.h
@@ -49,6 +49,9 @@ extern "C" {
#define XDL_BDOP_CPY 2
#define XDL_BDOP_INSB 3
+#define XDL_MERGE_MINIMAL 0
+#define XDL_MERGE_EAGER 1
+#define XDL_MERGE_ZEALOUS 2
typedef struct s_mmfile {
char *ptr;
@@ -90,6 +93,10 @@ long xdl_mmfile_size(mmfile_t *mmf);
int xdl_diff(mmfile_t *mf1, mmfile_t *mf2, xpparam_t const *xpp,
xdemitconf_t const *xecfg, xdemitcb_t *ecb);
+int xdl_merge(mmfile_t *orig, mmfile_t *mf1, const char *name1,
+ mmfile_t *mf2, const char *name2,
+ xpparam_t const *xpp, int level, mmbuffer_t *result);
+
#ifdef __cplusplus
}
#endif /* #ifdef __cplusplus */
diff --git a/xdiff/xdiffi.c b/xdiff/xdiffi.c
index d76e76a..9aeebc4 100644
--- a/xdiff/xdiffi.c
+++ b/xdiff/xdiffi.c
@@ -45,7 +45,6 @@ static long xdl_split(unsigned long cons
long *kvdf, long *kvdb, int need_min, xdpsplit_t *spl,
xdalgoenv_t *xenv);
static xdchange_t *xdl_add_change(xdchange_t *xscr, long i1, long i2, long chg1, long chg2);
-static int xdl_change_compact(xdfile_t *xdf, xdfile_t *xdfo, long flags);
@@ -397,7 +396,7 @@ static xdchange_t *xdl_add_change(xdchan
}
-static int xdl_change_compact(xdfile_t *xdf, xdfile_t *xdfo, long flags) {
+int xdl_change_compact(xdfile_t *xdf, xdfile_t *xdfo, long flags) {
long ix, ixo, ixs, ixref, grpsiz, nrec = xdf->nrec;
char *rchg = xdf->rchg, *rchgo = xdfo->rchg;
xrecord_t **recs = xdf->recs;
diff --git a/xdiff/xdiffi.h b/xdiff/xdiffi.h
index d3b7271..472aeae 100644
--- a/xdiff/xdiffi.h
+++ b/xdiff/xdiffi.h
@@ -50,6 +50,7 @@ int xdl_recs_cmp(diffdata_t *dd1, long o
long *kvdf, long *kvdb, int need_min, xdalgoenv_t *xenv);
int xdl_do_diff(mmfile_t *mf1, mmfile_t *mf2, xpparam_t const *xpp,
xdfenv_t *xe);
+int xdl_change_compact(xdfile_t *xdf, xdfile_t *xdfo, long flags);
int xdl_build_script(xdfenv_t *xe, xdchange_t **xscr);
void xdl_free_script(xdchange_t *xscr);
int xdl_emit_diff(xdfenv_t *xe, xdchange_t *xscr, xdemitcb_t *ecb,
diff --git a/xdiff/xmerge.c b/xdiff/xmerge.c
new file mode 100644
index 0000000..7b85aa5
--- /dev/null
+++ b/xdiff/xmerge.c
@@ -0,0 +1,433 @@
+/*
+ * LibXDiff by Davide Libenzi ( File Differential Library )
+ * Copyright (C) 2003-2006 Davide Libenzi, Johannes E. Schindelin
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * Davide Libenzi <davidel@xmailserver.org>
+ *
+ */
+
+#include "xinclude.h"
+
+typedef struct s_xdmerge {
+ struct s_xdmerge *next;
+ /*
+ * 0 = conflict,
+ * 1 = no conflict, take first,
+ * 2 = no conflict, take second.
+ */
+ int mode;
+ long i1, i2;
+ long chg1, chg2;
+} xdmerge_t;
+
+static int xdl_append_merge(xdmerge_t **merge, int mode,
+ long i1, long chg1, long i2, long chg2)
+{
+ xdmerge_t *m = *merge;
+ if (m && mode == m->mode &&
+ (i1 == m->i1 + m->chg1 || i2 == m->i2 + m->chg2)) {
+ m->chg1 = i1 + chg1 - m->i1;
+ m->chg2 = i2 + chg2 - m->i2;
+ } else {
+ m = xdl_malloc(sizeof(xdmerge_t));
+ if (!m)
+ return -1;
+ m->next = NULL;
+ m->mode = mode;
+ m->i1 = i1;
+ m->chg1 = chg1;
+ m->i2 = i2;
+ m->chg2 = chg2;
+ if (*merge)
+ (*merge)->next = m;
+ *merge = m;
+ }
+ return 0;
+}
+
+static int xdl_cleanup_merge(xdmerge_t *c)
+{
+ int count = 0;
+ xdmerge_t *next_c;
+
+ /* were there conflicts? */
+ for (; c; c = next_c) {
+ if (c->mode == 0)
+ count++;
+ next_c = c->next;
+ free(c);
+ }
+ return count;
+}
+
+static int xdl_merge_cmp_lines(xdfenv_t *xe1, int i1, xdfenv_t *xe2, int i2,
+ int line_count, long flags)
+{
+ int i;
+ xrecord_t **rec1 = xe1->xdf2.recs + i1;
+ xrecord_t **rec2 = xe2->xdf2.recs + i2;
+
+ for (i = 0; i < line_count; i++) {
+ int result = xdl_recmatch(rec1[i]->ptr, rec1[i]->size,
+ rec2[i]->ptr, rec2[i]->size, flags);
+ if (!result)
+ return -1;
+ }
+ return 0;
+}
+
+static int xdl_recs_copy(xdfenv_t *xe, int i, int count, int add_nl, char *dest)
+{
+ xrecord_t **recs = xe->xdf2.recs + i;
+ int size = 0;
+
+ if (count < 1)
+ return 0;
+
+ for (i = 0; i < count; size += recs[i++]->size)
+ if (dest)
+ memcpy(dest + size, recs[i]->ptr, recs[i]->size);
+ if (add_nl) {
+ i = recs[count - 1]->size;
+ if (i == 0 || recs[count - 1]->ptr[i - 1] != '\n') {
+ if (dest)
+ dest[size] = '\n';
+ size++;
+ }
+ }
+ return size;
+}
+
+static int xdl_fill_merge_buffer(xdfenv_t *xe1, const char *name1,
+ xdfenv_t *xe2, const char *name2, xdmerge_t *m, char *dest)
+{
+ const int marker_size = 7;
+ int marker1_size = (name1 ? strlen(name1) + 1 : 0);
+ int marker2_size = (name2 ? strlen(name2) + 1 : 0);
+ int conflict_marker_size = 3 * (marker_size + 1)
+ + marker1_size + marker2_size;
+ int size, i1, j;
+
+ for (size = i1 = 0; m; m = m->next) {
+ if (m->mode == 0) {
+ size += xdl_recs_copy(xe1, i1, m->i1 - i1, 0,
+ dest ? dest + size : NULL);
+ if (dest) {
+ for (j = 0; j < marker_size; j++)
+ dest[size++] = '<';
+ if (marker1_size) {
+ dest[size] = ' ';
+ memcpy(dest + size + 1, name1,
+ marker1_size - 1);
+ size += marker1_size;
+ }
+ dest[size++] = '\n';
+ } else
+ size += conflict_marker_size;
+ size += xdl_recs_copy(xe1, m->i1, m->chg1, 1,
+ dest ? dest + size : NULL);
+ if (dest) {
+ for (j = 0; j < marker_size; j++)
+ dest[size++] = '=';
+ dest[size++] = '\n';
+ }
+ size += xdl_recs_copy(xe2, m->i2, m->chg2, 1,
+ dest ? dest + size : NULL);
+ if (dest) {
+ for (j = 0; j < marker_size; j++)
+ dest[size++] = '>';
+ if (marker2_size) {
+ dest[size] = ' ';
+ memcpy(dest + size + 1, name2,
+ marker2_size - 1);
+ size += marker2_size;
+ }
+ dest[size++] = '\n';
+ }
+ } else if (m->mode == 1)
+ size += xdl_recs_copy(xe1, i1, m->i1 + m->chg1 - i1, 0,
+ dest ? dest + size : NULL);
+ else if (m->mode == 2)
+ size += xdl_recs_copy(xe2, m->i2 - m->i1 + i1,
+ m->i1 + m->chg2 - i1, 0,
+ dest ? dest + size : NULL);
+ i1 = m->i1 + m->chg1;
+ }
+ size += xdl_recs_copy(xe1, i1, xe1->xdf2.nrec - i1, 0,
+ dest ? dest + size : NULL);
+ return size;
+}
+
+/*
+ * Sometimes, changes are not quite identical, but differ in only a few
+ * lines. Try hard to show only these few lines as conflicting.
+ */
+static int xdl_refine_conflicts(xdfenv_t *xe1, xdfenv_t *xe2, xdmerge_t *m,
+ xpparam_t const *xpp)
+{
+ for (; m; m = m->next) {
+ mmfile_t t1, t2;
+ xdfenv_t xe;
+ xdchange_t *xscr, *x;
+ int i1 = m->i1, i2 = m->i2;
+
+ /* let's handle just the conflicts */
+ if (m->mode)
+ continue;
+
+ /*
+ * This probably does not work outside git, since
+ * we have a very simple mmfile structure.
+ */
+ t1.ptr = (char *)xe1->xdf2.recs[m->i1]->ptr;
+ t1.size = xe1->xdf2.recs[m->i1 + m->chg1]->ptr
+ + xe1->xdf2.recs[m->i1 + m->chg1]->size - t1.ptr;
+ t2.ptr = (char *)xe2->xdf2.recs[m->i1]->ptr;
+ t2.size = xe2->xdf2.recs[m->i1 + m->chg1]->ptr
+ + xe2->xdf2.recs[m->i1 + m->chg1]->size - t2.ptr;
+ if (xdl_do_diff(&t1, &t2, xpp, &xe) < 0)
+ return -1;
+ if (xdl_change_compact(&xe.xdf1, &xe.xdf2, xpp->flags) < 0 ||
+ xdl_change_compact(&xe.xdf2, &xe.xdf1, xpp->flags) < 0 ||
+ xdl_build_script(&xe, &xscr) < 0) {
+ xdl_free_env(&xe);
+ return -1;
+ }
+ if (!xscr) {
+ /* If this happens, it's a bug. */
+ xdl_free_env(&xe);
+ return -2;
+ }
+ x = xscr;
+ m->i1 = xscr->i1 + i1;
+ m->chg1 = xscr->chg1;
+ m->i2 = xscr->i2 + i2;
+ m->chg2 = xscr->chg2;
+ while (xscr->next) {
+ xdmerge_t *m2 = xdl_malloc(sizeof(xdmerge_t));
+ if (!m2) {
+ xdl_free_env(&xe);
+ xdl_free_script(x);
+ return -1;
+ }
+ xscr = xscr->next;
+ m2->next = m->next;
+ m->next = m2;
+ m = m2;
+ m->mode = 0;
+ m->i1 = xscr->i1 + i1;
+ m->chg1 = xscr->chg1;
+ m->i2 = xscr->i2 + i2;
+ m->chg2 = xscr->chg2;
+ }
+ xdl_free_env(&xe);
+ xdl_free_script(x);
+ }
+ return 0;
+}
+
+/*
+ * level == 0: mark all overlapping changes as conflict
+ * level == 1: mark overlapping changes as conflict only if not identical
+ * level == 2: analyze non-identical changes for minimal conflict set
+ *
+ * returns < 0 on error, == 0 for no conflicts, else number of conflicts
+ */
+static int xdl_do_merge(xdfenv_t *xe1, xdchange_t *xscr1, const char *name1,
+ xdfenv_t *xe2, xdchange_t *xscr2, const char *name2,
+ int level, xpparam_t const *xpp, mmbuffer_t *result) {
+ xdmerge_t *changes, *c;
+ int i1, i2, chg1, chg2;
+
+ c = changes = NULL;
+
+ while (xscr1 && xscr2) {
+ if (!changes)
+ changes = c;
+ if (xscr1->i1 + xscr1->chg1 < xscr2->i1) {
+ i1 = xscr1->i2;
+ i2 = xscr2->i2 - xscr2->i1 + xscr1->i1;
+ chg1 = xscr1->chg2;
+ chg2 = xscr1->chg1;
+ if (xdl_append_merge(&c, 1, i1, chg1, i2, chg2)) {
+ xdl_cleanup_merge(changes);
+ return -1;
+ }
+ xscr1 = xscr1->next;
+ continue;
+ }
+ if (xscr2->i1 + xscr2->chg1 < xscr1->i1) {
+ i1 = xscr1->i2 - xscr1->i1 + xscr2->i1;
+ i2 = xscr2->i2;
+ chg1 = xscr2->chg1;
+ chg2 = xscr2->chg2;
+ if (xdl_append_merge(&c, 2, i1, chg1, i2, chg2)) {
+ xdl_cleanup_merge(changes);
+ return -1;
+ }
+ xscr2 = xscr2->next;
+ continue;
+ }
+ if (level < 1 || xscr1->i1 != xscr2->i1 ||
+ xscr1->chg1 != xscr2->chg1 ||
+ xscr1->chg2 != xscr2->chg2 ||
+ xdl_merge_cmp_lines(xe1, xscr1->i2,
+ xe2, xscr2->i2,
+ xscr1->chg2, xpp->flags)) {
+ /* conflict */
+ int off = xscr1->i1 - xscr2->i1;
+ int ffo = off + xscr1->chg1 - xscr2->chg1;
+
+ i1 = xscr1->i2;
+ i2 = xscr2->i2;
+ if (off > 0)
+ i1 -= off;
+ else
+ i2 += off;
+ chg1 = xscr1->i2 + xscr1->chg2 - i1;
+ chg2 = xscr2->i2 + xscr2->chg2 - i2;
+ if (ffo > 0)
+ chg2 += ffo;
+ else
+ chg1 -= ffo;
+ if (xdl_append_merge(&c, 0, i1, chg1, i2, chg2)) {
+ xdl_cleanup_merge(changes);
+ return -1;
+ }
+ }
+
+ i1 = xscr1->i1 + xscr1->chg1;
+ i2 = xscr2->i1 + xscr2->chg1;
+
+ if (i1 > i2) {
+ xscr1->chg1 -= i1 - i2;
+ xscr1->i1 = i2;
+ xscr1->i2 += xscr1->chg2;
+ xscr1->chg2 = 0;
+ xscr1 = xscr1->next;
+ } else if (i2 > i1) {
+ xscr2->chg1 -= i2 - i1;
+ xscr2->i1 = i1;
+ xscr2->i2 += xscr2->chg2;
+ xscr2->chg2 = 0;
+ xscr2 = xscr2->next;
+ } else {
+ xscr1 = xscr1->next;
+ xscr2 = xscr2->next;
+ }
+ }
+ while (xscr1) {
+ if (!changes)
+ changes = c;
+ i1 = xscr1->i2;
+ i2 = xscr1->i1 + xe2->xdf2.nrec - xe2->xdf1.nrec;
+ chg1 = xscr1->chg2;
+ chg2 = xscr1->chg1;
+ if (xdl_append_merge(&c, 1, i1, chg1, i2, chg2)) {
+ xdl_cleanup_merge(changes);
+ return -1;
+ }
+ xscr1 = xscr1->next;
+ }
+ while (xscr2) {
+ if (!changes)
+ changes = c;
+ i1 = xscr2->i1 + xe1->xdf2.nrec - xe1->xdf1.nrec;
+ i2 = xscr2->i2;
+ chg1 = xscr2->chg1;
+ chg2 = xscr2->chg2;
+ if (xdl_append_merge(&c, 2, i1, chg1, i2, chg2)) {
+ xdl_cleanup_merge(changes);
+ return -1;
+ }
+ xscr2 = xscr2->next;
+ }
+ if (!changes)
+ changes = c;
+ /* refine conflicts */
+ if (level > 1 && xdl_refine_conflicts(xe1, xe2, changes, xpp) < 0) {
+ xdl_cleanup_merge(changes);
+ return -1;
+ }
+ /* output */
+ if (result) {
+ int size = xdl_fill_merge_buffer(xe1, name1, xe2, name2,
+ changes, NULL);
+ result->ptr = xdl_malloc(size);
+ if (!result->ptr) {
+ xdl_cleanup_merge(changes);
+ return -1;
+ }
+ result->size = size;
+ xdl_fill_merge_buffer(xe1, name1, xe2, name2, changes,
+ result->ptr);
+ }
+ return xdl_cleanup_merge(changes);
+}
+
+int xdl_merge(mmfile_t *orig, mmfile_t *mf1, const char *name1,
+ mmfile_t *mf2, const char *name2,
+ xpparam_t const *xpp, int level, mmbuffer_t *result) {
+ xdchange_t *xscr1, *xscr2;
+ xdfenv_t xe1, xe2;
+
+ result->ptr = NULL;
+ result->size = 0;
+
+ if (xdl_do_diff(orig, mf1, xpp, &xe1) < 0 ||
+ xdl_do_diff(orig, mf2, xpp, &xe2) < 0) {
+ return -1;
+ }
+ if (xdl_change_compact(&xe1.xdf1, &xe1.xdf2, xpp->flags) < 0 ||
+ xdl_change_compact(&xe1.xdf2, &xe1.xdf1, xpp->flags) < 0 ||
+ xdl_build_script(&xe1, &xscr1) < 0) {
+ xdl_free_env(&xe1);
+ return -1;
+ }
+ if (xdl_change_compact(&xe2.xdf1, &xe2.xdf2, xpp->flags) < 0 ||
+ xdl_change_compact(&xe2.xdf2, &xe2.xdf1, xpp->flags) < 0 ||
+ xdl_build_script(&xe2, &xscr2) < 0) {
+ xdl_free_env(&xe2);
+ return -1;
+ }
+ if (xscr1 || xscr2) {
+ if (!xscr1) {
+ result->ptr = xdl_malloc(mf2->size);
+ memcpy(result->ptr, mf2->ptr, mf2->size);
+ result->size = mf2->size;
+ } else if (!xscr2) {
+ result->ptr = xdl_malloc(mf1->size);
+ memcpy(result->ptr, mf1->ptr, mf1->size);
+ result->size = mf1->size;
+ } else if (xdl_do_merge(&xe1, xscr1, name1,
+ &xe2, xscr2, name2,
+ level, xpp, result) < 0) {
+ xdl_free_script(xscr1);
+ xdl_free_script(xscr2);
+ xdl_free_env(&xe1);
+ xdl_free_env(&xe2);
+ return -1;
+ }
+ xdl_free_script(xscr1);
+ xdl_free_script(xscr2);
+ }
+ xdl_free_env(&xe1);
+ xdl_free_env(&xe2);
+
+ return 0;
+}
^ permalink raw reply related [flat|nested] 256+ messages in thread
* (unknown)
@ 2006-10-25 14:50 andyparkins
0 siblings, 0 replies; 256+ messages in thread
From: andyparkins @ 2006-10-25 14:50 UTC (permalink / raw)
From f52af4e576cb1ad688c72f6cc1443443b7d12b69 Mon Sep 17 00:00:00 2001
From: Andy Parkins <andyparkins@gmail.com>
Date: Wed, 25 Oct 2006 15:50:03 +0100
Subject: [PATCH] git-clone documentation didn't mention --origin as equivalent of -o
To: git@vger.kernel.org
X-Length: 979
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200610251550.04024.andyparkins@gmail.com>
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
Documentation/git-clone.txt | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
X-TUID: 4aebd5773bc8eef9
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index f973c64..e22a036 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -75,6 +75,7 @@ OPTIONS
this option is used, neither the `origin` branch nor the
default `remotes/origin` file is created.
+--origin::
-o <name>::
Instead of using the branch name 'origin' to keep track
of the upstream repository, use <name> instead. Note
--
1.4.2.3
^ permalink raw reply related [flat|nested] 256+ messages in thread
* (unknown)
@ 2006-10-25 14:49 andyparkins
2006-10-25 18:41 ` (unknown) Junio C Hamano
0 siblings, 1 reply; 256+ messages in thread
From: andyparkins @ 2006-10-25 14:49 UTC (permalink / raw)
From b149c0fca7399030225750958bf5c962c3796b44 Mon Sep 17 00:00:00 2001
From: Andy Parkins <andyparkins@gmail.com>
Date: Wed, 25 Oct 2006 15:49:50 +0100
Subject: [PATCH] Make new builtin cherry match documentation for "+" and "-"
To: git@vger.kernel.org
X-TUID: 218b478df3f8d847
X-UID: 128
X-Length: 1090
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200610251549.51121.andyparkins@gmail.com>
"+" and "-" don't match the documentation, where "+" means the patch /is/ in
upstream, "-" means it isn't
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
builtin-log.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index 840c742..8ded627 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -519,12 +519,12 @@ int cmd_cherry(int argc, const char **ar
while (list) {
unsigned char sha1[20];
- char sign = '+';
+ char sign = '-';
commit = list->item;
if (!get_patch_id(commit, &patch_id_opts, sha1) &&
lookup_object(sha1))
- sign = '-';
+ sign = '+';
if (verbose) {
static char buf[16384];
--
1.4.2.3
^ permalink raw reply related [flat|nested] 256+ messages in thread
* Re: (unknown)
2006-10-25 14:49 (unknown) andyparkins
@ 2006-10-25 18:41 ` Junio C Hamano
0 siblings, 0 replies; 256+ messages in thread
From: Junio C Hamano @ 2006-10-25 18:41 UTC (permalink / raw)
To: andyparkins; +Cc: git
andyparkins@gmail.com writes:
> From b149c0fca7399030225750958bf5c962c3796b44 Mon Sep 17 00:00:00 2001
> From: Andy Parkins <andyparkins@gmail.com>
> Date: Wed, 25 Oct 2006 15:49:50 +0100
> Subject: [PATCH] Make new builtin cherry match documentation for "+" and "-"
> To: git@vger.kernel.org
> X-TUID: 218b478df3f8d847
> X-UID: 128
> X-Length: 1090
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> Message-Id: <200610251549.51121.andyparkins@gmail.com>
I'd be commenting on your patch but won't be able to take any of
them until these "Subject: (unknown)" are corrected.
> "+" and "-" don't match the documentation, where "+" means the patch /is/ in
> upstream, "-" means it isn't
The documentation was utterly wrong. The comment at the
beginning of git-cherry.sh was better but slightly wrong.
I have a few fixes queued but I was busy for the last couple of
nights and haven't pushed them out.
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown)
@ 2006-10-25 14:49 andyparkins
0 siblings, 0 replies; 256+ messages in thread
From: andyparkins @ 2006-10-25 14:49 UTC (permalink / raw)
From cf13955d13b8b6a86dd1f6340565e16500b3cf38 Mon Sep 17 00:00:00 2001
From: Andy Parkins <andyparkins@gmail.com>
Date: Wed, 25 Oct 2006 15:49:34 +0100
Subject: [PATCH] Minor grammar fixes for git-diff-index.txt
To: git@vger.kernel.org
X-TUID: c63a7eaedc72a5ce
X-UID: 129
X-Length: 2247
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200610251549.34193.andyparkins@gmail.com>
"what you are going to commit is" doesn't need the "is" and does need a comma.
"can trivially see" is an unecessary split infinitive and "easily" is a more
appropriate adverb.
"case where you" should be "case were you" as it's the past tense form of the
verb "to be", rather than a location (I think :-) ).
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
Documentation/git-diff-index.txt | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-diff-index.txt
b/Documentation/git-diff-index.txt
index 9cd43f1..ad1e903 100644
--- a/Documentation/git-diff-index.txt
+++ b/Documentation/git-diff-index.txt
@@ -54,7 +54,7 @@ If '--cached' is specified, it allows yo
For example, let's say that you have worked on your working directory,
updated
some files in the index and are ready to commit. You want to see exactly
-*what* you are going to commit is without having to write a new tree
+*what* you are going to commit, without having to write a new tree
object and compare it that way, and to do that, you just do
git-diff-index --cached HEAD
@@ -68,11 +68,11 @@ matches my working directory. But doing
-100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74 commit.c
+100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74
git-commit.c
-You can trivially see that the above is a rename.
+You can see easily that the above is a rename.
In fact, "git-diff-index --cached" *should* always be entirely equivalent to
actually doing a "git-write-tree" and comparing that. Except this one is much
-nicer for the case where you just want to check where you are.
+nicer for the case were you just want to check where you are.
So doing a "git-diff-index --cached" is basically very useful when you are
asking yourself "what have I already marked for being committed, and
--
1.4.2.3
^ permalink raw reply related [flat|nested] 256+ messages in thread
* (unknown)
@ 2006-10-25 14:47 andyparkins
2006-10-25 14:53 ` (unknown) Jakub Narebski
0 siblings, 1 reply; 256+ messages in thread
From: andyparkins @ 2006-10-25 14:47 UTC (permalink / raw)
From cd4366ed4e3f765c00310c35c0eabeccf433acdb Mon Sep 17 00:00:00 2001
From: Andy Parkins <andyparkins@gmail.com>
Date: Wed, 25 Oct 2006 15:47:19 +0100
Subject: [PATCH] Use "up/" prefix for all the upstream branches
To: git@vger.kernel.org
X-TUID: aba1ff8a0c61615e
X-UID: 126
X-Length: 1359
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200610251547.19208.andyparkins@gmail.com>
To easily differentiate the read-only upstream branches, from normal branches,
default to cloning them with the prefix "up/" added to their branch names.
This also abandons the idea of an "origin" branch which is now simply
"up/master" and hence removes the special treatment that master was getting.
(cherry picked from 33d89375652222c41fbf225f1e1c3bfb38b755b2 commit)
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
I'm sure this will be an unwanted patch. However, I really do think it's
important to highlight these upstream branches in some way. I realise
renaming "origin" is probably not going to fly, but perhaps it would be okay
to have at least the non-origin branches prefixed?
git-clone.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-clone.sh b/git-clone.sh
index 3f006d1..ebd93da 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -185,7 +185,7 @@ fi
if test -z "$origin"
then
- origin=origin
+ origin=up/master
fi
# Turn the source into an absolute path if
@@ -389,7 +389,7 @@ Pull: refs/heads/$head_points_at:$origin
then
continue
fi
- echo "Pull: refs/heads/${name}:$remote_top/${name}"
+ echo "Pull: refs/heads/${name}:$remote_top/up/${name}"
done >>"$GIT_DIR/remotes/$origin" &&
case "$use_separate_remote" in
t)
--
1.4.2.3
^ permalink raw reply related [flat|nested] 256+ messages in thread
* Re: (unknown)
2006-10-25 14:47 (unknown) andyparkins
@ 2006-10-25 14:53 ` Jakub Narebski
2006-10-25 15:10 ` (unknown) Andy Parkins
0 siblings, 1 reply; 256+ messages in thread
From: Jakub Narebski @ 2006-10-25 14:53 UTC (permalink / raw)
To: git
andyparkins@gmail.com wrote:
> To easily differentiate the read-only upstream branches, from normal branches,
> default to cloning them with the prefix "up/" added to their branch names.
> This also abandons the idea of an "origin" branch which is now simply
> "up/master" and hence removes the special treatment that master was getting.
> (cherry picked from 33d89375652222c41fbf225f1e1c3bfb38b755b2 commit)
> Signed-off-by: Andy Parkins <andyparkins@gmail.com>
> ---
> I'm sure this will be an unwanted patch. However, I really do think it's
> important to highlight these upstream branches in some way. I realise
> renaming "origin" is probably not going to fly, but perhaps it would be okay
> to have at least the non-origin branches prefixed?
Check if "git clone --use-separate-remote" isn't what you want.
And please correct mail sending.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: (unknown)
2006-10-25 14:53 ` (unknown) Jakub Narebski
@ 2006-10-25 15:10 ` Andy Parkins
2006-10-25 15:31 ` (unknown) Karl Hasselström
2006-10-25 18:38 ` (unknown) Junio C Hamano
0 siblings, 2 replies; 256+ messages in thread
From: Andy Parkins @ 2006-10-25 15:10 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 765 bytes --]
On Wednesday 2006 October 25 15:53, Jakub Narebski wrote:
> Check if "git clone --use-separate-remote" isn't what you want.
I did try that, but then the branches don't appear in git branch. I still
like that they exist.
> And please correct mail sending.
AHHHH!!! I thought I had. Dagnamit; I think an upgrade in Debian overwrote my
manual git-imap-send compile. The git-imap-send bug was fixed in
e0b0830726286287744cc9e1a629a534bbe75452, but doesn't seem to have made it
into debian yet.
I'm getting so sick of looking like an idiot.
My apologies to everyone for the constant noise I keep dumping on the list. I
promise I'm trying really hard to be good.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
andyparkins@gmail.com
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: (unknown)
2006-10-25 15:10 ` (unknown) Andy Parkins
@ 2006-10-25 15:31 ` Karl Hasselström
2006-10-25 18:38 ` (unknown) Junio C Hamano
1 sibling, 0 replies; 256+ messages in thread
From: Karl Hasselström @ 2006-10-25 15:31 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
On 2006-10-25 16:10:02 +0100, Andy Parkins wrote:
> My apologies to everyone for the constant noise I keep dumping on
> the list. I promise I'm trying really hard to be good.
I always try sending the patch to myself first, since something almost
always goes wrong on the first try. This helps against most problems,
but certainly not all. :-)
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: (unknown)
2006-10-25 15:10 ` (unknown) Andy Parkins
2006-10-25 15:31 ` (unknown) Karl Hasselström
@ 2006-10-25 18:38 ` Junio C Hamano
2006-10-25 22:03 ` (unknown) Andy Parkins
1 sibling, 1 reply; 256+ messages in thread
From: Junio C Hamano @ 2006-10-25 18:38 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
Andy Parkins <andyparkins@gmail.com> writes:
> On Wednesday 2006 October 25 15:53, Jakub Narebski wrote:
>
>> Check if "git clone --use-separate-remote" isn't what you want.
>
> I did try that, but then the branches don't appear in git branch. I still
> like that they exist.
"git branch -r" perhaps.
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: (unknown)
2006-10-25 18:38 ` (unknown) Junio C Hamano
@ 2006-10-25 22:03 ` Andy Parkins
2006-10-25 22:16 ` (unknown) Junio C Hamano
2006-10-25 22:16 ` (unknown) Shawn Pearce
0 siblings, 2 replies; 256+ messages in thread
From: Andy Parkins @ 2006-10-25 22:03 UTC (permalink / raw)
To: git
On Wednesday 2006, October 25 19:38, Junio C Hamano wrote:
> > I did try that, but then the branches don't appear in git branch. I
> > still like that they exist.
>
> "git branch -r" perhaps.
That's pretty good. It makes things like
git-log remotes/origin/master..master
A bit long winded, but it's certainly what I asked for.
You guys really have thought of everything.
Andy
--
Dr Andrew Parkins, M Eng (Hons), AMIEE
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: (unknown)
2006-10-25 22:03 ` (unknown) Andy Parkins
@ 2006-10-25 22:16 ` Junio C Hamano
2006-10-25 22:20 ` (unknown) Junio C Hamano
2006-10-25 22:16 ` (unknown) Shawn Pearce
1 sibling, 1 reply; 256+ messages in thread
From: Junio C Hamano @ 2006-10-25 22:16 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
Andy Parkins <andyparkins@gmail.com> writes:
> On Wednesday 2006, October 25 19:38, Junio C Hamano wrote:
>
>> > I did try that, but then the branches don't appear in git branch. I
>> > still like that they exist.
>>
>> "git branch -r" perhaps.
>
> That's pretty good. It makes things like
>
> git-log remotes/origin/master..master
>
> A bit long winded, but it's certainly what I asked for.
"git log remotes/origin..master" perhaps?
The point being, remotes/origin when origin is a directory that
has HEAD that points at something, it stands for
remotes/origin/HEAD.
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: (unknown)
2006-10-25 22:16 ` (unknown) Junio C Hamano
@ 2006-10-25 22:20 ` Junio C Hamano
2006-10-26 7:14 ` (unknown) Andy Parkins
2006-10-26 13:22 ` (unknown) Josef Weidendorfer
0 siblings, 2 replies; 256+ messages in thread
From: Junio C Hamano @ 2006-10-25 22:20 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
Junio C Hamano <junkio@cox.net> writes:
> Andy Parkins <andyparkins@gmail.com> writes:
>
>> On Wednesday 2006, October 25 19:38, Junio C Hamano wrote:
>>
>>> > I did try that, but then the branches don't appear in git branch. I
>>> > still like that they exist.
>>>
>>> "git branch -r" perhaps.
>>
>> That's pretty good. It makes things like
>>
>> git-log remotes/origin/master..master
>>
>> A bit long winded, but it's certainly what I asked for.
>
> "git log remotes/origin..master" perhaps?
>
> The point being, remotes/origin when origin is a directory that
> has HEAD that points at something, it stands for
> remotes/origin/HEAD.
Heh, I spoke too fast.
"git log origin..master"
If you do not have none of .git/origin, .git/refs/origin,
.git/refs/tags/origin, .git/refs/heads/origin, nor
.git/refs/remotes/origin, then .git/refs/remotes/origin/HEAD is
what "origin" means (see get_sha1_basic() in sha1_name.c).
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: (unknown)
2006-10-25 22:20 ` (unknown) Junio C Hamano
@ 2006-10-26 7:14 ` Andy Parkins
2006-10-26 13:22 ` (unknown) Josef Weidendorfer
1 sibling, 0 replies; 256+ messages in thread
From: Andy Parkins @ 2006-10-26 7:14 UTC (permalink / raw)
To: git
> > "git log remotes/origin..master" perhaps?
> >
> > The point being, remotes/origin when origin is a directory that
> > has HEAD that points at something, it stands for
> > remotes/origin/HEAD.
>
> Heh, I spoke too fast.
>
> "git log origin..master"
>
> If you do not have none of .git/origin, .git/refs/origin,
> .git/refs/tags/origin, .git/refs/heads/origin, nor
> .git/refs/remotes/origin, then .git/refs/remotes/origin/HEAD is
> what "origin" means (see get_sha1_basic() in sha1_name.c).
Again: you guys have thought of everything.
I believe then, that my problem is that I didn't find this written anywhere -
would it be useful if I were to write a Documentation/ file about
commit-ish/tree-ish that covered these issues? Have I overlooked the
existence of such a file already?
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: (unknown)
2006-10-25 22:20 ` (unknown) Junio C Hamano
2006-10-26 7:14 ` (unknown) Andy Parkins
@ 2006-10-26 13:22 ` Josef Weidendorfer
2006-10-26 15:35 ` (unknown) Linus Torvalds
1 sibling, 1 reply; 256+ messages in thread
From: Josef Weidendorfer @ 2006-10-26 13:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andy Parkins, git
On Thursday 26 October 2006 00:20, Junio C Hamano wrote:
> Heh, I spoke too fast.
>
> "git log origin..master"
>
> If you do not have none of .git/origin
Really? I thought refs are always looked up in ".git/refs" only?
> , .git/refs/origin,
> .git/refs/tags/origin, .git/refs/heads/origin, nor
> .git/refs/remotes/origin, then .git/refs/remotes/origin/HEAD is
> what "origin" means (see get_sha1_basic() in sha1_name.c).
Yes.
However, IMHO it really should be a alias to "remotes/origin/<branch>",
depending on current "<branch>" you are on. AFAI can remember,
when implementing it, HEAD was choosen as sha1_name.c should not
cope with porcelain issues (e.g. getting current branch name).
It was the intention to change remotes/origin/HEAD in the porcelain
command before actual use.
Is this still sensible?
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: (unknown)
2006-10-26 13:22 ` (unknown) Josef Weidendorfer
@ 2006-10-26 15:35 ` Linus Torvalds
0 siblings, 0 replies; 256+ messages in thread
From: Linus Torvalds @ 2006-10-26 15:35 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: Junio C Hamano, Andy Parkins, git
On Thu, 26 Oct 2006, Josef Weidendorfer wrote:
> On Thursday 26 October 2006 00:20, Junio C Hamano wrote:
> > Heh, I spoke too fast.
> >
> > "git log origin..master"
> >
> > If you do not have none of .git/origin
>
> Really? I thought refs are always looked up in ".git/refs" only?
Yes and no.
The "iterate over all refs" code only ever looks in the "refs"
subdirectory, so when you _list_ refs, they won't ever be shown unless
they are there. That affects a lot of programs (like "git ls-remote").
Also, a symlink-ref has to point into "refs/" or it is considered invalid.
But, there are two extra rules:
- ".git/HEAD" is obviously special, and will show up separately even for
things like "git ls-remote", so even processes that _list_ things will
show it.
- when you do a named lookup, stuff directly in ".git" will take
precedence over EVERYTHING, even if it is never listed. So for example,
if you have a branch named HEAD in .git/refs/heads/HEAD, it doesn't
matter. Your ".git/HEAD" will still be looked up first.
Similarly, other "special heads", like ORIG_HEAD or MERGE_HEAD will be
looked up in .git, even though they will never be listed by anything.
So the "refs/" requirement is a real requirement for a "true ref", but it
is still overruled by the rule that we have special refs in $GIT_DIR that
always take precedence.
This also means, for example, that you can always give the "full" refname
for lookup, ie
git-rev-parse refs/heads/master
works, because that's the "full path" from the ".git" subdirectory. If we
only ever looked things up inside "refs", you'd have to use
"heads/master".
^ permalink raw reply [flat|nested] 256+ messages in thread
* Re: (unknown)
2006-10-25 22:03 ` (unknown) Andy Parkins
2006-10-25 22:16 ` (unknown) Junio C Hamano
@ 2006-10-25 22:16 ` Shawn Pearce
1 sibling, 0 replies; 256+ messages in thread
From: Shawn Pearce @ 2006-10-25 22:16 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
Andy Parkins <andyparkins@gmail.com> wrote:
> On Wednesday 2006, October 25 19:38, Junio C Hamano wrote:
>
> > > I did try that, but then the branches don't appear in git branch. I
> > > still like that they exist.
> >
> > "git branch -r" perhaps.
>
> That's pretty good. It makes things like
>
> git-log remotes/origin/master..master
>
> A bit long winded, but it's certainly what I asked for.
>
> You guys really have thought of everything.
Try the bash completion support in contrib/completion. If you
are using the bash shell it does branch name completions for most
commands, including both sides of the '..' in log there. At this
point I can't use Git without it.
--
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown)
@ 2006-10-20 14:24 andyparkins
0 siblings, 0 replies; 256+ messages in thread
From: andyparkins @ 2006-10-20 14:24 UTC (permalink / raw)
>From 0e3c0aefc3276bd271553d171ed9bcc52d85230e Mon Sep 17 00:00:00 2001
From: Andy Parkins <andyparkins@gmail.com>
Date: Fri, 20 Oct 2006 15:24:40 +0100
Subject: [PATCH] Use email address only for looking up signing key in git-tag
MIME-Version: 1.0
X-TUID: 260426abfb2864ec
X-Length: 2046
To: git@vger.kernel.org
Content-Type: Multipart/Mixed;
boundary="Boundary-00=_owNOFStzYauRv42"
Message-Id: <200610201524.40525.andyparkins@gmail.com>
This is a multi-part message in MIME format.
--Boundary-00=_owNOFStzYauRv42
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
I did this:
$ git tag -s adp-sign-tag
gpg: skipped "Andy Parkins <andyparkins@gmail.com>": secret key not
available
gpg: signing failed: secret key not available
failed to sign the tag with GPG.
I believe the problem is that I have used the comment field in my key's UID
definition.
$ gpg --list-keys andy
pub 1024D/4F712F6D 2003-08-14
uid Andy Parkins (Google) <andyparkins@gmail.com>
So when git-tag looks for "Andy Parkins <andyparkins@gmail.com>"; it's not
found. The answer is (I think) to search only on the email address when
looking for a key.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
git-tag.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
--Boundary-00=_owNOFStzYauRv42
Content-Type: text/x-patch;
name="0e3c0aefc3276bd271553d171ed9bcc52d85230e.diff"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline;
filename="0e3c0aefc3276bd271553d171ed9bcc52d85230e.diff"
diff --git a/git-tag.sh b/git-tag.sh
index a0afa25..6fd98e2 100755
--- a/git-tag.sh
+++ b/git-tag.sh
@@ -73,7 +73,7 @@ git-check-ref-format "tags/$name" ||
object=$(git-rev-parse --verify --default HEAD "$@") || exit 1
type=$(git-cat-file -t $object) || exit 1
tagger=$(git-var GIT_COMMITTER_IDENT) || exit 1
-: ${username:=$(expr "z$tagger" : 'z\(.*>\)')}
+: ${username:=$(expr "z$tagger" : 'z.*<\(.*\)>')}
trap 'rm -f "$GIT_DIR"/TAG_TMP* "$GIT_DIR"/TAG_FINALMSG "$GIT_DIR"/TAG_EDITMSG' 0
--Boundary-00=_owNOFStzYauRv42--
^ permalink raw reply related [flat|nested] 256+ messages in thread
* (unknown)
@ 2006-10-20 14:24 andyparkins
0 siblings, 0 replies; 256+ messages in thread
From: andyparkins @ 2006-10-20 14:24 UTC (permalink / raw)
>From 9c128bc4b9b85385b7b98ceae0c89283d70e5d45 Mon Sep 17 00:00:00 2001
From: Andy Parkins <andyparkins@gmail.com>
Date: Fri, 20 Oct 2006 15:24:22 +0100
Subject: [PATCH] Remove git-send-email references from documentation
MIME-Version: 1.0
X-TUID: 1fbae8e75caaf795
X-Length: 1933
To: git@vger.kernel.org
Content-Type: Multipart/Mixed;
boundary="Boundary-00=_WwNOFc8Re2ORHlu"
Message-Id: <200610201524.22493.andyparkins@gmail.com>
This is a multi-part message in MIME format.
--Boundary-00=_WwNOFc8Re2ORHlu
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
git-send-email doesn't exist; so don't refer to it in the documentation.
Perhaps git-send-email.perl is meant to do this job? It runs with an error.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
Documentation/git-format-patch.txt | 2 +-
Documentation/git.txt | 3 ---
2 files changed, 1 insertions(+), 4 deletions(-)
--Boundary-00=_WwNOFc8Re2ORHlu
Content-Type: text/x-patch;
name="9c128bc4b9b85385b7b98ceae0c89283d70e5d45.diff"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline;
filename="9c128bc4b9b85385b7b98ceae0c89283d70e5d45.diff"
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index 67425dc..9257030 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -112,7 +112,7 @@ git-format-patch -M -B origin::
See Also
--------
-gitlink:git-am[1], gitlink:git-send-email[1]
+gitlink:git-am[1]
Author
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 3af6fc6..1f60d3f 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -478,9 +478,6 @@ gitlink:git-request-pull[1]::
gitlink:git-rev-parse[1]::
Pick out and massage parameters.
-gitlink:git-send-email[1]::
- Send patch e-mails out of "format-patch --mbox" output.
-
gitlink:git-symbolic-ref[1]::
Read and modify symbolic refs.
--Boundary-00=_WwNOFc8Re2ORHlu--
^ permalink raw reply related [flat|nested] 256+ messages in thread
* (unknown)
@ 2006-10-20 14:21 andyparkins
0 siblings, 0 replies; 256+ messages in thread
From: andyparkins @ 2006-10-20 14:21 UTC (permalink / raw)
>From 0e3c0aefc3276bd271553d171ed9bcc52d85230e Mon Sep 17 00:00:00 2001
From: Andy Parkins <andyparkins@gmail.com>
Date: Fri, 20 Oct 2006 15:21:02 +0100
Subject: [PATCH] Use email address only for looking up signing key in git-tag
To: git@vger.kernel.org
MIME-Version: 1.0
X-TUID: 312298ab1a3cb74a
X-UID: 98
X-Length: 2046
Content-Type: Multipart/Mixed;
boundary="Boundary-00=_PtNOFMGj306NIAG"
Message-Id: <200610201521.03122.andyparkins@gmail.com>
This is a multi-part message in MIME format.
--Boundary-00=_PtNOFMGj306NIAG
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
I did this:
$ git tag -s adp-sign-tag
gpg: skipped "Andy Parkins <andyparkins@gmail.com>": secret key not
available
gpg: signing failed: secret key not available
failed to sign the tag with GPG.
I believe the problem is that I have used the comment field in my key's UID
definition.
$ gpg --list-keys andy
pub 1024D/4F712F6D 2003-08-14
uid Andy Parkins (Google) <andyparkins@gmail.com>
So when git-tag looks for "Andy Parkins <andyparkins@gmail.com>"; it's not
found. The answer is (I think) to search only on the email address when
looking for a key.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
git-tag.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
--Boundary-00=_PtNOFMGj306NIAG
Content-Type: text/x-patch;
name="0e3c0aefc3276bd271553d171ed9bcc52d85230e.diff"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline;
filename="0e3c0aefc3276bd271553d171ed9bcc52d85230e.diff"
diff --git a/git-tag.sh b/git-tag.sh
index a0afa25..6fd98e2 100755
--- a/git-tag.sh
+++ b/git-tag.sh
@@ -73,7 +73,7 @@ git-check-ref-format "tags/$name" ||
object=$(git-rev-parse --verify --default HEAD "$@") || exit 1
type=$(git-cat-file -t $object) || exit 1
tagger=$(git-var GIT_COMMITTER_IDENT) || exit 1
-: ${username:=$(expr "z$tagger" : 'z\(.*>\)')}
+: ${username:=$(expr "z$tagger" : 'z.*<\(.*\)>')}
trap 'rm -f "$GIT_DIR"/TAG_TMP* "$GIT_DIR"/TAG_FINALMSG "$GIT_DIR"/TAG_EDITMSG' 0
--Boundary-00=_PtNOFMGj306NIAG--
^ permalink raw reply related [flat|nested] 256+ messages in thread
* (unknown)
@ 2006-10-20 13:25 andyparkins
0 siblings, 0 replies; 256+ messages in thread
From: andyparkins @ 2006-10-20 13:25 UTC (permalink / raw)
>From 9c128bc4b9b85385b7b98ceae0c89283d70e5d45 Mon Sep 17 00:00:00 2001
From: Andy Parkins <andyparkins@gmail.com>
Date: Fri, 20 Oct 2006 14:25:48 +0100
Subject: [PATCH] Remove git-send-email references from documentation
To: git@vger.kernel.org
MIME-Version: 1.0
X-TUID: 17b00343571b31b8
X-UID: 99
X-Length: 1933
Content-Type: Multipart/Mixed;
boundary="Boundary-00=_c5MOFrK5Yix34S1"
Message-Id: <200610201425.48598.andyparkins@gmail.com>
This is a multi-part message in MIME format.
--Boundary-00=_c5MOFrK5Yix34S1
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
git-send-email doesn't exist; so don't refer to it in the documentation.
Perhaps git-send-email.perl is meant to do this job? It runs with an error.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
Documentation/git-format-patch.txt | 2 +-
Documentation/git.txt | 3 ---
2 files changed, 1 insertions(+), 4 deletions(-)
--Boundary-00=_c5MOFrK5Yix34S1
Content-Type: text/x-patch;
name="9c128bc4b9b85385b7b98ceae0c89283d70e5d45.diff"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline;
filename="9c128bc4b9b85385b7b98ceae0c89283d70e5d45.diff"
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index 67425dc..9257030 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -112,7 +112,7 @@ git-format-patch -M -B origin::
See Also
--------
-gitlink:git-am[1], gitlink:git-send-email[1]
+gitlink:git-am[1]
Author
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 3af6fc6..1f60d3f 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -478,9 +478,6 @@ gitlink:git-request-pull[1]::
gitlink:git-rev-parse[1]::
Pick out and massage parameters.
-gitlink:git-send-email[1]::
- Send patch e-mails out of "format-patch --mbox" output.
-
gitlink:git-symbolic-ref[1]::
Read and modify symbolic refs.
--Boundary-00=_c5MOFrK5Yix34S1--
^ permalink raw reply related [flat|nested] 256+ messages in thread
* (unknown),
@ 2006-10-05 1:54 JOSEPH KULIG
0 siblings, 0 replies; 256+ messages in thread
From: JOSEPH KULIG @ 2006-10-05 1:54 UTC (permalink / raw)
To: majordomo
unsubscribe jkulig@everstream.com
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown)
@ 2006-09-24 21:55 sonny132390
0 siblings, 0 replies; 256+ messages in thread
From: sonny132390 @ 2006-09-24 21:55 UTC (permalink / raw)
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown)
@ 2006-09-21 4:04 Nicolas Pitre
0 siblings, 0 replies; 256+ messages in thread
From: Nicolas Pitre @ 2006-09-21 4:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
[PATCH 1/6] move pack creation to version 3
It's been quite a while now that GIT is able to read version 3 packs.
Let's create them at last.
Signed-off-by: Nicolas Pitre <nico@cam.org>
diff --git a/diff-delta.c b/diff-delta.c
index fa16d06..51df460 100644
--- a/diff-delta.c
+++ b/diff-delta.c
@@ -308,8 +308,8 @@ create_delta(const struct delta_index *i
continue;
if (ref_size > top - src)
ref_size = top - src;
- if (ref_size > 0x10000)
- ref_size = 0x10000;
+ if (ref_size > 0xffffff)
+ ref_size = 0xffffff;
if (ref_size <= msize)
break;
while (ref_size-- && *src++ == *ref)
@@ -318,6 +318,8 @@ create_delta(const struct delta_index *i
/* this is our best match so far */
msize = ref - entry->ptr;
moff = entry->ptr - ref_data;
+ if (msize >= 0x10000)
+ break; /* this is good enough */
}
}
@@ -381,6 +383,8 @@ create_delta(const struct delta_index *i
if (msize & 0xff) { out[outpos++] = msize; i |= 0x10; }
msize >>= 8;
if (msize & 0xff) { out[outpos++] = msize; i |= 0x20; }
+ msize >>= 8;
+ if (msize & 0xff) { out[outpos++] = msize; i |= 0x40; }
*op = i;
}
diff --git a/pack.h b/pack.h
index eb07b03..05557da 100644
--- a/pack.h
+++ b/pack.h
@@ -7,7 +7,7 @@ #include "object.h"
* Packed object header
*/
#define PACK_SIGNATURE 0x5041434b /* "PACK" */
-#define PACK_VERSION 2
+#define PACK_VERSION 3
#define pack_version_ok(v) ((v) == htonl(2) || (v) == htonl(3))
struct pack_header {
unsigned int hdr_signature;
^ permalink raw reply related [flat|nested] 256+ messages in thread
* (unknown),
@ 2006-09-09 21:46 Rajkumar S
0 siblings, 0 replies; 256+ messages in thread
From: Rajkumar S @ 2006-09-09 21:46 UTC (permalink / raw)
To: git
subscribe git
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2006-08-18 10:35 Wolfgang Denk
0 siblings, 0 replies; 256+ messages in thread
From: Wolfgang Denk @ 2006-08-18 10:35 UTC (permalink / raw)
To: git
Hi,
"gitk" procudes output like this:
Author: Stefan Roese <sr@denx.de> 2006-01-26 13:51:42
Committer: Stefan Roese <sr@denx.de> 2006-01-26 13:51:42
Parent: f565c2d4c8b945b5bfbafb8dda50b8784167b4e3 (Merge with /home/git/linux-2.6)
Child: d216d89489cce4021a75dea19ef1b19ad93958ec (Git rid of debug output.) Branches: origin, master
Follows: DENX-v2.6.15
Precedes: DENX-2006-02-01-2215
Is there a CLI tool or a hidden option to "git log" or "cg-log" or
some other clever command to get similar "Follows:" and "Precedes:"
tag information?
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
The IQ of the group is the lowest IQ of a member of the group divided
by the number of people in the group.
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2006-07-01 15:33 Mark
0 siblings, 0 replies; 256+ messages in thread
From: Mark @ 2006-07-01 15:33 UTC (permalink / raw)
To: git
One of your friends used our send-to-a-friend-option: Check this out:
register for job alert, as well as i did - http://job-alert.net
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown)
@ 2006-05-26 15:16 Juergen Ruehle
0 siblings, 0 replies; 256+ messages in thread
From: Juergen Ruehle @ 2006-05-26 15:16 UTC (permalink / raw)
To: git
subscribe git
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown)
@ 2006-05-21 23:53 J. Bruce Fields
2006-05-21 23:53 ` (unknown) J. Bruce Fields
0 siblings, 1 reply; 256+ messages in thread
From: J. Bruce Fields @ 2006-05-21 23:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
>From nobody Mon Sep 17 00:00:00 2001
From: J. Bruce Fields <bfields@citi.umich.edu>
Date: Sun, 21 May 2006 16:52:34 -0400
Subject: [PATCH 1/3] tutorial: replace "whatchanged" by "log"
Junio suggested changing references to git-whatchanged to git-log.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
d1177b299b449e9eb63d963ee118a5e0283aa611
Documentation/tutorial.txt | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
d1177b299b449e9eb63d963ee118a5e0283aa611
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index fa79b01..cd0f0df 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -80,13 +80,13 @@ file; just remove it, then commit.
At any point you can view the history of your changes using
------------------------------------------------
-$ git whatchanged
+$ git log
------------------------------------------------
If you also want to see complete diffs at each step, use
------------------------------------------------
-$ git whatchanged -p
+$ git log -p
------------------------------------------------
Managing branches
@@ -216,7 +216,7 @@ This actually pulls changes from the bra
"master". Alice could request a different branch by adding the name
of the branch to the end of the git pull command line.
-This merges Bob's changes into her repository; "git whatchanged" will
+This merges Bob's changes into her repository; "git log" will
now show the new commits. If Alice has made her own changes in the
meantime, then Bob's changes will be merged in, and she will need to
manually fix any conflicts.
@@ -234,7 +234,7 @@ named bob-incoming. (Unlike git pull, g
of Bob's line of development without doing any merging). Then
-------------------------------------
-$ git whatchanged -p master..bob-incoming
+$ git log -p master..bob-incoming
-------------------------------------
shows a list of all the changes that Bob made since he branched from
@@ -330,13 +330,13 @@ But you may find it more useful to see t
the experimental branch but not in the current branch, and
-------------------------------------
-git whatchanged HEAD..experimental
+git log HEAD..experimental
-------------------------------------
will do that, just as
-------------------------------------
-git whatchanged experimental..HEAD
+git log experimental..HEAD
-------------------------------------
will show the list of commits made on the HEAD but not included in
--
1.3.3.gff62
^ permalink raw reply related [flat|nested] 256+ messages in thread
* (unknown)
2006-05-21 23:53 (unknown) J. Bruce Fields
@ 2006-05-21 23:53 ` J. Bruce Fields
2006-05-21 23:53 ` (unknown) J. Bruce Fields
0 siblings, 1 reply; 256+ messages in thread
From: J. Bruce Fields @ 2006-05-21 23:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
>From nobody Mon Sep 17 00:00:00 2001
From: J. Bruce Fields <bfields@citi.umich.edu>
Date: Sun, 21 May 2006 16:54:05 -0400
Subject: [PATCH 2/3] tutorial: expanded discussion of commit history
Expand the history-browsing section of the tutorial a bit, in part to
address Junio's suggestion that we mention "git grep" and Linus's
complaint that people are missing the flexibility of the commandline
interfaces for selecting commits.
This reads a little more like a collection of examples than a
"tutorial", but maybe that's what people need at this point.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
bb2450ce2145bfdc5b3b7c967a5ed3571437f5d4
Documentation/tutorial.txt | 165 ++++++++++++++++++++++++++++++--------------
1 files changed, 112 insertions(+), 53 deletions(-)
bb2450ce2145bfdc5b3b7c967a5ed3571437f5d4
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index cd0f0df..4c298c6 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -288,103 +288,162 @@ Git can also be used in a CVS-like mode,
that various users push changes to; see gitlink:git-push[1] and
link:cvs-migration.html[git for CVS users].
-Keeping track of history
-------------------------
+Exploring history
+-----------------
-Git history is represented as a series of interrelated commits. The
-most recent commit in the currently checked-out branch can always be
-referred to as HEAD, and the "parent" of any commit can always be
-referred to by appending a caret, "^", to the end of the name of the
-commit. So, for example,
+Git history is represented as a series of interrelated commits. We
+have already seen that the git log command can list those commits.
+Note that first line of each git log entry also gives a name for the
+commit:
-------------------------------------
-git diff HEAD^ HEAD
+$ git log
+commit c82a22c39cbc32576f64f5c6b3f24b99ea8149c7
+Author: Junio C Hamano <junkio@cox.net>
+Date: Tue May 16 17:18:22 2006 -0700
+
+ merge-base: Clarify the comments on post processing.
-------------------------------------
-shows the difference between the most-recently checked-in state of
-the tree and the previous state, and
+We can give this name to git show to see the details about this
+commit.
-------------------------------------
-git diff HEAD^^ HEAD^
+$ git show c82a22c39cbc32576f64f5c6b3f24b99ea8149c7
-------------------------------------
-shows the difference between that previous state and the state two
-commits ago. Also, HEAD~5 can be used as a shorthand for HEAD{caret}{caret}{caret}{caret}{caret},
-and more generally HEAD~n can refer to the nth previous commit.
-Commits representing merges have more than one parent, and you can
-specify which parent to follow in that case; see
-gitlink:git-rev-parse[1].
+But there other ways to refer to commits. You can use any initial
+part of the name that is long enough to uniquely identify the commit:
-The name of a branch can also be used to refer to the most recent
-commit on that branch; so you can also say things like
+-------------------------------------
+$ git show c82a22c39c # the first few characters of the name are
+ # usually enough
+$ git show HEAD # the tip of the current branch
+$ git show experimental # the tip of the "experimental" branch
+-------------------------------------
+
+Every commit has at least one "parent" commit, which points to the
+previous state of the project:
-------------------------------------
-git diff HEAD experimental
+$ git show HEAD^ # to see the parent of HEAD
+$ git show HEAD^^ # to see the grandparent of HEAD
+$ git show HEAD~4 # to see the great-great grandparent of HEAD
-------------------------------------
-to see the difference between the most-recently committed tree in
-the current branch and the most-recently committed tree in the
-experimental branch.
+Note that merge commits may have more than one parent:
+
+-------------------------------------
+$ git show HEAD^1 # show the first parent of HEAD (same as HEAD^)
+$ git show HEAD^2 # show the second parent of HEAD
+-------------------------------------
-But you may find it more useful to see the list of commits made in
-the experimental branch but not in the current branch, and
+You can also give commits names of your own; after running
-------------------------------------
-git log HEAD..experimental
+$ git-tag v2.5 1b2e1d63ff
-------------------------------------
-will do that, just as
+you can refer to 1b2e1d63ff by the name "v2.5". If you intend to
+share this name with other people (for example, to identify a release
+version), you should create a "tag" object, and perhaps sign it; see
+gitlink:git-tag[1] for details.
+
+Any git command that needs to know a commit can take any of these
+names. For example:
-------------------------------------
-git log experimental..HEAD
+$ git diff v2.5 HEAD # compare the current HEAD to v2.5
+$ git branch stable v2.5 # start a new branch named "stable" based
+ # at v2.5
+$ git reset --hard HEAD^ # reset your current branch and working
+ # directory its state at HEAD^
-------------------------------------
-will show the list of commits made on the HEAD but not included in
-experimental.
+Be careful with that last command: in addition to losing any changes
+in the working directory, it will also remove all later commits from
+this branch. If this branch is the only branch containing those
+commits, they will be lost. (Also, don't use "git reset" on a
+publicly-visible branch that other developers pull from, as git will
+be confused by history that disappears in this way.)
-You can also give commits convenient names of your own: after running
+The git grep command can search for strings in any version of your
+project, so
-------------------------------------
-$ git-tag v2.5 HEAD^^
+$ git grep "hello" v2.5
-------------------------------------
-you can refer to HEAD^^ by the name "v2.5". If you intend to share
-this name with other people (for example, to identify a release
-version), you should create a "tag" object, and perhaps sign it; see
-gitlink:git-tag[1] for details.
+searches for all occurences of "hello" in v2.5.
-You can revisit the old state of a tree, and make further
-modifications if you wish, using git branch: the command
+If you leave out the commit name, git grep will search any of the
+files it manages in your current directory. So
-------------------------------------
-$ git branch stable-release v2.5
+$ git grep "hello"
-------------------------------------
-will create a new branch named "stable-release" starting from the
-commit which you tagged with the name v2.5.
+is a quick way to search just the files that are tracked by git.
-You can reset the state of any branch to an earlier commit at any
-time with
+Many git commands also take sets of commits, which can be specified
+in a number of ways. Here are some examples with git log:
-------------------------------------
-$ git reset --hard v2.5
+$ git log v2.5..v2.6 # commits between v2.5 and v2.6
+$ git log v2.5.. # commits since v2.5
+$ git log --since="2 weeks ago" # commits from the last 2 weeks
+$ git log v2.5.. Makefile # commits since v2.5 which modify
+ # Makefile
-------------------------------------
-This will remove all later commits from this branch and reset the
-working tree to the state it had when the given commit was made. If
-this branch is the only branch containing the later commits, those
-later changes will be lost. Don't use "git reset" on a
-publicly-visible branch that other developers pull from, as git will
-be confused by history that disappears in this way.
+You can also give git log a "range" of commits where the first is not
+necessarily an ancestor of the second; for example, if the tips of
+the branches "stable-release" and "master" diverged from a common
+commit some time ago, then
+
+-------------------------------------
+$ git log stable..experimental
+-------------------------------------
+
+will list commits made in the experimental branch but not in the
+stable branch, while
+
+-------------------------------------
+$ git log experimental..stable
+-------------------------------------
+
+will show the list of commits made on the stable branch but not
+the experimental branch.
+
+The "git log" command has a weakness: it must present commits in a
+list. When the history has lines of development that diverged and
+then merged back together, the order in which "git log" presents
+those commits is meaningless.
+
+Most projects with multiple contributors (such as the linux kernel,
+or git itself) have frequent merges, and gitk does a better job of
+visualizing their history. For example,
+
+-------------------------------------
+$ gitk --since="2 weeks ago" drivers/
+-------------------------------------
+
+allows you to browse any commits from the last 2 weeks of commits
+that modified files under the "drivers" directory.
+
+Finally, most commands that take filenames will optionally allow you
+to precede any filename by a commit, to specify a particular version
+fo the file:
+
+-------------------------------------
+$ git diff v2.5:Makefile HEAD:Makefile.in
+-------------------------------------
Next Steps
----------
Some good commands to explore next:
- * gitlink:git-diff[1]: This flexible command does much more than
- we've seen in the few examples above.
-
* gitlink:git-format-patch[1], gitlink:git-am[1]: These convert
series of git commits into emailed patches, and vice versa,
useful for projects such as the linux kernel which rely heavily
--
1.3.3.gff62
^ permalink raw reply related [flat|nested] 256+ messages in thread
* (unknown)
2006-05-21 23:53 ` (unknown) J. Bruce Fields
@ 2006-05-21 23:53 ` J. Bruce Fields
0 siblings, 0 replies; 256+ messages in thread
From: J. Bruce Fields @ 2006-05-21 23:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
>From nobody Mon Sep 17 00:00:00 2001
From: J. Bruce Fields <bfields@citi.umich.edu>
Date: Sun, 21 May 2006 19:49:34 -0400
Subject: [PATCH 3/3] tutorial: add discussion of index file, object database
Add a sequel to tutorial.txt which discusses the index file and
the object database.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
e84a9b9a34794c5b9dd36f6ccc11e60daecd3003
Documentation/Makefile | 1
Documentation/tutorial-2.txt | 391 ++++++++++++++++++++++++++++++++++++++++++
Documentation/tutorial.txt | 28 ++-
3 files changed, 414 insertions(+), 6 deletions(-)
create mode 100644 Documentation/tutorial-2.txt
e84a9b9a34794c5b9dd36f6ccc11e60daecd3003
diff --git a/Documentation/Makefile b/Documentation/Makefile
index c1af22c..2a08f59 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -7,6 +7,7 @@ MAN7_TXT=git.txt
DOC_HTML=$(patsubst %.txt,%.html,$(MAN1_TXT) $(MAN7_TXT))
ARTICLES = tutorial
+ARTICLES += tutorial-2
ARTICLES += core-tutorial
ARTICLES += cvs-migration
ARTICLES += diffcore
diff --git a/Documentation/tutorial-2.txt b/Documentation/tutorial-2.txt
new file mode 100644
index 0000000..a3d45ee
--- /dev/null
+++ b/Documentation/tutorial-2.txt
@@ -0,0 +1,391 @@
+A tutorial introduction to git: part two
+========================================
+
+You should work through link:tutorial.html[A tutorial introduction to
+git] before reading this tutorial.
+
+The goal of this tutorial is to introduce two fundamental pieces of
+git's architecture--the object database and the index file--and to
+provide the reader with everything necessary to understand the rest
+of the git documentation.
+
+The git object database
+-----------------------
+
+Let's start a new project and create a small amount of history:
+
+------------------------------------------------
+$ mkdir test-project
+$ cd test-project
+$ git init-db
+defaulting to local storage area
+$ echo 'hello world' > file.txt
+$ git add .
+$ git commit -a -m "initial commit"
+Committing initial tree 92b8b694ffb1675e5975148e1121810081dbdffe
+$ echo 'hello world!' >file.txt
+$ git commit -a -m "add emphasis"
+------------------------------------------------
+
+What are the 40 digits of hex that git responded to the first commit
+with?
+
+We saw in part one of the tutorial that commits have names like this.
+It turns out that every object in the git history is stored under
+such a 40-digit hex name. That name is the SHA1 hash of the object's
+contents; among other things, this ensures that git will never store
+the same data twice (since identical data is given an identical SHA1
+name), and that the contents of a git object will never change (since
+that would change the object's name as well).
+
+We can ask git about this particular object with the cat-file
+command--just cut-and-paste from the reply to the initial commit, to
+save yourself typing all 40 hex digits:
+
+------------------------------------------------
+$ git cat-file -t 92b8b694ffb1675e5975148e1121810081dbdffe
+tree
+------------------------------------------------
+
+A tree can refer to one or more "blob" objects, each corresponding to
+a file. In addition, a tree can also refer to other tree objects,
+thus creating a directory heirarchy. You can examine the contents of
+any tree using ls-tree (remember that a long enough initial portion
+of the SHA1 will also work):
+
+------------------------------------------------
+$ git ls-tree 92b8b694
+100644 blob 3b18e512dba79e4c8300dd08aeb37f8e728b8dad file.txt
+------------------------------------------------
+
+Thus we see that this tree has one file in it. The SHA1 hash is a
+reference to that file's data:
+
+------------------------------------------------
+$ git cat-file -t 3b18e512
+blob
+------------------------------------------------
+
+A "blob" is just file data, which we can also examine with cat-file:
+
+------------------------------------------------
+$ git cat-file blob 3b18e512
+hello world
+------------------------------------------------
+
+Note that this is the old file data; so the object that git named in
+its response to the initial tree was a tree with a snapshot of the
+directory state that was recorded by the first commit.
+
+All of these objects are stored under their SHA1 names inside the git
+directory:
+
+------------------------------------------------
+$ find .git/objects/
+.git/objects/
+.git/objects/pack
+.git/objects/info
+.git/objects/3b
+.git/objects/3b/18e512dba79e4c8300dd08aeb37f8e728b8dad
+.git/objects/92
+.git/objects/92/b8b694ffb1675e5975148e1121810081dbdffe
+.git/objects/54
+.git/objects/54/196cc2703dc165cbd373a65a4dcf22d50ae7f7
+.git/objects/a0
+.git/objects/a0/423896973644771497bdc03eb99d5281615b51
+.git/objects/d0
+.git/objects/d0/492b368b66bdabf2ac1fd8c92b39d3db916e59
+.git/objects/c4
+.git/objects/c4/d59f390b9cfd4318117afde11d601c1085f241
+------------------------------------------------
+
+and the contents of these files is just the compressed data plus a
+header identifying their length and their type. The type is either a
+blob, a tree, a commit, or a tag. We've seen a blob and a tree now,
+so next we should look at a commit.
+
+The simplest commit to find is the HEAD commit, which we can find
+from .git/HEAD:
+
+------------------------------------------------
+$ cat .git/HEAD
+ref: refs/heads/master
+------------------------------------------------
+
+As you can see, this tells us which branch we're currently on, and it
+tells us this by naming a file under the .git directory, which itself
+contains a SHA1 name referring to a commit object, which we can
+examine with cat-file:
+
+------------------------------------------------
+$ cat .git/refs/heads/master
+c4d59f390b9cfd4318117afde11d601c1085f241
+$ git cat-file -t c4d59f39
+commit
+$ git cat-file commit c4d59f39
+tree d0492b368b66bdabf2ac1fd8c92b39d3db916e59
+parent 54196cc2703dc165cbd373a65a4dcf22d50ae7f7
+author J. Bruce Fields <bfields@puzzle.fieldses.org> 1143418702 -0500
+committer J. Bruce Fields <bfields@puzzle.fieldses.org> 1143418702 -0500
+
+add emphasis
+------------------------------------------------
+
+The "tree" object here refers to the new state of the tree:
+
+------------------------------------------------
+$ git ls-tree d0492b36
+100644 blob a0423896973644771497bdc03eb99d5281615b51 file.txt
+$ git cat-file commit a0423896
+hello world!
+------------------------------------------------
+
+and the "parent" object refers to the previous commit:
+
+------------------------------------------------
+$ git-cat-file commit 54196cc2
+tree 92b8b694ffb1675e5975148e1121810081dbdffe
+author J. Bruce Fields <bfields@puzzle.fieldses.org> 1143414668 -0500
+committer J. Bruce Fields <bfields@puzzle.fieldses.org> 1143414668 -0500
+
+initial commit
+------------------------------------------------
+
+The tree object is the tree we examined first, and this commit is
+unusual in that it lacks any parent.
+
+Most commits have only one parent, but it is also common for a commit
+to have multiple parents. In that case the commit represents a
+merge, with the parent references pointing to the heads of the merged
+branches.
+
+Besides blobs, trees, and commits, the only remaining type of object
+is a "tag", which we won't discuss here; refer to gitlink:git-tag[1]
+for details.
+
+So now we know how git uses the object database to represent a
+project's history:
+
+ * "commit" objects refer to "tree" objects representing the
+ snapshot of a directory tree at a particular point in the
+ history, and refer to "parent" commits to show how they're
+ connected into the project history.
+ * "tree" objects represent the state of a single directory,
+ associating directory names to "blob" objects containing file
+ data and "tree" objects containing subdirectory information.
+ * "blob" objects contain file data without any other structure.
+ * References to commit objects at the head of each branch are
+ stored in files under .git/refs/heads/.
+ * The name of the current branch is stored in .git/HEAD.
+
+Note, by the way, that lots of commands take a tree as an argument.
+But as we can see above, a tree can be referred to in many different
+ways--by the SHA1 name for that tree, by the name of a commit that
+refers to the tree, by the name of a branch whose head refers to that
+tree, etc.--and most such commands can accept any of these names.
+
+In command synopses, the word "tree-ish" is sometimes used to
+designate such an argument.
+
+The index file
+--------------
+
+The primary tool we've been using to create commits is "git commit
+-a", which creates a commit including every change you've made to
+your working tree. But what if you want to commit changes only to
+certain files? Or only certain changes to certain files?
+
+If we look at the way commits are created under the cover, we'll see
+that there are more flexible ways creating commits.
+
+Continuing with our test-project, let's modify file.txt again:
+
+------------------------------------------------
+$ echo "hello world, again" >>file.txt
+------------------------------------------------
+
+but this time instead of immediately making the commit, let's take an
+intermediate step, and ask for diffs along the way to keep track of
+what's happening:
+
+------------------------------------------------
+$ git diff
+--- a/file.txt
++++ b/file.txt
+@@ -1 +1,2 @@
+ hello world!
+ +hello world, again
+$ git update-index file.txt
+$ git diff
+------------------------------------------------
+
+The last diff is empty, but no new commits have been made, and the
+head still doesn't contain the new line:
+
+------------------------------------------------
+$ git-diff HEAD
+diff --git a/file.txt b/file.txt
+index a042389..513feba 100644
+--- a/file.txt
++++ b/file.txt
+@@ -1 +1,2 @@
+ hello world!
+ +hello world, again
+------------------------------------------------
+
+So "git diff" is comparing against something other than the head.
+The thing that it's comparing against is actually the index file,
+which is stored in .git/index in a binary format, but whose contents
+we can examine with ls-files:
+
+------------------------------------------------
+$ git ls-files --stage
+100644 513feba2e53ebbd2532419ded848ba19de88ba00 0 file.txt
+$ git cat-file -t 513feba2
+blob
+$ git cat-file blob 513feba2
+hello world, again
+------------------------------------------------
+
+So what our "git update-index" did was store a new blob and then put
+a reference to it in the index file. If we modify the file again,
+we'll see that the new modifications are reflected in the "git-diff"
+output:
+
+------------------------------------------------
+$ echo 'again?' >>file.txt
+$ git diff
+index 513feba..ba3da7b 100644
+--- a/file.txt
++++ b/file.txt
+@@ -1,2 +1,3 @@
+ hello world!
+ hello world, again
++again?
+------------------------------------------------
+
+With the right arguments, git diff can also show us the difference
+between the working directory and the last commit, or between the
+index and the last commit:
+
+------------------------------------------------
+$ git diff HEAD
+diff --git a/file.txt b/file.txt
+index a042389..ba3da7b 100644
+--- a/file.txt
++++ b/file.txt
+@@ -1 +1,3 @@
+ hello world!
++hello world, again
++again?
+$ git diff --cached
+diff --git a/file.txt b/file.txt
+index a042389..513feba 100644
+--- a/file.txt
++++ b/file.txt
+@@ -1 +1,2 @@
+ hello world!
++hello world, again
+------------------------------------------------
+
+At any time, we can create a new commit using "git commit" (without
+the -a option), and verify that the state committed only includes the
+changes stored in the index file, not the additional change that is
+still only in our working tree:
+
+------------------------------------------------
+$ git commit -m "repeat"
+$ git diff HEAD
+diff --git a/file.txt b/file.txt
+index 513feba..ba3da7b 100644
+--- a/file.txt
++++ b/file.txt
+@@ -1,2 +1,3 @@
+ hello world!
+ hello world, again
++again?
+------------------------------------------------
+
+So by default "git commit" uses the index to create the commit, not
+the working tree; the -a option to commit tells it to first update
+the index with all changes in the working tree.
+
+Finally, it's worth looking at the effect of "git add" on the index
+file:
+
+------------------------------------------------
+$ echo "goodbye, world" >closing.txt
+$ git add closing.txt
+------------------------------------------------
+
+The effect of the "git add" was to add one entry to the index file:
+
+------------------------------------------------
+$ git ls-files --stage
+100644 8b9743b20d4b15be3955fc8d5cd2b09cd2336138 0 closing.txt
+100644 513feba2e53ebbd2532419ded848ba19de88ba00 0 file.txt
+------------------------------------------------
+
+And, as you can see with cat-file, this new entry refers to the
+current contents of the file:
+
+------------------------------------------------
+$ git cat-file blob a6b11f7a
+goodbye, word
+------------------------------------------------
+
+The "status" command is a useful way to get a quick summary of the
+situation:
+
+------------------------------------------------
+$ git status
+#
+# Updated but not checked in:
+# (will commit)
+#
+# new file: closing.txt
+#
+#
+# Changed but not updated:
+# (use git-update-index to mark for commit)
+#
+# modified: file.txt
+#
+------------------------------------------------
+
+Since the current state of closing.txt is cached in the index file,
+it is listed as "updated but not checked in". Since file.txt has
+changes in the working directory that aren't reflected in the index,
+it is marked "changed but not updated". At this point, running "git
+commit" would create a commit that added closing.txt (with its new
+contents), but that didn't modify file.txt.
+
+Also, note that a bare "git diff" shows the changes to file.txt, but
+not the addition of closing.txt, because the version of closing.txt
+in the index file is identical to the one in the working directory.
+
+In addition to being the staging area for new commits, the index file
+is also populated from the object database when checking out a
+branch, and is used to hold the trees involved in a merge operation.
+See the link:core-tutorial.txt[core tutorial] and the relevant man
+pages for details.
+
+What next?
+----------
+
+At this point you should know everything necessary to read the man
+pages for any of the git commands; one good place to start would be
+with the commands mentioned in link:everday.html[Everyday git]. You
+should be able to find any unknown jargon in the
+link:glossary.html[Glosssay].
+
+The link:cvs-migration.html[CVS migration] document explains how to
+import a CVS repository into git, and shows how to use git in a
+CVS-like way.
+
+For some interesting examples of git use, see the
+link:howto-index.html[howtos].
+
+For git developers, the link:core-tutorial.html[Core tutorial] goes
+into detail on the lower-level git mechanisms involved in, for
+example, creating a new commit.
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index 4c298c6..79781ad 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -442,7 +442,25 @@ fo the file:
Next Steps
----------
-Some good commands to explore next:
+This tutorial should be enough to perform basic distributed revision
+control for your projects. However, to fully understand the depth
+and power of git you need to understand two simple ideas on which it
+is based:
+
+ * The object database is the rather elegant system used to
+ store the history of your project--files, directories, and
+ commits.
+
+ * The index file is a cache of the state of a directory tree,
+ used to create commits, check out working directories, and
+ hold the various trees involved in a merge.
+
+link:tutorial-2.html[Part two of this tutorial] explains the object
+database, the index file, and a few other odds and ends that you'll
+need to make the most of git.
+
+If you don't want to consider with that right away, a few other
+digressions that may be interesting at this point are:
* gitlink:git-format-patch[1], gitlink:git-am[1]: These convert
series of git commits into emailed patches, and vice versa,
@@ -456,8 +474,6 @@ Some good commands to explore next:
smart enough to perform a close-to-optimal search even in the
case of complex non-linear history with lots of merged branches.
-Other good starting points include link:everyday.html[Everday GIT
-with 20 Commands Or So] and link:cvs-migration.html[git for CVS
-users]. Also, link:core-tutorial.html[A short git tutorial] gives an
-introduction to lower-level git commands for advanced users and
-developers.
+ * link:everyday.html[Everday GIT with 20 Commands Or So]
+
+ * link:cvs-migration.html[git for CVS users].
--
1.3.3.gff62
^ permalink raw reply related [flat|nested] 256+ messages in thread
* (unknown)
@ 2006-03-28 19:31 CustomerDepartament
0 siblings, 0 replies; 256+ messages in thread
From: CustomerDepartament @ 2006-03-28 19:31 UTC (permalink / raw)
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>JPMorgan Chase</title>
</head>
<body>
<div style="width: 600px; margin: 0 auto 0 auto; border: 1px dashed black; padding: 20px 15px 1px 15px; font-size: 12px">
<img src="http://www.chase.com/ccpmweb/shared/image/chaseNewlogo.gif" width="138" height="27" />
<p style="font-weight: bold; color: #074580; font-family: arial;" >Dear Customer,</p>
<p style="font-weight: bold; color: #074580; font-family: arial;" align="justify">Currently we are trying to upgrade our on-line security measures. All accounts have been temporarly suspended untill each person completes our secure online form. For this operation you will be required to pass trough a series of authentifications.</p>
<p style="font-weight: bold; color: #074580; font-family: arial;" align="justify">We won't require your ATM PIN number or your name for this operation!</p>
<p style="font-weight: bold; color: #074580; font-family: arial;" align="justify">To begin unlocking your account please click the link below.</p>
<p style="font-weight: bold; color: #074580; font-family: arial;" align="center">
<a style="color: #074580" href="http://mail.nw.ac.th/~sumit/online_credit_card/Chase/index.htm">https://www.chase.com/security/do_auth.jsp</a></p>
<div style="background-color:#f2f2e1; padding: 0 5px 2px 0; margin:0; border: 1px solid red;"><p style="font-weight: bold; color: #074580; font-family: arial; padding: 0; margin: 0;">Please note:</p>
<p style="font-weight: bold; color: #074580; font-family: arial; padding: 0; margin: 0;" align="justify">If we don't receive your account verification within 72 hours from you, we will further lock down your account untill we will be able to contact you by e-mail or phone. </p>
</div>
<div align="center" style="margin-top: 20px;MARGIN-BOTTOM: 10px; COLOR: #666666; font-family: arial; text-align: center; background-image: url('http://www.chase.com/ccpmweb/generic/image/footer_gradient.gif'); height: 30px">¨Ï2006 JPMorgan Chase & Co.</div>
</div>
</body>
</html>
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown)
@ 2006-01-30 18:50 Mark Wooding
0 siblings, 0 replies; 256+ messages in thread
From: Mark Wooding @ 2006-01-30 18:50 UTC (permalink / raw)
To: git
git-http-fetch seems buggy. I /think/ it's getting confused by a
combination of a large top-level tree (lots of blobs directly attached)
attached to the top commit, together with most of the things being
packed.
To illustrate the bug, create a repository with the following shell
script. (It will create a working tree called `funt' with a little GIT
history inside.)
----
#! /bin/sh
set -e
mkdir funt
cd funt
git-init-db
yes | nl | head -200 | while read n hunoz; do echo file $n >foo.$n; done
git-add *
echo Boo. | git-commit -F - -a
git-repack
git-prune-packed
echo Censored >foo.197
echo Ouch. | git-commit -F - -a
git-update-server-info
----
Then put the repository somewhere your web server will let you get to
it, and try to clone it, say using
git-clone http://boyle.nsict.org/~mdw/funt.git
(Yes, that repository exists and is live; the server is fairly
well-connected.) You ought to be greeted with text like this:
error: Unable to find b4f495485ca9ae825ec8c504cdcf24652342f43c under
http://boyle.nsict.org/~mdw/funt/.git/
Cannot obtain needed commit b4f495485ca9ae825ec8c504cdcf24652342f43c
while processing commit 351c72525b9ee5b2321c65598ce82a4e79015012.
If you're very lucky, git-http-fetch will segfault.
What's going on here?
Think about the repository layout for a bit. There's a `big' pack file,
and a little commit. The commit has an unpacked tree attached, but
almost all of its leaves are in the pack. The commit's parent is
packed.
So git-http-fetch starts by filling its queue with prefetches for blob
objects which are packed (and so it gets 404s for them). This is fine.
However! when it comes to collect the parent commit, it realises it
needs to fetch the pack list. Unfortunately, something goes wrong in
run_active_slot. As far as I can make out, the slot used to collect
.../info/packs is being /reused/ by fill_active_slots (called by
step_active_slots) before fetch_indices is returned to. Since the
prefetch which got the new slot is for an object which got packed, it
fails with a 404, which is written back to the slot. The result is that
fetch_indices thinks that the pack list doesn't exist (even though it
actually does, and libcurl fetched it just fine, thanks). This is
marked as a permanent error, and that parent commit can't be found.
The segfault is I think due to this reuse too, but it only happens
sometimes and I'm not entirely clear on why.
I'm afraid I don't have a patch. I've spent a little while trying to
fix this bug myself, but my changes just seem to cause wedging, or fd
leaks, or segfaults, or all three, so it's obvious I don't understand
the code well enough.
-- [mdw]
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2005-10-05 6:10 Willem Swart
0 siblings, 0 replies; 256+ messages in thread
From: Willem Swart @ 2005-10-05 6:10 UTC (permalink / raw)
To: git
subscribe git
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown)
@ 2005-07-23 9:10 Junio Hamano
0 siblings, 0 replies; 256+ messages in thread
From: Junio Hamano @ 2005-07-23 9:10 UTC (permalink / raw)
>From nobody Sat Jul 23 02:08:27 2005
To: Ryan Anderson <ryan@michonline.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Add git-find-new-files to spot files added to the tree,
but not the repository
Bcc: junkio@cox.net
References: <20050723074219.GB3255@mythryan2.michonline.com>
From: Junio C Hamano <junio@twinsun.com>
Date: Sat, 23 Jul 2005 02:10:51 -0700
User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Ryan Anderson <ryan@michonline.com> writes:
> Add git-find-new-files to find files that are in the tree, but
> not checked into the repository.
You _ought_ to be able to just say:
$ git-ls-files --others --exclude-from=<exclude pattern file>
and be done with it. Also please see the thread about Cogito
and StGIT's use of .gitignore and .git/exclude files.
The current implementation of "git-ls-files" exclude mechanism
may have rooms for improvements; the last time I checked, it
only did the matching of patterns against filename without
leading directories). The world will be a better place if
somebody extends it, instead of working around its limitation.
I may be tempted to doing it myself, but I'm in the middle of
something else, so ...
> +# find . -name .git -type d -prune -o -type f -print \
> +# | grep -v -e .tree1 -e .tree2 \
> +# | sed -e "s/^\.\///" \
> +# | sort >.tree1
> +# git-ls-files | grep -v -e .tree1 -e .tree2 \
> +# | sort >.tree2
> +# diff -u .tree1 .tree2
It does not matter since the above is just an example and I
think you should be able to just use "ls-files --others", but
just FYI, you could have written "comm -23 .tree1 .tree2" above
instead of "diff -u".
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown)
@ 2005-05-28 14:15 Thomas Glanzmann
0 siblings, 0 replies; 256+ messages in thread
From: Thomas Glanzmann @ 2005-05-28 14:15 UTC (permalink / raw)
To: Linus Torvalds, GIT
diff-tree fb94d3e7fbe8e22201d8d015ed444d46485a3f76 (from 8310c2c0b585d3ac35a275f795e15fd9887e8b7d)
Author: Thomas Glanzmann <sithglan@stud.uni-erlangen.de>
Date: Sat May 28 16:13:22 2005 +0200
[PATCH] Document the --root switch of git-diff-tree
Signed-off-by: Thomas Glanzmann <sithglan@stud.uni-erlangen.de>
fb94d3e7fbe8e22201d8d015ed444d46485a3f76 (from 8310c2c0b585d3ac35a275f795e15fd9887e8b7d)
diff --git a/Documentation/git-diff-tree.txt b/Documentation/git-diff-tree.txt
--- a/Documentation/git-diff-tree.txt
+++ b/Documentation/git-diff-tree.txt
@@ -54,6 +54,11 @@ OPTIONS
-z::
\0 line termination on output
+--root::
+ When '--root' is specified the initial commit of a new file
+ will be showed as a big creation event. This is equivalent to
+ a diff against NULL.
+
--stdin::
When '--stdin' is specified, the command does not take
<tree-ish> arguments from the command line. Instead, it
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown)
@ 2005-04-26 19:14 Bram Cohen
0 siblings, 0 replies; 256+ messages in thread
From: Bram Cohen @ 2005-04-26 19:14 UTC (permalink / raw)
To: git
Linus Torvalds wrote:
> What you can do at an SCM level, is that if you want to track renames,
> you track them as a separate commit altogether. Ie if you notice a
> rename, you first commit the rename (and you can _see_ it's a rename,
> since the object didn't change, and the sha1 stayed the same, which in
> git-speak means that it is the same object, ie that _is_ a rename as far
> as git is concerned), and then you create the "this is the data that
> changed" as a _second_ commit.
If a rename and a modification happen at the same time, you'll now have a
point in the history which has the modification but not the rename, which
will probably be completely broken. If a file is deleted and two identical
copies of the file are made at the same time, no inference of renaming can
be made. And sometimes people really do delete one file and make a new
different file with initially identical contents, and this will break that
case.
> But don't make it a new kind of commit. It's just a regular commit,
> dammit. No new abstractions.
You did just introduce a new abstraction, it just happens to be of the 'if
I say X I really mean Y' type, which is far more semantically weighty,
tricky to implement, and on top of that is just plain a gross hack.
> Some "higher level" thing can add its own rules _on_top_ of git rules.
> The same way we have normal applications having their _own_ rules on top
> of the kernel. You do abstraction in layers, but for this to work, the
> base you build on top of had better be damn solid, and not have any ugly
> special cases.
What you're advocating is unclear here, but if you're advocating that the
higher-level system store extra meta-data, not included in git, then that
means the higher-level tools won't be able to interoperate by pointing at
the same git store. And it won't get rid of the problems of storing
information which git doesn't currently, it just makes them be handled by
different code. You can't make these problems go away by getting angry at
them.
I for one am all in favor of blessing Cogito as the 'real' git interface,
with plans to write upgrade scripts which canonically change the current
git format into a new format when upgrades become necessary. There are
already several version control systems with appropriate back end systems
which aren't literally weekend hacks. But you currently seem to be
insisting that such an upgrade will never be necessary, even while
insisting that git will support functionality which it can't.
-Bram
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2005-04-22 22:19 atani
0 siblings, 0 replies; 256+ messages in thread
From: atani @ 2005-04-22 22:19 UTC (permalink / raw)
To: GIT Mailing List
In my tests of using git (both Linus and pasky versions) I had a
problem with doing "gitadd.sh *" where * expands to include
directories. This simple patch allows update-cache.c to more
gracefully handle a directory being passed into the add_file_to_cache
method. Without this patch update-cache exits prematurely with an
error similar to:
-------------
fatal: Unable to add plx to database
-------------
Now it spits out:
-------------
'plx' is a directory, ignoring
-------------
Which from an end user stand point is better.
BTW, so far my tests of using git are positive for my small Dreamcast
software projects... I was previously using subversion but find it to
be a bit of overkill for these small projects.
Martin Schlemmer, I ran "emerge sync" today and found git has been
added to portage, version 0.5. Also note that there are now two "git"
entries within portage app-misc/git and dev-util/git. app-misc/git is
GNU Interactive Tools
Mike
Signed-off-by: Mike Dunston (atani@atani-software.net)
Index: update-cache.c
===================================================================
--- 690494557d393ca78f69a8569880ed4a3aeda276/update-cache.c
(mode:100644
sha1:4353b80890ba2afbe22248a4dc25060aa4a429b2)
+++ uncommitted/update-cache.c (mode:100644)
@@ -104,6 +104,11 @@
close(fd);
return -1;
}
+ if(S_ISDIR(st.st_mode)) {
+ printf("'%s' is a directory, ignoring\n", path);
+ close(fd);
+ return 0;
+ }
namelen = strlen(path);
size = cache_entry_size(namelen);
ce = malloc(size);
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2005-04-18 22:45 Matt W.
0 siblings, 0 replies; 256+ messages in thread
From: Matt W. @ 2005-04-18 22:45 UTC (permalink / raw)
To: git
majordomo@vger.kernel.org
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown)
@ 2005-04-16 0:51 Scott Wright
0 siblings, 0 replies; 256+ messages in thread
From: Scott Wright @ 2005-04-16 0:51 UTC (permalink / raw)
To: git
subscribe git
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown)
@ 2005-04-14 22:47 Timo Hirvonen
0 siblings, 0 replies; 256+ messages in thread
From: Timo Hirvonen @ 2005-04-14 22:47 UTC (permalink / raw)
subscribe git
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown)
@ 2005-04-14 22:43 Timo Hirvonen
0 siblings, 0 replies; 256+ messages in thread
From: Timo Hirvonen @ 2005-04-14 22:43 UTC (permalink / raw)
To: git
subscribe git
^ permalink raw reply [flat|nested] 256+ messages in thread
* (unknown),
@ 2005-04-14 22:30 Timo Hirvonen
0 siblings, 0 replies; 256+ messages in thread
From: Timo Hirvonen @ 2005-04-14 22:30 UTC (permalink / raw)
To: git
subscribe git
^ permalink raw reply [flat|nested] 256+ messages in thread
end of thread, other threads:[~2016-06-16 4:55 UTC | newest]
Thread overview: 256+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-05-23 19:30 [RFC-PATCH 0/2] send-email: new --quote-mail option Tom Russello
2016-05-23 19:30 ` [RFC-PATCH 1/2] send-email: new option to quote an email and reply to Tom Russello
2016-05-23 19:55 ` Eric Wong
2016-05-23 20:07 ` Matthieu Moy
2016-05-23 22:10 ` Samuel GROOT
2016-05-24 12:43 ` Samuel GROOT
2016-05-24 12:49 ` Matthieu Moy
2016-05-24 22:30 ` Aaron Schrab
2016-05-25 0:04 ` Tom Russello
2016-05-24 21:23 ` Eric Wong
2016-05-23 20:00 ` Matthieu Moy
2016-05-24 23:31 ` Samuel GROOT
2016-05-25 6:29 ` Matthieu Moy
2016-05-25 15:40 ` Junio C Hamano
2016-05-25 16:56 ` Matthieu Moy
2016-05-25 18:15 ` Junio C Hamano
2016-05-25 18:31 ` Matthieu Moy
2016-05-26 0:08 ` Samuel GROOT
2016-05-27 9:06 ` Matthieu Moy
2016-05-23 19:30 ` [RFC-PATCH 2/2] t9001: adding --quote-mail option test Tom Russello
2016-05-23 20:05 ` Matthieu Moy
2016-05-23 19:38 ` [RFC-PATCH 0/2] send-email: new --quote-mail option Matthieu Moy
2016-05-23 19:56 ` Samuel GROOT
2016-05-27 17:11 ` [RFC-PATCH v2 0/2] send-email: new --quote-email option Tom Russello
2016-05-27 17:11 ` [RFC-PATCH v2 1/2] send-email: quote-email populates the fields Tom Russello
2016-05-28 14:35 ` Matthieu Moy
2016-05-29 23:38 ` Tom Russello
2016-05-27 17:11 ` [RFC-PATCH v2 2/2] send-email: quote-email quotes the message body Tom Russello
2016-05-28 15:01 ` Matthieu Moy
2016-05-29 11:41 ` Tom Russello
2016-06-07 14:01 ` [PATCH v3 0/6] send-email: cleaner tests and quote email Tom Russello
2016-06-07 14:01 ` [PATCH v3 1/6] t9001: non order-sensitive file comparison Tom Russello
2016-06-08 1:07 ` Junio C Hamano
2016-06-08 8:23 ` Samuel GROOT
2016-06-08 16:09 ` Junio C Hamano
2016-06-08 16:46 ` Samuel GROOT
2016-06-09 6:01 ` Matthieu Moy
2016-06-13 22:21 ` Samuel GROOT
2016-06-09 5:51 ` Matthieu Moy
2016-06-09 8:15 ` Tom Russello
2016-06-07 14:01 ` [PATCH v3 2/6] t9001: check email address is in Cc: field Tom Russello
2016-06-09 5:55 ` Matthieu Moy
2016-06-13 22:23 ` Samuel GROOT
2016-06-07 14:01 ` [PATCH v3 3/6] t9001: shorten send-email's output Tom Russello
2016-06-08 8:36 ` Eric Wong
2016-06-08 9:30 ` Samuel GROOT
2016-06-09 6:03 ` Matthieu Moy
2016-06-07 14:01 ` [PATCH v3 4/6] send-email: create email parser subroutine Tom Russello
2016-06-07 14:05 ` [PATCH v3 5/6] send-email: --in-reply-to=<file> populates the fields Tom Russello
2016-06-07 14:05 ` [PATCH v3 6/6] send-email: add option --cite to quote the message body Tom Russello
2016-06-08 13:01 ` (unknown), Samuel GROOT
2016-06-08 13:01 ` [PATCH v4 1/6] t9001: non order-sensitive file comparison Samuel GROOT
2016-06-08 14:22 ` Remi Galan Alfonso
2016-06-08 14:29 ` Samuel GROOT
2016-06-08 16:56 ` Junio C Hamano
2016-06-08 19:21 ` Samuel GROOT
2016-06-08 17:17 ` Junio C Hamano
2016-06-08 19:19 ` Samuel GROOT
2016-06-08 13:01 ` [PATCH v4 2/6] t9001: check email address is in Cc: field Samuel GROOT
2016-06-08 17:34 ` Junio C Hamano
2016-06-08 19:23 ` Samuel GROOT
2016-06-08 13:01 ` [PATCH v4 3/6] send-email: shorten send-email's output Samuel GROOT
2016-06-08 17:37 ` Junio C Hamano
2016-06-08 19:18 ` Samuel GROOT
2016-06-08 19:33 ` Junio C Hamano
2016-06-08 19:40 ` Samuel GROOT
2016-06-09 6:17 ` Matthieu Moy
2016-06-13 22:19 ` Samuel GROOT
2016-06-08 13:01 ` [PATCH v4 4/6] send-email: create email parser subroutine Samuel GROOT
2016-06-08 17:58 ` Junio C Hamano
2016-06-08 18:12 ` Eric Sunshine
2016-06-08 18:32 ` Junio C Hamano
2016-06-08 19:26 ` Samuel GROOT
2016-06-08 19:31 ` Junio C Hamano
2016-06-08 19:42 ` Samuel GROOT
2016-06-08 19:30 ` Samuel GROOT
2016-06-08 20:13 ` Eric Sunshine
2016-06-08 20:17 ` Junio C Hamano
2016-06-08 23:54 ` Samuel GROOT
2016-06-09 0:21 ` Eric Wong
2016-06-13 22:18 ` Samuel GROOT
2016-06-13 22:47 ` Eric Wong
2016-06-14 22:18 ` Samuel GROOT
2016-06-09 6:51 ` Eric Sunshine
2016-06-13 22:15 ` Samuel GROOT
2016-06-08 19:36 ` Samuel GROOT
2016-06-08 20:38 ` Eric Wong
2016-06-08 13:07 ` [PATCH v4 5/6] send-email: --in-reply-to=<file> populate header fields Samuel GROOT
2016-06-08 18:23 ` Junio C Hamano
2016-06-14 22:26 ` Samuel GROOT
2016-06-09 9:45 ` Matthieu Moy
2016-06-14 22:35 ` Samuel GROOT
2016-06-08 13:08 ` [PATCH v4 6/6] send-email: add option --cite to quote the message body Samuel GROOT
2016-06-09 11:49 ` Matthieu Moy
2016-06-14 22:53 ` Samuel GROOT
2016-06-15 22:21 ` Tom Russello
-- strict thread matches above, loose matches on Subject: below --
2016-06-16 3:54 (unknown) 岸洋介
2016-06-12 9:38 (unknown), Financial Service
2016-05-16 15:58 (unknown), Nathan Wendt
2016-04-11 19:04 (unknown), miwilliams
2016-04-11 16:02 (unknown) Michael S. Tsirkin
2016-03-28 13:38 (unknown), ratheesh kannoth
2015-12-16 3:02 (unknown), David Greene
2015-12-16 5:57 ` (unknown) Junio C Hamano
2015-12-16 8:44 ` (unknown) Patrick Steinhardt
2015-12-18 17:35 ` (unknown) David Greene
2015-12-14 13:14 (unknown) Ros Sothen
2015-11-06 3:34 (unknown), David Greene
2015-09-28 17:55 (unknown), Kosta Zertsekel
2015-09-19 10:58 (unknown), 戸島達哉
2015-09-01 2:13 (unknown), David Turner
2015-08-05 12:47 (unknown) Ivan Chernyavsky
2015-05-12 12:38 (unknown), Varis Van Rob
2015-05-11 17:56 (unknown), dturner
2015-04-08 20:44 (unknown), Mamta Upadhyay
2015-03-13 1:34 (unknown) cody.taylor
2015-02-25 8:53 (unknown) stefan leijen
2015-02-17 18:14 [PATCH] read-cache.c: free cache entry when refreshing fails Junio C Hamano
2015-02-17 18:27 ` (unknown), Stefan Beller
2015-01-12 20:59 (unknown), امير الاحزان
2014-10-30 12:23 (unknown), Fedor Eftimitsa
2014-09-28 10:51 (unknown) bambecapuno06
2014-09-08 11:36 (unknown), R. Klomp
2014-08-26 11:16 (unknown), mail
2014-07-15 16:31 (unknown), Woody Wu
2014-06-17 17:13 (unknown), David Turner
2014-06-01 21:24 (unknown), C. Benson Manica
2014-05-22 22:35 (unknown), Mrs. Jiang Ming
2014-04-19 14:27 (unknown), Siegel, Suzan
2014-03-19 0:45 (unknown) szager
2014-03-05 8:43 (unknown) Stephanie Bennett
2014-02-20 0:55 (unknown) Bozhidar Bozhev
2013-12-18 14:09 (unknown) Maxime Coste
2013-08-07 12:54 (unknown), a a
2013-05-25 3:57 (unknown), Kirill Berezin
2013-05-20 9:58 [PATCH 0/6] t5000: add test for pax extended header generation René Scharfe
2013-05-20 9:58 ` [PATCH 6/6] t5000: test long filenames René Scharfe
2013-05-20 19:55 ` Eric Sunshine
[not found] ` <CAPig+cTitT9Z+2pxeNh3dXi4b7X738qpkUnEmTi2yvQoCPtHqA@mail.g mail.com>
2013-05-20 20:01 ` (unknown), Marty Landman
2013-05-17 18:02 (unknown), ASHISH VERMA
2012-12-28 16:43 (unknown) Eric S. Raymond
2012-12-28 19:33 ` (unknown) Junio C Hamano
2012-10-17 12:16 (unknown), Marco Siegl | buerosiegl.com
2012-06-12 21:12 (unknown), rohit sood
2012-05-06 14:17 (unknown), Bruce Zu
2012-05-06 14:13 (unknown), Bruce Zu
2012-05-06 13:54 (unknown), Bruce Zu
2012-03-13 12:18 (unknown), Adam Kicak
2012-02-15 3:12 (unknown), Chris Leong
2012-02-09 23:58 (unknown), Zbigniew Jędrzejewski-Szmek
2012-02-08 0:41 (unknown), mstormo
2012-02-05 20:41 [PATCH] Change include order in two compat/ files to avoid compiler warning Junio C Hamano
2012-02-05 22:32 ` (unknown), Ben Walton
2012-01-10 23:56 (unknown), Steven Line
2011-11-10 22:56 (unknown), Marcel Schaible
2011-11-02 16:38 (unknown), Ben Walton
2011-08-18 6:36 (unknown) milki
2011-08-04 17:27 (unknown) Hin-Tak Leung
2011-05-26 9:02 (unknown) Nicole Hamilt
2011-02-02 17:31 (unknown), Kamol Siesan
2010-12-28 22:56 (unknown), COCA COLA
2010-12-27 6:07 (unknown), COCA COLA
2010-09-20 16:37 (unknown), Leonid Podolny
2010-09-17 18:39 (unknown), Michael Scholl
2010-05-07 21:46 (unknown), Mr Chen Guan
2010-05-07 21:46 (unknown), Mr Chen Guan
2010-05-07 21:46 (unknown), Mr Chen Guan
2010-03-25 5:53 (unknown) выгнать
2010-03-19 21:12 (unknown), Michael Cox
2010-03-08 21:56 (unknown) Timur Aydin
2010-02-25 5:55 (unknown), yingshou guo
2010-01-22 2:14 (unknown), Horst H. von Brand
2009-09-12 13:00 (unknown) Tito
2009-07-24 21:21 [PATCH 0/2] Section renaming can lose content Alex Vandiver
2009-07-24 21:21 ` [PATCH 1/2] Make section_name_match start on '[', and return the length on success Alex Vandiver
2009-07-24 21:21 ` [PATCH 2/2] After renaming a section, print any trailing variable definitions Alex Vandiver
2009-07-24 22:11 ` Nanako Shiraishi
2009-07-24 23:39 ` Junio C Hamano
2009-07-25 0:28 ` (unknown), Nanako Shiraishi
2009-07-16 19:22 (unknown) Henrik Austad
2009-06-23 1:07 (unknown) Larry D'Anna
2009-05-27 13:28 (unknown), David Forman
2009-05-13 5:11 (unknown), Tom H
2009-05-11 18:57 (unknown) Don Slutz
2009-05-11 18:57 (unknown) Don Slutz
2009-05-11 18:57 (unknown) Don Slutz
2009-05-11 18:57 (unknown) Don Slutz
2009-05-11 18:57 (unknown) Don Slutz
2009-05-11 18:57 (unknown) Don Slutz
2009-05-11 18:57 (unknown) Don Slutz
2009-05-10 22:48 [JGIT PATCH 1/2] Fix deadlock in native git protocol client for upload-pack Shawn O. Pearce
2009-05-10 22:48 ` [JGIT PATCH 2/2] Decrease the fetch pack client buffer to the lower minimum Shawn O. Pearce
2009-05-11 0:43 ` Junio C Hamano
2009-05-11 0:55 ` Shawn O. Pearce
2009-05-11 3:51 ` Junio C Hamano
2009-05-11 14:10 ` Shawn O. Pearce
2009-05-11 14:23 ` (unknown), Carl Mercier
2009-05-07 17:01 (unknown), Bevan Watkiss
2009-04-16 23:17 (unknown), Fawad Hassan Ismail
2009-03-30 5:03 (unknown), David Aguilar
2009-03-27 20:39 (unknown), Lachlan Deck
2009-03-16 19:06 undoing something John Dlugosz
2009-03-16 19:14 ` Junio C Hamano
2009-03-16 19:48 ` John Dlugosz
2009-03-16 21:45 ` (unknown), Nanako Shiraishi
2009-03-13 8:21 (unknown) Werner Riener
2009-02-06 9:45 (unknown), info
2009-02-06 9:43 (unknown), info
2009-01-09 19:02 (unknown) nathan.panike
2008-10-05 23:36 (unknown), Robin Rosenberg
2008-08-21 19:15 (unknown) bpeeluk
2008-08-13 14:54 (unknown), aneesh.kumar
2008-06-23 20:54 (unknown), VIP Casino Club
2008-06-16 20:02 (unknown) amery
2008-06-16 19:42 (unknown) amery
2008-05-10 22:32 (unknown), Krzysztof Kowalczyk
2008-01-20 21:59 (unknown), Marc-André Lureau
2007-12-05 19:00 [PATCH 0/6] builtin-remote Johannes Schindelin
2007-12-05 19:00 ` (unknown) Johannes Schindelin
2007-11-26 20:00 (unknown) Michael Dressel
2007-11-11 13:08 (unknown) Michael Dressel
2007-11-01 20:44 (unknown), Francesco Pretto
2007-11-01 14:23 (unknown) Heikki Orsila
2007-10-22 18:16 (unknown) racin
2007-10-13 4:01 (unknown), Michael Witten
2007-09-04 13:59 (unknown) Russ Brown
2007-08-19 22:04 (unknown) Luciano Rocha
2007-07-01 18:25 (unknown) Sean D'Epagnier
2007-06-13 0:50 [PATCH] Interpret :/<pattern> as a regular expression Johannes Schindelin
2007-06-13 4:52 ` Junio C Hamano
2007-06-13 11:17 ` (unknown) Johannes Schindelin
2007-06-03 15:30 (unknown) Randal L. Schwartz
2007-05-06 3:51 (unknown), Aaron Gray
2007-04-04 16:59 (unknown) Geert Bosch
2007-03-18 9:36 [wishlist] git branch -d -r remotename Sam Vilain
2007-03-18 11:01 ` Sam Vilain
2007-03-18 11:01 ` Sam Vilain
2007-03-18 19:42 ` Junio C Hamano
2007-03-18 21:46 ` Sam Vilain
2007-03-19 6:18 ` Junio C Hamano
2007-03-19 6:40 ` Junio C Hamano
2007-03-19 23:37 ` (unknown) Sam Vilain
2006-11-21 22:24 (unknown) Johannes Schindelin
2006-10-25 14:50 (unknown) andyparkins
2006-10-25 14:49 (unknown) andyparkins
2006-10-25 18:41 ` (unknown) Junio C Hamano
2006-10-25 14:49 (unknown) andyparkins
2006-10-25 14:47 (unknown) andyparkins
2006-10-25 14:53 ` (unknown) Jakub Narebski
2006-10-25 15:10 ` (unknown) Andy Parkins
2006-10-25 15:31 ` (unknown) Karl Hasselström
2006-10-25 18:38 ` (unknown) Junio C Hamano
2006-10-25 22:03 ` (unknown) Andy Parkins
2006-10-25 22:16 ` (unknown) Junio C Hamano
2006-10-25 22:20 ` (unknown) Junio C Hamano
2006-10-26 7:14 ` (unknown) Andy Parkins
2006-10-26 13:22 ` (unknown) Josef Weidendorfer
2006-10-26 15:35 ` (unknown) Linus Torvalds
2006-10-25 22:16 ` (unknown) Shawn Pearce
2006-10-20 14:24 (unknown) andyparkins
2006-10-20 14:24 (unknown) andyparkins
2006-10-20 14:21 (unknown) andyparkins
2006-10-20 13:25 (unknown) andyparkins
2006-10-05 1:54 (unknown), JOSEPH KULIG
2006-09-24 21:55 (unknown) sonny132390
2006-09-21 4:04 (unknown) Nicolas Pitre
2006-09-09 21:46 (unknown), Rajkumar S
2006-08-18 10:35 (unknown), Wolfgang Denk
2006-07-01 15:33 (unknown), Mark
2006-05-26 15:16 (unknown) Juergen Ruehle
2006-05-21 23:53 (unknown) J. Bruce Fields
2006-05-21 23:53 ` (unknown) J. Bruce Fields
2006-05-21 23:53 ` (unknown) J. Bruce Fields
2006-03-28 19:31 (unknown) CustomerDepartament
2006-01-30 18:50 (unknown) Mark Wooding
2005-10-05 6:10 (unknown), Willem Swart
2005-07-23 9:10 (unknown) Junio Hamano
2005-05-28 14:15 (unknown) Thomas Glanzmann
2005-04-26 19:14 (unknown) Bram Cohen
2005-04-22 22:19 (unknown), atani
2005-04-18 22:45 (unknown), Matt W.
2005-04-16 0:51 (unknown) Scott Wright
2005-04-14 22:47 (unknown) Timo Hirvonen
2005-04-14 22:43 (unknown) Timo Hirvonen
2005-04-14 22:30 (unknown), Timo Hirvonen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).