BUG: "git checkout" displays Q-escaped commit titles

BUG: "git checkout" displays Q-escaped commit titles

[Teemu Likonen]

When commit message's first line (i.e. the title) contains non-Ascii
characters "git checkout <commit>" displays this title in Q-escaped form
which looks something like this: =?utf-8?q?=C3=84=C3=A4kk=C3=B6si=C3=A4?=

Steps to reproduce:

$ mkdir repo
$ cd repo
$ git init
$ echo stuff >file
$ git add file
$ git commit -m "Ääkkösiä"
$ git checkout $(git rev-list -1 HEAD)
Note: moving to "dc968d26f2fb74a6991c03798ee1d7aab458548a" which isn't a local branch
If you want to create a new branch from this checkout, you may do so
(now or later) by using -b with the checkout command again. Example:
  git checkout -b <new_branch_name>
HEAD is now at dc968d2... =?utf-8?q?=C3=84=C3=A4kk=C3=B6si=C3=A4?=

Re: BUG: "git checkout" displays Q-escaped commit titles

[Jeff King]

On Fri, May 02, 2008 at 04:39:03PM +0300, Teemu Likonen wrote:

> When commit message's first line (i.e. the title) contains non-Ascii
> characters "git checkout <commit>" displays this title in Q-escaped form
> which looks something like this: =?utf-8?q?=C3=84=C3=A4kk=C3=B6si=C3=A4?=

Definitely a bug. This patch fixes it, but I'm not sure it's the best
solution. It seems like pp_title_line should perhaps just be checking
for fmt == CMIT_FMT_EMAIL, but I'm not sure if that would break anything
else, and I don't have time to investigate further right now.

-- >8 --
checkout: don't rfc2047-encode oneline on detached HEAD

When calling pretty_print_commit, there is an implicit
assumption that passing in a non-NULL "subject" variable
for oneline or email formats means that the output is part
of a subject and therefore "subject" to rfc2047 encoding.
This is not the desired effect when reporting the movement
of detached HEAD.
---
 builtin-checkout.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/builtin-checkout.c b/builtin-checkout.c
index 14b2fe7..10ec137 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -142,7 +142,7 @@ static void describe_detached_head(char *msg, struct commit *commit)
 	struct strbuf sb;
 	strbuf_init(&sb, 0);
 	parse_commit(commit);
-	pretty_print_commit(CMIT_FMT_ONELINE, commit, &sb, 0, "", "", 0, 0);
+	pretty_print_commit(CMIT_FMT_ONELINE, commit, &sb, 0, NULL, NULL, 0, 0);
 	fprintf(stderr, "%s %s... %s\n", msg,
 		find_unique_abbrev(commit->object.sha1, DEFAULT_ABBREV), sb.buf);
 	strbuf_release(&sb);
-- 
1.5.5.1.221.ga481

Re: BUG: "git checkout" displays Q-escaped commit titles

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> .... It seems like pp_title_line should perhaps just be checking
> for fmt == CMIT_FMT_EMAIL, but I'm not sure if that would break anything
> else,...

Yeah, your patch obviously would fix the caller, as subject and
after_subject should not be given unless you are doing FMT_EMAIL.  But I
also think we should not even look at subject and after_subject unless fmt
is CMIT_FMT_EMAIL inside pp_title_line().

Re: BUG: "git checkout" displays Q-escaped commit titles

[Jeff King]

On Sat, May 03, 2008 at 06:54:10PM -0700, Junio C Hamano wrote:

> > .... It seems like pp_title_line should perhaps just be checking
> > for fmt == CMIT_FMT_EMAIL, but I'm not sure if that would break anything
> > else,...
> 
> Yeah, your patch obviously would fix the caller, as subject and
> after_subject should not be given unless you are doing FMT_EMAIL.  But I
> also think we should not even look at subject and after_subject unless fmt
> is CMIT_FMT_EMAIL inside pp_title_line().

It took a look, and that feels a little wrong, too; we end up with a
function that ignores half of its parameters based on the value of one
of the other parameters, which makes me feel that it really should be
two separate functions.

So maybe there is some heavier refactoring to be done there. In general,
I think pretty_print has gotten a bit messy because of the increase in
the number of formats.  We might do better to turn it "inside out":
rather than going sequentially through and switching each stage on the
format type, make a set of good utility functions and have each format
type implemented as a function that builds out of the utility
primitives.

I also think we can turn several of the formats into --pretty=format:
aliases, which should make the code a lot simpler.  I had also wanted to
add a few features (one of them was giving pretty printing more context
of the tree walk, so you could do things like --pretty=format:'Patch
X/Y: %s' where X and Y would be substitutions for "current number in
walk" and "total number in walk."

I can try to take a look at that sometime in the next week or so, though
I expect it is major enough surgery to be for the next release cycle.

-Peff