login
Search
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(-)
=46or a minor style issue, see my reply to your original patch. Also, please read Documentation/SubmittingPatches. Particularly, the third= =20 point under the "Patch" heading on the first page. Also, since you appear = to=20 sympathize with Thunderbird users you might want to read the "Thunderbird"= =20 section, and either improve it or petition the developers to make the=20 application more amenable to users needs in this case. =2D-=20 Boyd Stephen Smith Jr. ,=3D ,-_-. =3D. bss@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/
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 --
Hi, 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 --
...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 <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 --
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 Yup, I think that's the best way - git is using email only as protocol, I don't think it's a matter of clue, it's a matter of background and attitude. Ben --
Hi, ... which is a moot point, as the responder has to do extra work to quote Aha. And putting extra comments in (manually) does not count. 'cause I 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 --
There is this useful thingy called "vim" which lets you edit the 00* 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 --
=46or the record, KMail does f=3Df by default, too. And I think any client= that=20 doesn't do format=3Dflowed by default it probably doing a disservice to it'= s=20 users. Luckily, in KMail it is easy to turn off for a particular message w= ith=20 "Options -> Word Wrap" in the composer window. I think you can turn it off= =20 globally, but patches aren't a big enough part of my workflow that I've=20 investigated it too much. =2D-=20 Boyd Stephen Smith Jr. ,=3D ,-_-. =3D. bss@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/
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 Please be sure to also cite the pref change I mentioned above as alternative. 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 --
Hi, 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 --
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 --
(This was a hack, caused by the different use of spaces in Japanese / 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 --
We have a utility, git-imap-send, that sends the email into the drafts Ah, rats. I figured that picking charset out of the body might be /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 --
Jeremy White venit, vidit, dixit 09.02.2009 16:38: 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 --
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). --
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 --
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 --
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 --
Hi, 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 --
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. --
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 I did not modify the suggested file name. The saved file has a '.eml' Nope, '.eml' extension. -brandon --
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 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 --
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. --
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 main menu or context menu both produce the same results for me. 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
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 --
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 --
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 --
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. --
For me diff -u shows a removal of one line and an insertion of two lines Also using linux here. Would Thunderbird possibly do a blind conversion of ^M to newline? -brandon --
Yes, that's my work-around. Though it's pine, we're not modern enough to have alpine. -brandon --
Hi, 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 --
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 --
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. --
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 --
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 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 --
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
+
!"#$%&'()*+,./0123456789:;<=>?@[\]^_`{|}~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(-) 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 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 --
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>
--
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 --
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 --
