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@xxxxxxxxxxx?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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
