[PATCH v2] Enable setting attach as the default in .gitconfig for git-format-patch.

[PATCH v2] Enable setting attach as the default in .gitconfig for git-format-patch.

[Jeremy White]

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


Signed-off-by: Jeremy White <jwhite@codeweavers.com>
---
  Documentation/git-format-patch.txt |    4 +++-
  builtin-log.c                      |   15 +++++++++++++++
  2 files changed, 18 insertions(+), 1 deletions(-)



[-- Attachment #2: 7ed4bdd60ca12e71e1438defefbf83075b39a60b.diff --]
[-- Type: text/x-patch, Size: 1864 bytes --]

diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index 11a7d77..2e8e94e 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -174,7 +174,8 @@ CONFIGURATION
 -------------
 You can specify extra mail header lines to be added to each message
 in the repository configuration, new defaults for the subject prefix
-and file suffix, and number patches when outputting more than one.
+and file suffix, control attachements, and number patches when outputting
+more than one.
 
 ------------
 [format]
@@ -183,6 +184,7 @@ and file suffix, and number patches when outputting more than one.
 	suffix = .txt
 	numbered = auto
 	cc = <email>
+	attach [ = mime-boundary-string ]
 ------------
 
 
diff --git a/builtin-log.c b/builtin-log.c
index 2ae39af..c79895c 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -428,6 +428,8 @@ static const char *fmt_patch_suffix = ".patch";
 static int numbered = 0;
 static int auto_number = 1;
 
+static char *default_attach = NULL;
+
 static char **extra_hdr;
 static int extra_hdr_nr;
 static int extra_hdr_alloc;
@@ -488,6 +490,14 @@ static int git_format_config(const char *var, const char *value, void *cb)
 		auto_number = auto_number && numbered;
 		return 0;
 	}
+	if (!strcmp(var, "format.attach")) {
+		if (value && *value)
+			default_attach = xstrdup(value);
+		else
+			default_attach = xstrdup(git_version_string);
+		return 0;
+	}
+
 
 	return git_log_config(var, value, cb);
 }
@@ -787,6 +797,11 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
 
 	rev.subject_prefix = fmt_patch_subject_prefix;
 
+	if (default_attach) {
+		rev.mime_boundary = default_attach;
+		rev.no_inline = 1;
+	}
+
 	/*
 	 * Parse the arguments before setup_revisions(), or something
 	 * like "git format-patch -o a123 HEAD^.." may fail; a123 is

Re: [PATCH v2] Enable setting attach as the default in .gitconfig for git-format-patch.

[Boyd Stephen Smith Jr.]

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

For a minor style issue, see my reply to your original patch.

Also, please read Documentation/SubmittingPatches.  Particularly, the third 
point under the "Patch" heading on the first page.  Also, since you appear to 
sympathize with Thunderbird users you might want to read the "Thunderbird" 
section, and either improve it or petition the developers to make the 
application more amenable to users needs in this case.
-- 
Boyd Stephen Smith Jr.                   ,= ,-_-. =.
bss@iguanasuicide.net                   ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy         `-'(. .)`-'
http://iguanasuicide.net/                    \_/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH v2] Enable setting attach as the default in .gitconfig for git-format-patch.

[Jeremy White]

Boyd Stephen Smith Jr. wrote:
> For a minor style issue, see my reply to your original patch.

Sure, thanks.

> 
> Also, please read Documentation/SubmittingPatches.  Particularly, the third 
> point under the "Patch" heading on the first page.  Also, since you appear to 
> sympathize with Thunderbird users you might want to read the "Thunderbird" 
> section, and either improve it or petition the developers to make the 
> application more amenable to users needs in this case.

Sorry about that; I allowed my pleasure at the cuteness of using my own
patch to send the patch override the requested courtesy of this list.

As an aside, there is a long (and discouraging) read about the issue
with Thunderbird here:
  https://bugzilla.mozilla.org/show_bug.cgi?id=141983

Essentially, the problem is well understood - Thunderbird uses
format=flowed by default, which is what mangles the patches.  The author
of the relevant code is unmoved by arguments that the default should
switch, and no one has yet been willing to create a simpler UI for
switching the setting.

Cheers,

Jeremy

Re: [PATCH v2] Enable setting attach as the default in .gitconfig for git-format-patch.

[Johannes Schindelin]

Hi,

On Sun, 8 Feb 2009, Jeremy White wrote:

> As an aside, there is a long (and discouraging) read about the issue
> with Thunderbird here:
>   https://bugzilla.mozilla.org/show_bug.cgi?id=141983
> 
> Essentially, the problem is well understood - Thunderbird uses
> format=flowed by default, which is what mangles the patches.  The author
> of the relevant code is unmoved by arguments that the default should
> switch, and no one has yet been willing to create a simpler UI for
> switching the setting.

I guess I'll start discouraging use of Thunderbird from now on.  Seems 
that not even the opposition of a guy named Andrew Morton was clue bat 
enough.

Ciao,
Dscho

Re: [PATCH v2] Enable setting attach as the default in .gitconfig for git-format-patch.

[Michael J Gruber]

Johannes Schindelin venit, vidit, dixit 08.02.2009 18:28:
> Hi,
> 
> On Sun, 8 Feb 2009, Jeremy White wrote:
> 
>> As an aside, there is a long (and discouraging) read about the issue
>> with Thunderbird here:
>>   https://bugzilla.mozilla.org/show_bug.cgi?id=141983
>>
>> Essentially, the problem is well understood - Thunderbird uses
>> format=flowed by default, which is what mangles the patches.  The author
>> of the relevant code is unmoved by arguments that the default should
>> switch, and no one has yet been willing to create a simpler UI for
>> switching the setting.
> 
> I guess I'll start discouraging use of Thunderbird from now on. 

...specifically for patch submission, please ;)
I'm a TB user who compiles the beast and writes extensions for it, and
yet I found git-send-email the more reliable and practical solution for
sending out patches. Put yourself in bcc and you'll have a copy in TB's
inbox or another folder (use filters).

> Seems 
> that not even the opposition of a guy named Andrew Morton was clue bat 
> enough.

<sarcasm style="reality: exaggerated;">
Isn't that some Linux guy? How would he matter for Mozilla? Does he even
know how to send HTML mail...
</sarcasm>

Michael

Re: [PATCH v2] Enable setting attach as the default in .gitconfig for git-format-patch.

[Ben Bucksch]

On 09.02.2009 13:34, Michael J Gruber wrote:
> Johannes Schindelin venit, vidit, dixit 08.02.2009 18:28:
>    
>> On Sun, 8 Feb 2009, Jeremy White wrote
>>> Essentially, the problem is well understood - Thunderbird uses
>>> format=flowed by default, which is what mangles the patches.
>>>        
>> I guess I'll start discouraging use of Thunderbird from now on.

Or you could just publish:
1. Prefs | Advanced | General | Config Editor...
2. "mailnews.send_plaintext_flowed" = false

The defaults should be best for the average user, not the rare 
programmer, who has no problem changing prefs.

f=f helps the normal user (and more importantly his recipient) by 
properly flowing text, which allows me to read with line lengths which 
are comfortable to read for me. It harms only in rare cases where 
line-endings are very important, *but* are not explicitly marked so. I 
think you can switch to "preformat" in the HTML editor and it would 
work, because we then know it's not flowing text, but I haven't tried 
it, because I attach such documents as txt / diff files.

As inline attachments, they'll show up inline in the msg viewer as well 
(which means I can read and copy&paste them), but are clearly separated 
from the body (which is assumed to be human-created natural language 
text), avoiding the problem mentioned here, and can easily be saved as 
file, opened in an external app etc.. I don't know why you didn't choose 
that way, but I assume you had your reasons. Just as we had our reasons 
for choosing f=f.

> I found git-send-email the more reliable and practical solution for 
> sending out patches. Put yourself in bcc and you'll have a copy in 
> TB's inbox or another folder (use filters).

Yup, I think that's the best way - git is using email only as protocol, 
so it's good to have special clients to that, as it's a really special use.

> <sarcasm style="reality: exaggerated;">
> Isn't that some Linux guy? How would he matter for Mozilla? Does he even
> know how to send HTML mail...
> </sarcasm>
>    
I don't think it's a matter of clue, it's a matter of background and 
attitude.

Ben

Re: [PATCH v2] Enable setting attach as the default in .gitconfig for git-format-patch.

[Johannes Schindelin]

Hi,

On Mon, 9 Feb 2009, Ben Bucksch wrote:

> On 09.02.2009 13:34, Michael J Gruber wrote:
> > Johannes Schindelin venit, vidit, dixit 08.02.2009 18:28:
> >    
> > > On Sun, 8 Feb 2009, Jeremy White wrote
> > > > Essentially, the problem is well understood - Thunderbird uses
> > > > format=flowed by default, which is what mangles the patches.
> > > >        
> > > I guess I'll start discouraging use of Thunderbird from now on.
> 
> Or you could just publish:
> 1. Prefs | Advanced | General | Config Editor...
> 2. "mailnews.send_plaintext_flowed" = false

Ah.  Mhm...

> As inline attachments, they'll show up inline in the msg viewer as well 

... which is a moot point, as the responder has to do extra work to quote 
the stuff.  Definitely not my type of friendliness.

> > I found git-send-email the more reliable and practical solution for 
> > sending out patches. Put yourself in bcc and you'll have a copy in 
> > TB's inbox or another folder (use filters).
> 
> Yup, I think that's the best way - git is using email only as protocol, so
> it's good to have special clients to that, as it's a really special use.

Aha.  And putting extra comments in (manually) does not count.  'cause I 
do not see send-email allowing that.

> > <sarcasm style="reality: exaggerated;">
> > Isn't that some Linux guy? How would he matter for Mozilla? Does he even
> > know how to send HTML mail...
> > </sarcasm>
> >    
>
> I don't think it's a matter of clue, it's a matter of background and 
> attitude.

Yeah, I think my background dictates that I stay by my word and recommend 
other mailers than Thunderbird.

It is one thing to be nice to the "average" user, but another one to be 
unfriendly to the people making the internet revolution possible.

Ciao,
Dscho

Re: [PATCH v2] Enable setting attach as the default in .gitconfig for git-format-patch.

[Michael J Gruber]

Johannes Schindelin venit, vidit, dixit 09.02.2009 14:36:
> Hi,
> 
> On Mon, 9 Feb 2009, Ben Bucksch wrote:
> 
>> On 09.02.2009 13:34, Michael J Gruber wrote:
>>> Johannes Schindelin venit, vidit, dixit 08.02.2009 18:28:
>>>    
>>>> On Sun, 8 Feb 2009, Jeremy White wrote
>>>>> Essentially, the problem is well understood - Thunderbird uses
>>>>> format=flowed by default, which is what mangles the patches.
>>>>>        
>>>> I guess I'll start discouraging use of Thunderbird from now on.
>> Or you could just publish:
>> 1. Prefs | Advanced | General | Config Editor...
>> 2. "mailnews.send_plaintext_flowed" = false
> 
> Ah.  Mhm...
> 
>> As inline attachments, they'll show up inline in the msg viewer as well 
> 
> ... which is a moot point, as the responder has to do extra work to quote 
> the stuff.  Definitely not my type of friendliness.
> 
>>> I found git-send-email the more reliable and practical solution for 
>>> sending out patches. Put yourself in bcc and you'll have a copy in 
>>> TB's inbox or another folder (use filters).
>> Yup, I think that's the best way - git is using email only as protocol, so
>> it's good to have special clients to that, as it's a really special use.
> 
> Aha.  And putting extra comments in (manually) does not count.  'cause I 
> do not see send-email allowing that.

There is this useful thingy called "vim" which lets you edit the 00*
files... Come on, Dscho ;)

>>> <sarcasm style="reality: exaggerated;">
>>> Isn't that some Linux guy? How would he matter for Mozilla? Does he even
>>> know how to send HTML mail...
>>> </sarcasm>
>>>    
>> I don't think it's a matter of clue, it's a matter of background and 
>> attitude.
> 
> Yeah, I think my background dictates that I stay by my word and recommend 
> other mailers than Thunderbird.
> 
> It is one thing to be nice to the "average" user, but another one to be 
> unfriendly to the people making the internet revolution possible.

I think Ben made it clear why "format flowed" is the default, and there
are numerous posts in the TB/moz community which make it clear why they
spell it "format flawed".  The default will not change.

I thought about writing an extension which let's you change the config
on a per message basis. (You can already do it per folder using mnenhy,
I suppose.) But then I still have to navigate from TB to my repo and
include the output of git-format-patch, or dump it to an mbox (or upload
to an imap drafts folder).

So, even with f-f issues out of the way I would find git-send-email
(+vim) to be the right tool for the job. Which is why I use it, for
sending patches by e-mail, not for corresponding by e-mail.

So, let's be peaceful, and talk about Mozilla's choice of hg instead ;)
[No, please don't!]

Michael

Re: [PATCH v2] Enable setting attach as the default in .gitconfig for git-format-patch.

[Boyd Stephen Smith Jr.]

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

On Monday 09 February 2009 07:50:09 Michael J Gruber wrote:
> Johannes Schindelin venit, vidit, dixit 09.02.2009 14:36:
> > On Mon, 9 Feb 2009, Ben Bucksch wrote:
> >> On 09.02.2009 13:34, Michael J Gruber wrote:
> >>> Johannes Schindelin venit, vidit, dixit 08.02.2009 18:28:
> >>>> On Sun, 8 Feb 2009, Jeremy White wrote
> >>>>> Essentially, the problem is well understood - Thunderbird uses
> >>>>> format=flowed by default, which is what mangles the patches.
> >>>> I guess I'll start discouraging use of Thunderbird from now on.
> >> Or you could just publish:
> >> 1. Prefs | Advanced | General | Config Editor...
> >> 2. "mailnews.send_plaintext_flowed" = false
> > Ah.  Mhm...
> >> I don't think it's a matter of clue, it's a matter of background and
> >> attitude.
> > Yeah, I think my background dictates that I stay by my word and recommend
> > other mailers than Thunderbird.
> I think Ben made it clear why "format flowed" is the default.
> The default will not change.

For the record, KMail does f=f by default, too.  And I think any client that 
doesn't do format=flowed by default it probably doing a disservice to it's 
users.  Luckily, in KMail it is easy to turn off for a particular message with 
"Options -> Word Wrap" in the composer window.  I think you can turn it off 
globally, but patches aren't a big enough part of my workflow that I've 
investigated it too much.
-- 
Boyd Stephen Smith Jr.                   ,= ,-_-. =.
bss@iguanasuicide.net                   ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy         `-'(. .)`-'
http://iguanasuicide.net/                    \_/



[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH v2] Enable setting attach as the default in .gitconfig for git-format-patch.

[Ben Bucksch]

On 09.02.2009 14:36, Johannes Schindelin wrote:
> On Mon, 9 Feb 2009, Ben Bucksch wrote:
>    
>> Or you could just publish:
>> 1. Prefs | Advanced | General | Config Editor...
>> 2. "mailnews.send_plaintext_flowed" = false
>>      
> Ah.  Mhm...
>    
>> As inline attachments, they'll show up inline in the msg viewer as well
>>      
> ... which is a moot point, as the responder has to do extra work to quote
> the stuff.  Definitely not my type of friendliness.

In newer Thunderbirds, you can mark / select a text, and when you hit 
reply, it (and only that) will be quoted - called selective quote. You 
can press Ctrl-A (for Select All) before hitting reply, and the inline 
attachment will be included in the quote.

> I stay by my word and recommend other mailers than Thunderbird.
>    

Please be sure to also cite the pref change I mentioned above as 
alternative.

<diversion>
> It is one thing to be nice to the "average" user, but another one to be
> unfriendly to the people making the internet revolution possible.
>    
Hey now!

I hope you realize that Netscape / Mozilla had a really important role 
in making the Internet popular in the public in the first place (the 
alternatives were AOL and CompuServe back then), and that Mozilla is 
*the* most-used Open Source application. In fact, Firefox' market share 
on Windows made a large contribution to Linux, by convincing web sites 
authors to not assume IE, which is a big reason why Linux is usable at 
all. Imagine the web or email was only usable with IE or Outlook...
</diversion>

I use Linux myself everywhere, and recommend it to many people, and I 
think it's technically excellent.

BTW: I want to use this occasion to thank all you Linux programmers for 
your awesome, technically superiour work. Thanks a lot, and keep it up! :-)

Ben

Re: [PATCH v2] Enable setting attach as the default in .gitconfig for git-format-patch.

[Johannes Schindelin]

Hi,

On Mon, 9 Feb 2009, Ben Bucksch wrote:

> In newer Thunderbirds, you can mark / select a text, and when you hit reply,
> it (and only that) will be quoted - called selective quote.

Which would require the _recipient_ to choose Thunderbird, newer ones, as 
their mail program.

Hey, it is a free world, I like Firefox, for example, and you would have 
to rip it out of my dead, cold hands.

I just do not care for Thunderbird, I started using pine a long time 
ago, too long to change now, but that is just my choice, I guess.

It's just for that really important workflow -- sending patches as easily 
commentable text that still works as input to GNU patch or git-apply -- 
that I will recommend against using Thunderbird, as there are other 
mailers which can do it without much clickety-click.

BTW in contrast to other people, I do not feel insulted that you chose Hg 
for Mozilla; as I said, it is a free world (as long as we can keep it that 
way, at least).

Ciao,
Dscho

Thunderbird and patches (was Re: [PATCH v2] Enable setting attach as the default in .gitconfig for git-format-patch.)

[Jeremy White]

> Yeah, I think my background dictates that I stay by my word and recommend 
> other mailers than Thunderbird.
> 
> It is one thing to be nice to the "average" user, but another one to be 
> unfriendly to the people making the internet revolution possible.

Gah!  With all due respect, I think this attitude is a part of the problem.

It is clear to me that Ben and all the Thunderbird devs are doing their level
best to make the best possible MUA.

Patch senders are a tiny fraction of the Thunderbird user base, and it's
reasonable to down prioritize our concerns.  Even so, Ben has spent a lot of time
on this issue.   One of my great frustrations on the bug I copied was that 
I thought that Robin was articulating some valid points, but then couldn't 
help flaming on, thereby making it much harder for any human Mozilla dev to want to help.

I'd like to hope that there is a reasonable solution that 
works both for us and for the general public.

I spent some time with the git-format-patch code as well as the Thunderbird
code.  I discovered that if I just injected charset=iso-2022-jp, format=flowed
would stay off! <grin>

Ben, along those lines, we do have the ability to control the entire
body of a possible patch before Thunderbird sees it.  Would it be possible,
or reasonable, for Thunderbird to look for and preserve a 'format=fixed'
setting inside a body that we generated?

Cheers,

Jeremy

Re: Thunderbird and patches (was Re: [PATCH v2] Enable setting attach as the default in .gitconfig for git-format-patch.)

[Ben Bucksch]

On 09.02.2009 14:52, Jeremy White wrote:
> I discovered that if I just injected charset=iso-2022-jp, format=flowed
> would stay off!<grin>
>    
(This was a hack, caused by the different use of spaces in Japanese / 
CJK, which means a different kind of "flow".)

> Ben, along those lines, we do have the ability to control the entire 
> body of a possible patch before Thunderbird sees it. Would it be 
> possible, or reasonable, for Thunderbird to look for and preserve a 
> 'format=fixed' setting inside a body that we generated?

I don't know how you're injecting the email to Thunderbird. mailto:?

What you propose is a header, not a body.
(I'm a bit irritated that TB would react to a charset header *in the 
body*, but maybe that's a hack specially for charsets, in some code part 
I don't know, given that they are unfortunately sometimes only marked in 
content.)

I think it would most likely work easily if you inject HTML (read before 
you scream):
mailto:fred@example.com?html-body=Here's patch revision abc from repo 
def:<p><pre>Patch: file ....<br>+++ bla<br>line 3<br></pre>
(properly escaped, of course)
It should invoke the normal rich editor, with the patch properly marked 
as preformatted. Once you send it, it would send it as plaintext, 
depending on your prefs. During the formatting, it would see the 
preformat section and should send it out with the lineendings as marked.
I haven't tried the full chain, but it's something to play with.

Ben

Re: Thunderbird and patches (was Re: [PATCH v2] Enable setting attach as the default in .gitconfig for git-format-patch.)

[Jeremy White]

> 
> I don't know how you're injecting the email to Thunderbird. mailto:?

We have a utility, git-imap-send, that sends the email into the drafts
folder.

> 
> What you propose is a header, not a body.
> (I'm a bit irritated that TB would react to a charset header *in the 
> body*, but maybe that's a hack specially for charsets, in some code part 
> I don't know, given that they are unfortunately sometimes only marked in 
> content.)

Ah, rats.  I figured that picking charset out of the body might be
considered a bug; I was hoping it was a feature :-/.

> 
> I think it would most likely work easily if you inject HTML (read before 
> you scream):

/me carefully takes the nice coat with extra long sleeves out <grin>.

I've tried this, and *shudder*, it appears to work.

I'll cobble up an experimental patch to git-format-patch to see if
this is tractable.

Cheers,

Jeremy

Re: Thunderbird and patches (was Re: [PATCH v2] Enable setting attach as the default in .gitconfig for git-format-patch.)

[Michael J Gruber]

Jeremy White venit, vidit, dixit 09.02.2009 16:38:
...
> I've tried this, and *shudder*, it appears to work.
> 
> I'll cobble up an experimental patch to git-format-patch to see if
> this is tractable.

Please don't forget quoting of "<,>" as I did, see my other experimental
post where the s-o-b address got lost in translation (from HTML to
text). I don't remember what else you need to quote within <pre></pre>.

Michael

Re: Thunderbird and patches (was Re: [PATCH v2] Enable setting attach as the default in .gitconfig for git-format-patch.)

[Ben Bucksch]

On 09.02.2009 16:54, Michael J Gruber wrote:
> I don't remember what else you need to quote within<pre></pre>.
>    

Escaping:

With mailto:, you send HTML (SGML) in a URL.

So, you first have to quote using HTML rules:
<   -> &lt;
 >   -> &gt;
&   -> &amp;
"   -> &quot;

If that's not done, TB/Mozilla may or may not fix it up: e.g. if you 
have html tags in your source code, it would probably go wrong without 
quoting.

After that, given that you put it in a URL, you need to escape it using 
"URL component rules" (same as you escape any URL GET parameter), using 
the %charcode rule, e.g.
(space)  ->   %20
=   ->   %3D
&   ->   %26
#   ->   %23
(Firefox does the URL escaping automatically when putting it in the 
URLbar, and you can also try it in JS using encodeURIComponent(), e.g. 
by opening the Firefox Error Console and writing 
encodeURIComponent("foo=bla&bar=baz bal"); or starting the 
yourfirefoxdir/js runner.)

E.g. "<" in original turns into "mailto:?html-body=<pre>%26lt;<pre>"

Sorry that it's non-trivial (I also hate escaping).

Re: Thunderbird and patches (was Re: [PATCH v2] Enable setting attach as the default in .gitconfig for git-format-patch.)

[Jeremy White]

> So, you first have to quote using HTML rules:
> <   -> &lt;
>  >   -> &gt;
> &   -> &amp;
> "   -> &quot;

Thanks; that was helpful.

I've sent an experimental patch for further discussion (I even sent it
using my patch + Thunderbird, and now I'm carefully studying my navel
<grin>).

Cheers,

Jeremy

Re: Thunderbird and patches (was Re: [PATCH v2] Enable setting attach as the default in .gitconfig for git-format-patch.)

[Brandon Casey]

I have an issue with Thunderbird that I'd like to describe while we have
the developers ear.

I was sent a patch which had a sequence of control characters in it.

To save an emailed patch, I normally write click in the message body and
choose 'Save As...'.  Thunderbird populates the 'Name:' field for the
name of the saved file with a name based on the subject, which I like.

But, in this case, Thunderbird corrupted the original message and saved
something that was not equivalent to what was sent.  Naturally, the patch
could not be applied, and after investigating, it was determined that
Thunderbird was responsible.  If I instead choose View -> 'Message Source'
and then in the window that pops up choose File -> 'Save Page As', and then
give it a name, I do indeed get the original uncorrupted message, but it
is _not_ convenient.

This is Thunderbird v2.0.0.19.
Is this a bug? Or is there something I can set or disable so that Thunderbird
saves the original contents when right clicking in the message body and
selecting 'Save As...'?

I will follow up with an example patch which has the control characters in
it.

-brandon

Re: Thunderbird and patches (was Re: [PATCH v2] Enable setting attach as the default in .gitconfig for git-format-patch.)

[Ben Bucksch]

On 09.02.2009 19:54, Brandon Casey wrote:
> I will follow up with an example patch which has the control characters in
> it.
>    

I can only advise against sending patches in the bodies, sorry. Bodies 
are for human-language text. Attachments are for files like diffs, and 
are preserved. Attachments with "Content-Disposition: inline" are for 
attachments which are supposed to be read directly in the email reader, 
like is the case here.

I guess that other, console-based email software won't deal with inline 
attachments as nicely, but the major email clients do. Instead of trying 
to do something that's going to be fruitless - email bodies are never 
going to be character-to-character identical, because there are many 
demands on formatting (up to graphical smiles) and from many different 
languages (charsets, like seems to be the problem here) on it by users 
-, I think your better route for success would be to use inline 
attachments and fix the software which can't deal with *that* properly, 
including display and quoting.

Sorry to brush you off, but I this is a battle we can't win, either way. 
Too many demands from too many sides.

Ben

Re: Thunderbird and patches (was Re: [PATCH v2] Enable setting attach as the default in .gitconfig for git-format-patch.)

[Johannes Schindelin]

Hi,

On Mon, 9 Feb 2009, Ben Bucksch wrote:

> On 09.02.2009 19:54, Brandon Casey wrote:
> > I will follow up with an example patch which has the control 
> > characters in it.

You can use a mailer such as Alpine, which has no problems with patches 
like that whatsoever.

Especially the "Save" command will save the byte-identical body of the 
mail.

Ciao,
Dscho

Re: Thunderbird and patches (was Re: [PATCH v2] Enable setting attach as the default in .gitconfig for git-format-patch.)

[Ben Bucksch]

On 09.02.2009 20:14, Johannes Schindelin wrote:
> On 09.02.2009 19:54, Brandon Casey wrote:
>>> I will follow up with an example patch which has the control
>>> characters in it.
>>>        

> Especially the "Save" command will save the byte-identical body of the
> mail.
>    

I think Thunderbird will also save a byte-identical copy of the mail, if 
you use File | Save... and use ".eml" (for email = RFC822) file extension.

The dialog is sensitive to the file extension and determines the format 
based on that, but is unfortunately not communicative about it.

If you save as HTML (.html) or plaintext (.txt), it runs it through the 
MIME converters and reformats it for display / human reading.

Re: Thunderbird and patches (was Re: [PATCH v2] Enable setting attach as the default in .gitconfig for git-format-patch.)

[Brandon Casey]

Ben Bucksch wrote:
> On 09.02.2009 20:14, Johannes Schindelin wrote:
>> On 09.02.2009 19:54, Brandon Casey wrote:
>>>> I will follow up with an example patch which has the control
>>>> characters in it.
>>>>        
> 
>> Especially the "Save" command will save the byte-identical body of the
>> mail.
>>    
> 
> I think Thunderbird will also save a byte-identical copy of the mail, if
> you use File | Save... and use ".eml" (for email = RFC822) file extension.

Did you try it with the message I sent titled
'[PATCH] example patch corrupted by thunderbird'?

The body of the patch has 1 hunk which adds 6 lines.

When I save with Thunderbird, part of what was on line 5 is now
on another line and the control-M is missing.  At least that is
what is apparent to me.

> The dialog is sensitive to the file extension and determines the format
> based on that, but is unfortunately not communicative about it.

I did not modify the suggested file name.  The saved file has a '.eml'
extension.

> If you save as HTML (.html) or plaintext (.txt), it runs it through the
> MIME converters and reformats it for display / human reading.

Nope, '.eml' extension.

-brandon

Re: Thunderbird and patches (was Re: [PATCH v2] Enable setting attach as the default in .gitconfig for git-format-patch.)

[Ben Bucksch]

On 09.02.2009 20:30, Brandon Casey wrote:
> Did you try it with the message I sent titled
> '[PATCH] example patch corrupted by thunderbird'?

I tried now, and none of the editors/viewers I tried are displaying 
anything that would come close to readable to me, even if you count 
clearly marked hex character codes as readable. I tried less, e3 and 
kwrite. Therefore, a) I can't verify whether the result is correct or 
not b) I declare this an edge case.

> When I save with Thunderbird, part of what was on line 5 is now
> on another line and the control-M is missing.
> Nope, '.eml' extension.
>    

That would be a bug. If you save as .eml, it should save exactly what's 
in your IMAP mailbox or what View as source | File | Save... saves. If 
it doesn't do that, it's a bug.

The View Source workaround may be inconvenient, but is a workaround for 
such a strong edgecase, until this bug is fixed. Don't hope for it, 
though, because TB is working on completely different things, like a 
message database.

You're welcome to file a bug, but please without political statements or 
broad generic demands. TB is geared towards comfortable writing and 
reading of human language text.

---

Apart from that, I can only recommend that you re-consider sending 
patches as inline attachments (Content-Disposition: inline, which is an 
official Internet Standard since many years), which is IMHO correctly 
reflecting reality, and fixing the software which can't deal with 
*that*, including inline display and quoting.

Ben

Re: Thunderbird and patches (was Re: [PATCH v2] Enable setting attach as the default in .gitconfig for git-format-patch.)

[Ben Bucksch]

On 09.02.2009 20:51, Ben Bucksch wrote:
> On 09.02.2009 20:30, Brandon Casey wrote:
>> Did you try it with the message I sent titled
>> '[PATCH] example patch corrupted by thunderbird'?
>
> I tried now, and none of the editors/viewers I tried are displaying 
> anything that would come close to readable to me, even if you count 
> clearly marked hex character codes as readable. I tried less, e3 and 
> kwrite. Therefore, a) I can't verify whether the result is correct or not

I now compared the result of File | Save as.... (main menu, not context 
menu) | "1.eml" with the email on the cyrus server, and they are 
identical (diff and md5sum). So, TB *does* save it correctly, byte-for-byte.

Re: Thunderbird and patches (was Re: [PATCH v2] Enable setting attach as the default in .gitconfig for git-format-patch.)

[Brandon Casey]

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

Ben Bucksch wrote:
> On 09.02.2009 20:51, Ben Bucksch wrote:
>> On 09.02.2009 20:30, Brandon Casey wrote:
>>> Did you try it with the message I sent titled
>>> '[PATCH] example patch corrupted by thunderbird'?
>>
>> I tried now, and none of the editors/viewers I tried are displaying
>> anything that would come close to readable to me, even if you count
>> clearly marked hex character codes as readable. I tried less, e3 and
>> kwrite. Therefore, a) I can't verify whether the result is correct or not

You could look to see whether there are 6 lines in the hunk or 7.
There should only be 6.

  i.e. something like:

  @@ -0,0 +1,6 @@
  +T31,23
  +m4_location(_AC_LIST_MEMBER_IF)autoconf/fortran.m4:115
  +T17,203
  +m4_cr_not_Letters<sequence_of_control_characters>
  +<more_control_characters>
  +T15,855
  --

I have attached the original patch.  The headers will be different, and in the
attached patch they are only placeholders, but the content after the '---' should
be identical in all versions.

> I now compared the result of File | Save as.... (main menu, not context
> menu)

main menu or context menu both produce the same results for me.
Do they produce different results for you?

> | "1.eml" with the email on the cyrus server, and they are
> identical (diff and md5sum). So, TB *does* save it correctly,
> byte-for-byte.

Sorry, but I think you did your comparison wrong.  Possibly the tool
which extracted the email from the cyrus server performed the same
transformation that Thunderbird does.

You can also make a comparison with what is saved when you do
'View | Message Source' which pops up a new window, and then
File | Save Page As...

For me, they produce two different results. The one produced by
'View | Message Source ..etc' has a message body which is identical to
the one saved by pine, and to the original which is attached.

-brandon


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-autoconf.patch --]
[-- Type: text/x-patch; name="0001-autoconf.patch", Size: 760 bytes --]

From 9ad60e2f109029f8c96fcdc111625017cb8f3ef2 Mon Sep 17 00:00:00 2001
From: Brandon Casey <casey@nrlssc.navy.mil>
Date: Wed, 14 Jan 2009 07:24:52 -0600
Subject: [PATCH] example patch corrupted by thunderbird

This is an example patch which is corrupted when saved using Thunderbird
v2.0.0.19.

---
diff --git a/autoconf.m4f b/autoconf.m4f
new file mode 100644
index 0000000..73283b5
--- /dev/null
+++ b/autoconf.m4f
@@ -0,0 +1,6 @@
+T31,23
+m4_location(_AC_LIST_MEMBER_IF)autoconf/fortran.m4:115
+T17,203
+m4_cr_not_Letters\x01\x02\x03\x04\x05\x06\a\b	
+\v\f\r\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a^[\x1c\x1d\x1e\x1f !"#$%&'()*+,./0123456789:;<=>?@[\]^_`{|}~\x7f€‚ƒ„…†‡ˆ‰Š‹ŒŽ‘’“”•–—˜™š›œžŸ ¡¢£¤¥¦§¨©ª«¬­®¯°±²³´µ¶·¸¹º»¼½¾¿ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþÿ-
+T15,855
-- 
1.6.1.239.gcf3bf

Re: Thunderbird and patches (was Re: [PATCH v2] Enable setting attach as the default in .gitconfig for git-format-patch.)

[Brandon Casey]

Brandon Casey wrote:
> Ben Bucksch wrote:

>> | "1.eml" with the email on the cyrus server, and they are
>> identical (diff and md5sum). So, TB *does* save it correctly,
>> byte-for-byte.
> 
> Sorry, but I think you did your comparison wrong.

Or possibly (hopefully) there is something in my configuration that
is causing this, and it can be unset or set, whichever is the case.

Though my configuration is not much changed from the defaults.

-brandon

Re: Thunderbird and patches (was Re: [PATCH v2] Enable setting attach as the default in .gitconfig for git-format-patch.)

[Ben Bucksch]

On 09.02.2009 22:03, Brandon Casey wrote:
> > So, TB *does* save it correctly, byte-for-byte.
>
> Sorry, but I think you did your comparison wrong.  Possibly the tool
> which extracted the email from the cyrus server performed the same
> transformation that Thunderbird does.
>    

No. Cyrus stores each mail in its own file. All I did was:
TB | File | Save as.... | "1.eml"
scp root@<imap server>:/<mailbox store path>/<mail folder path>/749\. 2.eml
md5sum 1.eml 2.eml
b98d288357e384b8f58fe332ed65748b  1.eml
b98d288357e384b8f58fe332ed65748b  2.eml
(the md5sum will be different for you, as my mail contains the Received: 
headers from my server.)
Given that I don't think TB changes the email on the server, what TB 
saved is exactly what I received, verbatim, on the wire.

Re: Thunderbird and patches (was Re: [PATCH v2] Enable setting attach as the default in .gitconfig for git-format-patch.)

[Brandon Casey]

Ben Bucksch wrote:
> On 09.02.2009 22:03, Brandon Casey wrote:
>> > So, TB *does* save it correctly, byte-for-byte.
>>
>> Sorry, but I think you did your comparison wrong.  Possibly the tool
>> which extracted the email from the cyrus server performed the same
>> transformation that Thunderbird does.
>>    
> 
> No. Cyrus stores each mail in its own file. All I did was:
> TB | File | Save as.... | "1.eml"
> scp root@<imap server>:/<mailbox store path>/<mail folder path>/749\. 2.eml
> md5sum 1.eml 2.eml
> b98d288357e384b8f58fe332ed65748b  1.eml
> b98d288357e384b8f58fe332ed65748b  2.eml
> (the md5sum will be different for you, as my mail contains the Received:
> headers from my server.)
> Given that I don't think TB changes the email on the server, what TB
> saved is exactly what I received, verbatim, on the wire.

Any thoughts on why I get different results from

  TB | File | Save as... | 1.eml

and

  TB | View | Message Source ... File | Save Page as | 2.eml

-brandon

Re: Thunderbird and patches (was Re: [PATCH v2] Enable setting attach as the default in .gitconfig for git-format-patch.)

[Ben Bucksch]

On 09.02.2009 23:13, Brandon Casey wrote:
> Any thoughts on why I get different results from
>    TB | File | Save as... | 1.eml
>
> and
>
>    TB | View | Message Source ... File | Save Page as | 2.eml
>    
No. View source is expected to have pretty printing, at least in the 
browser (shared code), maybe that interferes.
(Confirmed - the latter gives me a different result, too.)
But if the latter doesn't work, just don't use it :).

Re: Thunderbird and patches (was Re: [PATCH v2] Enable setting attach as the default in .gitconfig for git-format-patch.)

[Brandon Casey]

Ben Bucksch wrote:
> On 09.02.2009 23:13, Brandon Casey wrote:
>> Any thoughts on why I get different results from
>>    TB | File | Save as... | 1.eml
>>
>> and
>>
>>    TB | View | Message Source ... File | Save Page as | 2.eml
>>    
> No. View source is expected to have pretty printing, at least in the
> browser (shared code), maybe that interferes.
> (Confirmed - the latter gives me a different result, too.)
> But if the latter doesn't work, just don't use it :).

But it's the latter one that gives me the *correct* results. :b

-brandon

Re: Thunderbird and patches (was Re: [PATCH v2] Enable setting attach as the default in .gitconfig for git-format-patch.)

[Ben Bucksch]

On 09.02.2009 23:28, Brandon Casey wrote:
> But it's the latter one that gives me the *correct* results. :b
>    
Oh. As I showed, File | Save As... in normal msg viewer works here.
When I save in View Source, the file is different, and diff -u shows 
every line different, and diff -uw shows no difference. Therefore, I 
think it's the line ending.

FWIW, I'm on Linux, in case TB adapts to the system line ending in one 
case and not in the other, which may explain the difference between what 
we see.

/me just realizes that he's talking with the military.

Re: Thunderbird and patches (was Re: [PATCH v2] Enable setting attach as the default in .gitconfig for git-format-patch.)

[Brandon Casey]

Ben Bucksch wrote:
> On 09.02.2009 23:28, Brandon Casey wrote:
>> But it's the latter one that gives me the *correct* results. :b
>>    
> Oh. As I showed, File | Save As... in normal msg viewer works here.
> When I save in View Source, the file is different, and diff -u shows
> every line different, and diff -uw shows no difference. Therefore, I
> think it's the line ending.

For me diff -u shows a removal of one line and an insertion of two lines
at the same location.  The ^M has been converted into a newline.

> FWIW, I'm on Linux, in case TB adapts to the system line ending in one
> case and not in the other, which may explain the difference between what
> we see.

Also using linux here.

Would Thunderbird possibly do a blind conversion of ^M to newline?

-brandon

Re: Thunderbird and patches (was Re: [PATCH v2] Enable setting attach as the default in .gitconfig for git-format-patch.)

[Brandon Casey]

Johannes Schindelin wrote:
> Hi,
> 
> On Mon, 9 Feb 2009, Ben Bucksch wrote:
> 
>> On 09.02.2009 19:54, Brandon Casey wrote:
>>> I will follow up with an example patch which has the control 
>>> characters in it.
> 
> You can use a mailer such as Alpine, which has no problems with patches 
> like that whatsoever.

Yes, that's my work-around.  Though it's pine, we're not modern enough to
have alpine.

-brandon

Re: Thunderbird and patches (was Re: [PATCH v2] Enable setting attach as the default in .gitconfig for git-format-patch.)

[Johannes Schindelin]

Hi,

On Mon, 9 Feb 2009, Brandon Casey wrote:

> Johannes Schindelin wrote:
> > Hi,
> > 
> > On Mon, 9 Feb 2009, Ben Bucksch wrote:
> > 
> >> On 09.02.2009 19:54, Brandon Casey wrote:
> >>> I will follow up with an example patch which has the control 
> >>> characters in it.
> > 
> > You can use a mailer such as Alpine, which has no problems with patches 
> > like that whatsoever.
> 
> Yes, that's my work-around.  Though it's pine, we're not modern enough to
> have alpine.

BTW it seems that a few people misunderstood my comments.

Just to clarify: I am happy if a lot of non-technical people use 
Thunderbird.  I mean, I am happy for them.

If it is too complicated for Thunderbird to accomodate the workflow 
required on our mailing list, however, I will have to recommend another 
tool to the people who want to contribute to Git.

I would not recommend emacs to a vim user, either.  Or vice versa.

In other words: use the right tool.  Or, as somebody put it at the 
GitTogether: to a hammer, everything looks like a nail.

Ciao,
Dscho

Re: Thunderbird and patches (was Re: [PATCH v2] Enable setting attach as the default in .gitconfig for git-format-patch.)

[Michael J Gruber]

Johannes Schindelin venit, vidit, dixit 09.02.2009 21:09:
> Hi,
> 
> On Mon, 9 Feb 2009, Brandon Casey wrote:
> 
>> Johannes Schindelin wrote:
>>> Hi,
>>>
>>> On Mon, 9 Feb 2009, Ben Bucksch wrote:
>>>
>>>> On 09.02.2009 19:54, Brandon Casey wrote:
>>>>> I will follow up with an example patch which has the control 
>>>>> characters in it.
>>> You can use a mailer such as Alpine, which has no problems with patches 
>>> like that whatsoever.
>> Yes, that's my work-around.  Though it's pine, we're not modern enough to
>> have alpine.
> 
> BTW it seems that a few people misunderstood my comments.
> 
> Just to clarify: I am happy if a lot of non-technical people use 
> Thunderbird.  I mean, I am happy for them.
> 
> If it is too complicated for Thunderbird to accomodate the workflow 
> required on our mailing list, however, I will have to recommend another 
> tool to the people who want to contribute to Git.
> 
> I would not recommend emacs to a vim user, either.  Or vice versa.
> 
> In other words: use the right tool.  Or, as somebody put it at the 
> GitTogether: to a hammer, everything looks like a nail.

It just seems that the workflow "required" here on the git list is the
way it is because it caters for differently abled MUAs which can't
handle certain standards (inline disposition) efficiently. Mutt
obviously can, so it's not a matter of John Doe's MUA versus geeky MUAs.

Thunderbird is differently abled also, of course, by way of definition,
but also because there's no easy way to directly feed an e-mail (or a
bunch of them) into a shell command such as git-am, e.g. So it certainly
won't be a maintainer's MUA.

When I joined the git community I adjusted my personal workflow, which
required posting by e-mail rather than nntp (gmane) and avoiding the
natural way (attachments) for patch submission, even avoiding my main
standards compliant MUA; rather than arguing for a change to the better,
more standard conforming approach, and telling people here to use MUAs
which can deal with it, i.e.: use the right tool. I know things won't
change here, just as certain people won't either.

But please don't take the status quo here as something setting global
standards. And don't take my conformance with the requirements here as
approval.

Ben has shown remarkable willingness in helping get around the
limitations of sending out patch files plainly included in e-mails, when
using TB, so let's please focus on making that successful and keep the
flame(r)s off this thread. Everyone will benefit, because it will keep
the number of misformed patches (i.e. not matching local requirements) low.

Michael

Re: Thunderbird and patches

[Miles Bader]

Michael J Gruber <git@drmicha.warpmail.net> writes:
>> In other words: use the right tool.  Or, as somebody put it at the 
>> GitTogether: to a hammer, everything looks like a nail.
>
> It just seems that the workflow "required" here on the git list is the
> way it is because it caters for differently abled MUAs which can't
> handle certain standards (inline disposition) efficiently.  Mutt
> obviously can, so it's not a matter of John Doe's MUA versus geeky
> MUAs.

So, since you decry flames later in your message, why did you feel it
necessary to throw in this rather creaky bit of flamebait?

[The issue is apparently MUAs which munge messages when not wanted; that
says _nothing_ about what non-munging MUAs can or can not "handle".]

-Miles

-- 
Mayonnaise, n. One of the sauces that serve the French in place of a state
religion.

Re: Thunderbird and patches

[Michael J Gruber]

Miles Bader venit, vidit, dixit 12.02.2009 05:37:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>>> In other words: use the right tool.  Or, as somebody put it at the 
>>> GitTogether: to a hammer, everything looks like a nail.
>> It just seems that the workflow "required" here on the git list is the
>> way it is because it caters for differently abled MUAs which can't
>> handle certain standards (inline disposition) efficiently.  Mutt
>> obviously can, so it's not a matter of John Doe's MUA versus geeky
>> MUAs.
> 
> So, since you decry flames later in your message, why did you feel it
> necessary to throw in this rather creaky bit of flamebait?
> 
> [The issue is apparently MUAs which munge messages when not wanted; that
> says _nothing_ about what non-munging MUAs can or can not "handle".]

I think we all (all who participated so far) agreed that the MUAs we
talked about have different abilities, thus are differently abled (pun
intended).

By now, all sides have worked constructively together to make things
work for all MUAs and all users. Dscho even cooked up a Thunderbird
extension, Ben provided input for git-imap-send.

If you want to fuel the flames you're too late. If you want to
contribute you're welcome to.

Michael

Re: Thunderbird and patches (was Re: [PATCH v2] Enable setting attach as the default in .gitconfig for git-format-patch.)

[Brandon Casey]

Ben Bucksch wrote:
> On 09.02.2009 19:54, Brandon Casey wrote:
>> I will follow up with an example patch which has the control
>> characters in
>> it.

<snip>
> email bodies are never
> going to be character-to-character identical, because there are many
> demands on formatting (up to graphical smiles) and from many different
> languages (charsets, like seems to be the problem here) on it by users
> -,

I can understand that the display of the message would not be optimal, and
could be different from what the sender intended, but I expect that the
saved version would be identical to the original.

In the 'graphical smilie' example, you still save colon-close-parenthesis
in the file don't you? and not the little smiley face bitmap?

> I think your better route for success would be to use inline
> attachments and fix the software which can't deal with *that* properly,
> including display and quoting.

It's not the display part that causes a problem for me, it's the "saving" part.
The displayed gobledygook is fine.  The saved gobledygook is not.

Why doesn't Thunderbird just save out the raw message?

-brandon

[PATCH] example patch corrupted by thunderbird

[Brandon Casey]

This is an example patch which is corrupted when saved using Thunderbird
v2.0.0.19.

---
diff --git a/autoconf.m4f b/autoconf.m4f
new file mode 100644
index 0000000..73283b5
--- /dev/null
+++ b/autoconf.m4f
@@ -0,0 +1,6 @@
+T31,23
+m4_location(_AC_LIST_MEMBER_IF)autoconf/fortran.m4:115
+T17,203
+m4_cr_not_Letters\x01\x02\x03\x04\x05\x06\a\b	
+\v\f\r\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a^[\x1c\x1d\x1e\x1f !"#$%&'()*+,./0123456789:;<=>?@[\]^_`{|}~\x7f€‚ƒ„…†‡ˆ‰Š‹ŒŽ‘’“”•–—˜™š›œžŸ ¡¢£¤¥¦§¨©ª«¬­®¯°±²³´µ¶·¸¹º»¼½¾¿ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþÿ-
+T15,855
-- 
1.6.1.239.gcf3bf

Re: Thunderbird and patches (was Re: [PATCH v2] Enable setting attach as the default in .gitconfig for git-format-patch.)

[Michael J Gruber]

Currently, git-notes barks when asked to show an empty (i.e.
non-existing) note. Change this to explicitly say there is none.

Signed-off-by: Michael J Gruber 
---
 git-notes.sh     |    2 ++
 t/t3301-notes.sh |    2 +-
 2 files changed, 3 insertions(+), 1 deletions(-)


Ben Bucksch venit, vidit, dixit 09.02.2009 15:18:
> On 09.02.2009 14:52, Jeremy White wrote:
>   
>> I discovered that if I just injected charset=iso-2022-jp, format=flowed
>> would stay off!<grin>
>>    
>>     
> (This was a hack, caused by the different use of spaces in Japanese / 
> CJK, which means a different kind of "flow".)
>
>   
>> Ben, along those lines, we do have the ability to control the entire 
>> body of a possible patch before Thunderbird sees it. Would it be 
>> possible, or reasonable, for Thunderbird to look for and preserve a 
>> 'format=fixed' setting inside a body that we generated?
>>     
>
> I don't know how you're injecting the email to Thunderbird. mailto:?
>
>   
git comes with a contributed hint which suggests using the external
editor extension. There's also a script which shuffles things around and
into place for TB to accept the header lines. Alternatively, call vim as
the external editor....
> What you propose is a header, not a body.
> (I'm a bit irritated that TB would react to a charset header *in the 
> body*, but maybe that's a hack specially for charsets, in some code part 
> I don't know, given that they are unfortunately sometimes only marked in 
> content.)
>
> I think it would most likely work easily if you inject HTML (read before 
> you scream):
> mailto:fred@example.com?html-body=Here's patch revision abc from repo 
> def:<p><pre>Patch: file ....<br>+++ bla<br>line 3<br></pre>
> (properly escaped, of course)
> It should invoke the normal rich editor, with the patch properly marked 
> as preformatted. Once you send it, it would send it as plaintext, 
> depending on your prefs. During the formatting, it would see the 
> preformat section and should send it out with the lineendings as marked.
> I haven't tried the full chain, but it's something to play with.
>
> Ben
>   
OK, for the first time in I don't know how many months/years I fire up
the HTML composer in TB. Please don't tell anyone from my git
acquaintances, they'll give me an even tougher rub than usual on my next
patch submission...

I'll try and inline with <pre> a patch I sent resently... Now this looks
interesting after coming back from external editor (gvim -f). Kinda
cute. We'll see what TB makes out of it (hopefully confirming Ben's
pre-theory, uhm).

Cheers,
Michael


diff --git a/git-notes.sh b/git-notes.sh
index bfdbaa8..9cbad02 100755
--- a/git-notes.sh
+++ b/git-notes.sh
@@ -58,6 +58,8 @@ edit)
 		"$GIT_NOTES_REF" $NEW_HEAD $CURRENT_HEAD
 ;;
 show)
+	git rev-parse -q --verify "$GIT_NOTES_REF":$COMMIT > /dev/null ||
+		die "No note for commit $COMMIT."
 	git show "$GIT_NOTES_REF":$COMMIT
 ;;
 *)
diff --git a/t/t3301-notes.sh b/t/t3301-notes.sh
index 7ef1c29..ff4ea05 100755
--- a/t/t3301-notes.sh
+++ b/t/t3301-notes.sh
@@ -36,7 +36,7 @@ test_expect_success 'need valid notes ref' '
 '
 
 # 1 indicates caught gracefully by die, 128 means git-show barked
-test_expect_failure 'handle empty notes gracefully' '
+test_expect_success 'handle empty notes gracefully' '
 	git notes show ; test 1 = $?
 '
 
-- 
1.6.1.2.253.ga34a

Re: Thunderbird and patches

[Ben Bucksch]

Summary of proposed/possible solutions:

    * TB | normal msg viewer | main menu | File | Save As | File |
      "foo.eml" saves the verbatim, on the wire RFC822 mail
      (that may include quoted printable etc., though, so verbatim may
      not actually be what you want)
    * You can turn off format=flowed during sending, if it disturbs you:
         1. Prefs | Advanced | General | Config Editor...
         2. "mailnews.send_plaintext_flowed" = false
    * Jeremy White has a patch for git-imap-send to work around TB's
      body reformatting, by inserting a preformatted (<pre>) section.

(Other solutions, involves other software:)

    * I strong suggest to send inline attachments (Content-Disposition:
      inline, RFC 2183 [1], Internet Standard), because patches are
      arguably files, and the body is for human language text.
      Therefore, it's an attachment that you want to see inline,
      therefore inline attachment is the IMHO correct solution.
      If some mailers cannot handle this comfortably (display inline,
      quote), maybe you can also advocate having *them* fixed.


[1] <http://www.apps.ietf.org/rfc/rfc2183.html>

Re: Thunderbird and patches

[Jeremy White]

>     * I strong suggest to send inline attachments (Content-Disposition:
>       inline, RFC 2183 [1], Internet Standard), because patches are
>       arguably files, and the body is for human language text.
>       Therefore, it's an attachment that you want to see inline,
>       therefore inline attachment is the IMHO correct solution.
>       If some mailers cannot handle this comfortably (display inline,
>       quote), maybe you can also advocate having *them* fixed.


So, I start an email in Thunderbird, and attach test.patch to it.
I don't see a way to control things, but it seems to go across as
a multipart; the patch is disposition inline, type of text/x-patch.  I
rename it to test.txt, and now it goes across as a multipart, both parts
are text/plain.

I get the patch, and I can see it.  Very nice.

I click 'Reply', and I get no quoting in Thunderbird.  (A quick check
with mutt *does* show quoting.)

I'm hazarding a guess that is not the expected result; am I doing it wrong?

Cheers,

Jeremy

Re: Thunderbird and patches

[Ben Bucksch]

On 09.02.2009 23:55, Jeremy White wrote:
> [inline attachments]
>
> I get the patch, and I can see it. Very nice.
> I click 'Reply', and I get no quoting in Thunderbird.  (A quick check
> with mutt *does* show quoting.)
>    
Yeah. As mentioned before, you have to press Ctrl-A first (Select All, 
in combination with the new selective quoting feature in TB 3).
You can also select only a smaller portion of the patch, then only that 
will be quoted.
Last but not least, you can quote via copy & paste: select in view, then 
menu | Edit | Paste as quotation.

HTH,

Ben

Re: [PATCH v2] Enable setting attach as the default in .gitconfig for git-format-patch.

[Junio C Hamano]

Jeremy White <jwhite@codeweavers.com> writes:

> diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
> index 11a7d77..2e8e94e 100644
> --- a/Documentation/git-format-patch.txt
> +++ b/Documentation/git-format-patch.txt
> @@ -174,7 +174,8 @@ CONFIGURATION
>  -------------
>  You can specify extra mail header lines to be added to each message
>  in the repository configuration, new defaults for the subject prefix
> -and file suffix, and number patches when outputting more than one.
> +and file suffix, control attachements, and number patches when outputting
> +more than one.
>  
>  ------------
>  [format]
> @@ -183,6 +184,7 @@ and file suffix, and number patches when outputting more than one.
>  	suffix = .txt
>  	numbered = auto
>  	cc = <email>
> +	attach [ = mime-boundary-string ]
>  ------------

Once you added this configuration, if you ever wanted to defeat it for a
single invocation, how would you do so?  Edit the configuration file
again?

Not that I am objecting to the patch, as I am unlikely to have such a
configuration, but are there people who need to send attachment sometimes
but not other times?  They can say --attach from the command line without
adding the configuraiton if they send their patch non-attached more often
than as an attachment, but if they most of the time need to attach but
sometimes need to send in-line, they do not have an easy way to do so.

[PATCH v2] Enable setting attach as the default in .gitconfig for git-format-patch.

[Jeremy White]

Signed-off-by: Jeremy White <jwhite@codeweavers.com>
---

This v2 patch reflects a concern from Junio that you could
not temporarily override the configuration setting.


 Documentation/git-format-patch.txt |   11 +++++++++--
 builtin-log.c                      |   19 +++++++++++++++++++
 2 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index 11a7d77..f89f73c 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -10,7 +10,8 @@ SYNOPSIS
 --------
 [verse]
 'git format-patch' [-k] [-o <dir> | --stdout] [--thread]
-		   [--attach[=<boundary>] | --inline[=<boundary>]]
+		   [--attach[=<boundary>] | --inline[=<boundary>] |
+		     [--noattach]]
 		   [-s | --signoff] [<common diff options>]
 		   [-n | --numbered | -N | --no-numbered]
 		   [--start-number <n>] [--numbered-files]
@@ -117,6 +118,10 @@ include::diff-options.txt[]
 	which is the commit message and the patch itself in the
 	second part, with "Content-Disposition: attachment".
 
+--noattach::
+	Disable the creation of an attachment, overriding the
+	configuration setting.
+
 --inline[=<boundary>]::
 	Create multipart/mixed attachment, the first part of
 	which is the commit message and the patch itself in the
@@ -174,7 +179,8 @@ CONFIGURATION
 -------------
 You can specify extra mail header lines to be added to each message
 in the repository configuration, new defaults for the subject prefix
-and file suffix, and number patches when outputting more than one.
+and file suffix, control attachements, and number patches when outputting
+more than one.
 
 ------------
 [format]
@@ -183,6 +189,7 @@ and file suffix, and number patches when outputting more than one.
 	suffix = .txt
 	numbered = auto
 	cc = <email>
+	attach [ = mime-boundary-string ]
 ------------
 
 
diff --git a/builtin-log.c b/builtin-log.c
index 2ae39af..991543a 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -428,6 +428,8 @@ static const char *fmt_patch_suffix = ".patch";
 static int numbered = 0;
 static int auto_number = 1;
 
+static char *default_attach = NULL;
+
 static char **extra_hdr;
 static int extra_hdr_nr;
 static int extra_hdr_alloc;
@@ -488,6 +490,14 @@ static int git_format_config(const char *var, const char *value, void *cb)
 		auto_number = auto_number && numbered;
 		return 0;
 	}
+	if (!strcmp(var, "format.attach")) {
+		if (value && *value)
+			default_attach = xstrdup(value);
+		else
+			default_attach = xstrdup(git_version_string);
+		return 0;
+	}
+
 
 	return git_log_config(var, value, cb);
 }
@@ -787,6 +797,11 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
 
 	rev.subject_prefix = fmt_patch_subject_prefix;
 
+	if (default_attach) {
+		rev.mime_boundary = default_attach;
+		rev.no_inline = 1;
+	}
+
 	/*
 	 * Parse the arguments before setup_revisions(), or something
 	 * like "git format-patch -o a123 HEAD^.." may fail; a123 is
@@ -849,6 +864,10 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
 			rev.mime_boundary = argv[i] + 9;
 			rev.no_inline = 1;
 		}
+		else if (!strcmp(argv[i], "--noattach")) {
+			rev.mime_boundary = NULL;
+			rev.no_inline = 0;
+		}
 		else if (!strcmp(argv[i], "--inline")) {
 			rev.mime_boundary = git_version_string;
 			rev.no_inline = 0;
-- 
1.6.2.rc0.57.g4ab7.dirty

Re: [PATCH v2] Enable setting attach as the default in .gitconfig for git-format-patch.

[Junio C Hamano]

Jeremy White <jwhite@codeweavers.com> writes:

> diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
> index 11a7d77..f89f73c 100644
> --- a/Documentation/git-format-patch.txt
> +++ b/Documentation/git-format-patch.txt
> @@ -10,7 +10,8 @@ SYNOPSIS
>  --------
>  [verse]
>  'git format-patch' [-k] [-o <dir> | --stdout] [--thread]
> -		   [--attach[=<boundary>] | --inline[=<boundary>]]
> +		   [--attach[=<boundary>] | --inline[=<boundary>] |
> +		     [--noattach]]

Hmph, don't we usually do this with --no-attach?  Especially when
format-patch starts using parse_options, I suspect that would be how the
API gives negated options natively.

If there are no other issues people find in this patch, I'll amend it to
use dash between no and attach and apply (hence no need to resend).

Thanks.