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

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?=

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

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(-)

Jeff King <peff@peff.net> writes:

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().

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

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